Mauvais développeur = (bon) Chef de projet ??
Publié le 28 July 2008, par Babozor dans la catégorie Développement, Emploi, Gestion de projet
[Allez, on va s’énerver un peu et se prendre le choux… mais dans la bonne humeur bien sûr]
Certains ont une espèce de malédiction qui plane au dessus de leur tête… ils sont certes motivés et passionnés par le web, mais ce sont de piètres développeurs (on peu même dire des développeurs tout pourris), après quelques cassages de dents sévères, quelle est la solution? Passer chef de projet? Aller élever des chèvres dans le larzac? Bonn question…
J’ai en fait eut plusieurs fois le cas et Seb en parles en connaissance de cause sur son blog… ou d’ex développeurs passaient chef de projet pour les mauvaises raisons, pas par volonté fondamentale de gérer des projet, manager une équipe, mais comme roue de secours pour rester dans le domaine…
Comme dit le fameux proverbe: “Those who can’t do teach… Those who can’t teach, teach gym…” (et je vous laisse méditer dessus!)
Le métier de chef de projet est un métier passionnant, mais dur, qui demande beaucoup d’expérience et de compétences variées… en particulier pour un ex-développeur, le pas est d’autant plus dur à franchir, voici donc quelques points essentiels pour éventuellement passer dans l’autre camps.
1. Gagner le respect des développeurs
C’est un point crucial… vous VOULEZ que les développeurs vous aiment, ou au moins qu’ils ne vous traitent pas comme une sous-merde ou un n00b, vous devez donc gagner leur respect. Tout un programme. C’est malheureusement le seul moyen pour vous d’être sûr d’être traité décemment par vos développeurs. C’est crucial, puisque dans leurs têtes vous avez trahis, vous êtes passés à l’ennemi… de l’autre côté en quelque sorte
Deux moyens pour cela:
- vous leur montrez quel bon développeur vous êtes (mais ça c’est pas gagné puisque vous êtes un développeur moyen voir nul), ou qu’avec vous ils peuvent apprendre des choses, au niveau du code, de la gestion de projet, se servir de votre expérience, etc…
- vous restez humble, vous ne vous la pétez pas et vous demandez des précisions, de l’aide, qu’on vous explique, etc… rien de plus insupportable que quelqu’un qui croit savoir quelque chose alors qu’il est à côté de la plaque, qui prend les mauvaises décisions avec en main les mauvaises données.
Vous allez être la passerelle entre les développeurs et le reste de la boite, il doit donc y avoir une confiance réciproque entre les dev et vous, c’est indispensable, si ce n’est pas le cas, c’est mort pour vous, vous allez au devant d’emmerdes sans nom.
2. Une très bonne connaissance du WorkFlow
Vous devez vous mettre à jour… savoir quel est le processus de production, quels sont les postes, qui travaille où, quel est son domaine, sa chasse gardée. C’est important, souvent on rentre dans un projet à la barbare sans penser aux divers susceptibilités, sans vraiment connaître le workFlow et on se met à dos des gens important dans ce workFlow.
N’ayez pas peu de demander, ça n’a rien de déshonorant au contraire.
3. Bonne capacité de communication avec des corps de métiers différents
Vous n’êtes plus le barbu dans sa cave, mais la personne qui fait le lien entre les différents corps de métier, vous devez donc avoir un contact direct avec tous, connaître leur spécificité, et surtout essayer de parler leur langage. On ne parle pas de la même façon à un dévloppeur et à un DA (c’est un peu cliché je sais mais tellement vrai).
Vous devez être la colle, l’élément qui fait que la mayonnaise prend, pas un obstacle de plus…
4. Trouver des solutions
C’est peut être le conseil fondateur, celui qu’il ne faut pas oublier… Plutôt que de rejeter la faute à un quelconque stagiaire ou à un presta externe, tentez de trouver des solutions, c’est le meilleur moyen pour rendre tout le monde heureux.
Les specs ne sont pas bonnes, trouvez un moyen d’y remédier, pas assez de dev pour finir le projet à temps, chiffrer les options alternatives, etc… rien ne sert de trouver un bouc émissaire, il faut trouver une solution (et analyser pourquoi ça a merdé)
La décision de passer d’un mauvais développeur à un bon chef de projet n’est pas si évidente que ça en fait, cela demande des compétences relativement éloignées d’un bon dev: un sens du contact, de l’organisation, de l’expérience, etc… si c’est une volonté réelle de changer de métier pour l’amour de la gestion de projet, c’est une bonne décision. Si c’est pour échapper à un choix de carrière catastrophique, c’est tout une autre histoire…
le 28 July 2008 à 13h54
Hahahah Je ne connaissais pas la suite du proverbe
Enfin plus exactement je connaissais la version “Ceux qui savent font, ceux qui ne savent pas enseignent”, mais la seconde partie du proverbe est excellente :-D.
Sinon je n’ai aucune expérience sur le sujet mais je suis d’accord sur le “dans leurs têtes vous avez trahis, vous êtes passés à l’ennemi…”, à part que le terme “ennemi” est un peu fort (un peu) :-p
le 28 July 2008 à 14h10
Un article qui encore une fois vise juste surtout avec cette phrase “Vous devez être la colle, l’élément qui fait que la mayonnaise prend, pas un obstacle de plus…”
J’ai le sentiment vraiment que c’est trop souvent le cas. Le pire étant que le chef de projet arrive à cacher son incompétence à ses supérieurs, chose qui éclate pourtant aux yeux de ses subordonnées.
A croire que des belles paroles font plus belles effets que de réels compétences.
Le point 1 est là encore primordiale, comme je le disais dans mon article, tout le monde veut devenir chef de projet en sortant d’école sans avoir les compétences d’une part parce qu’il pense que c’est mieux payé et d’autre part parce qu’ils sont incompétents et que par conséquent ils “”"”"méprisent”"”"” le développeur.
le 28 July 2008 à 16h33
Et le mauvais chef de projet ? Il devient développeur ? Moi j’en connais
Effectivement c’est super différent comme démarche, et ça dépend si c’est un chef de projets qui deviendra directeur de projets - on reste très ancré dans le technique, l’organisation, l’opérationnel et être passé par la case développeur est très appréciable - ou un chef de projets qui deviendra directeur de clientèle, là on est plus dans le commercial.
le 29 July 2008 à 11h59
Ces 4 sont tout à fait pertinent à mon sens. On en revient à la définition meme du chef de projet : c’est une mission de relationnel, une mission éminemment humaine donc, réclamant à ce titre des qualités comportementales. Un chef de projet qui code 10x mieux que c’est codeur ne vaudra pas mieux qu’un chef de projet qui confond AJAX et flash, le bon chef de projet est celui qui saura placer son interlocuteur dans le meilleur rapport possible. Soit en étant attentif, soit pédagogique, soit directif, soit souple, etc etc. On peut tres bien savoir driver un dev et avec d’autres ça ne passera pas, preuve s’il en fallait que le chef de projet doit bien savoir s’adapter, donc rester humble.