Qué entrega realmente una fase de discovery (y qué no)

Una fase de discovery es un bloque breve y acotado de análisis al inicio de un proyecto de software, el que convierte una idea en bruto en un plan definido, presupuestado y construible. Va antes de cualquier línea de código de producción. Su función es cambiar suposiciones por decisiones: qué se construye, para quién, en qué orden, en qué rango de precio y qué se deja fuera a propósito.

Se recurre a una discovery cuando la idea está clara en la cabeza pero no sobre el papel, cuando dos proveedores dan cifras muy distintas por el mismo brief, o cuando un equipo interno vuelve a discutir el alcance en cada reunión. El resultado es un conjunto de documentos y un prototipo lo bastante concretos como para que un segundo equipo pueda tomarlos y construir a partir de ahí. Esto es lo que entrega una discovery, cuánto cuesta y las cuatro cosas que nunca debería fingir ser.

La versión de 30 segundos

Una discovery suele durar de una a seis semanas y cuesta entre el 10 y el 15 por ciento del presupuesto total del proyecto. Entrega un documento de alcance, historias de usuario, un mapa de stakeholders, una dirección de arquitectura, prototipos de baja fidelidad y una hoja de ruta con una estimación de coste. Existe porque los requisitos poco claros son la mayor causa de fracaso de los proyectos de software. No fija un precio final, no sustituye a la construcción y deja de aportar valor en cuanto tienes suficiente claridad para empezar.

Por qué existe la discovery

La mayoría de los proyectos de software no fracasa por la calidad del código. Fracasa por los requisitos. El análisis del Standish Group sitúa los requisitos poco claros a la cabeza de las causas, por delante del scope creep y de la planificación deficiente. El Project Management Institute reporta la misma forma: los requisitos imprecisos o mal gestionados están detrás de cerca de cuatro de cada diez proyectos fallidos. Las revisiones del sector estiman que la mitad del retrabajo en un proyecto viene de requisitos mal recogidos desde el principio.

La discovery es el lugar más barato para equivocarse. Cambiar una decisión en un documento cuesta un correo. Cambiar esa misma decisión tras tres sprints de código cuesta semanas. Esa diferencia es toda la justificación económica de la fase, y es la razón por la que saltársela en algo no trivial suele costar más que hacerla.

Cómo transcurre una discovery

El trabajo es en parte entrevista, en parte taller, en parte sonda técnica. Empieza con sesiones que sacan el objetivo real de la cabeza del fundador y lo llevan a una pizarra compartida: el problema, los usuarios, el modelo de ingresos, las restricciones. A partir de ahí el equipo ejecuta unas pocas actividades concretas. Los talleres de requisitos convierten los objetivos en funcionalidades acotadas. Un spike técnico pone a prueba la integración arriesgada o la hipótesis sin verificar antes de ponerle precio. Entrevistas rápidas a usuarios o stakeholders comprueban que el problema sea el que vale la pena resolver. Cada actividad termina en uno de los entregables de abajo: así distingues una discovery real de una serie de reuniones. Cada sesión produce algo sobre lo que alguien puede actuar.

Qué entrega realmente una discovery

Una discovery seria produce artefactos, no diapositivas. El conjunto exacto varía según el proyecto, pero seis entregables aparecen en casi todos los casos:

• Un documento de alcance. La referencia única de qué entra, qué queda explícitamente fuera y por qué. Cualquier discusión futura sobre "¿eso estaba incluido?" se cierra aquí.
• Historias de usuario y casos de uso. Las funcionalidades descritas desde el punto de vista de quien las usa, con el detalle suficiente para estimarlas y luego probarlas.
• Un mapa de stakeholders. Quién decide, quién aprueba, a quién hay que consultar y cómo quiere cada uno mantenerse al tanto.
• Una dirección de arquitectura. Las decisiones técnicas principales (stack, modelo de datos, integraciones, hosting) con los compromisos por escrito, no el diseño completo del sistema.
• Prototipos de baja fidelidad. Clicables lo justo para detectar problemas de flujo antes de que sean código, no tan pulidos como para confundirlos con el producto.
• Una hoja de ruta con una estimación. Un plan por fases y un rango de coste ligado a hipótesis explícitas, de modo que el número solo se mueve cuando se mueven las hipótesis.

Cuánto dura y cuánto cuesta

La duración sigue a la complejidad. Una herramienta interna sencilla o un MVP ajustado caben en una o dos semanas. La mayoría del software de negocio se sitúa entre dos y cuatro semanas. Los sistemas enterprise, las funciones de IA o los requisitos de cumplimiento pesados la llevan de cuatro a ocho. Cuatro semanas son el punto de equilibrio más común entre velocidad y profundidad.

El coste suele estar entre el 10 y el 15 por ciento del presupuesto de desarrollo. En concreto, un MVP con un presupuesto de 50.000 dólares lleva unos 2.500-5.000 dólares de discovery; una plataforma SaaS completa de unos 150.000 dólares va sobre los 8.000-15.000. Los proveedores que venden discovery estiman que gastar entre el 5 y el 10 por ciento del presupuesto en esta fase reduce el sobrecoste de desarrollo entre un 40 y un 60 por ciento. Tómalo como una indicación de dirección de una parte interesada, no como una ley. La dirección, eso sí, coincide con los datos de fracaso por requisitos: cuanto antes detectas una hipótesis equivocada, menos cuesta.

Imagina un equipo de dos fundadores que llega con "un marketplace para X". Cuatro semanas de discovery pueden convertirlo en un conjunto de historias de usuario acotadas, en la decisión de lanzar primero un solo lado del marketplace, en una integración de pagos marcada como riesgo técnico principal y en una estimación con una banda de oscilación ligada a una pregunta abierta: si la mensajería interna entra en el lanzamiento. Esa sola pregunta puede valer tres semanas de desviación en los plazos. Encontrarla en un documento en lugar de en el sprint seis es el sentido de la fase.

Cuatro cosas que la discovery no debería fingir ser

La fase se gana la confianza siendo honesta sobre sus límites.

1. Un precio final. La discovery produce un rango y una lista de hipótesis, no una cifra de contrato. Quien te da un total exacto por un producto sin construir está poniendo precio a ciegas.
2. Un sustituto de la construcción. Un prototipo clicable es una herramienta de comunicación. No tiene datos reales, ni casos límite, ni solidez de producción. Confundirlo con el producto es como se desvían los plazos.
3. El lugar donde diseñar cada pantalla. La interfaz al pixel para toda la app y un backlog escrito por completo pertenecen a la fase de entrega. Pagarlos a tarifa de discovery es caro y prematuro.
4. Una búsqueda de certeza. Pasadas las ocho semanas aproximadamente, la discovery se desliza hacia la parálisis por análisis. El objetivo es claridad suficiente para moverse con seguridad, no un conocimiento perfecto que nunca llegará.

Una más, en voz baja: la discovery no debería ser una propuesta comercial disfrazada de investigación. Una discovery que solo puede terminar en "sí, encárganos todo el desarrollo" nunca fue investigación. Una de verdad puede acabar en "construid primero una versión más pequeña", o "esto ni siquiera necesita software a medida".

Cuándo puedes saltártela

Sáltate una discovery formal cuando el alcance es de verdad pequeño y está bien entendido: una landing page, una sola integración, un cambio en un sistema que ya operas. Para cualquier cosa multi-tenant, regulada o más larga que unas pocas semanas, saltarse la discovery suele ser el punto donde empieza el sobrecoste.

Dónde se sitúa la discovery frente al coste y la contratación

La discovery es la primera partida de un presupuesto de desarrollo, así que se lee bien junto a qué pagar y qué no en una fase de discovery. Si estás haciendo una discovery para comparar proveedores, los seis entregables de arriba funcionan también como tarjeta de evaluación: todo licitador serio debería devolverte los mismos artefactos.