Un chef de projet peut il à la fois faire son travail de chef de projet (planification des projets, cahier des charges, relations clientèles ......) et coder sur ses projets ?
Ces 2 tâches sont elles compatibles pour une même personne ?
Merci
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Un chef de projet peut-il coder ?
Un chef de projet peut il à la fois faire son travail de chef de projet (planification des projets, cahier des charges, relations clientèles ......) et coder sur ses projets ?
Ces 2 tâches sont elles compatibles pour une même personne ?
Merci
tout dépend du projet
Si il a une equipe de 2 personnes, il a largement le temps.
Si il a une equipe de 20 personnes, il aura pas le temps.
Et si il a d'autres responsabilité telles que responsable informatique et télécom (admin réseaux et systèmes, EDI....)
le réponse est toujours le meme. C'est une question de charge de travail.
En tous cas, il doit avoir la compétence de le faire, du moins d'un point de vue algorithmique.
Certains chefs de projets ne savent pas coder, de près comme de loin, mais se cachent derrière le fait qu'ils doivent "gérer" une équipe de 3 personnes (souvent autonomes) pour prétexter qu'ils ne peuvent pas le faire.
Je l'ai déjà vu sans que cela ne pose problème... c'est d'ailleurs un plus indéniable dans un forfait pour chiffrer convenablement le reste à faire
déjà vu aussi. En même temps, je l'avais vu coder avant, eh bien il était préfèrable qu'elle cesse cette activité ou elle était fort néfaste. Comme CP, elle était moins nuisible.....Envoyé par dgi77
par contre, j'en ai vu d'autres mettre les mains dans le cambouis quand ils avaient le temps, et avec beaucoup de talent. Bien utile pour rattraper certains retards.
Bonjour,
je travaille pour un grand groupe de consulting IT americain, et je suis plus ou moins bac + 7. Suivant les missions. j'occuppe diverses fonctions, dont parfois celle de chef de projet d'une equipe de developpement.
J'ai eu la chance (et je pense que c'est une chance) de souvent avoir des responsabilites techniques operationnelles sur mes projets. Cela veut dire que j'ai code (souvent la partie la plus delicate), debuggue du code (le plaisir de reprendre du code C pourri ecrit par quelqu'un qui est parti), mais aussi de faire des tests de performance et du tuning, ainsi que de l'exploitation. Je pense que cette experience me permet d'etre beaucoup plus efficace comme chef de projet d'une equipe de dev. D'abord parce que je peux aider les gens que j'encadre, et que je deviens automatiquement credible aupres d'eux (et parfois de mon client). Ensuite, parce que je comprend mieux les petits aleas de la vie de developpeur, et puis je peux aussi orienter mon projet dans une direction qui facilitera la vie de l'equipe technique. Il m'arrive encore (meme si c'est quelques jours par trimestre) de mettre les mains dans le code.
Attention, l'experience technique n'est pas la seule necessaire pour reussir un projet. Il est aussi necessaire de se mettre a la porte des utilisateurs (idealement, il faudrait passer quelques jours avec les utilisateurs du logiciel) pour comprendre leur metier). Il est aussi important de bien comprendre le marche et le metier du client (peut-etre qu'une fonction est delicate a coder, mais elle est cruciale pour le metier du client. Le but de la direction d'un projet est ensuite de trouver le meilleur compromis entre les besoins clients et l'equipe de developpement, et de garder un etat d'esprit constructif entre tous les interlocuteurs du projet.
La "technique" de gestion de projet est certes important (planification, gestion de la liste des actions), mais c'est un travail repetitif, presque mecanique, que je delegue autant que je le peux. J'ai l'impression que beaucoup cachent leur mediocrite derriere leur plan MSProject ou leur Action List.
Complètement d'accord avec toi uchimizu, et surtout sur le dernier paragraphe !
Il me semble en effet plus simple de déléguer la gestion des planning que le support technique, mais peu de chefs de projets en ont les moyens... Et je pense que les mêmes ne sont pas en mesure de comprendre ton post, car ils n'ont jamais été en mesure de pouvoir apprécier combien il était plus confortable et crédible d'être CP lorsqu'on maîtrise la composante technique.
absolument d'accord avec vous 2...
C'etait d'ailleurs le sens de pas mal d'interventions du lien cite plus haut...
En ce moment, je cherche ce genre de postes, donc ce débat m'intéresse fortement
Il est clair que le boulot d'un chef de projet est très vaste. Outre le lien avec le client, le lien avec les développeurs est tout de même différent si on sait programmer ou si on ne le sait pas. Mais en même temps si on est un programmeur avec de l'expérience et que les autres codent comme des pieds...
A mon avis, le CP doit surtout connaître le corps de métier. S'il travaille dans la gestion ou dans les systèmes critiques, ce n'est pas la même chose, il y a une différence sur le chef de projet à prendre, il n'y a pas les mêmes priorités, les mêmes outils à utiliser, ...
Le CP c'est l'homme à tout faire sur le projet.
Il est le responsable du projet.
Si le projet dérape c'est lui qu'on ira voir.
S'il y a des pb entre MOA / MOE, c'est lui qui ira voir.
S'il y a un souci sur un programme, c'est lui qu'on ira voir (il pourra aiguiller vers la bonne personne, par exemple)
S'il y a un pb avec un prestat, c'est lui qu'on ira voir.
S'il manque du personnel sur le projet et qu'il faut coder une routine pour demain, c'est lui qu'on ira voir.
Si un développeur souhaite prendre du congés, c'est lui qu'on ira voir.
Si le téléphone ne marche pas, c'est lui qu'on ira voir.
Si un développeur n'a pas le bon mot de passe pour se connecter à la BDD, c'est lui qu'on ira voir.
Si .....; c'est lui qu'on ira voir !
Bref, Il est là pour mener à bien son projet, qq soient les pb !
Et oui certains font même des plannings sans découpage fonctionnel, sans estimation des charges, sans définition des chemins critiques, sans estimation précise des risques, sans consulter son équipe qui a beaucoup plus d'années d'expérience dans le domaine...
Répondre avec citation
Partager