El documento que define si tu proyecto de software sale bien o mal antes de escribir una línea de código.
Hay una etapa del desarrollo de software que casi nadie menciona y que determina el 80% del resultado. Se llama levantamiento de requerimientos. Y la mayoría lo hace mal.
Project App
Equipo de Ingeniería
Si tuvieras que identificar el momento exacto en que un proyecto de software empieza a fallar, casi nunca es en el desarrollo. Es antes. Es en la etapa donde alguien intentó definir qué construir, cómo funcionaría, y qué problema resolvería — y esa definición quedó incompleta, ambigua, o simplemente mal hecha. En ProjectApp llamamos a esa etapa el diagnóstico. En la industria se llama levantamiento de requerimientos. Y en mi experiencia, es el paso que más determina si un proyecto termina a tiempo, dentro del presupuesto, y siendo usado por el equipo del cliente. O si no termina.
Por qué la mayoría de los requerimientos están mal hechos
El problema no es que el cliente no sepa lo que quiere. El problema es que lo que quiere está en su cabeza en un formato que no se puede construir directamente. El cliente piensa en términos de su operación: 'necesito que el sistema me avise cuando un pedido lleva más de dos días sin movimiento.' El desarrollador necesita traducir eso a: cuándo exactamente empieza el conteo, qué tipo de notificación, a quién le llega, con qué información, qué pasa si el pedido se reactiva. Esa traducción — del lenguaje del negocio al lenguaje técnico — es el corazón del levantamiento de requerimientos. Y cuando se hace mal, el sistema construido no resuelve el problema real.
"El cliente sabe perfectamente qué problema tiene. Casi nunca sabe exactamente qué sistema necesita para resolverlo. Ese es el trabajo del diagnóstico."
— Lo que aprendí haciendo diagnósticos en más de 50 proyectos
Qué tiene un buen documento de requerimientos
Un buen levantamiento de requerimientos no es una lista de funcionalidades. Es un mapa del problema y de cómo el sistema lo va a resolver. En ProjectApp, el diagnóstico que hacemos en los primeros 5 días del proyecto siempre cubre estos elementos:
- El proceso actual en detalle — cómo fluye la información hoy, dónde está el dolor, qué pasos son manuales y cuáles podrían automatizarse.
- Los actores del sistema — quiénes van a usar el software, con qué roles, qué puede hacer cada uno y qué no.
- Los flujos críticos — los procesos que si fallan detienen la operación. Esos se construyen primero y se prueban más.
- Los casos borde — qué pasa cuando algo sale diferente a lo esperado. ¿Se rechaza? ¿Se escala? ¿Se registra con excepción?
- Las integraciones necesarias — con qué otros sistemas tiene que hablar el nuevo software y cómo.
- Lo que está fuera del alcance — tan importante como lo que está dentro. Define qué no se va a construir en esta versión.
Las señales de que el requerimiento está mal hecho
Después de trabajar en más de 50 proyectos, reconozco rápido cuándo un levantamiento de requerimientos tiene problemas:
Funcionalidades sin contexto
Una lista de cosas que el sistema 'debe tener' sin explicar para qué. 'Dashboard con métricas' — ¿qué métricas? ¿para quién? ¿con qué frecuencia se actualizan? Sin ese contexto, el desarrollador construye algo que funciona pero que nadie usa.
Sin casos borde definidos
Solo describe el camino feliz — lo que pasa cuando todo sale bien. El problema es que en producción, los casos borde son el 30% del trabajo real. Si no están definidos antes, aparecen como sorpresas caras en el desarrollo.
Validado solo con una persona
El requerimiento fue revisado con el dueño del proyecto pero no con el equipo que va a usar el sistema. Las personas que operan el día a día tienen una visión del proceso completamente diferente a la del directivo que pidió el software.
Sin criterio de aceptación
No define cuándo el sistema 'está listo'. Sin eso, no hay forma de saber si lo que se construyó resuelve el problema. El 'está bien' de alguien no es suficiente.
Por qué los 5 días de diagnóstico de ProjectApp son el paso más valioso
En ProjectApp no empezamos a escribir código hasta tener el diagnóstico completo. Esos 5 días parecen tiempo 'perdido' para el cliente que quiere ver avance inmediato. En realidad son el paso que más impacto tiene en el resultado final. Por una razón simple: un cambio en el requerimiento antes de escribir código cuesta cero. El mismo cambio durante el desarrollo puede costar días. El mismo cambio después de entregar puede costar semanas. El costo de hacer bien el requerimiento desde el inicio es órdenes de magnitud menor al costo de corregirlo después.
La pregunta que define si un requerimiento está listo
¿Podría una persona que no conoce el proyecto leer este documento y construir exactamente el sistema que necesitamos? Si la respuesta es no, el requerimiento no está listo.
Lo que me llevo de todo esto
Lo que me llevo de todo esto
- 1El levantamiento de requerimientos determina el 80% del resultado de un proyecto. Es el paso que menos tiempo recibe y más impacto tiene.
- 2Un buen requerimiento no es una lista de funcionalidades — es un mapa del problema, los actores, los flujos, los casos borde y lo que está fuera de alcance.
- 3El costo de un cambio antes de escribir código es cero. El mismo cambio después de entregar puede costar semanas.
- 4El requerimiento debe ser validado con el equipo que va a usar el sistema, no solo con quien lo pidió.
El documento que define si un proyecto de software sale bien se escribe antes de la primera línea de código. No después. En ProjectApp dedicamos los primeros 5 días de cada proyecto a construir ese documento — no porque tengamos tiempo de sobra, sino porque sin él, el resto del proyecto es construir sobre arena. Y eso, en nuestra experiencia, siempre cuesta más de lo que costó hacer el diagnóstico bien.
Si tienes un proyecto de software en mente y quieres saber exactamente qué necesitaría construirse para resolverlo, el diagnóstico es gratuito. Cinco días. Cero código. Un mapa completo de qué construir y cómo.