Projet VS produit

Derrière ce titre évocateur « projet vs produit » se cache un sujet très important de plus en plus discuté au sein des entreprises. Comment passer d’un mode projet à un mode produit ? Et quel est la différence entre les deux.

Le mode projet

Phases successives

Ce qu’on appelle le mode projet est un processus très axé sur les notions budgétaires et de phases successives d’avancement sur un produit (ou offre).

Certains y verront facilement un concept waterfall ou cycle en V. Mais la différenciation va bien au delà de la comparaison de Cycle en V vs Scrum.

Enveloppes budgétaires

En mode projet, on parle souvent d’enveloppes budgétaires allouées à différentes unités qui elles mêmes vont allouer des sous enveloppes budgétaires…

D’ailleurs en cas de besoin pour se terminer ou pour éventualiser une nouvelle release, le produit devra repasser par ce système hiérarchique de gestion budgétaire.

Si cela n’interdit pas de délivrer des produits à grande valeur ajoutée, il est loin d’être optimal comme nous le verrons en mode produit.

Nous pensons pour le client

En mode projet, les équipes imaginent le produit sans réellement impliquer les utilisateurs. Si dans certains « projets », de utilisateurs peuvent être interviewés, cela reste limité.

En effet, les utilisateurs sont principalement impliqués en fin de projet ce qui peut amener à comprendre que le produit réalisé exige de grosses modifications pour devenir utilisable. Et parfois, les utilisateurs ne veulent tout simplement pas de ce produit.

Un scope complet décidé en amont

En mode projet, on prévoit tout le travail à réaliser avant même de lancer les phases de réalisation. La seule variabilité du scope se fait sur la découverte de bugs non prévus ou de retours peu aimables de certaines parties prenantes. Mais cela reste limité car l’objectif en mode projet est de délivrer l’ensemble du scope initial prévu peu importe les éventuels ajouts.

Des décisions limitées et longues

En effet, avec ce concept de phases successives, le projet ne laisse peu de place aux réelles décisions à prendre et la fréquences de celles-ci. Elles sont parfois tardives et amènent à des coûts non négligeables.

Le mode produit

Le mode produit remet tous ces points en question. Et si nous parlons de « produit », c’est parce que tous ces changements amènent l’équipe à devenir product centric (soit beaucoup plus user-centric).

Pilotage par la valeur

Probablement l’un des points les plus difficiles pour les entreprises : sortir du concept de pilotage par enveloppe budgétaire et partir sur un pilotage par la valeur.

Bien que ce schéma soit pas le seul possible, il présente un parcours qui impose de prioriser les projets par la valeur, de travailler le minimum (en agile bien sûr) pour définir le ROI (return on investment) de chaque projet (quand on connait sa charge approximative) et de ne lancer que les phases de réalisation que des produits ayant le plus de ROI.

D’ailleurs dans certaines structures, la maintenance se prendra une partie de l’enveloppe budgétaire pour suivre les produits livrés et qui n’évoluent plus. Si les documentations sont bien faites en amont, des équipes spéciales peuvent gérer cela.

Sur ce dernier point, il y a différentes façons de faire qui ont toutes leurs qualités et leurs défauts.

Mais attention, cela implique beaucoup de changements gigantesques pour les grandes structures :

• changement organisationnel
• avoir des business unit amovibles en taille (squad ?)
• avoir des équipes capables de changer de scope de temps en temps (en gardant un maximum de stabilité des membres de l’équipe)
• gestion des ressources essentielles (recrutement, sourcing, formation…)
• rapprochement réel métiers/IT/prod…

Les utilisateurs présents tout au long de la création du produit

Les utilisateurs seront à la base des idées émergeantes, participeront à la phase de préparation, la phase de réalisation et après la fin des travaux sur le produit.

Je ne peux que recommander de regarder du côté du framing agile qui saura beaucoup vous aider dans la mise en place d’une phase de préparation 100% user-centric.

Travailler en itératif, incrémental et sur un scope variable

Pour être en mode produit, il sera indispensable de bien comprendre ces 3 notions différentes. Pour faire vivre un produit, il est indispensable de bien assimiler l’importance d’avoir un scope variable.

D’ailleurs cela permet à réellement maitriser les coûts et les délais comme l’explique l’Iron Triangle.

Et contrairement à quelques légendes urbaines, l’agilité n’est pas anti deadline… Bien au contraire. Mais pour que cela fonctionne, il est obligatoire d’accepter la notion de scope variable.

Pour bien travailler cette notion de scope variable, des framework tels que scrum ou XP amènent à une bonne gestion de ces notions d’itératif et incrémental.

Les itérations courtes permettent d’amener le client à faire des feedback réguliers, de faire évoluer le produit au fur et à mesure (même en partant d’une vision produit essentielle)…

Rapprochement des différents corps de métiers

En mode produit, nous ne parlons plus des « métiers », de l' »IT » voire de la « prod ». Nous faisons travailler tout le monde ensemble sur toute la vie du produit.

Nous sommes une équipe qui ont la même mission : « amener le produit à devenir l’image la plus proche de ce qu’attendent l’ensemble de nos utilisateurs ».

Conclusion projet vs produit

J’espère que ces notions vous permettront de mieux comprendre pourquoi de nombreuses entreprises parlent de mode « produit » aujourd’hui. Bien que ce mouvement est en continuité au différents précédents mouvements agiles, les transformations des entreprises prendront des années pour ne pas parler de dizaines d’années pour réussir une telle transformation.