Hay una escena que se repite. El empresario o ejecutivo necesita saber cuándo va a estar listo algo. Le pregunta al equipo de tech. El equipo da una fecha. Todos se van conformes de la reunión.

Pero, esa fecha muchas veces no significa nada.

No porque el equipo mienta. No porque el ejecutivo esté haciendo algo mal. Sino porque esa conversación está construida sobre un malentendido de base: que acordar una fecha es lo mismo que controlar un proyecto.
.

Cuando alguien de negocio le pide una fecha a un equipo de desarrollo, lo que en realidad está buscando es certeza. Quiere saber que el proyecto avanza y que puede comprometerse con alguien más. Es completamente razonable.

El problema es que una fecha sin contexto no da certeza. Da la ilusión de certeza. Y esa ilusión puede ser más cara que la incertidumbre real, porque hace que todos dejen de hacerse las preguntas que importan como: ¿Qué está construyendo exactamente el equipo? ¿Qué tan claros son los requerimientos? ¿Hubo cambios desde que se fijó la fecha? ¿El equipo tiene el ancho de banda real para cumplirla?

Cuando la fecha existe, esas preguntas se duermen. Y se despiertan cuando el proyecto falla.

La mayoría de inconvenientes en los proyectos tecnológicos no ocurren durante el desarrollo, sino en cómo se define lo que hay que construir.

Los requerimientos vagos son la causa silenciosa de la mayor parte de los atrasos y los resultados de mala calidad. Cuando no está claro qué se quiere, el equipo toma decisiones por su cuenta y asume cosas. Y cuando el resultado aparece, no es lo que se esperaba. Entonces hay que cambiar. Y cambiar a mitad de camino es costoso, no solo en tiempo sino en motivación y en calidad del producto final.

A esto se suma otro problema frecuente, los requerimientos que estaban claros al principio cambian sobre la marcha. Aparece una nueva necesidad, cambia el contexto del negocio, alguien tiene una idea mejor. Los cambios en sí no son el problema, el problema es cuando se hacen sin entender el impacto en lo que ya estaba en marcha. Cada cambio sin acuerdo explícito es una deuda que se cobra después.

Otro patrón habitual es la presión para que algo esté lo antes posible. En los negocios, el tiempo importa. Pero hay una trampa en esa lógica aplicada a proyectos tecnológicos.

Cuando se presiona por una fecha más cercana de lo que el equipo considera razonable, el equipo tiene que elegir. Y casi siempre elige entregar algo a tiempo antes que entregar algo bien. Porque eso es lo que se está midiendo.

El resultado suele caer en alguno de estos tres escenarios. Se llega a tiempo, pero con algo que no funciona como se esperaba o que va a generar problemas más adelante. Se llega tarde con algo que sí funciona, pero que ya perdió parte de su valor porque el contexto cambió. O el proyecto queda archivado.

En los tres casos, la responsabilidad no es solo del equipo de tech. También es de quien fijó la fecha sin consultar de verdad cuánto tiempo requería lo que se pedía.

La relación entre negocio y tecnología no es una relación de cliente y proveedor. Es un vínculo de trabajo conjunto, y como todo vínculo, funciona cuando hay comunicación real de los dos lados.

Parte de esa comunicación es el manejo de expectativas, y es responsabilidad de ambos. No alcanza con dar una fecha y desaparecer hasta que llegue. El equipo tiene que anticipar, avisar cuando algo se complica, proponer alternativas antes de que el problema sea irreversible. Y el ejecutivo tiene que crear las condiciones para que eso pase, que levantar la mano no se viva como un fracaso, sino como parte del trabajo bien hecho.

Si el empresario exige una fecha sin preguntar cuánto puede llevar el trabajo, está tomando una decisión con información incompleta. Pero si el equipo de tech acepta una fecha que sabe que es irreal y no lo dice, también está fallando. Levantar la mano a tiempo, ser claro sobre las implicancias de un pedido y proponer alternativas, es parte del trabajo, no una insubordinación.

Los proyectos que funcionan bien casi siempre lo que tienen es conversación real antes de comprometerse con algo. El equipo entiende qué necesita el negocio y por qué. El negocio entiende, al menos a grandes rasgos, qué implica lo que está pidiendo. Y cuando algo cambia, se habla antes de que el problema sea grande.

No hace falta entender de código para tener control real sobre un proyecto tecnológico. Hace falta hacer las preguntas correctas y sostener el diálogo en el tiempo.

El equipo puede explicar en lenguaje simple qué está construyendo y para qué. Cuando hay un problema lo comunican antes de que se convierta en una crisis. Los cambios de requerimiento se discuten, no se absorben en silencio. Las fechas vienen acompañadas de supuestos claros, no de optimismo.

El control real no viene de tener una fecha en el calendario. Viene de entender qué se está construyendo, con qué claridad, con qué recursos y con qué mecanismos para ajustar cuando algo cambia. La conversación que vale la pena tener no es «¿para cuándo?», sino «¿qué necesitamos acordar para que esto llegue bien?»