Claves
- Un descubrimiento debe producir decisiones, no solo documentos.
- Espere un mapa de procesos, un primer lanzamiento acotado, un esbozo de arquitectura y una estimación con supuestos.
- Incluya a quienes hacen el trabajo, no solo a quienes lo gestionan.
- Un buen descubrimiento a veces recomienda construir menos, o nada.
En el descubrimiento se fija la mayor parte del coste y el riesgo de un proyecto de software. Una lista de lo que entrega un descubrimiento útil y cómo reconocer uno que no ayuda.
Para qué sirve el descubrimiento
El descubrimiento sustituye supuestos por decisiones antes de que resulten caros. Responde a qué debe hacer el primer lanzamiento, para quién, con qué integraciones, con qué restricciones y cuánto costará de forma realista.
Lo que debería recibir
Un descubrimiento útil termina con unos pocos documentos que su equipo puede leer, cuestionar y aprobar.
- Un mapa de cómo se trabaja hoy y de cómo se trabajará con el nuevo sistema.
- Los roles de usuario y lo que cada uno necesita ver y hacer.
- Un primer lanzamiento acotado, con lo que se deja deliberadamente para después.
- Un inventario de integraciones: cada sistema con el que deberá comunicarse el nuevo, y cómo.
- Un esbozo de arquitectura: modelo de datos, componentes, hosting y enfoque de seguridad.
- Una estimación y un plan, con los supuestos que los sustentan por escrito.
Quién tiene que estar en la mesa
Los responsables describen cómo debería funcionar un proceso. Quienes hacen el trabajo describen cómo funciona de verdad, incluidas las soluciones provisionales que el nuevo sistema tendrá que admitir o eliminar. Hacen falta ambas visiones, y en la segunda suelen esconderse los requisitos importantes.
Señales de alarma
Cada una de estas señales indica que las decisiones difíciles se han aplazado al desarrollo, donde cuestan más.
- Un documento de requisitos que enumera pantallas pero ningún flujo.
- Ningún supuesto por escrito detrás de la estimación.
- Ninguna conversación sobre migración de datos o integraciones.
- Todas las funciones solicitadas están en el primer lanzamiento.
A veces la respuesta es construir menos
Un descubrimiento honesto recomienda a veces un producto estándar, un primer lanzamiento más pequeño o un cambio de proceso en lugar de software. Es un buen resultado: el código más barato es el que nunca hace falta escribir.
¿Le ha gustado? Reciba el próximo por correo.