Qué debe entregar un discovery de dos semanas para valer lo que cuesta
Un discovery que produce una propuesta es un proceso de venta. Cinco artefactos que lo vuelven un entregable de ingeniería tuyo, útil con cualquier proveedor.
El discovery pagado tiene mala fama, y muchas veces se la gana. Pasan dos semanas, llega una presentación, y la presentación es la propuesta del proyecto que el proveedor quería vender desde el principio. Pagaste para que te vendieran.
Un discovery vale lo que cuesta cuando produce artefactos que son tuyos, útiles aunque nunca contrates a quien los escribió, y que permitirían a otro equipo empezar el lunes.
El test
Antes de empezar, acuerden este criterio:
Si paramos aquí y le entregamos esto a otra firma, ¿puede empezar sin repetir el discovery?
Todo lo de abajo se deriva de eso. También hace honesto el proyecto: un proveedor que acepta ese criterio está apostando a que ser útil gana el trabajo, que es el incentivo que quieres.
Cinco artefactos
| Artefacto | Qué contiene | Por qué sobrevive al proyecto |
|---|---|---|
| Mapa del sistema | Lo que existe hoy: sistemas, flujos de datos, integraciones, dueños | Nadie lo tiene escrito, y todo el mundo lo necesita |
| Lista de restricciones | Lo que no puede cambiar, y por qué: contratos, cumplimiento, sistemas inamovibles | Las restricciones halladas tarde son lo que rompe los planes |
| Registro de riesgos | Lo desconocido, priorizado, con el costo de averiguarlo | Nombra lo que va a reventar la estimación |
| Plan secuenciado | Qué construir primero, segundo, tercero, y qué desbloquea cada cosa | Un plan con orden es un plan que puedes detener a la mitad |
| Registro de decisiones | Elecciones tomadas en el discovery, con alternativas rechazadas y por qué | Evita relitigar el mismo debate en el cuarto mes |
El registro de riesgos es el que más falta y el que paga el proyecto. Un discovery que solo reporta lo que encontró está describiendo la mitad fácil. La salida valiosa es la lista priorizada de lo que nadie pudo determinar en dos semanas, con una estimación de cuánto podría costar cada incógnita.
Qué tiene que pasar en esas dos semanas
Los artefactos solo salen si el proceso realmente va a buscar.
Lee el código, no solo la documentación. La documentación describe la intención. El código describe el comportamiento. Donde discrepan, el código es lo que corre en producción.
Mira los datos reales. Perfílalos. Cuenta los nulos, los duplicados, los valores que violan restricciones que la aplicación supuestamente garantiza. Una estimación de migración hecha sin mirar datos es una suposición, y es un término dominante en lo que cuesta el software a medida.
Habla con quienes lo operan. No solo con quienes lo encargan. La persona que corre el trabajo nocturno sabe qué fallo es normal y cuál no, y ese conocimiento no está en el documento de nadie.
Prueba lo riesgoso. Si todo el plan depende de que una API sin documentar responda de cierta manera, dedica un día a probarlo. Un experimento que falla en la semana uno es el fallo más barato disponible.
Qué no puede hacer un discovery
Alinear la expectativa con honestidad importa tanto como el trabajo.
No puede producir un precio cerrado para un sistema con incógnitas reales. Puede producir un precio para la primera fase y un rango para el resto, con los supuestos por escrito. Quien convierte dos semanas de mirar en un número firme para un año de trabajo está poniendo precio al riesgo, y tú lo estás pagando.
No puede resolver un desacuerdo organizacional. Si dos departamentos quieren cosas distintas, el discovery lo va a exponer con claridad y no lo va a zanjar. Esa es una decisión de alguien con autoridad, y el trabajo del discovery es hacer explícito el intercambio.
No sustituye construir. Algunas preguntas solo se responden escribiendo código. La salida correcta es un experimento con nombre en la primera fase, no un discovery más largo.
Después de que termina
El plan debe tener una primera fase que podrías ejecutar con otro equipo, y un punto de parada donde todavía tendrías algo útil. Si la secuencia solo produce valor al final, no es una secuencia, es una única apuesta grande con hitos dibujados encima.
Para un sistema que debe seguir funcionando mientras se reemplaza, esa secuencia es una migración por partes, y el trabajo del discovery es elegir la primera parte.
Si lo estás corriendo como parte de una selección de proveedores, el discovery también es la evaluación: juzga los artefactos por su mérito, que es el enfoque de cómo saber si un proveedor puede construirlo.
Así empiezan nuestros proyectos. Qué producimos y cómo manejamos el acceso a tus sistemas durante ese tiempo está en nuestras prácticas de seguridad, y la forma del trabajo está en desarrollo a medida.