Usines à Fonctionnalités vs Générateurs de Valeur - Historique des versions

Fabrice Aimetti : Fabrice Aimetti a déplacé la page Feature Factories vs Value Generators vers Usines à Fonctionnalités vs Générateurs de Valeur sans laisser de redirection

2025-08-13T10:22:11Z

Fabrice Aimetti a déplacé la page Feature Factories vs Value Generators vers Usines à Fonctionnalités vs Générateurs de Valeur sans laisser de redirection

← Version précédente		Version du 13 août 2025 à 10:22
(Aucune différence)

Fabrice Aimetti le 10 mars 2024 à 14:13

2024-03-10T14:13:23Z

← Version précédente		Version du 10 mars 2024 à 14:13
Ligne 1 :		Ligne 1 :
			[[Catégorie:Itamar Gilad]]
	[[Category: Rôle du Product Manager]]		[[Category: Rôle du Product Manager]]
	[[Category: Portail Product Owner]]		[[Category: Portail Product Owner]]

Fabrice Aimetti : /* Entrez dans l'usine à fonctionnalités */

2023-12-11T13:18:25Z

Entrez dans l'usine à fonctionnalités

← Version précédente		Version du 11 décembre 2023 à 13:18
Ligne 41 :		Ligne 41 :
	Mais il y a eu quelques complications :		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.		* 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.		* 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 Product Manager, 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/>		Une fois ces deux problèmes résolus, nous avons pu créer l'usine à fonctionnalités :<br/>

Fabrice Aimetti le 11 décembre 2023 à 13:17

2023-12-11T13:17:39Z

← Version précédente		Version du 11 décembre 2023 à 13:17
Ligne 20 :		Ligne 20 :

	==Usines traditionnelles==		==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/>		Voici à quoi ressemble une unité de production, par exemple une usine, du point de vue de la [https://en.wikipedia.org/wiki/Systems_theory théorie des systèmes].<br/>
	<br/>		<br/>
	[[Fichier:Classic-Factory-Model-scaled.jpg\|border\|700px\|link=]]<br/>		[[Fichier:Classic-Factory-Model-scaled.jpg\|border\|700px\|link=]]<br/>

Fabrice Aimetti le 11 décembre 2023 à 13:15

2023-12-11T13:15:03Z

← Version précédente		Version du 11 décembre 2023 à 13:15
Ligne 68 :		Ligne 68 :
	<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.		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.

			==Créateurs de valeur==
			Les meilleures entreprises de produits utilisent un tout autre modèle mental. '''Elles poursuivent des objectifs, et non des feuilles de route, et elles optimisent les résultats, et non les fonctionnalités'''. Elles considèrent leurs organisations de produits (qui sont presque toujours divisées en équipes produits interfonctionnelles semi-autonomes) non pas comme des producteurs de code, mais comme des créateurs de valeur - de la valeur pour l'entreprise et de la valeur pour les clients. L'organisation produit moderne produit non seulement des résultats, mais aussi des connaissances dans le domaine - une ressource critique pour le succès.<br/>
			<br/>
			[[Fichier:Value-Generator.jpg\|border\|700px\|link=]]<br/>
			''Vue systémique de l'organisation produit en tant que modèle de création de valeur''<br/>
			<br/>
			Ce changement entraîne une rupture encore plus importante avec l'approche traditionnelle du management. '''On ne dit plus à l'organisation produit ce qu'elle doit faire (comme dans une feuille de route), mais plutôt ce qu'elle doit réaliser (comme dans des objectifs basés sur les résultats). La délégation et la confiance jouent un rôle clé.'''<br/>
			<br/>
			Le changement va dans les deux sens. L'équipe produit doit cesser de se considérer comme une unité de production (vous seriez surpris de voir combien d'entre elles le pensent). Notre travail ne consiste plus seulement à travailler tête baissée à l'élaboration de fonctionnalités conformément à des spécifications. L'organisation produit doit produire de la traction vers les objectifs, et cette traction doit être communiquée clairement au reste de l'entreprise (ce qui contribue à créer de la confiance). [https://itamargilad.com/resources/idea-testing-ebook/ L'expérimentation] et [https://itamargilad.com/the-tool-that-will-help-you-choose-better-product-ideas/ les preuves] jouent un rôle majeur.<br/>
			<br/>
			(Pour avoir une idée de ce à quoi ressemble ce monde, jetez un coup d'œil au [http://itamargilad.com/gist-framework cadre de travail GIST]).<br/>
			<br/>
			De manière encore plus large, le silotage classique entre le management, le développement et l'entreprise doit disparaître. Comme je l'ai [https://itamargilad.com/5-tips-for-building-effective-product-management-teams/ déjà écrit], notre objectif devrait être de briser les murs et de faire en sorte que l'ensemble de l'entreprise travaille ensemble à la réalisation d'objectifs communs - créer de la valeur pour l'entreprise et pour les clients.<br/>
			<br/>
			Certains managers avant-gardistes avec lesquels je m'entretiens souhaitent vraiment passer à ce modèle. Mais ils sont freinés par la pensée traditionnelle. Je vois beaucoup d'OKR concernant l'amélioration de l'efficacité et de la productivité. De nombreux CTO considèrent que l'objectif principal est de faire travailler les développeurs à 100% de leur capacité et poussent leurs équipes à livrer plus de points de user stories par sprint. Bien qu'il n'y ait rien de mal à cela en soi, il s'agit au mieux d'optimisations de second ordre, et au pire d'importantes sources de gaspillage. La meilleure optimisation consiste à rechercher '''un ratio plus élevé de lancements à valeur positive'''. Si vous embrassez cet objectif, beaucoup de choses que vous faites aujourd'hui n'auront plus de sens. Il s'agit de la première étape d'un long voyage visant à mettre un terme au modèle obsolète de l'usine à fonctionnalités.

Fabrice Aimetti : /* Des fissures importantes dans le modèle */

2023-12-11T13:00:37Z

Des fissures importantes dans le modèle

← Version précédente		Version du 11 décembre 2023 à 13:00
Ligne 67 :		Ligne 67 :
	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/>		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/>		<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.

Fabrice Aimetti le 11 décembre 2023 à 12:58

2023-12-11T12:58:00Z

← Version précédente		Version du 11 décembre 2023 à 12:58
Ligne 58 :		Ligne 58 :
	Mais est-ce le cas ?<br/>		Mais est-ce le cas ?<br/>
	<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 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 10% à 15%.<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/>		<br/>
	[[Fichier:Success-Rates-Ronny-Kohavi-research.jpg\|border\|700px\|link=]]<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/>		''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/>		<br/>

Fabrice Aimetti : /* Des fissures importantes dans le modèle */

2023-12-11T12:53:34Z

Des fissures importantes dans le modèle

← Version précédente		Version du 11 décembre 2023 à 12:53
Ligne 61 :		Ligne 61 :
	<br/>		<br/>
	[[Fichier:Success-Rates-Ronny-Kohavi-research.jpg\|border\|700px\|link=]]<br/>		[[Fichier:Success-Rates-Ronny-Kohavi-research.jpg\|border\|700px\|link=]]<br/>
	''Taux de réussite des expériences et risques de faux positifs. Source : [https://dl.acm.org/doi/10.1145/3534678.3539160 Kohavi et al]''<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/>		<br/>

Fabrice Aimetti le 11 décembre 2023 à 12:52

2023-12-11T12:52:50Z

@@ Ligne 48 : / Ligne 48 : @@
 <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/>
 <br/>

Fabrice Aimetti le 11 décembre 2023 à 12:48

2023-12-11T12:48:26Z

← Version précédente		Version du 11 décembre 2023 à 12:48
Ligne 46 :		Ligne 46 :
	[[Fichier:Feature-Factory.jpg\|border\|700px\|link=]]<br/>		[[Fichier:Feature-Factory.jpg\|border\|700px\|link=]]<br/>
	''Vue systémique d'une usine de fonctionnalités''<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/>
	<br/>		<br/>

Usines à Fonctionnalités vs Générateurs de Valeur - Historique des versions

Fabrice Aimetti : Fabrice Aimetti a déplacé la page Feature Factories vs Value Generators vers Usines à Fonctionnalités vs Générateurs de Valeur sans laisser de redirection

Fabrice Aimetti le 10 mars 2024 à 14:13

Fabrice Aimetti : /* Entrez dans l'usine à fonctionnalités */

Fabrice Aimetti le 11 décembre 2023 à 13:17

Fabrice Aimetti le 11 décembre 2023 à 13:15

Fabrice Aimetti : /* Des fissures importantes dans le modèle */

Fabrice Aimetti le 11 décembre 2023 à 12:58

Fabrice Aimetti : /* Des fissures importantes dans le modèle */

Fabrice Aimetti le 11 décembre 2023 à 12:52

Fabrice Aimetti le 11 décembre 2023 à 12:48

Fabrice Aimetti : Fabrice Aimetti a déplacé la page Feature Factories vs Value Generators vers Usines à Fonctionnalités vs Générateurs de Valeur sans laisser de redirection

Fabrice Aimetti : /* Entrez dans l'usine à fonctionnalités */

Fabrice Aimetti : /* Des fissures importantes dans le modèle */

Fabrice Aimetti : /* Des fissures importantes dans le modèle */