« Usines à Fonctionnalités vs Générateurs de Valeur » : différence entre les versions
De Wiki Agile
Aucun résumé des modifications |
|||
| 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. | |||
