Vision du travail : sens linéaire et besoin figé à un instant T

Au niveau de sa mise en œuvre, chaque projet est cadré dans un planning, avec un engagement des équipes sur les dates de début et de fin, qui sont généralement figées pendant toute la durée du projet (méthodologies de projets en Cascade ou en Cycle en V).

Le projet se déroule de façon linéaire : on passe d’une phase à l’autre, en avançant en permanence et en validant ce qui a été défini précédemment.

Ce processus de validation de chaque étape/livrable sous-entend qu’il n’est pas possible – ou du moins pas recommandé – de revenir sur les éléments validés aux étapes précédentes. Par exemple, si pendant la phase de développement les parties prenantes décident de modifier le scope du projet, alors cela risque d’impacter les délais (redéfinir le besoin avec les équipes, valider de nouvelles maquettes, refaire certaines tâches de développement : tout cela prendra du temps supplémentaire) et les coûts (les équipes d’UX/UI, de Développement et de Gestion de Projet seront sollicitées plus longtemps que prévu initialement).

Ce qui est défini en début de projet doit – en théorie – être livré exactement de la même façon en fin de projet, des mois plus tard.

Maîtrise du risque par le contrôle

Comme nous avons pu le voir précédemment : les organisations en mode projet tentent de contrôler de multiples paramètres dans le but de dé-risquer les projets :

• Les délais: planning figé à un moment T (au démarrage du projet)
• Le scope/la qualité: tout définir dans le détail, valider phase après phase, ne rien oublier au risque de livrer un projet incomplet et non satisfaisant
• Les coûts: qui découlent des délais des projets et des budgets alloués

Les risques (humains, juridiques, techniques, fournisseurs…) sont envisagés en amont du projet.

À la lecture de ces lignes (n’oubliez pas que j’ai grossi le trait 😉), on se demande tout de même si cette théorie est véritablement applicable dans la pratique par les équipes. Elle implique que ces paramètres peuvent être contrôlés par l’organisation, qu’un plan peut être établi, puis suivi jusqu’au bout, sans changer. Est-ce réaliste ?

Cela peut éventuellement être le cas sur des projets digitaux assez « simples », qui peuvent être créés sur du court terme. Mais à partir du moment où l’entreprise travaillera sur des projets innovants, complexes et interconnectés à de nombreux systèmes externes, les équipes atteindront rapidement les limites de ce mode d’organisation.

C’est pourquoi l’organisation en mode Produit a émergée : pour s’adapter au monde d’aujourd’hui qui est très incertain et en perpétuel mouvement. En plusieurs mois les besoins des équipes métiers évoluent, de nouveaux acteurs arrivent sur le marché avec des innovations, de nouveaux usages naissent chez les utilisateurs. Ce mode d’organisation tente de prendre ces incertitudes en compte.

Qu’est-ce qu’une organisation en mode Produit ?

Les origines de l’organisation Produit

Le Product Management voit ses origines dans le rôle de « Brand Man » créé dans les années 30 chez Procter & Gamble, puis adapté en rôle de Product Manager par Hewlett-Packard dans les années 50. Depuis, il n’a cessé de se transformer, notamment chez les leaders de la tech. En parallèle, l’organisation du travail a évolué et de nouveaux cadres ont émergé : naissance de frameworks tels que Kanban et SCRUM, ou encore du Manifeste Agile (écrit en 2001).

Ces principes et pratiques ont peu à peu transformé la manière de travailler des équipes et de leurs managers, jusqu’à se retrouver aujourd’hui à l’échelle des organisations entières sous forme d’organisation Produit (chez Google, Spotify et Leboncoin par exemple).

Pour en savoir plus sur l’histoire du Product Management, vous pouvez consulter l’article : Le Product Management, des années 30 à aujourd’hui.

Structure : le monde des squads

Ce terme « squad » est l’anglicisme du mot « escouade » désignant historiquement un petit groupe de soldats rassemblés pour mener une mission.

Dans l’organisation en mode Produit, une squad est une petite équipe pluridisciplinaire (composée généralement de 3 à 10 membres). On y retrouve différents profils et rôles en fonction des frameworks utilisés : Scrum Master, Product Owner, Business Analyst, Développeur/Développeuse, UX/UI Designer, Responsable Quality Assurance etc.

Dans les squads, c’est l’intelligence collective qui fait la force de l’équipe dans le but d’innover, imaginer des solutions aux problèmes rencontrés par les utilisateurs et de prendre les meilleures décisions possibles.  La squad fixe elle-même ses objectifs sous forme d’OKR (Objectives and Key Results) avec les membres de l’équipe, en partant des objectifs stratégiques de l’entreprise pour définir des indicateurs chiffrés qui permettront de mesurer la performance.

Une squad, c’est une équipe autonome et responsable, qui prend en charge un produit digital, elle se charge de concevoir, développer et mettre en ligne les différentes solutions qui correspondent aux problématiques/besoins des utilisateurs et des équipes métier. Elle fait évoluer le produit en fonction de son cycle de vie : supprimer des fonctionnalités qui sont de moins en moins utilisées, en créer de nouvelles, et parfois même mettre fin au produit.

Elle travaille en transparence avec les autres départements de l’entreprise : les parties prenantes, auprès desquels elle va se renseigner pour connaître les besoins internes, et envers lesquels elle va diffuser des informations sur l’évolution du produit, de son utilisation, et sa roadmap. Dans l’organigramme – en fonction des organisations – au-dessus des squads on pourra retrouver un ou une Head of Team (rôle de manager des équipes) et un ou une Product Manager : c’est la personne qui définit la vision du produit à moyen terme (entre 6 et 12 mois). Encore au-dessus, au niveau des directions de départements, on retrouvera un Chief Product Officer, qui sera le représentant du produit aux instances décisionnelles stratégiques, comme le Comité de Direction par exemple. Le CPO a une vision du produit sur 1 à 3 ans environ.

L’objectif de l’équipe Produit est toujours d’augmenter la valeur du produit, c’est-à-dire de faire en sorte qu’il réponde aux plus de besoins possibles des utilisateurs, et donc qu’il soit un véritable support de satisfaction. Puisque le produit a de la valeur alors cela se répercute en termes de résultats de l’entreprise : augmentation des ventes, des parts de marché, innovation, fidélisation etc.

Vision du travail : amélioration continue et mise sur le marché rapide

Le travail d’une organisation en mode Produit est basé sur 2 principes :

• L’amélioration continue
• La mise sur le marché la plus rapide possible

Le travail de l’équipe Produit est itératif, il a un rythme sous forme de boucle continue de mise en œuvre et de livraison incrémentale.  La logique ici est de mettre les évolutions en ligne, brique après brique, le plus rapidement possible en vue de vérifier si l’appétence du marché réelle vient confirmer les hypothèses formulées par l’équipe, au moyen de feedback utilisateurs. C’est ce qui fait grandir la valeur du produit. Si ce n’est pas le cas, ou si un élément a été oublié, alors il sera mis en place par la suite. Dans ces organisations il y a une place pour le droit à l’erreur car il y aura toujours possibilité de réajuster par la suite.

Les délais sont fixes (rythme des boucles séquentielles de travail), les coûts également (salaires et charges des membres de la squad). En revanche, le scope est variable, c’est cela qui permet d’être rapidement adaptable avec les évolutions du marché.

Evaluation récurrente du risque et feedback

La gestion du risque est un point très important que les équipent évaluent de façon récurrente au rythme des boucles d’itérations, tout au long de l’année, pour tenter de les anticiper ou définir des stratégies d’action pour réagir au mieux en cas de risque qui deviendrait réalité. De plus, la recherche du feedback utilisateur est permanente : en phase de conception, de maquettage, avant mise en ligne etc. Cela permet de limiter les risques en mettant le produit entre les mains de l’utilisateur au plus tôt, puis réajuster les choses si jamais son retour est négatif et que la direction prise n’était finalement pas la bonne.

Enfin, les organisations Produit acceptent l’incertitude, elles font confiance aux équipes et travaillent dans une logique de faire le mieux possible à un instant T, mettre au contact du marché, puis faire évoluer.

Organisation Projet vs Produit : comparatif

Un modèle est-il préférable à l’autre pour l’entreprise ?

Chaque modèle se choisi en fonction de la stratégie de l’entreprise, de son besoin en innovation digitale, de sa culture, etc.

Certaines entreprises fondent leur business model sur leur outil digital, elles s’organisent en mode Produit car c’est le modèle le plus adapté à leurs besoins : équipes IT habituées à travailler en mode Agile, utilisateurs dont les besoins changent, arrivée de nouveaux concurrents qui impliquent de réagir très rapidement.

D’autres entreprises existent depuis longtemps et se sont construites sur un modèle Projet, certaines d’entre elles ont gardé ce mode d’organisation car c’est celui qui leur correspond le plus : peu d’évolution des besoins utilisateurs, attentes internes bien délimitées, outils digitaux ne nécessitant pas ou peu d’évolution une fois en place.

Parmi ces dernières, certaines ont gardé leur modèle d’organisation en mode Projet, mais intègrent davantage la vision utilisateurs dans leur réflexion, et mettent en place de nouvelles pratiques : il s’agit du modèle Hybride. Par exemple, une enquête du Project Management Institute « Pulse of the profession » révèle qu’en 2020, 59% des organisations indiquent avoir utilisé des méthodes de Design Thinking au moins quelques fois, afin d’explorer le champ des possibles et résoudre des problèmes.

Enfin, certaines entreprises sont en mode Projet et souhaiteraient aller vers un mode Produit et plus d’Agilité, mais cela prend du temps et des ressources. De plus, il y a une évaluation du risque à mener si l’on souhaite passer d’un modèle à l’autre : cette transformation est profonde, elle impacte l’ensemble des acteurs de l’entreprise à tous les niveaux. La prise en compte du facteur humain est primordiale pour assurer le succès de cette transition, et la pérennité de la nouvelle organisation.

Anaïs BRAND – Consultante senior Product Owner Web / Mobile au sein de Davidson consulting