Que es una fase de discovery de software y por que va antes del codigo?

Discovery debe aclarar la próxima inversión. Documenta problema, evidencias, restricciones y supuestos que podrían cambiar la decisión de construir, comprar, reducir o parar. Puede evitar retrabajo, pero no implica un ahorro universal de semanas o meses.

Discovery + Roadmap de Wavect parte de una dirección de producto suficientemente clara para planificar la entrega. La oferta publicada tiene un precio fijo de EUR 3.500, sin el IVA aplicable, y una duración de 2 a 3 semanas. La tarifa se descuenta íntegramente de la factura de construcción si continúas con Wavect. Los resultados principales son arquitectura, hitos y oferta de implementación a precio cerrado. Acceso, decisiones del cliente y alcance firmado determinan el trabajo.

Si la demanda sigue sin probarse, consulta primero la validación temprana de producto. Planifica un experimento si puede cambiar la decisión, pero acuerda explícitamente reclutamiento, entrevistas, prototipos, sesiones de uso y ejecución técnica. Planificar no incluye automáticamente todos los experimentos recomendados.

Sal con un registro de decisiones, no una lista de deseos

Escribe una página con comprador, tarea del usuario, solución provisional actual, un recorrido completo y límite presupuestario. Añade la hipótesis más arriesgada, qué evidencia cambiaría la decisión y quién aprueba el alcance. Separa demanda comercial de viabilidad técnica: una API funcional no demuestra disposición a pagar ni uso recurrente.

Divide el backlog en imprescindible, aplazar y descartar. Imprescindible contiene el recorrido completo mínimo y los controles necesarios para operarlo con seguridad. Aplazar recoge mejoras útiles que no prueban la hipótesis actual. Descartar recoge ideas refutadas por evidencia o incompatibles con el presupuesto, indicando el motivo. Descartar elimina una función de este alcance; puede reconsiderarse si cambian las evidencias.

Antes de organizar una prueba con un prototipo, escribe qué decisión está pendiente y qué harás con cada resultado. Si la principal incógnita es una integración, comprueba primero si el proveedor dará acceso a un entorno de pruebas, si hay datos representativos y quién puede autorizar su uso. Si no puedes obtener la evidencia antes de aprobar el plan, registra la dependencia, el responsable y la fecha de comprobación. El manual de servicios de GOV.UK sitúa los prototipos para comprobar supuestos de riesgo en su fase alfa. Sirve de referencia para acotar el experimento por separado. Guía de GOV.UK sobre la fase alfa.

Ejemplo desarrollado: portal de solicitudes de mantenimiento

Es un ejercicio de investigación propuesto con alcance separado, no una entrega automática de la oferta fija de planificación. Un prototipo navegable permite probar comprensión y recorrido; autorización y enrutamiento en producción necesitan pruebas de implementación.

Es ilustrativo, no un resultado de un cliente de Wavect. Hipótesis: los responsables de edificios pueden enviar una solicitud completa sin que un coordinador la transcriba. Prueba: cinco responsables representativos reciben un prototipo navegable y solicitudes realistas; se observan envío y clasificación sin ayuda. Umbral ilustrativo acordado antes: cuatro de cinco completan los campos obligatorios sin asistencia y ninguna solicitud llega al edificio equivocado. La muestra pequeña comprueba usabilidad del flujo; no demuestra demanda de mercado ni una tasa de éxito estadísticamente fiable.

Imprescindible: identificar edificio, describir problema, confirmar envío y dirigirlo al coordinador adecuado con controles de acceso. Aplazar: apps nativas y recomendaciones automáticas de proveedores. Descartar para este alcance: un mercado público de proveedores que no prueba el flujo de solicitudes. Si no se alcanza el umbral, revisar y repetir; si el problema no aporta valor, detenerse. Si se supera, definir un piloto operativo limitado, sin declarar product-market fit.

Explicita aceptación y cambios

Para cada imprescindible, registra estado inicial, acción, resultado esperado y un caso de fallo. Añade supuestos de integración, responsabilidad sobre datos, dependencias, exclusiones y quién acepta la entrega. Una función nueva debe sustituir alcance acordado o recibir una decisión explícita de coste y plazo. Entrega hallazgos y preguntas pendientes para que otro equipo pueda continuar.

La guía de discovery de GOV.UK ayuda a entender el problema antes de implementar. Su guía de pruebas moderadas explica la observación de tareas representativas. Los umbrales anteriores son supuestos ilustrativos propios, no requisitos de esas fuentes. Fuentes consultadas el 11 de noviembre de 2026.