Réfléchissons à ce tube de la philosophie d'entreprise:
-
Je veux satisfaire des besoins d'utilisateurs, acheteurs, managers, décideurs.
-
Donc je veux des fonctionnalités.
-
Donc je veux optimiser la production de fonctionnalités.
-
C'est à dire que je veux maximiser la production de fonctionnalités.
Imaginez cette grande banque, qui cherche à régler les problèmes de ses conseillers, voire de ses clients. Avec l'aide de spécialistes à chaque étape, elle a formalisé ces besoins dans un backlog, lancé un appel d’offre, sélectionné un progiciel, lancé le projet, mis en place les contraintes pour s’assurer que tout est livré en temps et en heure, monté et démonté toutes ces équipes.
À chaque étape, elle va s'appuyer sur le fruit du travail investi, validé, et donc juste. On n'a plus qu'une chose à mesurer au moment du développement: la rapidité de production selon les spécifications. Ça sera des story points, des jours.homme, des lignes de code, des tests verts dans la campagne, peu importe.
On maximise la production de fonctionnalités parce qu'on ne veut pas revenir sur ce qui a déjà été validé, et parce qu'on ne sait pas comment gérer plusieurs étapes à la fois. Autrement dit, parce que c’est facile. En conséquence, on mesure qu’on accumule des choses sur des choses accumulées. Cette logique est ainsi la cause de l'échec de la plupart des projets.
Jeff Patton nous apprend que l’objectif est d’optimiser le résultat (i.e. les changements de comportements) pour améliorer l’impact (i.e. les conséquences pour l'organisation), tout en minimisant la production. Il s’agit d’obtenir le maximum d’impact en produisant le moins possible.
Comment faire concrètement ? Comme il est dit plus haut, on maximise la production de fonctionnalités parce que c'est facile. Les solutions seront donc plus difficiles. C'est une bonne nouvelle, qui vous donne l'occasion de prendre un avantage sur la concurrence.
Validation
Il est nécessaire d’avancer calmement, de vérifier l’utilité de ce qu’on produit, de consolider les fondations avant d’ajouter de nouveaux étages.
Comme dit Jim Benson, un logiciel est terminé comme la pelouse est tondue. Le logiciel devient intéressant quand il arrive dans les mains des utilisateurs, et est terminé quand il est décommissioné. Officialisez cela, en ajoutant une étape de validation/compréhension/apprentissage/retour à la fin du flux de fonctionnalités.
En fait, une fonctionnalité à sortir n'est pas du code à produire. C'est une hypothèse pour obtenir un résultat. John Cutler insiste pour qu'on parle de paris. Une fois le code libéré, il s'agit d'en évaluer les conséquences, et de décider comment continuer à partir de là:
-
c'est parfait on s'arrête là
-
on va essayer de modifier telle ou telle chose
-
on a besoin de plus d'infos
-
on désactive ou supprime tout ça
-
etc
Vous noterez au passage que si on doute, comme on le devrait, de l'utilité d'une fonctionnalité, il vaut mieux limiter le nombre d'expériences à lancer en parallèle. En sachant qu'une expérience mettra nécessairement un certain temps à livrer ses secrets. Ce délai est d'ailleurs un sujet de réflexion intéressant, notamment pour comprendre que les expériences dont on parle ne sont pas scientifiques stricto sensu (cynefin parle plutôt de sondage).
Pull system
Posez des limites d'encours sur toutes les étapes du flux, étude/priorisation comprises. Il s'agit de ne pas préparer un item pour l'étape suivante si celle-ci n'est pas prête à le recevoir. On voit bien que le backlog ne grossira pas plus que de raison en adoptant ce comportement:
-
la première étape est une liste priorisée de problèmes, suppositions, idées, souhaits. Ces sujets sont étudiés, par ordre de priorité, quand on a la place de les prendre. C'est à dire quand c'est utile d'en pousser la réflexion.
-
ce n'est qu'à ce moment-là qu'on va poursuivre l'étude: "à quoi ça sert", découpage, précision de l'objectif et des contraintes, partage de compréhension, etc.
-
puis développement si besoin, et tout ce que ça entraîne de tests, déploiement, etc.
-
et enfin validation du besoin, prise d'information pour itérer.
de proche en proche, on tire ainsi les fonctionnalités depuis la dernière étape: l'impact à avoir sur le monde.
Evidemment, ça ne marche que si les items qui traversent le flux sont petits. Petit à quel point ? Si vous débutez, ce n'est jamais trop petit. Si c'est trop petit, améliorez votre process pour diminuer le coût de transaction.
En bref
Corrigeons la logique exprimée plus haut. Au lieu de:
-
les utilisateurs ont des besoins
-
donc nous devons produire des fonctionnalités
-
donc il est bon d'optimiser la production de fonctionnalités
-
c'est à dire que nous devons maximiser la production de fonctionnalités
Essayons plutôt
-
les utilisateurs ont des besoins
-
nous pouvons les satisfaire avec des fonctionnalités
-
donc il est bon d'optimiser la production de fonctionnalités et l'impact
-
c'est à dire que nous devons minimiser la production de fonctionnalités et maximiser l'impact
Quand vous utilisez un produit, vous êtes ravi d'avoir sous les yeux la fonctionnalité dont vous avez besoin. Et c'est une excellente surprise de l'utiliser de manière fluide, comme vous anticipez qu'elle fonctionne. Ça change des produits qui croulent sous les menus et sous menus à force d'entasser les options, les formulaires sans fin pour supporter chaque possibilité imaginée, ôkazou.
Produisez ce que vous aimez utiliser:
-
vérifiez que les fonctionnalités sont utiles
-
faites peu de choses à la fois, et terminez-les
-
focalisez sur vos utilisateurs
Il n'est jamais trop tard pour bien faire.
1 comment for “Production frugale”