Qué debe entregar una fase de descubrimiento de pago

El descubrimiento sirve para tomar las grandes decisiones mientras son baratas

El descubrimiento, también llamado definición del alcance o fase de inception, es una fase breve y de pago previa al desarrollo de un software. Su función es eliminar la incertidumbre que hace poco fiables las estimaciones y cerrar las grandes decisiones mientras todavía es barato cambiarlas. Cambiar una decisión sobre el papel cuesta una conversación; cambiarla con el código ya escrito cuesta rehacer trabajo.

Las primeras estimaciones de software son amplias y solo se estrechan a medida que las decisiones eliminan incertidumbre, un efecto que suele llamarse cono de incertidumbre. Las reuniones por sí solas no las estrechan. Merece la pena pagar el descubrimiento cuando obliga a tomar esas decisiones: qué debe hacer primero el producto, qué restricciones son fijas y qué riesgos técnicos son reales.

Acuerde lo que recibirá antes de que empiece el descubrimiento

Compre el descubrimiento como cualquier otro entregable: una duración fija, un precio fijo, personas con nombre y una lista escrita de resultados. Si un socio no sabe decir qué tendrá usted en las manos al final, la fase puede derivar en talleres sin fin. Un conjunto completo de resultados suele cubrir lo siguiente.

• Una definición del problema: quiénes son los usuarios, qué necesitan y cómo se medirá el éxito
• El alcance de la primera versión: qué entra, qué queda fuera y qué se aplaza
• Los recorridos clave de los usuarios, esbozados o prototipados donde hay dudas
• Un esquema de arquitectura: componentes principales, integraciones, datos y alojamiento, con las opciones consideradas
• Un registro de riesgos que ordene lo que podría hacer fracasar el proyecto y cómo se gestionará cada riesgo
• Una estimación en forma de horquilla con sus hipótesis, y un primer hito con criterios de aceptación
• Un registro de decisiones que recoja qué se decidió, quién lo decidió y por qué

Busque decisiones, no un montón de documentos

Un informe de descubrimiento puede ser largo y no decidir nada. Léalo buscando compromisos: qué funcionalidades entran en la primera versión y cuáles no, qué decisiones de tecnología y de alojamiento se han tomado, qué integraciones hacen falta y qué preguntas siguen abiertas, cada una con un responsable y una fecha.

Una señal útil es lo que el socio desaconsejó. Si al final el alcance es mayor que al principio y no se ha recortado nada, lo más probable es que el descubrimiento haya registrado su lista de deseos en lugar de ponerla a prueba. A veces la conclusión correcta es comprar un producto existente, construir menos o no construir nada, y una buena fase de descubrimiento lo dice.

Los supuestos más arriesgados deben probarse, no solo enumerarse

Todo proyecto descansa en unos pocos supuestos que lo cambiarían todo si fueran falsos: una API externa que no admite la operación que necesita, unos datos más desordenados de lo previsto, un objetivo de rendimiento que el diseño elegido no puede alcanzar o unos usuarios que no van a cambiar su forma de trabajar.

Pida al socio que identifique pronto esos supuestos y que pruebe los peores durante el descubrimiento, con una prueba técnica exploratoria (spike), un prototipo navegable o una sesión de trabajo con las personas que gestionan el sistema en cuestión. Un riesgo que se ha probado es información. Un riesgo que solo se ha puesto por escrito sigue siendo una conjetura.

Una estimación honesta es una horquilla con sus hipótesis

Una única cifra al final del descubrimiento oculta la incertidumbre que queda. Pida una horquilla para la primera versión, desglosada por componente principal, con las hipótesis que la harían subir o bajar. Por ejemplo: la estimación supone que la API del proveedor de pagos ya admite reembolsos parciales; si no es así, hay que añadir el trabajo de integración que figura aparte.

Pregunte qué partes de la estimación son firmes y cuáles siguen siendo inciertas, y cómo tratará cada una el modelo comercial. Las partes firmes pueden ir a precio cerrado; las inciertas necesitan un presupuesto y un momento en el que usted vuelva a decidir. El primer hito debería estar especificado con el detalle suficiente como para poder entregarse a precio cerrado.

Mantenga una vía de salida en cada paso

El descubrimiento es también el momento más barato para irse. Asegúrese de que es suyo todo lo que produce, desde documentos y diagramas hasta prototipos y código, y de que los resultados están escritos para cualquier equipo competente, no solo para el socio que los redactó. Debe tener libertad para construir con ese socio, entregar los resultados a otro equipo, desarrollar internamente o parar.

Lleve la misma idea al plan que sigue: un primer hito con criterios de aceptación y, después, un punto de decisión en el que pueda continuar, cambiar de rumbo o terminar la colaboración. Así empezamos los proyectos en SDK Enterprises: un alcance por escrito, un primer hito fijo y los ingenieros identificados por su nombre, para que vea el plan antes de comprometer un presupuesto mayor. Cuando solo necesita asesoramiento, recibe una respuesta escrita con la que su propio equipo puede actuar, construya o no con nosotros.

Seis preguntas para saber si valió la pena pagar el descubrimiento

Cuando termine la fase, contraste los resultados con estas preguntas. Si la mayoría de las respuestas son afirmativas, el dinero compró claridad. Si la mayoría son negativas, pagó unos talleres.

• ¿Podría otro equipo empezar a construir a partir de estos resultados sin repetir el descubrimiento?
• ¿Habló el socio con los usuarios y con las personas que gestionan los sistemas implicados, y no solo con el promotor del proyecto?
• ¿Se probaron los supuestos más arriesgados y se pusieron por escrito los resultados?
• ¿La estimación es una horquilla con hipótesis claras y no una única cifra?
• ¿Se recortó, aplazó o cuestionó algo?
• ¿Está el primer hito especificado con el detalle suficiente para aceptarlo o rechazarlo?

Preguntas frecuentes