Dans la première partie de cette série , nous avons abordé les nombreux problèmes associés au modèle traditionnel de financement de projet, en mentionnant que les organisations doivent s'éloigner des projets et se tourner vers le modèle de produit. Maintenant, entrons dans les détails pour savoir pourquoi ce changement est si critique.
Pourquoi passer des projets aux produits ?
Le modèle de produit offre une approche alternative qui aide les organisations à fournir plus de valeur, plus rapidement, et à un niveau plus élevé de qualité durable en abordant les problèmes mentionnés ci-dessus. De plus, l'état d'esprit produit accorde également plus d'importance à l'innovation et à l'amélioration, ce qui permet à l'organisation de rester alignée sur les besoins du client. Pour ce faire, elle s'éloigne des équipes temporaires remplies de personnes empruntées et les remplace par des équipes transversales semi-permanentes composées de compétences provenant de tous les départements concernés, chaque équipe étant alignée sur un produit ou un flux de valeur de l'entreprise .
L'objectif du modèle de produit (ou modèle de flux de valeur) est de créer des équipes capables d'effectuer au moins 80% du travail qui leur est confié sans avoir besoin d'aide supplémentaire. Ainsi, il est courant que les organisations de développement de logiciels qui suivent ce modèle aient des équipes composées de.. :
- Gestionnaires de produits
- Designers
- Développeurs front-end et back-end
- Testeurs de qualité
- Personnel de déploiement
- Toute autre personne nécessaire à la réalisation de la majorité de la livraison des travaux
Cela permet de créer des équipes autonomes capables de travailler à toutes les étapes du développement d'un produit, de la vision à la valeur, sans avoir besoin d'aide supplémentaire. De plus, le fait de passer des projets au développement de produits permet d'abattre les silos départementaux et de créer un système qui favorise une véritable collaboration.
Au lieu d'emprunter des travailleurs pour des missions temporaires, les équipes sont placées dans une situation saine où leur objectif n'est pas simplement de mener à bien des projets, mais de travailler ensemble pour s'assurer que la valeur est constamment fournie pour leur produit ou leur flux de valeur à un niveau de qualité élevé et constant, et qu'elles disposent de la connaissance du domaine et des relations pour garantir que les résultats sont optimisés pour répondre aux besoins du client.
Sous le modèle SAFe®, ces équipes sont généralement composées d'environ 10 personnes, et le travail est assigné à l'équipe entière, et non à des membres individuels. Les équipes travaillent en utilisant Scrum ou Kanban, mais les membres de font toujours partie de la même équipe, quelle que soit la livraison du travail.
Il est important de s'assurer que les gens ne travaillent pas avec plus d'une équipe, car cela amène les départements à se faire concurrence pour la capacité, empêchant les gens de consacrer leur temps et leurs efforts à fournir un travail efficace.
Dans une petite organisation avec des produits plus petits et une architecture technologique moderne découplée, ces équipes transversales autonomes peuvent être tout ce qui est nécessaire pour atteindre l'agilité commerciale. Mais dans de nombreux cas, les grandes organisations doivent faire face à de grands produits complexes avec des architectures héritées qui nécessitent véritablement de nombreuses équipes coordonnées travaillant ensemble pour apporter une réelle valeur ajoutée. Dans ce cas, les équipes Agile sont regroupées en "équipes d'équipes". SAFe les appelle Agile Release Trains (ARTs pour faire court). Vous les verrez appelés vols, tribus, ailes et tout autre terme local, mais dans tous les cas, ils sont généralement composés de 5-12 équipes et de 50-125 personnes travaillant sur des objectifs technologiques et commerciaux communs, afin que l'organisation puisse répondre aux changements et fournir de la valeur plus efficacement.
Le résultat final est un modèle d'entreprise qui privilégie le retour d'information et l'adaptabilité plutôt que la planification prédictive. Ainsi, les organisations sont mieux équipées pour rester en phase avec les besoins et les attentes de leurs clients, afin de pouvoir apporter de la valeur ajoutée et traiter les points douloureux plus efficacement.
Réaffecter la capacité ?
Alors que les équipes sont censées rester ensemble et alignées sur un domaine d'activité pendant de longues périodes dans le modèle de produit, cela ne signifie pas pour toujours. Il est toujours judicieux de concentrer la capacité de production là où elle profitera le plus à l'entreprise.
Dans le modèle de financement de projet, cette réaffectation se produit lorsque les projets se terminent, que les anciennes équipes sont dissoutes et que de nouvelles sont formées pour de nouveaux travaux.
Dans le modèle de produit, l'idée est de réaffecter la capacité à une cadence basée sur les résultats commerciaux.
Dans la mesure du possible, les organisations qui suivent SAFe® et d'autres modèles Agile échelonnés placeront leurs équipes et leurs équipes d'équipes sur une cadence partagée. Les sprints Scrum bihebdomadaires sont synchronisés. Les événements de planification des grandes salles de moyenne envergure, à peu près trimestriels, sont également synchronisés. Ces cadences rendent la coordination au sein des équipes et avec les clients beaucoup plus facile à gérer. Ils constituent également des points de rupture parfaits pour transférer la capacité entre les produits ou les flux de valeur avec un minimum de perturbations.
Mais comment savoir si ou où déplacer la capacité ?
Les résultats plutôt que la production
Dans un modèle de produit, chaque produit ou flux de valeur devrait établir un ensemble lié d'indicateurs précoces et de mesures de l'entonnoir qui ont du sens pour leur aspect de l'entreprise. Ceux-ci devraient finalement conduire à des revenus ou à des économies ou à une autre mesure du résultat net. Mais ces types de métriques P&L sont souvent trop lents pour être utiles au pilotage, prenant de nombreux trimestres pour évoluer de manière suffisamment significative pour nous indiquer comment les choses se passent. Les indicateurs précoces et les mesures de l'entonnoir ne sont pas aussi définitifs, mais ils évoluent beaucoup plus rapidement, nous fournissant des données pour la prise de décision.
Voici quelques exemples d'indicateurs précoces :
- le nombre de personnes qui utilisent un aspect nouveau ou modifié d'un système
- le temps qu'ils passent sur un écran spécifique
- la charge que les utilisateurs imposent au système, telle qu'indiquée par nos systèmes de surveillance
- le nombre de tickets d'assistance (en hausse ou en baisse) liés aux divers aspects du système que nous avons modifiés
- les commentaires sur les médias sociaux
Lorsque nous apportons des modifications à nos produits, à condition que nous ayons investi dans une instrumentation suffisante, nous pouvons dire très rapidement si nos clients ont remarqué et profité des améliorations, et s'ils les considèrent comme des améliorations tout court. Les bons indicateurs précoces ne prouvent pas que nous obtiendrons de meilleurs résultats financiers, mais ils suggèrent que nous avons généré de la valeur pour les clients. Et l'absence d'indicateurs précoces devrait être un énorme signal d'alarme indiquant que nous gaspillons de l'argent et que nous devrions repenser nos hypothèses.
Si nous faisons les choses correctement, les indicateurs précoces mèneront à des résultats à moyen terme qui, même s'ils ne sont pas encore des mesures traditionnelles du P&L, sont beaucoup plus liés mathématiquement de manière semi-prévisible. Pour une entreprise typique de logiciels SaaS, un entonnoir pourrait ressembler à ceci :
- Un certain nombre de visiteurs du site Web téléchargeront un contenu quelconque.
- Parmi ceux-ci, un certain pourcentage s'inscrira pour un essai du produit.
- Parmi les comptes d'essai créés, un certain pourcentage sera encore actif quelques jours plus tard.
- Parmi ces essais actifs, un certain nombre prendra contact avec notre équipe de vente pour engager une conversation d'achat.
- Nous convertirons un pourcentage de ceux-ci en comptes payants après un nombre X de jours en moyenne.
- Notre nouveau compte typique commencera avec un nombre Y d'utilisateurs et passera généralement à un nombre Z d'utilisateurs en un an.
- Et, compte tenu d'un prix moyen du siège, cela signifie que nous générerons un certain montant de recettes au cours de l'année 1 d'un compte
On pourrait pousser l'idée plus loin, mais vous voyez l'idée. Chacun de ces rapports sera imparfait. Mais ils seront suffisamment prévisibles pour que nous puissions raisonnablement deviner comment un changement dans les résultats en amont de l'entonnoir se répercutera sur les résultats en aval. Plutôt que d'évaluer chaque travail potentiel de manière indépendante au fur et à mesure qu'une analyse de rentabilité passe sur nos bureaux, nous pouvons orienter nos efforts vers les changements qui auront un impact sur notre entonnoir. Et comme chacun connaît l'entonnoir, tous les membres de nos équipes sont mieux placés pour concentrer leurs efforts sur les résultats qui profiteront à l'ensemble.
Investir là où nous voyons de vrais résultats
Over time, we can use these funnel metrics to drive decision making within our teams and the product or value stream they support. We can also use them to help decide where to shift capacity. If one area of our business has had 10 teams for a year and generated flat results in their funnel metrics and another has had half that capacity and produced 50 % improvements, wouldn’t it make sense to move some teams? We may not know exactly which features produced those results. It doesn’t necessarily mean the people managing the first value stream are making bad decisions. But we can clearly see where we have productive investment opportunities and where we don’t. And we can shift teams accordingly.
L'approche centrée sur le produit permet aux équipes et aux individus de s'approprier davantage leur travail et leurs responsabilités. Comme les gens ne passent pas constamment d'une équipe à l'autre, ils ont un plus grand sens des responsabilités. Les employés ne sont pas seulement préoccupés par l'accomplissement du travail et le passage au projet suivant ; ils sont également préoccupés par l'innovation et l'amélioration continue, car un modèle de produit tient les équipes responsables du développement, du support et de la maintenance plutôt que d'attribuer les responsabilités à trois groupes différents.
En définitive, le modèle de produit permet aux équipes de passer d'une planification spéculative à une approche adaptative. Les équipes travaillent ensemble pour créer de la valeur grâce à une amélioration continue basée sur les besoins évolutifs d'un client. Ceci, à son tour, crée une culture d'entreprise qui donne la priorité à la fourniture de valeur plutôt qu'à la réalisation de projets. En établissant des paramètres de résultats significatifs pour nos flux de valeurs, nous disposons d'un moyen de déplacer la capacité là où elle peut faire le plus de bien. Et en tirant parti des cadences synchronisées, nous disposons d'un moyen peu perturbateur de déplacer les personnes et les équipes lorsque cela est nécessaire.
Pour en savoir plus sur la façon dont Planview permet de passer des projets aux produits, regardez la démo , ou téléchargez notre livre blanc sur "Lean Portfolio Management for the Enterprise" pour voir comment les organisations se tournent vers le LPM pour passer à un modèle centré sur les produits.
