Voir la source de Feature Factories vs Value Generators

[[Category: Rôle du Product Manager]]
[[Category: Portail Product Owner]]
Auteur : Itamar Gilad<br />
Source : [https://itamargilad.com/feature-factory/ Feature Factories vs. Value Generators]<br />
Date : 11/12/2023<br/>
----
Traducteur : Fabrice Aimetti<br />
Date : 11/12/2023<br />
----
Traduction :<br />
<br/>
[[Fichier:Cars-factory-by-Alden-Jewell.jpg|border|700px|link=]]<br/>
<small>Image : [https://www.flickr.com/photos/autohistorian/ Alden Jewell]</small><br/>
<br/>
Que nous le voulions ou non, nous sommes nombreux à travailler dans des usines à fonctionnalités (''feature factories''). Nous produisons des fonctionnalités les unes après les autres, en essayant de respecter une feuille de route. Pour certains, c'est tout à fait normal, mais pour d'autres, l'usine à fonctionnalités est devenue le symbole de tout ce qui ne va pas dans le développement traditionnel des produits.<br/>
<br/>
Pourquoi sommes-nous si divisés ? Et qui a raison ?<br/>
<br/>
La théorie des systèmes et une certaine perspective historique peuvent aider à faire la lumière, et peut-être aussi offrir une vision des alternatives. Cela peut sembler un peu théorique au début, mais restez avec moi et je vous promets de rendre cela très rapidement pertinent.<br/>

==Usines traditionnelles==
Voici à quoi ressemble une unité de production, par exemple une usine, du point de vue de la théorie des systèmes.<br/>
<br/>
[[Fichier:Classic-Factory-Model-scaled.jpg|border|700px|link=]]<br/>
''Vue d'une usine selon la théorie des systèmes''<br/>
<br/>
La fonction de l'usine est de transformer les entrées - matériaux, pièces, personnes, machines, etc. - en sorties, c'est-à-dire en unités fabriquées. Invariablement, l'usine produit également des déchets : des restes de matériaux, des sous-produits tels que la chaleur et la pollution, ainsi que des unités défectueuses qui ne sont pas conformes aux spécifications.<br/>
<br/>
Le modèle énonce immédiatement des objectifs clairs (qui sont devenus la marque de fabrique de la gestion d'entreprise classique) :
* Efficacité : améliorer le rapport entre les sorties et les entrées (c'est-à-dire faire plus avec moins).
* Qualité : améliorer le rapport entre les sorties et les déchets
* Débit : augmentation de la capacité de fabrication pour répondre à la demande.  

Le 20e siècle est en effet une histoire d'innovation dans tous ces domaines. Des chaînes de montage de Ford aux usines robotisées d'aujourd'hui, nous avons été en mesure d'augmenter considérablement le débit et la qualité de nos usines, tout en réduisant le coût de production, ce qui a conduit à l'abondance de produits que nous connaissons aujourd'hui.<br/>

==Entrez dans l'usine à fonctionnalités==
Dans les années 1980, les logiciels ont commencé à envahir le monde à un rythme accéléré. Les chefs d'entreprise se sont retrouvés à la tête de sociétés dotées d'un département logiciel (que, pour une raison ou une autre, beaucoup appellent IT), voire à la tête d'une société spécialisée dans les logiciels.<br/> 
<br/>
Pour ces personnes, le modèle de l'usine tenait toujours ; elles devaient créer une unité de production de logiciels (ou équipe de production ~ ''Delivery team'') avec des entrées et des sorties bien définies.<br/>
<br/>
Mais il y a eu quelques complications :
* Dans le domaine du logiciel, il n'y a pas "une seule bonne façon" (''one right way'', terme inventé par le théoricien du management traditionnel Frederick Winslow Taylor) de produire. Contrairement aux travailleurs à la chaîne, on ne peut pas dire aux développeurs de logiciels et aux concepteurs UX comment développer le logiciel parce que chaque projet est nouveau et différent ; c'est à eux qu'il incombe de trouver la solution. Cela signifiait qu'il fallait recruter des personnes plus instruites et leur verser des salaires plus élevés. La semaine-personne est devenue l'unité d'entrée la plus importante.
* Au fur et à mesure que les produits devenaient plus techniques et plus complexes, les responsables ont eu du mal à dire aux développeurs exactement ce qu'ils devaient construire. C'est ainsi qu'est apparu un nouveau rôle, celui de chef produit, ou aujourd'hui de Product Owner, qui, d'un point de vue management traditionnel, est la personne qui traduit les feuilles de route en spécifications que l'équipe de "delivery" peut utiliser. 

Une fois ces deux problèmes résolus, nous avons pu créer l'usine à fonctionnalités :<br/>
[[Fichier:Feature-Factory.jpg|border|700px|link=]]<br/>
''Vue systémique d'une usine de fonctionnalités''<br/>
<br/>
Les managers peuvent désormais se consacrer à l'important travail d'optimisation des résultats par rapport aux moyens mis en œuvre. Vous pouvez voir les résultats tout autour de vous. Certaines optimisations, telles que le cloud computing et la programmation par binôme, sont judicieuses.  D'autres, comme les open space et les évaluations des performances, ont un impact plus discutable. Mais la plus grande innovation en matière de productivité est peut-être venue des ingénieurs eux-mêmes. Le développement Agile a été inventé pour remplacer la gestion de projet classique en cascade par une approche légère et itérative de la création de logiciels. Cependant, les consultants ont progressivement appris qu'ils pouvaient mieux vendre le développement agile en le présentant comme un booster de productivité - plus de code mis en production en moins de temps et d'efforts. Ce fut un succès retentissant. Aujourd'hui, je constate une forte corrélation entre la focalisation sur les résultats et les mises en œuvre maladroites de Scrum et SAFe.<br/>

==Des fissures importantes dans le modèle==
En théorie, le modèle de l'usine à fonctionnalités est tout à fait logique. En pratique, il s'agit d'un modèle très imparfait.<br/>
<br/>
Dans une véritable usine, chaque unité produite - chaque voiture, chaise ou canette de soda - crée une certaine valeur : nous pouvons la vendre et gagner de l'argent. Par conséquent, plus de sortie équivaut à plus de valeur.<br/>
<br/>
Lorsque nous développons des logiciels, les fonctionnalités que nous "produisons" ne sont pas vendues individuellement, mais sont plutôt ajoutées à un produit existant (en ce sens, le développement de logiciels s'apparente davantage au développement d'une ville qu'à la fabrication d'une voiture). Chaque modification apportée au produit est censée créer une certaine valeur ajoutée - plus de transactions, plus de revenus, des gains de temps, etc. Dans l'esprit des industries de nos ancêtres, nous supposons que tout ce que nous choisissons de créer a de la valeur.<br/>
<br/>
Mais est-ce le cas ?<br/>
<br/>
Au cours de la dernière décennie, nous avons commencé à obtenir la réponse.  Les entreprises qui ont utilisé des techniques d'expérimentation A/B pour tester leurs idées ont appris que, dans le meilleur des cas, seule [https://hbr.org/2017/09/the-surprising-power-of-online-experiments une idée sur trois] aboutit à une amélioration mesurable et que, dans la plupart des cas, le taux de réussite est beaucoup plus faible, de l'ordre de [https://vwo.com/blog/cro-industry-insights/ 10% à 15%].<br/>
<br/>
[[Fichier:Success-Rates-Ronny-Kohavi-research.jpg|border|700px|link=]]<br/>
''Taux de réussite des expériences et risques de faux positifs (''False Positive Risks'').  Source : [https://dl.acm.org/doi/10.1145/3534678.3539160 Kohavi et al]''<br/>
<br/>
Mais les mauvaises nouvelles ne s'arrêtent pas là. Chaque fonctionnalité que nous lançons nous revient cher de multiples façons. Outre le coût du développement, il y a aussi le coût du support et de la maintenance de la nouvelle fonctionnalité pendant toute sa durée de vie. Dans une usine de fonctionnalités, les "travailleurs" produisent le produit et en assurent la maintenance. Chaque ajout au produit augmente le coût global de la maintenance et complique également le code source et l'interface utilisateur, ce qui rend le développement futur beaucoup plus lent et compliqué.<br/>
<br/>
La conclusion de ces deux nouveaux facteurs est assez peu intuitive. Lorsque la majeure partie de ce que nous produisons n'a aucune valeur, mais que tout nous coûte de multiples façons, l'optimisation du débit signifie produire plus de déchets, plus rapidement, à un coût toujours plus élevé (voir [https://itamargilad.com/velocity-vs-impact/ cet article] pour des exemples chiffrés).  La voie classique de l'optimisation de l'efficacité, de la qualité et du rendement entraîne les entreprises sur la pente glissante de la production de produits surdimensionnés, difficiles à entretenir et de faible valeur.<br/>
<br/>
Cette réalité n'est pas un secret. C'est la raison pour laquelle le fossé se creuse de plus en plus entre les organisations produit et le management traditionnel. Les PM, les développeurs et les concepteurs savent que le modèle de l'usine à fonctionnalités est terriblement inadapté et souhaitent le remplacer par quelque chose de mieux, tandis que les dirigeants formés au management persistent dans l'approche historique.