Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Novembre 2016 www.ictjournal.ch © netzmedien ag
36 avis d'expert
gestion produit
Management projet vs
management produit
P...
Novembre 2016www.ictjournal.ch © netzmedien ag
37
petite réalisation qui permette de collecter le maximum
d’informations u...
Prochain SlideShare
Chargement dans…5
×

Management projet vs management produit

1 679 vues

Publié le

Article publié dans l'ICT Journal (www.ictjournal.ch) de novembre 2016, comparant la gestion de produit et la gestion de projet.

Publié dans : Direction et management
  • Soyez le premier à commenter

Management projet vs management produit

  1. 1. Novembre 2016 www.ictjournal.ch © netzmedien ag 36 avis d'expert gestion produit Management projet vs management produit Partant du constat que 50% des fonctions d’un produit logiciel sont rarement, voire jamais utili- sées, il est indispensable de remettre en question notre façon de gérer les projets de développe- ment logiciel. Une approche centrée sur le produit apportera la juste valeur aux utilisateurs. L’auteur Jérôme Van Der Linden, OCTO Technology Management projet Projet: un ensemble d’activités et d’actions réalisées afin de répondre à un besoin défini dans des délais fixés et un budget alloué. Dans cette définition du projet, il n’est nulle part fait men- tion de la réalisation d’un produit. Les besoins sont «dé- finis», souvent gravés dans un cahier des charges, et comme le montre la figure 1 ci-contre, une solution est imaginée et déclinée en spécifications, puis développée pour être enfin testée. Les besoins ne sont jamais rééva- lués et la solution en cours de développement n’est pas confrontée aux utilisateurs. On ne pourra constater le décalage entre la solution ima- ginée, la solution livrée et les réels besoins des utilisa- teurs qu’à la fin du cycle complet. Management produit Produit: un bien ou un service résultant d’une activité créative afin de satisfaire les besoins et de répondre aux usages d’un client. Si les méthodes agiles, avec des cycles courts et itératifs, nous permettent d’ores et déjà de sécuriser le développe- ment d’un produit (visibilité, adaptabilité, qualité), pour- quoi ne pas en tirer parti également pour sa définition? L’objectif premier de ces méthodes est d’obtenir rapidement des feedbacks utilisateurs et ainsi ajuster sa trajectoire. La figure 2 ci-contre décrit clairement cette boucle de feedback, presque infinie, où l’on définit le produit tout au long de son cycle de création en fonction des retours utilisateurs. On ajuste donc le produit au plus près du besoin, en évitant ainsi un gâchis substantiel. Management projet vs management produit Que l’on soit en mode projet ou en mode produit, on dis- pose généralement d’un délai et d’un budget fixe. Dans les deux cas, on s’efforcera de les respecter. En mode projet, le périmètre fonctionnel est également prédéfini. La variable d’ajustement dans ce cas est alors la qualité, souvent mise à mal. Le paradigme du management produit est quelque peu différent. La définition du produit et de son périmètre fait intrinsèquement partie du projet. L’objectif est d’ap- prendre le plus rapidement possible sur ce que souhaite l’utilisateur, et ainsi limiter les développements inutiles (stocks). On pourra arrêter à mi-chemin si la solution convient, ou même avant de commencer les développe- ments s’il n’y a pas de réel besoin. Par ailleurs, la qualité est un élément non négociable: que l’on parle d’expérience utilisateur ou d’implémentation technique, les fonctionnalités livrées doivent être irrépro- chables. D’un point de vue utilisateur, l’application sera plus efficace et agréable à utiliser. Et du point de vue pro- jet, on investit dans la maintenabilité et l’évolutivité du produit, grâce notamment à des tests automatisés, des revues de code, de l’intégration continue et d’autres pra- tiques issues de la mouvance Software Craftsmanship. Le credo du management produit est «Build the right product, and build the product right»: faire le bon produit et le faire correctement. Très loin du sempiternel et fade «Build the specified product on time and on budget», faire le produit spécifié dans les temps et le budget... Les outils du management produit L’objectif est donc d’apprendre le plus vite possible, pour ajuster le produit au besoin et éviter au plus tôt les fonc- tionnalités inutiles. Ne pouvant évaluer et ajuster que ce que l’on mesure, il est important de mesurer un maximum de choses. Le premier outil, issu du Lean Startup est donc la boucle d’apprentissage: on émet une hypothèse, on construit, on mesure et on apprend. Les mesures peuvent se faire via des outils d’analytics ou des logs (quantitatif) pour un investissement négligeable et des résultats très factuels. On peut également aller voir les utilisateurs (qualitatif): soit en amont d’un développement avec des propositions de maquettes, ou bien a posteriori avec des tests utilisateurs (on ne parle pas de tests d’acceptation, mais d’observation du comportement des utilisateurs face au produit). Également dans l’optique de valider un besoin, le MVP (Minimum Viable Product) permet de confronter une hy- pothèse à la réalité du terrain. Attention, il ne s’agit pas d’un POC (Proof Of Concept) ni même nécessairement d’un sous-ensemble du produit cible. Il s’agit de la plus
  2. 2. Novembre 2016www.ictjournal.ch © netzmedien ag 37 petite réalisation qui permette de collecter le maximum d’informations utilisateurs avec un minimum d’effort. Parfois, un simple formulaire d’inscription permet de jau- ger l’attrait d’une idée. Le Lean Canvas, croisement entre le Lean Startup et le Business Model Canvas, fournit un cadre synthétique afin de valider et documenter un business model. Son ob- jectif, un peu comme le MVP, est de tuer au plus vite les mauvaises idées, invalider les besoins qui n’en sont pas et finalement investir dans les idées qui auront survécu. Enfin et toujours dans l’objectif d’accélérer la boucle d’apprentissage, le déploiement continu est primordial. On voudra en effet mettre le produit à la disposition des utilisateurs le plus fréquemment et rapidement possible pour obtenir leurs feedbacks et analyser toutes les me- sures prises. Le produit, c’est l’équipe L'équipe, plus encore que les outils, est un facteur déter- minant de succès. Elle doit être pluridisciplinaire, auto- nome, mais surtout responsable du produit de bout en bout. La célèbre citation de Werner Vogels (CTO Amazon) «You build it, you run it» en est la parfaite illustration. Outre les développeurs, graphistes, architectes néces- saires dans tous les cas, une équipe «produit» possède un profil particulier: le Product Owner (PO). Il porte la vision produit, est au centre des décisions fonctionnelles et valide le résultat. La gestion du projet est assurée par un PMO (Project Management Office), en charge de suivre les indicateurs d’avancement et de coordonner les inter- venants (comités). Dans l’optique de faire du déploiement continu, il est également recommandé d’intégrer à l’équipe un profil Ops, capable de fournir l’infrastructure et les environne- ments pour déployer l’application au plus vite. Enfin et c’est la clé de la réussite, le client (ou un de ses représentants) doit faire partie intégrante de l’équipe, participer aux différents rituels et travailler main dans la main avec le PO pour définir le meilleur produit possible. Outre les processus et les outils, ce sont bien les hommes qui vont concevoir et construire la solution qui sont la clé du succès d’un produit. Une culture d'entre- prise favorisant la responsabilité, l’autonomie, l’améliora- tion continue et la coopération renforce les chances de succès de ces équipes à livrer LE produit dont rêvent les utilisateurs. avis d'expert gestion produit Développer Développer Délivrer Délivrer Découvrir Découvrir Problème identifié? Solution imaginée Expression de besoins Spécifications UATSolution livrée Produit/Solution Utilisateurs Marché/Problème Clients Développement client Développement produit Développement Cycle projet (figure 1) Cycle produit (figure 2)

×