La respuesta corta
El discovery de producto es la fase de descubrimiento que viene antes del desarrollo: entender el problema donde ocurre, escuchar a quien usa y a quien decide, probar la idea con un prototipo y salir con un alcance validado. El objetivo es reducir el riesgo de construir lo equivocado, que es el error más caro de un proyecto.
En DevPlans, esta fase se llama validación y estudio de producto y es la primera de las seis etapas de nuestro ciclo. No es burocracia antes del trabajo de verdad. Es la parte del trabajo en la que cambiar de idea todavía cuesta una conversación, y no reescribir código.
Para qué sirve la fase de descubrimiento de un software
Quien pide un sistema generalmente ya tiene una idea de solución. El discovery sirve para verificar si la solución imaginada resuelve el problema real y si existe un camino más pequeño que resuelva el mismo problema.
- Entender el problema antes de la solución. El pedido "necesitamos una aplicación" a veces esconde un problema de proceso, de integración o de datos que una aplicación no resuelve.
- Encontrar el menor alcance que resuelve. Separar lo esencial de lo deseable, para que la primera versión entre en uso antes.
- Descubrir los riesgos pronto. Una integración que no existe, una regla que nadie sabe explicar, un dato que no es confiable. Todo esto sale más barato si se descubre ahora.
- Alinear a quien decide y a quien opera. La gestión y el equipo suelen describir la misma rutina de maneras distintas. El discovery pone las dos versiones sobre la mesa.
- Dar base a la estimación. Plazo e inversión estimados sin estudio son una suposición. Con el estudio, se convierten en una estimación por fase.
Qué se hace durante el discovery
Las actividades varían según el proyecto, pero estas aparecen en casi todos.
- Entrevistas e inmersión en la operación. Conversamos con quien usa y con quien decide y, siempre que es posible, acompañamos la rutina en el lugar donde ocurre. Quien ejecuta el proceso todos los días conoce las excepciones que ningún documento registra.
- Mapa del proceso actual. Dibujamos cómo ocurre el trabajo hoy, paso a paso, con los cuellos de botella, el retrabajo y los controles paralelos en hojas de cálculo. Muchas veces ese mapa es la primera vez que todos ven el proceso completo de la misma forma.
- Análisis de lo que ya existe. Relevamos los sistemas, los datos y las integraciones en uso, y lo que permite cada sistema. De aquí sale buena parte de la decisión entre software listo o a medida.
- Prototipo. Un prototipo rápido, a veces solo algunas pantallas navegables, muestra la idea a quien la va a usar. La reacción ante una pantalla concreta revela mucho más que la respuesta a una pregunta abstracta.
- Validación. Definimos hipótesis e indicadores de éxito y probamos el prototipo con quien va a usar el sistema. Lo que no se sostiene sale del alcance o cambia de forma antes de convertirse en código.
La inteligencia artificial ayuda en esta fase, sintetizando entrevistas y documentos y proponiendo una primera versión de las historias de usuario. La revisión y la decisión siguen en manos de nuestro equipo y de usted, como describimos en cómo trabajamos.
Qué sale del discovery: los entregables
Un discovery bien hecho termina con documentos que alguien puede usar para decidir. Estos son los principales:
| Entregable | Qué contiene | Para qué sirve |
|---|---|---|
| Diagnóstico de la operación | Proceso actual, cuellos de botella, retrabajo y sistemas en uso | Mostrar dónde está el problema y qué ya funciona |
| Prototipo validado | Pantallas navegables probadas con quien las va a usar | Confirmar la solución antes de convertirla en código |
| Alcance validado | Objetivo, perfiles, rutinas, reglas, integraciones y exclusiones | Fijar lo que se construirá y lo que queda fuera |
| Backlog priorizado | Ítems en orden de prioridad, con criterio de aceptación | Organizar la primera versión y los sprints |
| Estimación por fase | Plazo e inversión de cada etapa | Decidir si seguir y cómo, con la información en la mano |
| Registro de decisiones y riesgos | Premisas, elecciones y riesgos, con responsable | Guardar el porqué de cada decisión a lo largo del proyecto |
En nuestro ciclo, el alcance se aprueba formalmente antes de que empiece el diseño. Con estos entregables, usted decide si sigue, cómo y en qué orden, y eso vale aunque la decisión sea no construir. Lo que debe contener un alcance está en cómo definir el alcance de un software.
Cuánto pesa el discovery en el proyecto
No existe una proporción fija, y conviene desconfiar de quien da una antes de conocer el caso. El peso del discovery depende de cuánto del problema ya está claro. Cuando la operación sabe qué necesita cambiar y el proceso es conocido, el estudio es corto. Cuando el problema todavía está enredado, con varias áreas involucradas, reglas no escritas e integraciones inciertas, la validación lleva más tiempo.
Ese tiempo no se pierde. Corregir un flujo en el prototipo cuesta mucho menos que corregirlo en el sistema terminado, y descubrir en el estudio que una integración no existe cuesta mucho menos que descubrirlo a mitad del desarrollo. Tampoco hace falta agotarlo todo antes de empezar: el estudio detalla la primera versión y deja el resto en un nivel que permite priorizar, y las etapas siguientes se superponen a partir de los primeros sprints.
Lo que el discovery pide de su lado es tiempo de personas: alguien con autonomía para decidir por el proyecto y quienes ejecutan el proceso en el día a día, durante algunas horas de entrevistas y validaciones. La participación de quien va a usar el sistema es lo que más reduce el retrabajo después.
Cuándo se puede omitir el discovery
Se puede acortar bastante, y en algunos casos omitir, cuando:
- El problema y la solución ya fueron validados. Por ejemplo, cuando ya existe un prototipo probado o una versión en uso y el proyecto es evolucionar lo que funciona.
- El alcance es pequeño y conocido. Una integración puntual entre dos sistemas o la automatización de una tarea bien definida piden un relevamiento corto, no una fase entera.
- Hay documentación confiable. Un término de referencia bien escrito, un proceso mapeado y reglas documentadas ya cumplen parte del papel.
Incluso en esos casos, algo de estudio ocurre: confirmar lo que permite el otro sistema, quién aprueba cada entrega y cuál es el criterio de aceptación. En un proyecto con muchas incertidumbres, omitir el discovery no ahorra tiempo, solo posterga el momento de descubrir.
Si su idea todavía está en la fase de probar si vale la pena, el discovery y el MVP van juntos: el primero descubre qué construir, el segundo lo prueba con uso real. Así empieza todo proyecto de desarrollo de software a medida que hacemos.