Novembre 2016 www.ictjournal.ch © netzmedien ag

36avis d'expertgestion produit

Management projet vsmanagement produitPartant 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 a� n

de répondre à un besoin dé� ni dans des délais � xés et un

budget alloué.

Dans cette dé� nition du projet, il n’est nulle part fait men-

tion de la réalisation d’un produit. Les besoins sont «dé-

� nis», souvent gravés dans un cahier des charges, et

comme le montre la � gure 1 ci-contre, une solution est

imaginée et déclinée en spéci� cations, puis développée

pour être en� n 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 � n du cycle complet.

Management produit

Produit: un bien ou un service résultant d’une activité

créative a� n 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é� nition?

L’objectif premier de ces méthodes est d’obtenir rapidement

des feedbacks utilisateurs et ainsi ajuster sa trajectoire.

La � gure 2 ci-contre décrit clairement cette boucle de

feedback, presque in� nie, où l’on dé� nit 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 � xe. Dans

les deux cas, on s’efforcera de les respecter.

En mode projet, le périmètre fonctionnel est également

prédé� ni. 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é� nition 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 ef� cace 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 speci� ed product on time and on budget», faire

le produit spéci� é 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

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

a�n 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 �nalement investir dans les idées qui auront survécu.

En�n 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 pro�l 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 Of�ce), 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 pro�l

Ops, capable de fournir l’infrastructure et les environne-

ments pour déployer l’application au plus vite.

En�n 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é�nir 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'expertgestion produit

Développer

Développer

Délivrer

Délivrer

Découvrir

Découvrir

Problème identi�é?

Solution imaginée

Expression de besoins

Spéci�cations

UATSolution livrée

Produit/SolutionUtilisateurs

Marché / ProblèmeClients

Développement client Développement produit

Développement

Cycle projet (!gure 1)

Cycle produit (!gure 2)