Comment cadrer un projet logiciel

Presque tous les dépassements de budget ont la même cause profonde : le projet n'a jamais vraiment été cadré. Le travail a démarré sur une compréhension vague et partagée, qui s'est révélée différente selon que l'on était côté client ou côté équipe — et cet écart est remonté à la surface sous forme de dépassements et de conversations difficiles. Un bon cadrage n'est pas de la bureaucratie : c'est l'assurance la moins chère qui soit contre un projet qui déraille.

Le périmètre, c'est une définition commune de « terminé »

L'objectif du cadrage est un document sur lequel les deux parties s'accordent sincèrement : ce qui sera construit, ce qui ne le sera pas, et comment on saura que c'est fini. Si le client et l'équipe décrivent le livrable différemment, vous n'avez pas de périmètre — vous avez un malentendu qui attend d'être découvert en plein milieu du développement.

Commencez par les résultats, pas par les fonctionnalités

Partez des résultats que le projet doit atteindre, et non d'une liste de fonctionnalités. « Les clients peuvent souscrire et gérer leur facturation eux-mêmes » est un résultat. « Ajouter une page de facturation » est une fonctionnalité qui peut, ou non, permettre de l'atteindre. Raisonner en termes de résultats maintient la conversation centrée sur la valeur, et rend évident le fait qu'une fonctionnalité proposée n'en sert aucun.

À partir de chaque résultat, déduisez les fonctionnalités réellement nécessaires pour l'atteindre, et repérez celles qui ne correspondent à aucun résultat. Ce sont généralement les premières à supprimer.

Écrivez ce qui est hors périmètre

La section la plus précieuse d'un document de cadrage est celle qui décrit ce qu'il exclut. Lister explicitement ce que vous ne construisez pas dans cette phase empêche l'expansion lente et silencieuse qui sabote les délais.

• Nommez les fonctionnalités tentantes que vous reportez délibérément.
• Précisez les intégrations, plateformes et cas limites que vous ne traitez pas encore.
• Consignez les hypothèses — si l'une s'avère fausse, c'est un changement de périmètre, et cela doit être acté.

Estimez par fourchettes, avec une marge

Les estimations à chiffre unique sont une fausse précision. Estimez par fourchettes qui reflètent l'incertitude réelle, et ajoutez une marge explicite pour les inconnues que vous ne pouvez pas encore voir. Décomposez le travail en morceaux suffisamment petits pour être estimés honnêtement — tout ce que vous ne pouvez pas estimer est une tâche de recherche déguisée en tâche de développement, et doit faire l'objet d'un spike séparé au préalable.

Faites du contrôle des changements un processus prévu, pas une exception

Le périmètre va évoluer — les exigences changent toujours à mesure que tout le monde apprend. L'erreur est d'absorber les changements en silence jusqu'à ce que le budget s'évapore discrètement. Convenez plutôt dès le départ d'un processus simple :

1. Un changement est proposé et consigné par écrit.
2. Son impact sur les délais et les coûts est estimé.
3. Les deux parties décident de l'intégrer, de le reporter ou de l'échanger contre autre chose.

Le contrôle des changements n'est pas un frein. C'est ce qui vous permet de dire oui aux changements sans mentir sur les délais.

Phasez pour livrer de la valeur rapidement

Cadrez la plus petite tranche cohérente qui délivre une valeur réelle, livrez-la, puis cadrez la suivante. Le phasage fait remonter les mauvaises hypothèses pendant qu'elles sont encore peu coûteuses à corriger, et met un logiciel fonctionnel entre les mains des utilisateurs bien plus tôt qu'une livraison en mode big-bang.

Chez Pykero, nous cadrons de façon transparente — résultats, exclusions, fourchettes et processus de changement — pour que les budgets tiennent et qu'il n'y ait pas de mauvaises surprises en fin de projet. Si vous planifiez un développement, parlons-en.