Ce qu'une phase de cadrage payante doit vous livrer

Le cadrage sert à trancher les grandes décisions tant qu'elles coûtent peu

Le cadrage, aussi appelé phase de discovery ou de scoping, est une courte phase payante avant le développement d'un logiciel. Son rôle est de lever l'incertitude qui rend les estimations peu fiables et de trancher les grandes décisions tant qu'elles sont encore peu coûteuses à changer. Changer une décision sur le papier coûte une conversation ; la changer une fois le code écrit coûte du travail refait.

Les premières estimations d'un logiciel sont larges, et elles ne se resserrent qu'à mesure que les décisions lèvent l'incertitude, un effet souvent appelé le cône d'incertitude. Les réunions seules ne les resserrent pas. Le cadrage vaut la peine d'être payé quand il force ces décisions : ce que le produit doit faire en premier, quelles contraintes sont fixes et quels risques techniques sont réels.

Convenez de ce que vous recevrez avant que le cadrage commence

Achetez le cadrage comme n'importe quel autre livrable : une durée fixe, un prix fixe, des personnes nommées et une liste écrite des livrables. Si un partenaire ne peut pas dire ce que vous aurez entre les mains à la fin, la phase peut dériver en ateliers sans fin. Un ensemble complet de livrables couvre généralement les points suivants.

• Un énoncé du problème : qui sont les utilisateurs, ce dont ils ont besoin et comment le succès sera mesuré
• Le périmètre de la première version : ce qui est dedans, ce qui est dehors et ce qui est reporté
• Les principaux parcours utilisateurs, esquissés ou prototypés là où ils sont incertains
• Une esquisse d'architecture : composants principaux, intégrations, données et hébergement, avec les options envisagées
• Un registre des risques classant ce qui pourrait faire échouer le projet, et comment chaque risque sera traité
• Une estimation en fourchette avec ses hypothèses, et un premier jalon avec ses critères de recette
• Un journal des décisions indiquant ce qui a été décidé, par qui et pourquoi

Cherchez des décisions, pas une pile de documents

Un rapport de cadrage peut être long et ne rien décider. Lisez-le pour ses engagements : quelles fonctionnalités font partie de la première version et lesquelles n'en font pas partie, quels choix de technologie et d'hébergement sont faits, quelles intégrations sont nécessaires, et quelles questions restent ouvertes, chacune avec un responsable et une date.

Un signal utile est ce que le partenaire a déconseillé. Si le périmètre est plus large à la fin qu'au début et que rien n'a été retiré, le cadrage a probablement enregistré votre liste de souhaits au lieu de la mettre à l'épreuve. Parfois, la bonne conclusion est d'acheter un produit existant, de construire moins ou de ne rien construire du tout, et un bon cadrage le dit.

Les hypothèses les plus risquées doivent être testées, pas seulement listées

Chaque projet repose sur quelques hypothèses qui changeraient tout si elles étaient fausses : une API externe qui ne permet pas l'opération dont vous avez besoin, des données plus désordonnées que prévu, un objectif de performance que la conception choisie ne peut pas tenir, ou des utilisateurs qui ne changeront pas leur façon de travailler.

Demandez au partenaire de nommer ces hypothèses tôt et de tester les pires pendant le cadrage, avec un spike technique, un prototype cliquable ou une séance de travail avec les personnes qui exploitent le système concerné. Un risque testé est une information. Un risque seulement écrit reste une supposition.

Une estimation honnête est une fourchette accompagnée de ses hypothèses

Un chiffre unique à la fin du cadrage masque l'incertitude qui demeure. Demandez une fourchette pour la première version, détaillée par composant principal, avec les hypothèses qui la feraient monter ou descendre. Par exemple : l'estimation suppose que l'API du prestataire de paiement gère déjà les remboursements partiels ; si ce n'est pas le cas, ajoutez le travail d'intégration indiqué à part.

Demandez quelles parties de l'estimation sont fermes et lesquelles restent incertaines, et comment le modèle commercial traitera chacune. Les parties fermes peuvent être chiffrées au forfait ; les parties incertaines ont besoin d'un budget et d'un moment où vous décidez à nouveau. Le premier jalon doit être assez bien spécifié pour pouvoir être livré au forfait.

Gardez une porte de sortie à chaque étape

Le cadrage est aussi le moment le moins coûteux pour partir. Assurez-vous que tout ce qu'il produit vous appartient, des documents et schémas aux prototypes et au code, et que les livrables sont écrits pour n'importe quelle équipe compétente, pas seulement pour le partenaire qui les a rédigés. Vous devez rester libre de construire avec ce partenaire, de confier les résultats à une autre équipe, de développer en interne ou d'arrêter.

Appliquez la même idée au plan qui suit : un premier jalon avec ses critères de recette, puis un point de décision où vous pouvez continuer, changer de cap ou mettre fin à la collaboration. C'est ainsi que nous démarrons les projets chez SDK Enterprises : un périmètre écrit, un premier jalon fixe et les ingénieurs nommés, pour que vous voyiez le plan avant de vous engager sur un budget plus important. Quand vous avez seulement besoin d'un conseil, vous recevez une réponse écrite sur laquelle votre équipe peut agir, que vous construisiez avec nous ou non.

Six questions pour savoir si le cadrage valait son prix

À la fin de la phase, confrontez les résultats à ces questions. Si la plupart des réponses sont oui, l'argent a acheté de la clarté. Si la plupart sont non, vous avez payé des ateliers.

• Une autre équipe pourrait-elle commencer à construire à partir de ces livrables sans refaire le cadrage ?
• Le partenaire a-t-il parlé aux utilisateurs et aux personnes qui exploitent les systèmes concernés, pas seulement au sponsor ?
• Les hypothèses les plus risquées ont-elles été testées, avec des résultats écrits ?
• L'estimation est-elle une fourchette aux hypothèses claires plutôt qu'un chiffre unique ?
• Quelque chose a-t-il été retiré, reporté ou remis en question ?
• Le premier jalon est-il assez bien spécifié pour être accepté ou refusé ?

FAQ