La mayoría de proyectos de software que fracasan no fracasan en el desarrollo — fracasan antes de empezar, cuando alguien puso precio y plazo a algo que nadie había mapeado. El Discovery es la fase que evita exactamente eso. Esta guía explica qué es, qué debe entregarte, y cómo usarlo para comparar proveedores aunque nunca hayas contratado desarrollo.
Respuesta directa
El Discovery es la fase previa al desarrollo donde se mapean los objetivos de negocio, los requisitos técnicos y la arquitectura del sistema — antes de escribir código y antes de comprometer un precio. Su resultado debe ser un documento escrito con tres cosas: la arquitectura propuesta (qué se construye y con qué tecnologías), el plan de hitos (qué se entrega y cuándo) y un presupuesto cerrado. Un precio dado sin Discovery es una adivinanza — y las adivinanzas se cobran después como "adicionales". En Grupo Hermoza el Discovery es gratuito y el documento es tuyo aunque no avances con nosotros.
El problema que el Discovery resuelve.
Cuando pides una cotización de software, describes tu proyecto en una llamada y recibes un número. El problema: lo que describiste es el 40% del sistema. El otro 60% — los casos borde, las integraciones, los roles que no mencionaste, la migración de datos que "se sobreentendía" — aparece durante el desarrollo. Y ahí hay dos finales posibles: el proveedor lo absorbe recortando calidad donde no ves, o te lo cobra como adicional. Ambos son malos y ambos eran evitables.
El Discovery invierte el orden: primero se mapea la operación completa — cómo trabajas, quién usa qué, qué se conecta con qué — y recién entonces se pone precio y plazo. No elimina la incertidumbre por completo, pero convierte lo "sobreentendido" en alcance escrito. Es la diferencia entre un presupuesto cerrado y un presupuesto que solo era el precio de entrada.
Qué debe incluir el entregable — exígelo por escrito.
"Hicimos discovery" no significa nada si no termina en un documento. Esto es lo que el documento debe contener, sea nuestro o de cualquier proveedor:
El alcance funcional en tu idioma. Qué hace el sistema, para quién, y qué queda explícitamente fuera de esta fase. La lista de "fuera de alcance" es tan valiosa como la de dentro — es la que evita las discusiones de después.
La arquitectura propuesta, con nombres. Tecnologías concretas — lenguajes, base de datos, infraestructura cloud — y por qué esas. Si el documento dice "tecnologías modernas y escalables" sin nombrarlas, no es arquitectura, es marketing.
El plan de hitos con entregables. Qué vas a ver funcionando y cuándo. Cada hito debe ser verificable por ti sin conocimientos técnicos: "el usuario puede registrarse y crear un pedido", no "se completó el módulo de persistencia".
El presupuesto cerrado, atado a los hitos. Cuánto cuesta cada fase y contra qué entregable se factura. Ese número sale del mapeo — por eso puede ser cerrado, y por eso el precio de la primera llamada no podía serlo.
Los supuestos y riesgos. Qué se asumió (accesos, datos existentes, terceros que deben responder) y qué puede mover el plazo. Un documento sin riesgos identificados es un documento que no miró de cerca.
¿Quieres el documento de tu proyecto?
Agenda el Discovery gratuito: arquitectura, hitos y presupuesto cerrado, por escrito.
En nuestro caso, el Discovery es la primera de cuatro fases — Discovery, Diseño, Desarrollo, Lanzamiento — y es la que define a las otras tres. De ahí salieron las arquitecturas de DoctorMBS (multi-tenant, diseñada para la expansión regional que después ocurrió) y de OXICARE DadeMedical (trazabilidad regulatoria como fundamento, no como parche).
Después del Discovery, el desarrollo corre por hitos quincenales con facturación contra entregables — el mecanismo completo está en la guía de plazos. Y si estás en la etapa anterior — decidir si construir siquiera —, empieza por software a medida vs SaaS genérico: a veces la conclusión correcta del Discovery es no construir todavía, y preferimos decírtelo antes que cobrártelo después.
Preguntas frecuentes.
01
¿Cuánto cuesta la sesión de Discovery de Grupo Hermoza?
Nada — es gratuita e incluye un entregable escrito: propuesta de arquitectura, plan de hitos y presupuesto cerrado. El documento es tuyo aunque decidas no avanzar con nosotros; puedes usarlo para comparar propuestas de cualquier proveedor. La apuesta es simple: si el documento es serio, una parte de quienes lo reciben construye con nosotros.
02
¿Qué necesito preparar antes de una sesión de Discovery?
No necesitas documentos técnicos ni saber de tecnología. Necesitas poder explicar tres cosas: cómo funciona tu operación hoy (aunque sea con Excel y WhatsApp), qué problema quieres resolver o qué oportunidad quieres capturar, y quién usaría el sistema. Si tienes cifras — volumen de pedidos, número de usuarios, tamaño del equipo — mejor, porque dimensionan la arquitectura.
03
¿En qué se diferencia un Discovery de una cotización normal?
Una cotización responde "¿cuánto cuesta?" con lo que el vendedor entendió en una llamada. Un Discovery responde primero "¿qué hay que construir y por qué?", y de ahí sale un presupuesto que no cambia a mitad de camino. La diferencia práctica: los proyectos cotizados sin Discovery acumulan "adicionales" — cosas que siempre fueron necesarias pero nadie mapeó. El presupuesto post-Discovery es cerrado porque el alcance está mapeado.
04
¿Cuánto dura el proceso de Discovery?
La sesión inicial es una conversación de trabajo sobre tu operación. El entregable escrito llega días después, no meses: mapear un alcance típico toma entre unos días y un par de semanas según la complejidad. Es tiempo que se recupera con creces — cada ambigüedad resuelta en Discovery es una semana de retraso que no ocurre en desarrollo.
05
¿Qué pasa si el Discovery concluye que no me conviene desarrollar a medida?
Te lo decimos. A veces la respuesta honesta es "esto lo resuelve un SaaS existente por una fracción del costo" o "valida primero tu modelo antes de invertir en sistema propio". Un proveedor que recomienda construir siempre, a todos, no está haciendo Discovery — está haciendo ventas. Nuestra guía de software a medida vs SaaS genérico documenta exactamente ese criterio.
