Discussion :

[Enhide]

Je suis d'accord avec ce que tu dis, mais n'avez vous jamais vu quelqu'un arriver chef de projet web sans une grande expérience de la programmation mais parce qu'il avait des compétences différentes comme un master communication ou un diplôme en management ?

[Matthieu Brucher]

Il va faire comment pour mesurer le temps de développement nécessaire pour un projet dans une certaine technologie ?

[Enhide]

Donc, vous êtes en train de me dire que ce n'est pas possible...

Moi ce qui m'intéresse, c'est la communication. Mais j'adore aussi l'informatique et le net donc je pensais m'orienter vers le communication et revenir vers le secteur du web, faire du web marketing en quelques sortes...

Je réfléchis parce que j'ai trouvé les études et le cursus qui me plaisent mais je ne vois pas vers quelles fonctions je me dirige...

C'est assez flippant de ne pas savoir vers quoi on se dirige et se qu'on va devenir...

[Matthieu Brucher]

Si c'est la communication qui t'intéresse, le poste de chef de projet n'est clairement pas pour toi Tu peux vendre, faire du marketing pour des projets web, mais pas plus (AMHA).

[Enhide]

Donc il me faut abandonner cette idée ?

J'avais juste envie de me tourner vers la com sans tourner le dos à la prog et à l'aspect technique du web...

Sinon, connaitriez-vous de bons forums sur la com et le web marketing ? celui de développez n'est pas très actif...

[gregory.broissard]

où alors se tourner vers les roles d'AMOA...

[Enhide]

Si j'ai bien compris la définition de wikipédia en ce qui concerne AMOA, il s'agit en quelque sorte d'un assistant chef de projet...


Pourriez-vous détailler ?

[gregory.broissard]

Sur des gros projets et généralement dans les grosses structures, on trouve parfois 2 personnes pour piloter un projet. Le CP informatique qui va piloter la partie technique et l'AMOA qui va piloter la partie fonctionnelle.

L'AMOA va s'occuper de recueillir les besoins utilisateurs, de les transcrire en spécifications fonctionnelles détaillées, d'accompagner la recette utilisateur, etc...

[Enhide]

Ça a l'air intéressant et déjà plus proche de se que je souhaite faire. Merci pour l'info mais quelle formation peut mener à ce genre de poste ?

[gregory.broissard]

Le métier d'AMOA est clairement orienté communication, ecoute, analyse, etc... et donc orienté coté fonctionnel.

On va te demander de connaitre le domaine fonctionnel sur lequel tu travailles, si c'est la banque, on te demandera de bien connaitre les marchés financiers ou ce genre de choses, si tu travailles sur des applications de vente automobile, on te demandera de bien connaitre les aspects fonctionnels de vente véhicule, logistique,facturation, etc...

Pour la formation, une formation BAC+5 en info ou en commerce (pour les AMOA liées à des applis de commerce)... Bref, les possibilités sont assez larges.

[iubito]

J'ai eu comme manager un bon codeur (disons qu'il avait parfois de bonnes idées là où je sèchais, les trucs que j'arrivais pas à faire il insistait, insistait, insistait, puis au bout d'un moment le faisait ;D )... mais niveau management c'était pas top.

- Il travaillait chez lui quand il voulait (les stats CVS ont révélé : le jour, la nuit, tard le soir, les week-ends) donc soit il était plus lent que nous, soit il était à la même vitesse mais s'imaginait qu'en une journée de 8h on allait faire ce qu'il faisait en 14h... surtout que la journée on faisait en même temps l'assistance utilisateurs !
- Il annonçait aux chefs des délais impossibles.
- sur le projet, on a fait le toit, les murs, les fenêtres, puis les fondations en dernier... ça s'est cassé la gueule.
- si tu l'appelles pour un problème, soit c'est 1) débrouille-toi, 2) vas-y fais voir ton code, hop hop hop je modifie super vite sans trop réfléchir, "bon j'te laisse là ça va tu vas pouvoir finir ?" et tu retrouves dans une pire merde qu'avant. Il pouvait pas comprendre qu'on réfléchisse pendant 1/2h comment tourner tout l'algo, comment éclater quelles fonctions...

Mais un chef de projet qui ne la connaît pas suffisamment n'est pas en mesure d'apprécier le niveau de difficulté du travail demandé à ses grouillots, ni d'en estimer valablement les charges. Donc, en général, comme il pense qu'en informatique tout est facile, il a tendance à sous-estimer, mais aussi bien de temps en temps il peut se faire avoir à la hausse sur des charges sans même pouvoir s'en rendre compte...

Donc il ne suffit pas de connaître le code, c'est sûr ça aide, mais il s'agit aussi qu'il ne tue pas le travail en faisant des horaires de fou et en croyant que ses subordonnés vont faire la même quantité de travail dans le même délai.


N'empêche que j'ai bien aimé le jour où il a sorti des stats du CVS, il s'attendait peut-être à avoir écrit le plus de lignes ? J'l'avais dépassé
Bizarrement il a arrêté de ponde les stats CVS, pensant peut-être que nous juger sur le nombre de lignes, de fichiers créés n'était pas une bonne idée (ça c'est sûr !)

[Expatri]

Je me suis bien amusé à lire toutes vos réponses...

Et finalement je me rends compte que je suis pratiquement d'accord avec tout le monde...

En fait pour répondre à la question, faut connaitre déjà :

La taille de l'entreprise (SSII), sa façon de fonctionner en interne.
La taille du projet.
L'expérience du CP et son cursus et formation.

Bref ayant et étant régulièrement confronté à cette question dans mon boulot bien souvent...

Je me retrouve des fois à coder deux trois trucs car le temps d'expliquer à un developpeur je vais aussi vite à le faire bref on est à la bourre...

Un livrable qui passe pas, cause une petite faille ou un truc qui plait pas au client, une deux corrections ou modifications d'urgence et ouf c'est autant de gagné sur le projet et sur la facturation...

R&D un CP qui n'a pas de projet en cours, son coté technique lui permet de faire de la R&D sur quelques technologies, les tester, les valider, ca m'a souvent bien servit dans des projets à venir quand il faut trouver des solutions.

Connaitre le produit et le coté technique en developpement permet aussi de mieux appréhender le chiffrage, les difficultés et savoir "plus ou moins" à l'avance où vont se situer certains problèmes...

Et comme toujours quand tu gères plusieurs developpeurs, avoir une bonne approche technique sur le code ca aide pour savoir parmi eux celui qui va aller vite, celui qui va lentement, celui qui fait un code propre, celui qui fait un code sale. Celui qui te raconte n'importe quoi et celui qui en fait trop par rapport à ce que tu as demandé...

Bref les exemples ne manquent pas pour te répondre qu'a mon avis un CP qui a en plus de son boulot cette compétence c'est quand même un plus mais tout dépend comme dit plus haut de la culture de l'entreprise et de son organisation et la culture et l'expérience du CP...

Dur dur de rester qu'un AMOA finalement dans bien des cas...

[blugnier]

Bonjour,

Je suis responsable des études dans une école de management de projet (www.groupe4.fr) et ancien chef de projet spécialisé dans le génie logiciel.

Le métier de chef de projet est souvent méconnu et son périmètre est tout le temps remis en cause.

Dans notre école, nous enseignons la gestion de projet selon la norme PMI. Selon cette norme, le chef de projet doit non seulement avoir l'oeil sur tout mais en plus produire beaucoup de documentation "projet" depuis la charte de projet jusqu'au plan qualité en passant par l'énoncé préliminaire du contenu.
Ces documents "projets" s'ajoutent aux documents "produits" (spécifications fonctionnelles et techniques, chartes de codage, ...).

De ce fait, le CDP n'a pas le temps matériel de faire du développement ou tout autre tâche technique.

C'est vrai que sur les tout petits projets, le contenu des documents projets et produits est plus léger. Mais même là, je reste méfiant sur la possibilité qu'à le CDP à dégager du temps.

De plus, la descente dans la technique fausse la vision globale d'un projet. Sans parler de la perte des compétences techniques avec le temps qui passe et qui remet en cause l'intérêt d'une telle démarche.

Benoist LUGNIER

[el_slapper]

Bonjour,

(.../...)(.../...)
De ce fait, le CDP n'a pas le temps matériel de faire du développement ou tout autre tâche technique.

C'est vrai que sur les tout petits projets, le contenu des documents projets et produits est plus léger. Mais même là, je reste méfiant sur la possibilité qu'à le CDP à dégager du temps.

De plus, la descente dans la technique fausse la vision globale d'un projet. Sans parler de la perte des compétences techniques avec le temps qui passe et qui remet en cause l'intérêt d'une telle démarche.

Benoist LUGNIER

Je suis d'accord avec la première partie. Le rôle primaire n'est pas de faire la technique. Si les programmeurs se suffisent à eux mêmes, alors avoir tout son temps pour gérer le projet et ses à-côtés, c'est le panard. Et si vôtre démarche était plus appliquée, erprendre un projet en cours ne tournerait pas à l'impossible ou au "on efface tout et on recommence".

Mais les programmeurs(moi, par exemple), ne sont pas eux-mêmes parfaits. Si il est POSSIBLE de gérer un projet sans rien comprendre à la technique, il est souvent préférable de surveiller tout ça quand même. Et, comme dit ci- dessus, en situation "chaude", il peut être plus efficace de mener soi-même une intervention limitée. C'est le fait que ça devienne une habitude qui est mauvais.

[Enhide]

Bien-sûr, c'est plus pratique que le CP maîtrise la technique, ou au moins les bases et comprenne comment cela fonction,mais cela ne doit pas forcément passer par des connaissance très pointues en programmation, mais comme dans tout les métiers, le CP doit s'intéresser à l'activité de la boite. S'il s'agit d'un éditeur de logiciel, même sans formation initiale en programmation, le CP finira par comprendre comment cela fonctionne pour être le plus efficace.

Cela dépend de l'implication du CP dans le fonctionnement de l'entreprise et de son activité.

[bloody22]

Pour moi la bonne réponse est bien celle de blugnier.
Faisons attention j'ai peur que parce que nous baignons dans du code, que l'on soit en train de chercher à légitimer ça pour dire que oui c'est la voie normale pour devenir CP.
Eh ben NON !
Effectivement il y a de tout, toutes sorte de voies pour y arriver, mais pour moi la meilleure est l'expérience de gestion de projet (passer par un poste d'assistant CP???) et le côté humain.
Le bon chef de projet est celui qui aura eu des expériences en la matière et qui saura quelle attitude avoir en cas de soucis et qui sait écouter, avec un bon côté humain supérieur à la norme.
on en a pas beaucoup parlé mais je pense que c'est le plus important.
quand on dit, le CP a su dire qu'il n'était pas compétent techniquement ben bravo, s'il gère le projet en terme de management il sera un bon CP.

Mais les programmeurs(moi, par exemple), ne sont pas eux-mêmes parfaits. Si il est POSSIBLE de gérer un projet sans rien comprendre à la technique, il est souvent préférable de surveiller tout ça quand même. Et, comme dit ci- dessus, en situation "chaude", il peut être plus efficace de mener soi-même une intervention limitée. C'est le fait que ça devienne une habitude qui est mauvais.

C'est vrai on n'est pas parfais, mais on doit pas le dire !
Notre but est de l'obtenir donc notre imperfection, on ne doit pas la prendre comme fatalité!
Et le chef de projet c'est pas le super codeur qui sait tout faire, je pense que si tu as toujours quelqu'un pour te corriger tu n'avances pas et franchement je pense pas que ce soit le rôle d'un CP.
D'ailleurs je sais pas d'où vient cette idée de progression de carrière genre Developpeur -> CP beurk moi ça m'a jamais interessé

Mais pour répondre à la question du titre je dirais NON

[Enhide]

Super, enfin quelqu'un qui me rassure.

Je veux devenir chef de projet, mais sans suivre la voie du super programmeur parce que même si je programme, je sens bien que je ne suis pas assez bon pour cela.

D'ailleurs je sais pas d'où vient cette idée de progression de carrière genre Developpeur -> CP beurk moi ça m'a jamais interessé

Je suis d'accord, je ne pense pas qu'il faille prendre le Chef de projet comme un supérieur hiérarchique, mais simplement comme une fonction équivalente aux très bon codeurs, qui sont indispensable pour mener un projet à bien.

[Vespasien]

quand on dit, le CP a su dire qu'il n'était pas compétent techniquement ben bravo, s'il gère le projet en terme de management il sera un bon CP

Si le chef de projet ne connait rien en technologie web et les differences qu'il y a entre une appli lourde (contrainte, avantages), il ne sera pas bon. Il ne faut rêver! Un CP qui ne fait pas le distingo entre ce qui est exécuté coté client et coté serveur sera mauvais. Il imposera des directives absurdes: augmenter la rapidité de l'appli alors qu'il refuse d'utiliser les capacités de travail du client par exemple. Et d'autres, j'ai fais suffisement de réunion pour entendre des aneries.

Je veux devenir chef de projet, mais sans suivre la voie du super programmeur parce que même si je programme, je sens bien que je ne suis pas assez bon pour cela.

Tout à fait d'accord. Mais il doit avoir suffisement de bagage pour ne pas confondre de l'interprété et du compilé ainsi que tout ce qui en découle. Donc, il doit savoir programmer.

D'ailleurs je sais pas d'où vient cette idée de progression de carrière genre Developpeur -> CP beurk moi ça m'a jamais interessé

Parce que tu imagines qu'une personne de 25 ans sortie de l'école va directement diriger de vieux briscards de la boite?
Quand au fait d'être un bon manager, j'ai plus souvent vu des jeunes se faire manipuler par des vieux que l'inverse.

[el_slapper]

effectivement, ce débat se sépare en 2 sous-débats :

1)le CP soit-il savoir programmer?
2)le CP doit-il programmer dans le cadre des ses activités de CP

Pour le point 2, il semble y avoir un semi consensus entre "Jamais" et "pas plus que parfois". Ce qui est assez proche, en fait, la différence concerne la gestion d'urgences(le prog est pas là, il faut que ça tourne ce soir, on fait quoi? Il peut être judicieux de dire "merde" histoire de faire comprendre au demandeur qu'il exige l'impossible, mais pas forcément).

le point 1 est, semble-t-il, la vraie ligne de faille. Et c'est un débat qui ne se limite pas à l'informatique. Le CP doit-il être capable de faire le travail de ses grouillots? De le comprendre? Ou même pas?

Mon point de vue est qu'il doit être capable de le faire - mais pas forcément au même rythme. J'ai eu une CP qui était très mauvaise en COBOL, mais qui savait quand même à quoi ça ressemblait - et comprenais le genre de difficultés auquelles je faisais face. Excellente CP.

Le strict minimum, à mon sens, est de connaître les subtilités techniques, et leurs contraintes. Pas forcément de les comprendre. Par exemple, savoir à quoi sert un EAI JAVA, dans quelles circonstance on peut l'utiliser, est-il pertinent de chercher à générer 100 millions de lignes XML en une nuit par cet outil.....(débat qui fait rage actuellement là ou je bosse). Savoir configurer l'EAI Java, ou même savoir ce que c'est exactement, pas besoin pour le CP. Avoir l'humilité d'accepter le verdict des sachants, obligatoire. (sauf quand on a pas de sachant sous la main, et là, il faut chercher à l'extérieur).

Le strict minimum, c'est d'accepter ses propres limites. Si il faut faire une allocation dynamique de fichiers(rare et compliqué en COBOL/MVS), inutile que le CP sache faire. Par contre, il doit comprendre le genre de contraintes que ça va poser au développeur et à l'exploitation. Et, si il n'a jamais fait ce genre de chose, encore une fois, avoir l'humilité de se remettre en question et d'accepter des réponses qui ne lui plaisent pas.

Le problème que j'ai vu avec les CP hors-technique que j'ai croisé, c'est qu'ils appliquent des schémas de pensée inadaptés, sans se remettre en question. Si appliquer de l'UML à COBOL est casse-gueule, mettre les specs UML à la poubelle pour un projet JAVA parcequ'on ne connais pas, c'est encore plus risqué. Ma CP(une autre) a systématiquement éradiqué l'UML de toutes les specs, rendant un ensemble brillant en patée pour chiens illisible. Parcequ'elle n'avait jamais pratiqué l'UML, et n'en voyait pas l'utilité.


En théorie, un CP peut diriger une équipe sans jamais avoir pratiqué les techniques utilisées. En pratique, il lui manque souvent l'humilité de remettre ses schémas de pensée en question. Et ça donne des choix techniques et/ou architecturaux non-optimisés(euphémisme).

[Mister Nono]

Je suis chef de projet, mais chez moi c'est plutot le contraire,
l'equipe n'est composee que de thesard et de post-doc qui code tres mal.
Alors toute les parties compliques, c'est pour bibi.

Tu peux alors prévoir des actions de formation, ou alors des réunions pour définir les normes de codage...

A+