Il était une fois… le Chef de projet idéal
Le dernier billet publié sur Les Intégristes parlait d’humilité et de bienveillance à l’égard de nos pairs.
Être bienveillant implique de soutenir nos collègues, d’être indulgent à leur égard, mais cela n’exclut pas d’avoir le courage de leur parler avec honnêteté en cas de problème.
C’est en écoutant des confrères et consœurs travailleurs du web me parler de leurs frustrations au quotidien, qui par email, qui sur Twitter, qui pendant Paris Web, que j’ai eu envie d’écrire sur la relation singulière entre intégrateurs et chefs de projet – une relation ô combien essentielle, sur laquelle on trouve pourtant bien peu de littérature.
Derrière ce billet, il y a un constat : en 2014, j’ai été témoin d’une irritation sourde et croissante chez mes pairs, irritation souvent provoquée par des gestions de projet catastrophiques.
À l’incompatibilité supposée entre intégrateurs et designers a succédé, semble-t-il, la lassitude de certains d’entre nous à l’égard de certains chefs de projet avec qui nous collaborons au quotidien. C’est un ressenti que j’ai perçu de façon assez globale, mais que j’ai trouvé particulièrement exacerbé auprès de mes confrères et consœurs travaillant en agence.
Certes, il est toujours plus facile de voir la paille dans l’œil du voisin que la poutre qui est dans le sien.
J’ai conscience que pointer du doigt les mauvaises habitudes de mes pairs est, sinon politiquement incorrect, du moins délicat. C’est pourquoi je me suis essayée à une forme d’écriture plus légère que d’habitude, sous forme de conte de Noël, ceci afin de provoquer une prise de recul salvatrice.
J’espère de tout cœur que cette prise de risque donnera lieu à des débats enrichissants pour nous tous.
Il était une fois…
Il était une fois, dans un pays très, très lointain, une petite agence web.
Cette petite agence web réussissait toujours à décrocher les projets les plus excitants et les plus valorisants.
Ses clients étaient tous éduqués, sages et riches.
Pour ne rien gâcher, ses locaux rutilants et faciles d’accès se trouvaient à deux pas de la meilleure boulangerie du pays.
C’est dans cette petite agence web que travaillaient main dans la main les Ergonomes, les Designers, les Intégrateurs, les Développeurs, les Commerciaux et les Managers :
- Les Ergonomes avaient toujours le budget nécessaire pour réaliser des tests utilisateurs ;
- Les Designers bénéficiaient à chaque fois d’au moins huit jours pour préparer les avant-ventes ;
- Les Intégrateurs convainquaient à tous les coups leurs interlocuteurs des bienfaits de l’accessibilité ;
- Les Développeurs avaient toujours à leur portée des spécifications complètes et finement rédigées ;
- Les Managers suivaient les plannings à la perfection. Réactifs, c’était des forces positives sur lesquelles on pouvait compter en cas de coup dur ;
- Les Commerciaux quant à eux réussissaient toujours à négocier plus de charges pour que les Ergonomes, les Designers, les Intégrateurs et les Développeurs puissent travailler sereinement, sans pression.
C’est aussi dans cette petite agence qu’officiaient des professionnels réputés : les Chefs de projet idéaux. Ceux-ci orchestraient tous les projets de la petite agence avec flair et doigté.
Que soient narrés aujourd’hui quelques-uns de leurs hauts faits, à travers le prisme de leurs interactions constantes avec les Intégristes Intégrateurs.
Chiffrage et planification
Avant toute chose, les Chefs de projet idéaux pensaient à mettre les Intégrateurs dans la boucle, non seulement pour valider la faisabilité du projet côté front-end et pour macro-chiffrer la charge en intégration, mais également pour lister avec eux tous les éléments dont ils auraient besoin pour commencer à travailler sereinement.
Quand ils savaient qu’un apprenti prendrait part à un projet complexe, les Chefs de projet idéaux veillaient à solliciter un Intégrateur senior afin d’estimer la charge en fonction de ce paramètre.
Les Chefs de projet idéaux faisaient tout leur possible pour éviter que les Intégrateurs soient envoyés du jour au lendemain dans une régie obscure. En effet, les Intégrateurs travaillaient mieux dans un contexte connu. Les régies sont bien souvent synonymes, au mieux, de webmastering désagréable, au pire, de gestion d’urgence, là où une organisation rigoureuse devrait pouvoir éviter ça.
Lorsque Ergonomes et Designers prenaient du retard dans la conception du projet, les Chefs de projet idéaux rassuraient les Intégrateurs en leur confirmant que la date butoir glissait également pour eux.
Enfin, les Chefs de projet idéaux étaient bien organisés, et briefaient les Intégrateurs avant qu’ils ne commencent à travailler.
Qualité du projet
Les Chefs de projet idéaux avaient le cran de parler avec franchise des diverses contraintes à leurs Clients. Ils savaient que, s’ils y manquaient, le projet hériterait d’exigences supplémentaires pour le moins coûteuses.
Les Chefs de projet idéaux avaient à cœur la qualité des projets qui passaient entre leurs mains. Ils ne demandaient pas aux Intégrateurs de mettre en place des mauvaises pratiques par simple peur de devoir dire « non » aux Clients. Par exemple, les Chefs de projet idéaux savaient qu’il était important de former les contributeurs au sous-titrage des vidéos.
Car, oui, les Chefs de projet idéaux accordaient de l’importance à l’accessibilité. Ils savaient que l’accessibilité du web ne concernaient pas uniquement les personnes en situation de handicap, mais qu’elle bénéficiait à tous, et que, si elle était prévue dès la genèse du projet, il serait plus facile de la mettre en œuvre.
En début de projet, les Chefs de projet idéaux prenaient soin d’annoncer aux Intégrateurs que le site devait être responsive, multilingue, optimisé « retina » et/ou compatible avec Internet Explorer 6.
Et, lorsque les Intégrateurs leur demandaient la liste complète des navigateurs avec lesquels le projet devait être compatible, les Chefs de projet idéaux la leur fournissaient facilement.
Les Chefs de projet idéaux prenaient soin de rassembler tous les entrants nécessaires à la bonne exécution des tâches, notamment les maquettes graphiques validées.
Tout affables qu’ils étaient, les Chefs de projet idéaux savaient argumenter face aux demandes parfois surprenantes des Clients.
Recette et maintenance
Les Chefs de projet idéaux apprirent un jour que le Chef de projet d’une autre petite agence web avait recetté un site 48 heures à peine avant la livraison, alors qu’il avait eu plusieurs mois pour le faire au fil de l’eau. Quand ils entendirent cela, les Chefs de projet idéaux éclatèrent d’un rire tonitruant mais noble, que l’on entendit jusqu’au Mont Fuji et au-delà.
Les Chefs de projet idéaux connaissaient très bien la différence entre ce qui relevait du design, du front-end et du back-end. Ils savaient aussi identifier les zones contribuables d’un site. Ainsi, les Chefs de projet idéaux étaient toujours à l’aise pour qualifier les tickets qui passaient entre leurs mains.
De même, les Chefs de projet idéaux assignaient un nombre raisonnable de tickets à une même personne, prenant en compte son degré de connaissance du projet et la difficulté des tâches attendues.
Les Chefs de projet idéaux évitaient aussi d’assigner aux Intégrateurs un ticket concernant, au choix :
- un bug déjà soulevé à plusieurs reprises,
- une anomalie repérée dans un navigateur hors périmètre,
- un problème de contribution,
- une erreur de traduction,
- une demande d’évolution,
- ou encore une majuscule manquante dans un texte, et ce sur 15 gabarits.
Par ailleurs, dans le cadre d’un projet responsive, les Chefs de projet idéaux prenaient soin de rédiger un rapport de bug complet, qui précisait la résolution et le périphérique sur lesquels apparaissaient les anomalies.
Diplomatie et confiance
Les Chefs de projet idéaux gardaient la tête froide. Ils savaient que leur rôle est essentiel pour mener les projets à bien, en particulier pour synchroniser les efforts des différents corps de métiers, et pour arbitrer en cas d’imprévu.
Si, d’aventure, un Intégrateur leur faisait part de ses inquiétudes, les Chefs de projet idéaux prenaient le temps de lui répondre, soit pour le rassurer, soit pour lui montrer qu’ils avaient bien pris en compte ses recommandations ou ses alertes.
Les Chefs de projet idéaux faisaient confiance aux équipes techniques et graphiques. Ils communiquaient suffisamment au quotidien pour que les premiers ne ressentent pas le besoin de devoir soumettre les autres à la question, jour après jour, pour savoir où ils en étaient.
Les Chefs de projet idéaux avaient la même considération pour HTML et CSS que pour n’importe quelle autre technologie web. Ils savaient que ces langages en apparence simples cachent des problématiques complexes.
Après une mise en production, les Chefs de projet idéaux citaient et remerciaient, dans les communications associées, tous les collègues ayant pris part au projet.
Lorsque les Intégrateurs terminaient un projet plus tôt que prévu, les Chefs de projet les incitaient à peaufiner le résultat, ou à rédiger un retour d’expérience lorsque le sujet était intéressant, ceci afin d’améliorer la qualité et de favoriser la capitalisation des connaissances.
Les Chefs de projet idéaux savaient créer un esprit d’équipe stimulant pour que chacun puisse, en toute confiance, donner le meilleur de lui-même.
Enfin, les Chefs de projet idéaux considéraient les contraintes de chaque intervenant avec impartialité. Ils étaient attentifs aux besoins de chacun, et savaient faire preuve d’écoute.
Épilogue
Le monde du travail n’est pas un conte de fées.
Derrière sa forme humoristique, ce billet a pour but d’attirer l’attention sur les éléments stratégiques d’une collaboration efficace entre chefs de projet et intégrateurs.
Les chefs de projet ont une grande part de responsabilité dans le succès (ou l’échec) des projets qu’ils gèrent, mais tout ne repose pas sur leurs épaules. Ils font souvent face à des clients qui n’y connaissent rien, persuadés que créer des sites web est facile et que ça ne coûte pas un rond.
Les chefs de projet doivent souvent réaliser un nombre de tâches indéfinies, qui fluctuent en fonction du milieu dans lequel ils évoluent (agence, annonceur) et surtout du client.
Quant à nous, nous ne sommes pas à la place de nos collègues. Nous ne percevons leur travail qu’à travers nos propres problématiques métier, notre sensibilité ainsi que nos a priori, parfois influencés par les tensions passagères que provoquent parfois les projets ambitieux.
C’est pourquoi nous manquons souvent de recul pour comprendre les contraintes particulières auxquelles les chefs de projet font face, ainsi que les décisions qu’ils sont amenés à prendre, d’autant plus lorsque la communication entre eux et nous est insuffisante.
Ensemble, il est sans doute possible d’améliorer les choses.
En tant qu’intégrateurs, nous avons souvent l’occasion de partager notre expérience professionnelle, que ça soit par tweet, par blog ou par conférence interposés.
Nous participons à l’effort collectif de documentation et de communication, peut-être parce que l’intégration web est toujours, fin 2014, une discipline mouvante, difficile à aborder et à définir.
Donner à voir notre quotidien professionnel fournit – espérons-le – des clés à nos interlocuteurs pour mieux comprendre notre métier et ses particularités.
Or, on n’entend que trop rarement les chefs de projet parler de leur métier et de leurs contraintes spécifiques, alors qu’il s’agit d’un métier tout aussi singulier et stratégique.
Une gestion de projet de qualité est cruciale à la réussite des projets web dont nous partageons la responsabilité et, pourtant, il me semble que les chefs de projet communiquent encore assez peu sur le web.
Les chefs de projet pourraient par exemple donner davantage à voir leur quotidien, leurs méthodes, leurs outils et leurs contraintes, quel que soit leur nombre d’années d’expérience, leur statut ou le type de structure pour laquelle ils travaillent, afin qu’eux et nous puissions mieux travailler ensemble.
J’adorerais aussi lire des retours d’expérience rédigés à quatre mains, par un chef de projet et par un intégrateur, tout comme j’adorerais les voir sur scène ensemble pour nous raconter comment ils ont réussi, jour après jour, à améliorer leur collaboration.
Mais cette collaboration renouvelée pourrait sans doute prendre d’autres formes encore…
Maintenant, c’est à vous : connaissez-vous un∙e Chef de projet idéal∙e ? Quelles sont les caractéristiques de vos chefs de projet préférés ? Racontez-moi une belle histoire, soit dans un commentaire, soit sur Twitter, en mentionnant @lesintegristes.
Et, d’avance, belles fêtes de fin d’année à tous !
Merci à Anne, Corinne, Damien, Delphine, Élodie, Éric, Florian, Fred, JP, Julien, Matthieu, Mehdi, Olivier, Pierre, Samuel et Vincent pour leur relecture et leurs conseils avisés.
Et merci à ma maman, Claire Guillaumet, pour ses illustrations.
Les commentaires sont fermés sur cet article.
22 commentaires
Flux RSS des commentaires de cet article
Le CP idéal n’existe pas. Tout comme l’inté idéal non plus. Ou ils habitent en « Théorie », car « En Théorie, tout se passe bien. »
Néanmoins, dans ma hotte du Père Noël, je lui demanderai surtout :
– de tout le temps s’assurer de la cohérence générale du projet, et de ne pas se reposer sur ses développeurs/intégrateurs pour le faire, qui n’aiment pas découvrir que les carrés ne rentrent pas dans les ronds.
– de ne pas avoir peur d’aborder les problèmes, sans affect ni dramatisation excessive : un problème soulevé, ça se règle. Un problème pas abordé, ça explose.
– de ne JAMAIS croire que tout se pilote tout seul, c’est un mythe délirant.
Le 24 Nov. 2014 à 11h52 par Nico
Ca fait plaisir de revoir un article ici !
De plus, super sympa à lire !
Le 24 Nov. 2014 à 11h59 par Residu
Merci beaucoup pour cet article.
Il y a encore beaucoup à écrire sur la gestion de projet.
J’espère que cet article incitera beaucoup de personnes à sortir leur plume :)
Le 24 Nov. 2014 à 12h04 par Aurélien
Encore un article de haute volée, merci ! Il est clair que l’aspect technologique du web a tendance à mettre en avant… les techniciens justement.
À tord, car la gestion de projet (que j’aimerai d’ailleurs voir un jour requalifier en gestion de produit ou de service, un projet étant moins une finalité qu’une ambition, mais c’est un autre débat) est au cœur du bon déroulement de l’ensemble, et cristallise, à beaucoup d’égards, les facteurs « humains » du projet (communication, échanges, concessions, etc).
Chez nous, elles ont pris la plume depuis le début de l’année, histoire de justement faire entendre leur voix (http://blog.lunaweb.fr/tags/gestion-de-projet/).
Le 24 Nov. 2014 à 12h14 par Guillaume
Sacré boulot !
Tu pointes des choses essentielles à notre travail pour une bonne entente.
Même si cela reste très utopique, je pense que certain CP comprendrons qu’ils ont encore des progrès à faire dans la façon de gérer un projet, et les pistes ne manquent pas !
Merci d’avoir pris le risque d’écrire cet article.
Le 24 Nov. 2014 à 12h32 par Stéphane
Salut à tous, merci pour vos réactions à chaud ! Contente que l’article vous plaise :)
@Guillaume : très intéressante, cette idée de troquer « gestion de projet » pour autre chose. J’adhère à ta vision ! Et merci pour le lien vers le blog de Luna, une référence de qualité, qui en intéressera plus d’un.
@Stéphane : Tu dis ça par rapport à la tête de cheval mort que quelqu’un a déposé dans mon lit ? :-P
Le 24 Nov. 2014 à 21h38 par Marie Guillaumet
Beaucoup des problèmes que tu décris sont symptomatiques d’une culture en silos, ça me fait presque bizarre de lire ça, on croirait que rien n’a bougé depuis 10 ans : les intégrateurs sont toujours de grands incompris, de même que les designers et pourquoi pas les chefs de projet et les clients ?
À te lire les différentes parties prenantes d’un projet vivraient chacune dans leur petit monde idéal et auraient donc beaucoup de mal à se comprendre. C’est vrai, ils ont chacun leur culture propre.
Le bouc émissaire serait donc celui qui fait tampon, le principal interlocuteur, à savoir le chef de projet — quand le chef de projet lui même ne désigne le client comme responsable de l’échec du projet, pour se dédouaner de toute responsabilité. Si on relègue l’intégration en bout de chaîne, alors on reporte la pression sur cette profession spécialisée dans la réalisation de miracles.
Accumulant la frustration,et faute de pouvoir communiquer de manière ouverte avec son collègue, par dépit on en est réduit à devoir écrire des articles de blog, sous forme de conte de Noël, pour aller puiser un peu de courage auprès des siens car la prochaine conférence est encore trop loin et qu’on a besoin de vider son sac ou qu’on se fait le porte-parole d’une profession incomprise et peu reconnue.
Tout ça est en partie vrai.
J’ai connu des chefs de projets, isolés du reste de leur équipe et qui cherchaient les coupables en fin de projet, car il y avait « du retard ». Et pam sur les doigts !
A l’inverse, j’ai connu des responsables produits, très impliqués et très concernés par le bien être de leur équipe.
Outre les délais ou un périmètre, ce qui peut aider l’équillpe c’est de partager des objectifs communs à *tous* les corps de métier.
Exemples :
* Augmenter le nombre d’inscrits depuis les terminaux mobile de 10%;
* Passer sous la barre des 5 secondes le temps de chargement des pages les plus consultées;
* Augmenter la durée moyenne des visites sur les articles du blog de 30 secondes.
* etc.
Une vision partagée, ça aide à se focaliser sur l’essentiel : la valeur ajoutée pour le client. Et on comprend bien que de tels objectifs dépendent des différentes parties prenantes et pas uniquement d’une seule personne.
À partir de là chaque corps de métier devrait être libre d’interagir quand nécessaire. (marketing, design, ergo, rédactionnel, front, back, etc.). Et les questions viendront d’elle-même si tout le monde est concerné.
Sans objectif clair et sans aide des différents intervenants, un designer peut par exemple perdre de vue certaines contraintes, même chose pour un intégrateur ou tout autre intervenant.
Et ce fameux « chef de projet » idéal, il est surtout là pour s’assurer que l’équipe ne perde pas de vue les objectifs du projet. Il est au service du produit (et donc du client) et de l’équipe : il récolte toutes les informations nécessaires à l’équipe, défini à l’aide du client les scénarios de recette, il écoute les conseils de ses experts métiers, et leur fait confiance pour estimer les tâches en fonction de leur expérience. Il sait à la fois écouter et expliquer quand il le faut au client les difficultés ou les contradictions dans ses demandes. Et il transmet les propositions que son équipe peut faire pour répondre à certaines problématiques, voire encore mieux, il laisse chaque expert expliquer une problèmatique particulière, s’il n’amène aucune valeur ajoutée.
Finalement, un « chef » de projet ne décide de pas grand chose même s’il peut être amené à devoir arbitrer certaines situations. Surtout si le périmètre est défini en fonction des estimations de l’équipe ou à l’inverse par le budget du client.
Il décide parfois des dates de planification au client, une fois que tout est prêt pour démarrer le projet (objectifs, budget, périmètre et recette).
La gratification du chef de projet, c’est un client qui est content de la prestation d’une équipe car ses objectifs sont atteints mais également une équipe épanouie à l’aide de laquelle il définit un cadre pour qu’elle puisse s’améliorer de projet en projet ou d’itération en itération.
Je vous assure, ça existe, on en rencontre même souvent dans les équipes agiles expérimentées, car ces équipes ont bien compris que la réussite d’un projet ne pouvait reposer sur un « chef », mais sur la collaboration des différents parties prenantes, où chacun prend ses responsabilités et s’engage dans une vison partagée avec le client.
Le 25 Nov. 2014 à 00h46 par Frank Taillandier
Un article très intéressant et des commentaires constructifs.
Par expérience, je comprend très bien le faussé qu’il peut y avoir entre le chef de projet et ses équipes.
Je crois aussi comme l’explique très bien Frank Taillandier que de très bon chefs de projet existent. Des chefs de projet qui savent communiquer avec chacun de leurs interlocuteurs et qui savent également les amener à s’exprimer.
C’est de cette image que j’aimerais m’inspirer dans mon travail, car après près de 10 ans à travailler dans le développement et l’intégration, avec une forte sensibilisation à l’accessibilité numérique, je m’oriente aujourd’hui vers le métier de chef de projet.
J’espère pouvoir tendre vers ce chef de projet idéal. Je n’hésiterais pas à faire un retour d’expérience après avoir géré 2 ou 3 projets.
Le 25 Nov. 2014 à 11h03 par Régis Lapeze
Salut Frank ! Merci pour ton long commentaire, qui pique un peu au début :)
Ce que tu dis a du sens quand on est impliqué dans une équipe « produit » chez l’éditeur. En agence, les choses sont un peu plus nuancées.
Pour rebondir sur les exemples d’objectifs que tu donnes (, etc.), quand on bosse en agence, on n’est pas forcément impliqués de la même manière sur ce type d’objectifs.
L’implication d’une agence dans la chaîne de production varie d’un projet à l’autre ; parfois, elle intervient suffisamment en amont, par exemple en planchant sur l’UX, pour effectivement être pertinente sur certains des objectifs que tu cites.
Mais quand elle intervient seulement en bout de chaîne (réalisation), ces objectifs ne sont pas du tout de son ressort.
Ça paraît évident, mais je voulais le préciser.
Après, oui, certaines agences bossent encore sur le mode des silos, je comprends bien que cela puisse appartenir à un autre temps, mais c’est le quotidien de nombreux confrères et consœurs. Ne les oublions pas.
Enfin, le but de l’article n’était pas de mettre sur un piédestal les intégrateurs, ces licornes à cinq pattes, ni de critiquer les CP juste pour le plaisir, mais de parler de la face émergée de l’iceberg, qui cache souvent des dysfonctionnements structurels, comme tu le rappelles à juste titre.
Après, oui, le format « conte de Noël » était assez défoulante, je dois dire ;)
Le 25 Nov. 2014 à 11h14 par Marie Guillaumet
D’abord merci à toi et à ceux qui ont contribué à cet article qui soulignent deux choses à propos desquelles on trouve peu de retour constructif :
– on voit souvent l’intégrateur/front-end dev comme le casque bleu qui se retrouve entre la tranchée du DA et celle du développeur back, or j’ai l’impression que ces 2 nations sont plus proches de l’armistice que de la guerre nucléaire. Aujourd’hui l’intégrateur échange beaucoup avec le CP parce que c’est lui qui est responsable de ce que voit le client. L’intégrateur travaille quasiment en binôme avec le CP lors de la phase de recette.
– la gestion de projet est le nerf de la guerre, ça ne sert à rien d’avoir les meilleurs contrats, les meilleurs développeurs, si c’est pour avoir le pire CP du monde. C’est le chef d’orchestre du projet.
Et quand on voit toutes les événements traitant du graphisme, du front et du back, il est vrai que celui qui s’occupe de la gestion peut vite avoir l’impression d’être laissé pour compte, de travailler dans l’ombre, de faire tampon avec le client, etc.
Pourtant si le projet se passe bien, le chef de projet sera le premier à recueillir les merci du client (pour peu qu’il s’agisse d’un client bien élevé). Il saura que c’est une réussite collective et il partagera les lauriers avec son équipe.
A contrario, si le projet se passe mal, le chef de projet sera en premier ligne et si la pression exercé par le client est mal gérée cela va se transformer en tension entre le chef de projet et sa propre équipe.
Bref, le CP est parfois un fusible entre client et équipe de production, alors qu’il devrait être le médiateur.
Je n’ai pas 10 ans d’expérience, mais j’ai connu des CPs ultra, des CPs débordés, des CPs à distance, en agence, en régie…
Et au final, ce n’est pas le meilleur CP qui s’en tirait le mieux, mais celui (ou celle) qui :
– avait/prenait le temps de communiquer avec son équipe
– connaissait les problématiques techniques/graphiques
– n’avait pas 20 projets en même temps
Je terminerai en insistant là dessus : là où ma relation d’intégrateur s’est le mieux passé avec les chefs de projet c’était étrangement là où j’ai vu les chefs de projets les plus épanouis : des agences / annonceurs qui avaient un nombre de chef de projet en adéquation avec leur charge de projets.
Être chef de projet ne s’improvise pas, c’est comme un graphiste ou un développeur. Un chef de projet ne fait pas que transférer les mails du client à l’intégrateur. C’est un métier qui mérite de la reconnaissance.
Car dans ce compte de Noël, tous les protagonistes ont le temps de bien faire les choses, donc puisqu’un des rôles du CP est de gérer le temps de chacun, il est important qu’il est le temps de bien le faire afin d’éviter un terrible effet domino.
Le 25 Nov. 2014 à 14h03 par Philippe
Superbes les illustration de la maman
Le 25 Nov. 2014 à 15h59 par AnCé
@Marie : désolé si je t’ai brusquée, mais prendre plaisir dans son travail et se sentir soutenu et respecté c’est essentiel pour progresser. Et ça me chagrine que tu aies à écrire ce type d’article. Pour toi ou pour quiconque vite cela. Vraiment. Et d’autant plus venant de quelqu’un d’aussi passionnée et qualifiée que toi.
Mais certaines phrases sont tellement révélatrices :
> Les chefs de projet pourraient par exemple donner davantage à voir leur quotidien, *leurs* méthodes, *leurs* outils et *leurs* contraintes.
Mais comment ça, ils sont pas avec vous ? Vous travaillez pas avec les mêmes outils ?
Pourquoi cet emploi du pronom possessif ? Et cela n’a rien à voir avec le fait de bosser, pour une agence, une start-up, ou une association. C’est bosser en silo. Et c’est très mauvais pour tout le monde, le chef de projet y compris.
Définissez d’abord les valeurs que vous partagez.
C’est pas facile, il faut une adoption commune. Mais il n’y a pas d’outils « pour le chef de projet », il y a des façons de réussir un projet et il y a comme tu le dis surtout le besoin d’interactions humaines de qualité entre des personnes qu’il faut savoir mettre en situation de confiance.
Si il y a une liste de tâches correctement découpées (s’inscrire sur le site, afficher la liste des derniers articles, etc.), elle devrait être visible par toute le monde, s’il y a des limites de temps, elles doivent être connues de tous, de même que l’avancement, le restant à faire etc. Plus ces informations sont difficiles à avoir, plus il y a de risques d’incompréhension entre les différentes parties et donc de ralentissement.
Je pars du principe que tu as déjà du faire face à ce genre de situation.
De mon expérience personnelle, cela demande de définir avant tout des valeurs et des engagements partagés plutôt que des outils de gestion de projet.
Et du coup, je suis curieux :
Comment décidez-vous du workflow de travail général ? Comment l’équipe sait-elle où elle en est, ce qui reste à faire ?
Chez nous, nous avons mis en place un grand Kanban au mur que l’équipe a sous les yeux en permanence, il représente l’état de notre workflow (ça peut aller de la piste commerciale aux déploiements de correctifs en passant par les tests d’utilisabilité, c’est selon le contexte). Il est utilisé par tout le monde. Il est soumis à des règles claires, définies progressivement par l’équipe elle-même.
Le Kanban physique est un outil très simple et très souple, bien adapté aux équipes pluridisciplinaires co-localisées. Il existe des versions en ligne comme le populaire Trello mais on perd l’essentiel, les interactions humaines.
Entre autres avantages, le Kanban permet de générer des discussions au bon moment en face to face, plutôt que par mail.
Il a pour but de faciliter la gestion du flux des tâches (rôle qui incombe au chef de projet), en focalisant l’équipe sur le travail en cours, pour le « tirer vers la droite », vers la colonne FINI au plus vite. Le kanban est un outil visuel, il va permettre de rapidement voir où le flux « bloque ».
Bref c’est un super outil sur lequel il y aurait beaucoup à dire et je ne peux qu’inviter les équipes à se pencher sérieusement dessus, car outre le fait de fournir une vision commune du flux de travail il pousse l’équipe à s’améliorer en la laissant s’organiser comme bon lui semble pour atteindre les objectifs fixés.
Aux chefs de projet, je dirais « arrêtez de vouloir tout contrôler, partagez la responsabilité, donnez des objectifs précis.
Car le problème que révèle ce conte est profondément humain, et derrière la problématique du « chef de projet » idéal se cachent des problématiques culturelles.
Sur l’importance de travailler avec des personnes qui partagent les mêmes valeurs, pour éviter de passer son temps à argumenter sur la façon dont il faut faire les choses, je vous renvoie à la conférence (en anglais) de Kevin Goldsmith à Sud Web sur le sujet : https://vimeo.com/102774091
On notera la notion de « Servant Leadersship » parmi les valeurs fondamentales, qui part du principe que les managers qui écoutent, font preuve d’empathie et font progresser leurs collègues obtiennent de meilleurs résultats sur le long terme.
Le 27 Nov. 2014 à 03h21 par Frank Taillandier
Merci Régis, et bonne chance pour ton évolution en tant que CP. :)
Le 29 Nov. 2014 à 16h16 par Marie Guillaumet
Hello Philippe, merci pour tes retours !
Je suis tout à fait d’accord avec toi.
À propos du mythe de la mésentente entre intégrateurs et web designers, j’avais donné mon avis chez l’ami Cabaroc il y a un an et demi : mon avis n’a pas bougé d’un iota.
Par ailleurs, c’est bien parce que le travail des intégrateurs et des CP est éminemment complémentaire que je me suis fendue de cette petite satire. La notion de binôme est très juste.
Tout à fait ! La problématique du staffing du CP est stratégique. Or, ce staffing dépend rarement de lui. Dans mon article, il y a pas mal de points qui sont liés plus ou moins directement à ça, aux écueils essuyés lorsqu’un CP est débordé, pressé par sa hiérarchie, et qu’il manque de temps pour soigner les finitions.
Le 29 Nov. 2014 à 16h23 par Marie Guillaumet
Salut Frank !
Y’a pas de mal du tout, au contraire ! Je suis contente qu’on me rentre un peu dans le lard, je m’étonne d’ailleurs que tu aies été le seul ;-)
Alors, avant de te répondre plus avant, je tiens à rappeler que cet article ne parle pas de moi ni de mon travail au quotidien (bien que certaines situations puissent me rappeler certains trucs que j’ai vécus).
Pour écrire ce conte de Noël, je me suis certes appuyée sur ce que me racontent parfois des confrères et consœurs intégrateurs, mais j’ai aussi pas mal grossi le trait à des fins de caricature. Si ça te paraît exagéré, c’est donc volontaire. Ce n’est pas un reportage ; c’est une satire.
Cela étant dit, il y a certaines anecdotes que j’ai à peine reformulées. Tout choquant que cela puisse sembler, ce genre de situations, ce morcellement du travail en silos, ce manque de communication et de valeurs communes, existent bel et bien.
À en juger par tes deux commentaires, il semble que toi, tu aies la chance de travailler dans un contexte qui, par bien des aspects, semble idéal, mais crois-moi, c’est loin d’être le cas pour tous les intés et tous les CP avec qui j’ai déjà discuté !
Je sais, je sais, tout cela paraît évident. ET POURTANT. ;-)
Merci beaucoup pour tout cela ! Les méthodes agiles sont bien ancrées en matière de développement back, mais j’en entends beaucoup moins parler côté front.
Oui, il y a de ça en effet. Le syndrôme du petit chef. Mais il y a aussi, comme le soulève Philippe dans son commentaire, des problèmes d’organisation qui découlent d’une surcharge d’activité. Si un CP est amené à gérer quatre ou cinq sujets importants en même temps, je ne vois pas trop comment ça peut fonctionner, qualitativement, humainement. Derrière tout ça, il y a aussi une responsabilité prise par les managers.
Bon, et sinon, j’écouterai la conférence de Kevin Goldsmith avec intérêt !
Merci encore pour ces échanges intéressants, Frank, tout cela m’apporte un point de vue complémentaire et d’autres axes de réflexion. Si, un jour, nous en discutons de vive voix de cette fantaisie de l’avent, j’aurai sans doute d’autres précisions à t’apporter.
Le 29 Nov. 2014 à 16h46 par Marie Guillaumet
Sympa ce conte de Noël. Je ne savais pas que les retours d’expérience de chefs de projet étaient aussi attendus sur le net !
Il est important que le chef de projet comprenne effectivement bien ses équipes et leur travail afin de bien communiquer avec elles et organiser le projet. Il me paraît primordial qu’il ait lui-même des notions dans ces différents métiers afin d’être plus efficace aussi bien côté équipes que côté client. Il pourra ainsi émettre des premières réserves si besoin quant à la faisabilité technique et pas dire oui tout azimut aux idées fantaisistes du client ou du commercial face également à un timing et budget limité.
La seule chose qui ne ressort pas j’ai l’impression dans cet article c’est justement la dimension commerciale. Parfois, le chef de projet n’a pas le pouvoir de dire non au client sur certaines décisions qui lui paraissent tout aussi injustifiées qu’à son équipe. Tout dépend de la politique de la boîte, vendre ou non à perte, vendre du non qualitatif mais vendre à tout prix… Après, le rôle du chef de projet est clairement d’expliquer au mieux les délais, de conseiller, trouver un compromis avec le client, anticiper de part et autres les problématiques afin de faciliter la production, être transparent avec ses équipes et éviter les quiproquos sur la finalité avec le client, mais il n’a pas toujours le dernier mot sur ce qui est vendu ou décidé au final.
C’est en tout cas très chouette de pouvoir discuter de ce sujet et de voir les avis/difficultés que peuvent rencontrer les intégrateurs aujourd’hui. Pour améliorer les process, il est également bon de faire un bilan une fois qu’un projet est fini afin de voir ce qui pourrait être améliorer la prochaine fois, si on a le temps et encore une fois, si la culture de l’entreprise le permet.
Comme vous l’avez évoqué dans les commentaires, la notion temps du chef de projet qui courre partout à gérer 5/6 projets à la fois est primordiale, limitative et affecte effectivement parfois son travail qualitatif avec les équipes de production. Je pense que dans ces cas là, la première chose qui saute, c’est malheureusement le côté transparence qui donne la visibilité globale à TOUS les acteurs du projet, même s’ils ne sont pas directement impactés, provocant ainsi le fameux côté silo et le « on ne sait pas trop pourquoi on fait çà comme çà mais on le fait parce qu’on doit le faire », provocant forcément certaines frustrations.
Mais bon, dans un monde idéal, on ferait tous des projets où les variables temps, délai, budgets seraient en adéquation !
Le 03 Déc. 2014 à 00h23 par Ally
Suffit de la terminologie d’intégrateur. Ce sont des Front-end Devs.
Des alliés puissants du CP pour argumenter le discour responsive web design auprès des clients et pour les faire monter en maturité !
Le 09 Déc. 2014 à 21h06 par Benoit
Developer front end, terme largement utiliser pour nous définir pourtant à mon avis nous sommes pas vraiment des developpeurs.
Nous sommes plutôt des artistes ( lol ) au service des Chef de projet qui nous donne les directives, pas forcement les plus justes mais on les suit quand même des fois.
Le 11 Déc. 2014 à 10h43 par Marc
Merci je me sens moins seul…
Je pense / développe au sein de l’équipe !
Hum sinon je change clairement de métier? Non?
Un créa assujetti aux problématiques clientèles…
Hum perso je passe par le client et c’est bcp + clair !
?
Le 20 Déc. 2014 à 06h19 par Ronan
Un chef de projet qui n’a que l’égo de lui même…
Hummmm ?
Le 20 Déc. 2014 à 06h22 par Ronan
Que de vérités dans notre quotidien !
Merci !
Le 20 Déc. 2014 à 06h25 par Ronan
A l’époque où j’étais encore en apprentissage, un chef de projets senior m’avait confié que, très souvent, le chef de projets ne sort de l’ombre que lorsqu’il y a des problèmes.
Lorsque « tout va bien », c’est normal pour tout le monde l’équipe de prod, le client, les prestas… mais c’est surtout parce le chef de projets est cette force de l’ombre qui dirige les flux des différents interlocuteurs.
Comme vous le dites, et le souligne Ally, la principale variable dans la qualité d’un taf de CDP c’est le temps. Préparer les échanges entre clients et prod, parfois faire la conception, suivi planning et prod sur au moins 5/6 projets actifs, plus la dette projets, c’est du temps.
Il n’y a pas de chef de projet parfait, mais il y a des chefs de projets qui apprennent et s’améliorent. Je pense que c’est le mieux que l’on puisse avoir :)
Le 02 Jan. 2015 à 16h35 par Cédric Dagherir