Projet vs. produit : les mots ont leur importance

Mal nommer les choses, c'est ajouter au malheur du monde.

Toujours ouvrir par une citation d'Albert Camus, histoire de s'attribuer un peu de son intelligence.

De quel malheur parle-t-on en l'occurrence ?

Du mien quand j'entends "On cherche un chef de projet agile". Si cette phrase ne vous donne pas instantanément l'envie de partir loin, très loin de toute civilisation afin de faire le point sur votre vie et de revoir vos priorités en profondeur 🐐🧘, lisez la suite.

"Un projet est un but que l'on se propose d'atteindre", nous renseigne Le Larousse. Mener un projet suppose donc de savoir où l'on va, ce qui s'entend dans certains contextes, selon les risques que l'on est prêt à prendre et la façon dont on évalue la rentabilité du projet.

Exemple d'actualité : les Jeux Olympiques de Paris 2024. Beau projet. Le cahier des charges, établi par le Comité international olympique, définit la liste des compétitions qui devront se tenir ainsi que les modalités afférentes. Sans oublier la temporalité : autant dire qu'il y a peu de place pour l'improvisation et que Tony Estanguet a quand-même, un peu, légèrement la pression 😱

Un projet a donc une fin programmée et repose sur un cahier des charges, qui définit le but à atteindre. Une fois livré, le projet est terminé et l'équipe projet démobilisée. Tony pourra ainsi prendre 4 ou 5 ans de vacances pour tenter de se remettre. On passe alors en phase de maintenance (maintenance des équipements dans ce cas précis).

Perspicace que vous êtes, vous avez remarqué que j'ai choisi un exemple extérieur au monde de l'informatique pour illustrer ce qu'est un projet. Logique, vu que la création de logiciels s'accommode mal de l'approche projet, et bien mieux d'une approche produit.

Le problème du produit (sa beauté ?), c'est que l'on croit savoir ce que l'on veut et que c'est faux. Vous le croyez, vous qui développez un produit, et vos utilisateurs le croient. Mais tout cela reste du déclaratif et le seul juge de paix, la vérité vraie, c'est le retour d'usage.

Construire un produit consiste donc à avancer dans l'inconnu à la recherche d'un marché, tester des hypothèses et ajuster le tir. Cela nécessite une approche itérative et incrémentale : produire, recueillir du feedback, aviser, recommencer. À chaque fois, faut-il en faire plus dans cette direction ? faire différemment ? revoir les priorités ?

Dans certains cas, le marché vous renvoie que vous faites fausse route ou vous présente une opportunité plus prometteuse. Il faut alors être prêt à "pivoter", c'est-à-dire changer radicalement la destination du service rendu et donc du produit. C'est monnaie courante : Instagram et Criteo en sont de bons exemples.

Par conséquent, un produit n'a pas de fin programmée. Il vit, aussi longtemps que possible, mais s'adapte, évolue à l'infini, quitte à se renouveler entièrement et n'avoir plus rien en commun avec ce qu'il était à l'origine.

En agilité, il n'y a pas de projet, il n'y a que des produits.