El error no estaba en el diseño, estaba en la pregunta

Cuando un proyecto se atrasa, se complica o se sale de presupuesto, casi siempre se revisa lo mismo: la ejecución. Se pregunta si el equipo era el correcto, si el cronograma era realista, si faltó comunicación. Rara vez alguien se pregunta si el problema que se estaba resolviendo era, desde el principio, el problema correcto.

Esa pregunta suele evitarse porque cuestionar el requerimiento se siente como un riesgo. El cliente ya lo definió, el contrato ya lo especifica, el reloj ya está corriendo. Es más cómodo ejecutar lo pedido que detenerse a verificar si lo pedido resuelve lo que realmente hace falta. Y sin embargo, ahí es donde se esconde una parte enorme del retrabajo que después se le atribuye a la ejecución.

Un ejemplo concreto ayuda a ver dónde exactamente se esconde ese retrabajo. Dos equipos reciben el mismo encargo: "el sistema tarda demasiado en responder, hay que reducir el tiempo de espera". Es un requerimiento claro, medible, con un número objetivo. Nada en su formulación sugiere que haya algo que cuestionar.

Por qué un requerimiento mal planteado se ve igual que uno bien ejecutado

Un requerimiento mal planteado no se anuncia como tal. Llega con la misma seguridad, el mismo nivel de detalle y el mismo tono de urgencia que uno bien pensado. La diferencia no está en cómo se presenta, está en si describe la causa real del problema o solo su síntoma más visible.

Esto es lo que lo vuelve peligroso: un equipo puede ejecutar perfectamente un requerimiento mal planteado, y el resultado no se sentirá como un fracaso de ejecución. Se sentirá como una solución completa y funcional, a un problema que no era el que había que resolver.

El primer equipo del ejemplo toma el requerimiento tal como llegó. Reducir el tiempo de espera significa optimizar el código, así que eso hacen: perfilan el sistema, encuentran cuellos de botella, los resuelven. Dos semanas después, el tiempo de respuesta bajó de forma medible. El encargo, tal como se planteó, quedó cumplido.

Por qué cuesta tanto hacer la pregunta

Cuestionar el requerimiento exige dos cosas que casi nunca coinciden bajo presión: tiempo para pensar antes de actuar, y la disposición a decirle a alguien que su encargo, tal como está planteado, puede no ser el correcto. Ninguna de las dos es cómoda cuando hay un cronograma corriendo y ya existe una expectativa formada sobre lo que se va a entregar.

Hay también un costo social en hacer esa pregunta. Cuestionar el marco puede leerse como resistencia, como falta de disposición a ejecutar, o como estar buscando pretextos para no avanzar. Por eso la mayoría de los equipos, como el primero del ejemplo, prefieren ejecutar lo pedido y descubrir después, si acaso, que el problema seguía ahí.

Y en este caso sigue ahí. Un mes más tarde llegan las mismas quejas de los usuarios, casi con las mismas palabras. El sistema técnicamente responde más rápido, pero la sensación de lentitud para quien lo usa no cambió.

El mecanismo: separar el síntoma del marco de referencia

Cuestionar el requerimiento no significa dudar de todo ni renegociar cada encargo. Significa hacer una pregunta específica antes de empezar a ejecutar: ¿este marco de referencia explica realmente el comportamiento que estamos viendo, o solo describe el síntoma? Si la respuesta no es clara, ahí está el verdadero punto de partida, no en la solución que ya se estaba diseñando.

El segundo equipo, antes de tocar código, hace esa pregunta: ¿por qué importa el tiempo de respuesta? Al investigar, descubren que el sistema procesa las solicitudes en un tiempo razonable, pero no muestra ninguna señal de que ya está trabajando en ello. El usuario ve una pantalla estática y asume que no pasó nada, así que reintenta, y ese reintento es lo que realmente satura el sistema. El síntoma reportado era "lentitud". La causa real era falta de retroalimentación visual.

El principio que se puede llevar a cualquier proyecto

Esa pregunta cambia dónde se invierte el esfuerzo. En vez de perfeccionar una solución dentro de un marco que nadie verificó, se invierte primero en confirmar el marco. El segundo equipo no toca el rendimiento del sistema. Agrega un indicador simple de "solicitud en proceso", y los reintentos, junto con la sensación de lentitud, desaparecen casi de inmediato. Es una inversión pequeña de tiempo al principio que evita semanas de ejecución mal dirigida después.

La próxima vez que un proyecto avance lento a pesar de que el equipo ejecuta bien, vale la pena detenerse antes de agregar más recursos o más horas. La pregunta que suele destrabar el problema no es "¿cómo lo resolvemos más rápido?" sino "¿estamos seguros de que este es el problema que hay que resolver?".

¿Cuándo fue la última vez que revisaste si el problema que llevas semanas resolviendo era, en realidad, el correcto?