Non.
Le chef de projet transcende la technique sous jacente; peu importe que l’on ait à gérer un projet Web 1 ou 2, un projet client-serveur ou de datawarehouse, la posture ne change pas, les données en entrées et les livrables sont toujours les mêmes – exigences en amont, logiciel en aval - les facteurs externes et internes sont stables et maîtrisés.
L’expérience permet sans doute de nuancer un propos aussi tranché.
On peut défendre l’idée que le chef de projet 2.0 à part entière existe, reprenant à sa charge les rôles classiques comme « gestionnaire de relation avec la maîtrise d’ouvrage » ou « chef d’équipe » et avec des spécificités issues de la technologie ou simplement conjoncturelles.
MOA 2.0 ?
Les relations avec la maîtrise d’ouvrage sont affectées. La nature même du contrat passé entre les parties évolue.
Il ne s’agit plus seulement de produire un logiciel conforme aux attentes exprimées dans un cahier des charges, il faut aussi qu’il tienne la comparaison avec ce qui existe ailleurs, sur Internet en particulier.
Cette nouvelle « meta-exigence » est le plus souvent informelle ; elle s’immisce dans les discours, les écrits et alimente les non-dits. Le projet Web2.0 n’est plus uniquement engagé dans une course contre la montre, mais aussi en compétition avec l’Internet tout entier.
Et la compétition est rude.
Le Web est devenu la référence; les nouvelles exigences sont dictées par les réussites fracassantes des meilleurs sites 2.0 et les composants Ajax les plus riches en libre essai à quelques clics de souris.
C’est l’effet Casino.
Dans un établissement de jeu, la densité des machines à sous est calculée de façon à ce que le joueur soit en permanence bercé par la douce musique des pièces qui tombent. Jouer devient une condition suffisante pour gagner. Transposé au Web, ce syndrome se traduit par des d’exigences supérieures ou égales au meilleur de ce que l’on peut voir sur le Net - moi aussi, je peux gagner autant - mais en sous estimant la difficulté et le coût – pour gagner beaucoup, il suffit de jouer un peu - le résultat est le même qu’au Casino ; on gagne peu et rarement, en investissant toujours plus que ce que l’on avait prévu au départ.
Pire, s’il on essaie de jouer avec une machine qui vient de « payer » le jackpot, c'est-à-dire reproduire ce qui existe de mieux sur le net dans une application maison, on perd – à coup sûr.
Et il revient naturellement au chef de projet de faire en sorte que la production d’applicatifs de qualité, soit moins aléatoire et plus fréquente que le jackpot d’un bandit manchot.
Il doit faire preuve de diplomatie et de psychologie; la MOA veut le même graphe que celui de Yahoo! Finance ou le même degré de personnalisation que le portail Mashup de Netvibes ? Que lui proposer et surtout comment lui présenter ?
Le chef de projet doit savoir s’engager sur un niveau d’exigences raisonnables et négocier en amont le degré de nouveauté du périmètre technique et fonctionnel de son projet.
Ne pas se tirer une balle dans le pied en gérant la frustration le plus tôt possible. Proposer des expérimentations locales et cadrées en jouant la transparence des coûts. Revendiquer le droit à l’erreur sur ces expérimentations.
Face à ce nouveau défi, quels sont les nouveaux moyens dont dispose le chef de projet dans son rôle de manager d’équipe ? Quelles sont les nouvelles contraintes internes ?
Avec le Web 2.0, le développement se complexifie ; de plus en plus fréquemment on emploie à plein temps des designers, ergonomes et intégrateurs HTML pour assister les développeurs de gestion. Les développeurs de frameworks et experts de la sécurité sont aussi couramment des profils que l’on trouve dans ces équipes 2.0.
Le développeur orchestre est un vestige ; les métiers se spécialisent, signe d’une maturation de l’industrie logicielle.
En tant que manager, recruteur, le chef de projet 2.0 doit savoir construire une équipe, en équilibrant ces différents nouveaux profils et en les plaçant sur l’axe temps de son projet.
Cette multiplicité de nouveaux talents introduit une complexité nouvelle dans la gestion des dépendances entre les tâches d’un projet ; 100 jour.hommes à 10 développeurs ne correspondent plus à 10 jours de délais ; les outils de base ne suivent plus, Excel montre rapidement ses limites et Project est aussi adapté pour le suivi de planning qu’une carte routière en papier sur une moto de course.
Cette nécessaire diversité des profils exacerbe la dimension collaborative du travail. Et « collaboratif » est justement l’adjectif le plus associé aux concepts Web 2.0.
De ce côté-là, les outils suivent difficilement ; on pense naturellement au Wikki pour le référentiel de documentation ou de meilleures pratiques et à la messagerie instantanée comme nouveau média à mi-chemin entre le téléphone et le mail.
Mais le développement véritablement collaboratif, lui, sort à peine des laboratoires.
Jazz chez Eclipse, et
TeamSystem chez Microsoft par exemple. Pour l’heure, on en est encore à industrialiser les usines de développement basées sur des middleware de build automatique et d’intégration continue dont les usages et les outils sont généralement issus de la communauté open source.
Influencés positivement par les pratiques de ces communautés, les développeurs ont l’initiative de la méthode ; du ‘test-driven’ au ‘test-first’ pour arriver aux méthodes agiles, les producteurs de code pressent leur management pour la prise en compte de ces nouvelles pratiques.
Bien évidemment, la nature d’une application Web 2.0 et la gestion d’un projet en mode Agile ne sont pas directement liées. Néanmoins, c’est un fait, les développeurs promoteurs de méthodes Agiles sont le plus souvent ceux que le chef de projet rencontre dans cet univers 2.0.
Et au chef de projet de vivre un nouveau moment de solitude : avec quels arguments peut-il convaincre sa DSI d’engager un projet Agile ? Comment « vendre » le « time-boxing» de Scrum et son caractère adaptif plus que prédictif ?
Si en parallèle, il est engagé dans un processus de certification Qualité de type CMMi, on mesure l’ampleur du grand écart à accomplir.
A lui de se convaincre d’abord que
CMMi et
Agile sont complémentaires, puis d’identifier un périmètre d’essai et faire une proposition d’expérimentation avec le même droit à l’erreur que s’il s’agissait de la mise en œuvre d’un nouveau framework. Faire le bilan, et recommencer en mieux.
D’un point de vue RH, cette spécialisation des équipes replace sur le devant de scène un vieux débat Franco-Français. Idéalement, le chef de projet 2.0 voudra s’entourer de développeurs experts ou au moins panacher son équipe avec des profils juniors et seniors.
Et quoi qu’en disent les grilles, on n’est pas expert à 25 ni à 30 ans. L’expert, celui dont le vécu permet d’emprunter le seul bon chemin parmi cent possibles, est nécessairement plus âgé ; il est le gourou, la référence sauf qu’en France, il n’existe pas.
Pourquoi ?
Parce que la fonction de chef de projet est une position hiérarchique plus qu’une fonction avec sa technique propre. On devient chef de projet, parce que c’est l’heure et parce que l’on a compris que c’est une étape obligatoire pour progresser dans l’entreprise.
Le résultat : des équipes avec des développeurs certes talentueux, mais inexpérimentés encadrées par des chefs de projets plus motivés par la reconnaissance que par le métier.
Rêvons d’un monde ou le développeur de 45 ans existe et s’épanoui au sein d’une équipe encadrée par un chef de projet communiquant et diplomate, favorisant le travail collaboratif entre des experts hyper-productifs et des jeunes à potentiel.
Le chef de projet 2.0 n’est pas une star ; il valorise la production de ses équipes et rend leur travail possible. Par tous les moyens.
