La empresa llevaba tres meses esperando el sistema que le iban a entregar “en seis semanas”. Cuando al fin llegó la primera versión, el flujo de aprobaciones no coincidía con cómo trabajaba el equipo en la práctica. La pantalla de carga de pedidos pedía datos que nadie usaba y no tenía los campos que sí eran críticos. El equipo de desarrollo había construido exactamente lo que les habían pedido. El problema era que nadie había preguntado bien.
Esta situación se repite más de lo que parece. No por mala fe ni falta de capacidad técnica, sino porque el proyecto arrancó sin una etapa de discovery: la fase donde, antes de escribir una sola línea de código, se define con claridad qué problema se está resolviendo, para quién, bajo qué restricciones y con qué criterios de éxito.
La etapa de discovery es la diferencia entre construir el sistema correcto y construir un sistema. No siempre resulta corta ni glamorosa, pero es invariablemente más barata que descubrir en producción que lo que se desarrolló no encaja con la operación real.
Una buena discovery no acelera el desarrollo; te protege de construir rápido en la dirección equivocada.
¿Qué es realmente una etapa de discovery?
Una etapa de discovery —también llamada fase de análisis, etapa de levantamiento o Sprint 0— es el período previo al desarrollo donde se trabaja para entender el problema real antes de comprometerse con una solución técnica específica.
No es una reunión de kickoff ni un documento de requisitos escrito apresuradamente para cumplir un trámite contractual. Es un proceso deliberado de exploración que involucra a los responsables del negocio, a los usuarios que van a usar el sistema y, en los mejores casos, a un equipo técnico que ya está pensando en las implicancias de lo que se pide.
Una discovery bien hecha dura entre una y cuatro semanas según la complejidad del proyecto. Lo que produce es un conjunto de documentos y acuerdos que permiten estimar con realismo, diseñar con criterio y construir con foco.
Definir los objetivos de negocio: el primer paso real
El error más frecuente es ir directo al “qué queremos construir” sin pasar por el “por qué lo necesitamos”. Los objetivos de negocio son el ancla de todo lo que viene después.
Un objetivo de negocio no es “quiero un sistema de gestión de pedidos”. Es “necesito reducir el tiempo que mi equipo dedica a procesar pedidos manuales porque estamos perdiendo dos horas por día y eso limita el volumen que podemos operar”.
La diferencia importa porque la segunda formulación ya contiene criterios de éxito medibles. Cuando el objetivo es claro, es posible evaluar durante el desarrollo si las decisiones de diseño lo sostienen o lo sabotean.
Durante la discovery, los objetivos de negocio se documentan junto con sus métricas esperadas. No hace falta que sean perfectos: hacen falta para que el equipo tenga un norte compartido.
Mapear procesos y usuarios: quién hace qué y cómo
Un sistema digital no reemplaza un proceso; lo acompaña. Por eso, antes de diseñar cualquier interfaz o flujo técnico, es imprescindible entender cómo trabaja la operación hoy.
El mapeo de procesos no es un diagrama de flujo corporativo con cincuenta cuadros. Es una descripción funcional de las tareas que realiza el sistema hoy —aunque lo haga una persona con Excel— y de los puntos de fricción que tiene.
Lo que se documenta en esta etapa:
- Quiénes son los usuarios reales del sistema: no los que la empresa cree que lo van a usar, sino los que efectivamente van a tener que abrir una pantalla todos los días.
- Qué hacen hoy para completar cada tarea: pasos, herramientas, decisiones intermedias.
- Dónde se pierde información, se duplica trabajo o se generan errores sistemáticos.
- Qué datos son críticos y cuáles son opcionales o históricos.
Este mapeo tiene un efecto secundario valioso: en muchos casos, revela que el problema real no es el que se había formulado originalmente. Aparecen pasos que nadie había documentado, dependencias que el equipo daba por sentadas y flujos alternativos que el sistema va a tener que contemplar.
Si no mapeás los procesos antes de diseñar, los vas a descubrir durante la construcción. Y eso tiene un costo concreto: retrabajo, cambios de alcance y, en muchos casos, arquitecturas que no escalan.
Alcance: decidir qué no entra es tan importante como decidir qué sí entra
Una de las decisiones más difíciles de una discovery es el corte de alcance. Todo el mundo quiere que el sistema resuelva todo. La presión por incluir funcionalidades “mientras estamos” es real y tiene lógica: si ya se está pagando el desarrollo, ¿por qué no aprovechar?
El problema es que el alcance ampliado sin priorización tiene un costo que rara vez se mide correctamente: mayor tiempo de desarrollo, mayor superficie de testing, mayor complejidad de mantenimiento y, sobre todo, mayor riesgo de que el proyecto se extienda hasta el punto donde nadie recuerda cuál era el objetivo original.
Una buena discovery produce un backlog priorizado, no una lista de deseos. Las funcionalidades se clasifican por impacto, urgencia y dependencias técnicas. Se define qué entra en la primera versión —el MVP— y qué va a la siguiente iteración.
Esto no implica entregar algo incompleto. Un MVP bien definido es una versión funcional y útil que resuelve el problema central. Lo que se deja para después son las mejoras, los reportes adicionales, las integraciones secundarias y los flujos alternativos de baja frecuencia.
En Gambit Lab, uno de los primeros ejercicios que hacemos con los clientes es distinguir entre lo que el sistema debe hacer el día del lanzamiento y lo que sería bueno que hiciera. Esa distinción cambia por completo la estimación y el plan de trabajo.
Identificar riesgos, supuestos y dependencias
Todo proyecto de software parte de supuestos. El problema es cuando esos supuestos no se explicitan y alguien los descubre en la mitad del desarrollo.
En la etapa de discovery, se identifican y documentan:
- Supuestos técnicos: infraestructura disponible, APIs de terceros que tienen que funcionar, datos que se asume que existen en determinado formato.
- Supuestos de negocio: procesos que “ya están definidos” pero que en realidad varían según el área, la persona o la temporada.
- Dependencias externas: integraciones con sistemas existentes, proveedores que tienen que cooperar, migraciones de datos que requieren limpieza previa.
- Riesgos de adopción: si los usuarios no van a querer usar el sistema, ese es un riesgo tan real como cualquier bug técnico.
Listar los riesgos no paraliza el proyecto. Al contrario: permite priorizarlos, asignarles un responsable y definir qué va a pasar si se materializan. Un equipo que sabe cuáles son sus riesgos puede gestionarlos; uno que los ignora los descubre cuando ya no hay margen para reaccionar.
No es casual que los proyectos de software fallen más por problemas de alcance y alineación que por razones técnicas. La mayoría de esos problemas son detectables en la discovery si se hace con honestidad y con las personas correctas en la sala.
Los entregables concretos de una discovery bien hecha
El resultado de una etapa de discovery no es intangible. Hay documentos específicos que deben existir al final del proceso para que el desarrollo pueda arrancar con bases sólidas:
- Documento de objetivos y criterios de éxito: qué resuelve el sistema y cómo se va a medir si lo resolvió.
- Mapa de procesos y usuarios: flujos actuales, actores, puntos de fricción y flujos objetivo.
- Definición de alcance del MVP: qué funcionalidades entran en la primera versión y qué va después.
- Backlog inicial priorizado: lista de funcionalidades con estimaciones de complejidad relativa.
- Inventario de supuestos y riesgos: lo que se asume que es verdad y los puntos donde el proyecto tiene exposición.
- Decisiones de arquitectura base: stack tecnológico, integraciones clave, definición de datos principales.
Con estos seis elementos, cualquier equipo de desarrollo puede empezar a trabajar con claridad. Sin alguno de ellos, el proyecto arranca con una deuda de información que tarde o temprano aparece como un problema concreto: un cambio de alcance, una integración que nadie previó o un flujo que requiere rediseñar pantallas enteras.
¿Cuánto tiempo tiene que durar una discovery?
Depende de la complejidad del proyecto, pero una guía razonable:
- Proyectos pequeños (un módulo, un sistema interno acotado): 1-2 semanas.
- Proyectos medianos (sistema con varios roles, integraciones, flujos de aprobación): 2-4 semanas.
- Proyectos grandes (plataforma con múltiples áreas, lógica de negocio compleja, migraciones): 4-6 semanas o más.
Una discovery que tarda más de lo previsto suele ser señal de que el problema era más complejo de lo que parecía, que hay desacuerdo interno sobre los objetivos o que los procesos no estaban tan definidos como se creía. En los tres casos, mejor descubrirlo en esta etapa que en el sprint 8.
La pregunta que vale hacerse no es “¿cuánto cuesta la discovery?” sino “¿cuánto me cuesta no hacerla?”. La mayoría de los proyectos que terminan en conflicto, retrasos o rediseños completos tienen en común que arrancaron sin una etapa de análisis seria.
Quién tiene que participar y cómo organizarla
Una discovery no la hace solo el equipo técnico ni solo el equipo de negocio. Es un proceso conjunto donde ambas partes tienen que estar presentes y comprometidas.
Del lado de la empresa, tienen que participar quienes entienden los procesos en profundidad y quienes toman las decisiones de alcance. No es suficiente con “el que pidió el sistema”; hace falta también quien lo va a usar día a día.
Del lado del equipo técnico, la discovery tiene que estar liderada por alguien con experiencia en análisis funcional y diseño de producto, no solo en programación. El objetivo no es empezar a codificar: es entender bien antes de comprometerse con una arquitectura y un cronograma.
Herramientas que ayudan en el proceso
No hay una sola forma de hacer una discovery, pero algunas dinámicas son consistentemente útiles:
- Entrevistas con usuarios clave: no para preguntarles qué quieren, sino para entender cómo trabajan.
- Talleres de mapeo de procesos: pizarra, notas adhesivas y las personas que ejecutan el proceso en el día a día.
- Revisión de datos existentes: qué información ya existe, en qué formato y con qué calidad.
- Prototipado conceptual: wireframes o esquemas simples para validar que todos están imaginando lo mismo.
Si estás evaluando si tiene sentido construir una solución propia antes de llegar a la discovery, puede ser útil leer primero cómo decidir entre SaaS y desarrollo a medida. La discovery aplica a ambos caminos, pero la profundidad varía según la complejidad de lo que se va a construir.
En resumen
Una etapa de discovery no es un trámite ni un gasto adicional. Es la fase donde se define si lo que se va a construir tiene sentido, es viable y va a resolver el problema correcto.
Las empresas que la saltean no ahorran tiempo: lo pagan después, con cambios costosos, frustraciones y, en los peores casos, sistemas que terminan en desuso porque nadie los adopta.
Si estás por encarar un proyecto de software y no tenés claro cómo estructurar esta etapa, podés escribirnos para conversar sobre el proceso. Sin compromiso, sin pitch: solo una charla para ver si el camino que estás planificando tiene los pasos correctos desde el principio.