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

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. 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)