El requerimiento que llega no es el problema que existe

Cuando el cliente sabe lo que quiere pero no sabe qué necesita

Un gerente de operaciones llega con un requerimiento concreto: "necesitamos un sistema de reportes para saber cuánto demora cada etapa del proceso". El equipo técnico anota, estima, cotiza. Tres meses después, el sistema está listo. Los reportes se generan solos. Nadie los usa.

¿Qué salió mal? Nada técnico. El sistema hace exactamente lo que se pidió. El problema es que lo que se pidió no resolvía lo que dolía.

Cuando se preguntó más a fondo, resultó que el dolor real era otro: los equipos no sabían en qué etapa estaba cada caso, lo que generaba llamadas internas constantes para preguntar estados. No necesitaban un reporte: necesitaban visibilidad en tiempo real. Son dos cosas distintas, y construir la primera no resuelve la segunda.

---

Por qué esto pasa más de lo que parece

Cuando alguien llega pidiendo un sistema, generalmente ya hizo un camino previo: identificó una incomodidad, la procesó, la tradujo a algo que le parece técnicamente pedible. Ese proceso de traducción es donde se pierde información.

No es negligencia. Es que la mayoría de las personas no tiene el vocabulario ni el marco para describir un problema operacional en términos que un equipo técnico pueda atacar directamente. Entonces lo convierten en lo que conocen: "quiero una app", "quiero un dashboard", "quiero que esto se automatice".

El requerimiento es una hipótesis sobre la respuesta, no una descripción del problema. Y si el equipo técnico lo toma como punto de partida sin cuestionarlo, construye sobre esa hipótesis sin validarla.

La consecuencia no es solo tiempo perdido. Es peor: el sistema queda funcionando, el desarrollo se cierra como exitoso, y el dolor original sigue ahí, ahora con una capa de código encima que hace más difícil verlo.

---

Cómo se ve el descubrimiento real en la práctica

Identificar bien un problema no es una reunión de kick-off con preguntas abiertas. Es un proceso de desarme: tomar el requerimiento como punto de entrada y trabajar hacia atrás hasta llegar al comportamiento o la restricción que lo genera.

Algunas preguntas que cambian el rumbo de un desarrollo:

• ¿Qué pasa hoy cuando esto falla? No qué debería pasar, sino qué pasa realmente.
• ¿Quién siente el dolor y cuándo? El que pide el sistema no siempre es el que lo va a usar.
• ¿Qué harías si no existiera ningún sistema para esto? La respuesta revela el proceso real, no el ideal.
• ¿Esto ya se intentó resolver antes? Si la respuesta es sí, por qué no funcionó.

Este tipo de conversación a veces toma una hora. A veces toma tres sesiones. Pero lo que produce no es un documento de requerimientos: es un diagnóstico compartido que hace que cada decisión técnica posterior, empezando por el diseño previo del sistema, tenga un porqué.

Volviendo al caso anterior: cuando se hizo esa pregunta sobre qué pasa cuando algo falla, la respuesta fue inmediata: "empiezan las llamadas y los mensajes de WhatsApp porque nadie sabe dónde está el caso". Eso es el problema. El reporte era una salida posible, pero no la única ni la mejor. Lo que se construyó en su lugar fue un panel de estado visible para todos los equipos involucrados, con notificaciones automáticas en los cambios de etapa. Las llamadas internas cayeron un 60% en el primer mes.

---

Lo que se evita cuando el problema está bien definido

No es solo que el producto final sea mejor. Es que todo el proceso de desarrollo cambia, y se evita buena parte de lo que explica por qué un desarrollo termina tarde y más caro:

• Las decisiones de alcance se vuelven fáciles. Cuando sabes qué problema estás resolviendo, es obvio qué funcionalidades son necesarias y cuáles son ruido. El criterio de corte deja de ser opinión y pasa a ser "¿esto resuelve el problema o no?".
• Las iteraciones tienen dirección. En lugar de ajustar porque "algo no se siente bien", los cambios responden a evidencia concreta de que el problema no está resuelto todavía.
• El equipo técnico puede proponer, no solo ejecutar. Cuando entiende el problema real, puede sugerir una alternativa más simple, más barata o más efectiva que la que se pidió originalmente, y a veces concluir que lo mejor es no construir nada.

Un equipo técnico que solo ejecuta requerimientos es un recurso. Un equipo que entiende el problema es un socio. La diferencia está en si alguien hizo las preguntas incómodas antes de empezar a construir.

---

Qué hacer ahora

1. Si tienes un requerimiento técnico pendiente, antes de pasarlo a desarrollo, escribe en una oración cuál es el comportamiento actual que quieres cambiar y qué consecuencia concreta tiene ese comportamiento hoy. Si no puedes escribirlo, el problema todavía no está definido.

2. Si ya tienes un sistema que no se usa o que no resolvió lo que esperabas, vale la pena hacer una retrospectiva corta: ¿el requerimiento original describía un síntoma o un problema? La respuesta suele ser reveladora para el próximo desarrollo.

3. Si estás evaluando un proveedor técnico, pregúntale cómo maneja la etapa previa al desarrollo. Si la respuesta es "levantamos requerimientos y estimamos", eso te dice algo. Si la respuesta incluye cómo cuestiona y valida el problema antes de proponer qué construir, eso te dice otra cosa.

Si quieres revisar un caso tuyo con nosotros, empezamos por entender tu operación, no por el requerimiento.