La bascule du projet au produit est la plus structurante de toutes, et la moins visible. Elle ne se voit ni dans les rituels, ni dans les outils. Elle se voit dans la façon dont l'argent et les équipes sont alloués.
Financer une capacité, pas une livraison
Un projet a un début, une fin, un périmètre et un budget. Il réussit s'il livre ce qui était prévu, dans le temps et le budget prévus. L'équipe est constituée pour lui, puis dissoute.
Un produit vit. Il n'a pas de date de fin. Il réussit s'il crée de la valeur pour ses utilisateurs, et cette valeur se mesure en continu. L'équipe reste, et c'est elle qui accumule la connaissance du domaine.
La question posée à la direction n'est donc pas quelle méthode adoptons-nous, mais finançons-nous une livraison ou une capacité. Tant que la réponse est la première, les rituels agiles se heurteront à la gouvernance.
Deux logiques de gouvernance
| Logique projet | Logique produit | |
|---|---|---|
| L'horizon | Un début, une fin | Continu, tant que le produit vit |
| Ce qu'on finance | Un périmètre | Une équipe et une capacité |
| Le succès | Livrer conforme, dans les délais | Créer de la valeur mesurable |
| L'équipe | Constituée puis dissoute | Stable, elle accumule la connaissance |
| Le pilotage | L'avancement contre le plan | La valeur produite et les retours |
| Le changement | Un avenant | Le mode normal |
| La question | Est-ce livré ? | Est-ce utile ? |
Ce que la stabilité de l'équipe apporte
Une équipe stable connaît son domaine, son code, ses utilisateurs et ses propres angles morts. Cette connaissance ne figure dans aucun document, et elle disparaît intégralement quand l'équipe est dissoute.
C'est le coût caché le plus lourd du fonctionnement par projets, et il n'apparaît sur aucune ligne budgétaire : chaque nouveau projet rachète une connaissance qu'on avait déjà payée.
Quand la logique projet reste la bonne
Il n'y a pas lieu d'être dogmatique. Une migration technique à périmètre connu, une mise en conformité réglementaire, un déménagement de système : ces travaux ont une fin, un périmètre définissable, et la logique projet leur va bien. C'est cohérent avec Cynefin : le compliqué se gère par l'analyse et le plan.
L'erreur n'est pas d'utiliser la logique projet. C'est de l'utiliser sur un produit dont on découvre le besoin en avançant.