The blog of blog of blogs

Les aventures d'un ethnologue dans le grand monde

L’équipe projet, version 2 9 septembre 2016


La manière habituelle de fabriquer des produits s’avère de plus en plus un facteur limitant. Mais bien sûr en contrepoint, il n’y a pas de nouvelle manière bien établie et faisant l’objet d’un consensus… ce qui explique que le problème est rarement évoqué en public puisque personne n’a la réponse.
Souvent le sujet est effleuré lors de projets, par une interrogation sur la nature des compétences à rassembler pour mettre en place une configuration qui fonctionne, dans le contexte des usages actuels.   (sur ce sujet plus vaste, cf. l’article sur le SI Digital).
En guise de préambule, je voudrais développer ci-dessous cinq points qui me semblent pertinents.

1980-2014_evolution-of-the-desk

 

 

1. Les équipes sont transverses

Pour toutes les fois où une maîtrise d’ouvrage (MOA) et une maîtrise d’oeuvre (MOE) sont impliquées dans un projet (et pas uniquement en informatique), il faut aller voir sur le terrain pour constater que les échanges d’information sont multiples, intensifs et transverses (ha !).
La transversalité se situe à la croisée de trois domaines : Conception, Réalisation et Production.

Ces trois domaines concentrent toutes les compétences pour élucider les questions de design (conception), de faisabilité (réalisation) et de viabilité (production). Le point de blocage vient du fait que dans le processus habituel, ces éléments interviennent l’un après l’autre chronologiquement, et qu’une bonne part du temps passé sur un projet consiste à comprendre ce que les précédents intervenants ont voulu dire dans leur spécifications, pourquoi ils ont adopté tel choix technique et pourquoi ils n’ont pas anticipé telle ou telle procédure. Comme dit l’anecdote du cuisinier sur le Titanic : « Moi, ma vaisselle était propre… »

Composez une équipe projet afin que ces domaines Conception, Réalisation et Production soient abordés en même temps; et n’ayez pas peur d’y ajouter d’autres fonctions si nécessaire. Dans le domaine de la cyberdéfense par exemple, on compte pas moins de sept domaines de compétences minimum.

.

2. Les équipes sont à 100%

Une affectation sur un sujet, sur 100% du temps de travail. Il y a une littérature pléthorique qui prouve l’inefficacité du travail multitâches. Pour une organisation, affecter ses employés à des projets parallèles différents est aussi dangereux que conduire et envoyer un texto en même temps.

Vous devez cesser de croire qu’un ingénieur de tests pourra résoudre cinq anomalies PHP dans la journée et proposer des idées innovantes la même journée. Vous devez cesser de croire qu’un chef de projet peut gérer 5 projets simultanément. Vous devez cesser de croire qu’un designer peut se montrer créatif sur des solutions d’écrans web alors qu’il est affecté à quatre projets différents sur 25% de son temps.

.

Maintenir en bon fonctionnement un système d’information est difficile, mais réussir un projet qui implique des technologies de moins de 10 ans, pour des usages de moins de 5 ans tout en restant compatible avec le SI qui a parfois 30 ans est un tour de force lorsqu’on y est à plein temps.
N’espérez pas y parvenir avec les méthodes qui fonctionnaient bien (en moyenne) il y a quinze ans. Lorsque vos collaborateurs sont affectés à moins de 100% de leur temps à un projet… c’est presque comme si vous vouliez ne pas y arriver.

.

3. Les équipes mangent des données au petit-déj

Personne n’a besoin d’être un expert en données (sauf le data scientist :) ). Mais tout le monde a besoin de prendre en compte les nouvelles données qui donnent des informations sur le travail accompli en vue d’améliorer le travail à faire.  Les équipes (de MOE) n’en peuvent plus de brûler des calories en respectant une liste de fonctionnalités requises (par la MOA), alors que si tout le monde avait travaillé ensemble dès la phase d’études, on aurait pu gagner du temps… C’est la responsabilité du management de constituer des équipes qui rassemblent toutes les compétences dont le projet a besoin et nous commençons bien à comprendre que les procédures habituelles empêchent cette mise à disposition en sacralisant la frontière entre MOA et MOE.

Voilà un autre élément qui légitime le recours à la méthode UX et l’observation directe en itérations successives :

  • votre produit minimum viable (MVP) doit générer des données, sinon ça s’appelle un prototype
  • vous devrez arbitrer entre les aspects quantitatifs (le quoi) et les aspects qualitatifs (le pourquoi)
  • vous devez mesurer des résultats, pas des fichiers de logs de sortie

Vos équipes devraient pouvoir exprimer fortement leurs différents avis, l’encadrement hiérarchique devrait être modéré et chaque décision devrait être argumentée par des faits et des données.
Une équipe de projet aujourd’hui n’est plus responsable de fournir une liste de fonctionnalités mais de justifier comment elle améliore sa contribution aux résultats de l’organisation.

4. Les équipes servent l’utilisateur

La principale amélioration stratégique pour une organisation consiste à mieux connaître ses utilisateurs / clients / usagers et à se rassembler autour d’eux. C’est l’usage qui doit décider de l’organisation interne et non l’inverse. De cette manière, les équipes connaîtront le pourquoi et seront à même de proposer des solutions techniques pertinentes.

Vous devez arrêter de questionner les utilisateurs après leur avoir livré un produit : si vous devez le faire une seule fois, faites-le avant. Une organisation centrée utilisateur observe, questionne et mesure les usages tout le temps.

 

Les équipes projet dignes de ce nom sont branchées en direct aux (futurs) utilisateurs et sans se limiter aux œillères imposées par un projet particulier. Et je dis bien en direct : sans intermédiaire qui parle « au nom de ». Ce sont des membres de l’équipe qui vont au contact des utilisateurs et qui remontent ces informations de première main. Si vous avez une Direction de l’UX ou un équivalent, elle devrait être capable de fournir de l’intelligence qui mettra en perspective et réutilisera cette collecte directe. La connaissance client / utilisateur / usager ne cesse jamais elle mérite donc d’être portée par une direction autonome et permanente au sein de votre organisation.

C’est ainsi que pourra s’estomper l’épaisseur des forteresses MOA et MOE : à force de partage, de travail en commun et de construction d’une compréhension partagée (et argumentée) des utilisateurs.

5. Les équipes sont diverses et parfois rouges

Quelle est la représentativité de vos équipes en comparaison de la population totale ? La culture de vos employés se reflète et influence le produit final jusqu’à avoir un impact sur la manière dont il sera perçu, une fois livré sur le marché.

Pas besoin d’aller chercher très loin pour trouver des exemples réels dans le monde d’aujourd’hui, dans vos produits, vos services et ceux de tous les autres.

La seule bonne volonté ne suffit pas ici, car il y a par exemple des législation qui empêchent de recruter sur une base de choix culturelle, d’origine géographique ou même religieuse. C’est une excellente chose dans l’absolu bien sûr, mais cela produit un cercle vicieux qui empêche aussi de corriger un manque de représentativité et qui ne fait finalement que protéger un état de fait largement insatisfaisant. C’est un sérieux problème que les directions des Ressources Humaines devraient traiter sérieusement… mais en termes de management, l’absence de réponse RH immédiate n’empêche pas de mettre en place certaines règles claires :red-team_contrarian-anticipation_equipe-rouge_anticipation-contrarienne

  • Permettre un environnement protecteur qui permette l’expression des points vue, y compris (et surtout) divergents. Acceptez aussi une remise en cause par… l’avis des utilisateurs et la réalité de leur contexte tel que les designers UX auront pu le constater.
  • Sur les sujets les plus importants, mandatez trois personnes pour établir précisément (et à 100% du temps alloué !) comment le plan pourrait échouer. On appelle ça une « Équipe Rouge » dont je suis un ardent défenseur. En termes militaires une équipe rouge prend le point de vue de l’ennemi pour trouver les points faibles d’un plan -et c’est nettement mieux d’avoir fait ce travail avant l’exécution du plan…
  • Montrez l’exemple. Acceptez la critique mais n’acceptez que des critiques constructives puisque bien construire est l’objectif. Pas de critique ad hominem, bien entendu.

.

Il y a encore beaucoup à dire… mais en forme de conclusion, j’ajouterai que si tout cela vise bien à améliorer la qualité de ce que vous proposez -produit ou service-, c’est aussi un moyen pour parvenir à une autre fin : renforcer l’organisation elle-même en diminuant l’entropie, la dispersion dans des luttes intestines et l’éloignement progressif de ce qui devrait être la priorité de chacun : le service rendu à l’utilisateur.

.

.

.

 

One Response to “L’équipe projet, version 2”

  1. […] que je l’écrivais dans mes articles précédents sur la nécessité de revoir ce qui constitue une équipe projet performante, il y a un fort besoin […]


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s