Le défi de la communication entre le métier et le développement

Soumis par sgraffite le jeu 06/02/2020 - 10:47

Les contraintes budgétaires laissent de moins en moins de marge dans la conduite de l'exécution des projets IT. Le client peut alors revendiquer un regard plus étendu sur l'accomplissement des tâches de développement que par le passé. Ce qui n'est pas sans poser des défis chez tous les intervenants dans un projet.


"Le client veut connaître le(s) développeur(s) à l'oeuvre. Il veut savoir à qui il a affaire et être rassuré de la bonne utilisation des budgets".


La multiplication des approches méthodologiques mixtes en matière de gestion de projet révèle la variabilité de plus en plus grande des contextes d'exécution des projets, qu'ils soient IT ou non-IT:

  • le projet est-il estimé et planifié en régie, prix fixe, scope variable?
  • la gestion des besoins est-elle menée de manière agile, monobloc ("waterfall-like") ou mixte?
  • l'exécution est-elle organisée chez le client, chez le prestataire, ou de façon mixte?
  • etc.

Un cadre commercial d'une société de services IT, principalement active dans le secteur public, résumait bien la situation actuelle ainsi: "Le client veut connaître le(s) développeur(s) à l'oeuvre. Il veut savoir à qui il a affaire et être rassuré de la bonne utilisation des budgets".

Toutefois, et il ne manquera pas de consultants, développeurs, analystes, chefs de projet, product owners, pour souligner le risque posé par l'option "porte ouverte" en matière de communication. En effet, plus forte est la contrainte budgétaire - et c'est le cas actuellement - plus forte sera le réflexe de vouloir vérifier tout ce qui est possible. Avec comme conséquence l'apparition de "raccourcis" dans le schéma de communication entre les différents intervenants d'un projet.


Laisser une porte de communication ouverte perturbe durablement le schéma de communication d'un projet.


Canaux de communication possibles
Trop de canaux de communication possibles nuisent à la communication!

Illustration: quels rôles un projet implique-t-il? Nous trouvons bien sûr les exécutants - en l'occurrence des développeurs, testeurs, architectes, analystes, etc. dans le cadre d'un projet informatique - mais aussi éventuellement un product owner, un ou plusieurs project manager(s), un scrummaster, un release manager, le comité de pilotage avec le(s) sponsor(s), le(s) stakeholder(s), etc.

En théorie, et chaque approche méthodologique excelle à le détailler, chaque rôle remplit des fonctions bien précises:

  • le développeur exécute les tâches de programmation, corrige les bugs éventuels, contribue à estimer la complexité (en story points) ou la charge de travail (en jours-hommes) des développements demandés, documente son code, implémente et exécute les tests unitaires, etc.
  • l'analyste structure, formalise les besoins exprimés par le métier et les traduits en spécifications qui sont communiquées aux développeurs. Il s'assure de la bonne compréhension mutuelle du développement et du métier et vérifie que le produit des développements corresponde bien aux exigences fonctionnelles telles que décrites dans les documents d'analyse et validées par le métier.
  • le scrum master s'assure de la gestion quotidienne de l'exécution du projet, du bon suivi du planning, de la bonne remontée des feedbacks requis vers le chef de projet, etc.
  • le product owner s'assure de la bonne communication et du bon alignement entre le pool de développement (prestataire) et le métier (client). Il est le facilitateur qui va rassurer tant le client que le pool de développement. Il est responsable de la bonne documentation de ce qui est demandé et exécuté.
  • le project manager est responsable de l'ensemble du projet, depuis son élaboration jusqu'à sa réception finale. Il est le facilitator entre le Comité de Pilotage et les intervenants du projet (product owner, pool de développement, scrummaster etc.)

Selon l'échelle du projet, ces diverses fonctions sont de facto cumulées par un nombre réduit de personnes, selon les combinaisons les plus diverses:

  • le(s) développeur(s) sont testeur(s)
  • l'analyste est le product owner et/ou le project manager
  • le scrum master est absent ou son rôle est assumé par le product owner ou le project manager
  • le product owner et/ou le project manager est une personne issue de chez le client
  • l'analyse est faite préalablement au projet chez et par le client
  • etc.

D'autre part, et apparemment en totale contradiction avec ceci, la gestion du projet peut être volontairement "éclatée" entre plusieurs personnes, par exemple un "Business Project Manager" de chez le client et un "IT Project Manager" chez le prestataire. Des cas ont existé avec 1 Business PM (client), 2 IT PM (client + prestataire), 1 Product Owner (prestataire ou tiers ou client)!

"Ménager la chèvre et le choux"

Cette variabilité dans la constitution des équipes de projet est impossible à résoudre d'un point de vue purement méthodologique. En effet, elle illustre bien leur impuissance à apporter une recette dans la gestion du facteur humain. Le cas par cas tend donc à prévaloir.


La variabilité dans la constitution des équipes projets illustre l'impuissance méthodologique à apprivoiser le facteur humain.


Chaque cas doit en revanche mettre en balance les aspects suivants:

  • la localisation des intervenants: la proximité entre le métier (ou son représentant) et le pool de développement favorise bien entendu l'alignement mutuel.
  • la latitude budgétaire propre au projet: au plus le budget est tendu, au plus on aura tendance à assigner différents rôles à un nombre réduit de personnes.
  • la maturité du client et celle du prestataire aux différents niveaux de gestion d'un projet: l'agilité est par exemple rarement identique chez le client et chez le prestataire.
  • la volonté du client et du prestataire à avoir la plus haute main sur la gestion du projet: il s'agit de trancher dès l'élaboration du projet afin de cadrer au plus strict les prérogatives de chacun et modalités de résolution des débats.
  • les disponibilités des intervenants: tous les rôles ne sont pas forcément à temps plein. Un chef de projet ou un analyste travaillera de plus en plus souvent à temps partiel si son ou ses projet(s) est/sont de faible envergure.
  • les impératifs de calendrier du client.
  • les impératifs de rentabilité des équipes chez le prestataire: celui-ci a forcément intérêt à ce que ses équipes soient rentabilisées sur projet à temps plein, et donc cherchera des modalités d'exécution de projets lui permettant de lisser le taux d'occupation individuel de ses employés (et à amener ce taux à une valeur la plus proche de 100%).
  • etc.

Tant pour des raisons de synergie que de gestion du facteur humain, la fonction de Product Owner est susceptible d'être sollicitée sur des projets de développement IT.

Le Product Owner: le pivot en matière de communication

Le Product Owner comme pivot de communication
Le Product Owner est à la jointure entre le métier et le support.

La fonction de Product Owner se situe à la croisée des rôles traditionnels. En effet:

  1. Il collecte, synthétise, structure, analyse et formalise les besoins formulés par le métier.
  2. Il communique avec le pool de développement sur la faisabilité (planning, effort, complexité) des tâches à faire pour rencontrer lesdits besoins.
  3. Il présente le résultat de cette communication au métier afin d'en valider les étapes, leurs contenus, leurs priorités respectives.
  4. Il communique à 360° sur les évolutions du produit dont il est responsable.
  5. Il gère le changement induit par les évolutions du produit.
  6. Il gère le backlog d'exécution.
  7. Il communique à 360° sur l'exécution des demandes et le support du produit.

Son rôle recoupe donc ceux de l'analyste, du scrummaster, du project manager. Il est aussi à cheval sur l'espace du client et celui du prestataires, étant donné qu'il est un maillon essentiel dans la gestion des besoins et la communication sur l'évolution du produit.

Le Product Owner chez le client

Affecter le rôle à une personne employée chez le client revient à confier la responsabilité de la gestion des requirements et celle du changement à 100% à ce dernier. Cela permet de s'assurer que le métier ne parle "que d'une seule voix".

Le cadrage doit être fait au niveau de la formalisation des besoins lorsqu'il s'agit de les communiquer à l'équipe du prestataire, afin de minimiser le risque de mauvaise interprétation dans l'exécution des demandes.

Associer le responsable de l'exécution du projet du prestataire aux réunions de concertation permet de réduire ce risque.

Le Product Owner chez le prestataire

Affecter le rôle à une personne employée chez le prestataire revient à confier la responsabilité de la gestion des requirements à une concertation entre le métier et le prestataire. Celui-ci doit pouvoir gérer les discordances entre ses interlocuteurs du métier, oeuvrer à la convergence des points de vue du métier et promouvoir le changement. Cela peut se traduire en une hausse sensible du budget d'exécution du projet.

Le cadrage doit être fait au niveau de l'organisation de la concertation et de la validation des requirements. En revanche, le gain peut être substantiel lorsqu'il s'agit de les communiquer à l'équipe du prestataire.

Un Product Owner tierce-personne?

Cette configuration quelque peu inhabituelle imposerait un cadrage au niveau du pilotage du projet. Le Product Owner aurait également des comptes à rendre au comité de pilotage au niveau de son Delivery (état du backlog, états des demandes, spécifications, rapports de concertation).

En revanche, cette configuration pourrait offrir la garantie de neutralité qui pourrait faire défaut dans les deux cas précédents.

 

Le positionnement d'un Product Owner dans un projet va être décidé sur base de nombreux critères dont beaucoup dépendent des personnalités amenées à travailler ensemble sur le projet. Il devra de toutes façons être organisé afin de définir au plus près les responsabilités de chaque intervenant dans la gestion, l'exécution et le Delivery du projet.