Cursus [ Chef de Projet ]

[naholyr]

Ben c'est pas vraiment comme ça en entreprise non, après il faut faire attention aux termes :
- le chargé de projet s'occupe de l'organisation du projet, en général il s'agit du développeur le plus capé dans le projet (à comparer avec le capitaine d'une équipe de foot).
- le chef de projet dirige tout ce petit monde, est en contact avec le client et est responsable dans le sens où s'il y a un retard ou un dépassement de budget c'est sa faute. Ça peut par exemple être une cause de licenciement pour échec de mission (à comparer avec l'entraineur d'un club).
- le directeur de projet a en général un rôle commercial, il s'agit souvent d'un «super chef de projet» et parfois du directeur commercial (à comparer avec le manager ou le président d'un club).

Donner des responsabilités aux différents acteurs du projet c'est important pour d'une part se décharger d'une partie des responsabilités, et d'autre part pour soulager un peu ses propres épaules. C'est pour ça que chacun ayant des responsabilités dans un projet, il faut bien le signifier officiellement, et donc donner un poste nominatif dans le cadre du projet.

Pour les titres pompeux, non ça ne se passe pas comme ça partout : moi j'ai 5 développeurs dans mon équipe, dans le lot je nomme un chargé du projet, les autres sont des analystes-programmeurs point-barre.


Un chef de projet qui ne va pas animer seul une réunion avec l'équipe projet client, c'est typiquement en fait un chargé de projet qui gonfle un peu son titre . Après il arrive aussi souvent qu'on gonfle un peu le titre de la personne à qui on confie des responsabilités pour la motiver : moi j'ai bien été propulsé directeur de projet sur l'un des projets en cours, alors que je sais bien que je ne suis que chef de projet dans les faits, mais le message implicite derrière c'est «ce projet est important et doit faire partie de tes priorités». Ou sur des projets sans piège ça peut aussi être l'occasion de tester les capacités de la personne à évoluer dans son poste, et donc si on saisit bien ce genre d'occasion c'est typiquement là qu'on arrive à grimper des échelons.




Pourquoi avoir été développeur pour savoir chiffrer un projet ? Comment veux-tu être capable (sans avoir géré 100 projets) de chiffrer correctement la réalisation d'un module avec les spécifications détaillées : il faut savoir détecter les pièges, savoir ce qui est facile et ce qui est difficile, savoir quel langage sera le plus adapté (et donc qui composera l'équipe de développement), savoir combien de temps prendra le développement de telle ou telle partie... Si on n'a jamais été développeur (et sur une vraie durée, pas 6 mois et 2 projets), on est selon moi incapable de faire ça correctement. Je le vois bien au bureau il y a 2 autres chefs de projet et l'un a un parcours essentiellement technique et ne foire jamais ses chiffrages, alors que l'autre nous fait toujours des projets merdiques à cause d'un chiffrage trop juste parce qu'il n'a tout simplement jamais pissé une ligne de code et qu'il ne sait donc pas que tel ou tel point va être critique et prendre 10 jours au lieu d'1.