Ce qu'une bonne phase de découverte doit produire

À quoi sert la découverte

La découverte remplace les hypothèses par des décisions avant qu'elles ne coûtent cher. Elle répond à ce que le premier livrable doit faire, pour qui, avec quelles intégrations, sous quelles contraintes – et à ce qu'il coûtera de façon réaliste.

Ce que vous devez recevoir

Une découverte utile se termine par quelques documents que votre équipe peut lire, contester et valider.

• Une cartographie de la façon dont le travail se fait aujourd'hui et se fera dans le nouveau système.
• Les rôles utilisateurs et ce que chacun doit voir et faire.
• Un premier livrable délimité, avec ce qui est volontairement reporté.
• Un inventaire des intégrations : chaque système avec lequel le nouveau devra communiquer, et comment.
• Une esquisse d'architecture : modèle de données, composants, hébergement et approche de sécurité.
• Une estimation et un plan, avec les hypothèses sous-jacentes écrites.

Qui doit être autour de la table

Les managers décrivent comment un processus devrait fonctionner. Les personnes qui font le travail décrivent comment il fonctionne vraiment – y compris les contournements que le nouveau système devra prendre en charge ou supprimer. Les deux points de vue sont nécessaires, et c'est généralement dans le second que se cachent les exigences importantes.

Les signaux d'alerte

Chacun de ces signaux indique que les décisions difficiles ont été reportées au développement, où elles coûtent plus cher.

• Un cahier des charges qui liste des écrans mais aucun flux.
• Aucune hypothèse écrite derrière l'estimation.
• Aucune discussion sur la migration des données ou les intégrations.
• Toutes les fonctionnalités demandées figurent dans le premier livrable.

Parfois, la réponse est de construire moins

Une découverte honnête recommande parfois un produit du marché, un premier livrable plus petit ou un changement de processus plutôt qu'un logiciel. C'est un bon résultat : le code le moins cher est celui qu'on n'a jamais besoin d'écrire.