Discussion :

[chenel80]

Alors là, je ne vais pas être content.

1°) je n'ai jamais dit que chef de projet était une suite logique pour un dev, JE veux être CDP quand je me sentirais prêt et quand je préfèrerais faire de l'analyse fonctionnel et technique.

2°) on me le propose maintenant, je pose une question pour montrer que je ne suis pas motivé plus que ça. Pourquoi alors je pose cette question ? Parce que je veux être CDP plus tard, est-ce que le train passera une seconde fois ? je l'ignore, vous êtes plus expérimenté que moi j'espérais des conseils.

3°) Je ne dénigre personne qui souhaite être expert technique et faire du "code" toute sa vie, au contraire, j'aime la programmation et je considère un expert technique sur la même marche qu'un CDP, un bon CDP a besoin de bon(s) expert(s) dans son équipe et doit travailler en concertation avec.

Je n'ai jamais pris un ton autain, je me pose des questions, je trouve ce forum intéressant du fait des expériences et des parcours différents de ce qui y participent.

Je me trouve trop jeune pour être CDP (même si c'est ce que je souhaite à terme) et je pense manquer de crédibilité auprès de développeurs experts pour faire le contre-pouvoir dans des décisions technique par rapport au coût.

Si vous relisez tout, vous verrez que quand je dis être "ravi" et "vouloir partager une bonne nouvelle" car pour moi c'est un aboutissement de ce que je souhaite faire, mais je ne dis pas qu'il faut qu'on soit tous CDP sinon on produit quoi ? et comment ? Je me trouve juste encore limite pour accepter le poste, c'est tout... Désolé pour le pavé mais j'ai l'impression que vous ne lisez qu'en travers ou que vous vous arrêtez de lire le texte parce qu'une chose ne vous a pas plu. Enfin, c'est une impression.

J'ai répondu de cette façon car pour toi il faut être excellent techniquement pour être chef de projet, alors que c'est faux, il faut juste avoir des connaissances un peu globales et savoir de quoi on parle, on peut devenir très tôt chef de projet, et les qualités pour être chef de projet et développeur n'ont rien à voir.
Par exemple, un chef de projet très bon techniquement aura tendance à moins déléguer les tâches et mettra son nez un peu partout en faisant le boulot des développeurs au lieu de se concentrer sur ses tâches à lui, ce qui en fera un très mauvais chef de projet par exemple, donc attention...

De plus, tu dis que tu aimes le développement, alors que tu cherches à être chef de projet, donc en lisant à travers les lignes tu considères effectivement que devenir chef de projet est la suite logique du développeur.

Moi j'ai envi de te dire que tu n'as pas l'air de bien savoir ce que tu veux, les deux métiers n'ont rien à voir, et si tu veux être chef de projet, 5 ans c'est déjà largement assez pour te lancer.

Il y a même beaucoup de JD qui deviennent directement chef de projet, à la limite pourquoi pas s'ils ont eu des stages assez variés. L'idéal c'est 2 ans d'xp pro je pense pour connaitre à peu près tout ce qui existe, toutefois sans trop connaitre les détails, pas besoin de chercher à être bon techniquement, ca ne sert à rien.

[Makichan]

Je voudrais partager avec vous une bonne nouvelle. Je suis promu CDP dès la fin de ma mission (c-à-d au 31 janvier 2012), je n'aurais que 5 ans d'XP, je trouve ça peu et je pensais encore faire mes gammes pdt 2 ou 3 ans, dois-je accepter ou au contraire refuser car je ne me sens pas prêt et j'aime bcp (encore) programmer. Vous allez certainement me rire au nez en disant que j'hésite à accepter mais je ne me sens vraiment pas prêt, je connais bcp de dev dans ma société meilleur que moi techniquement même si c'est vrai que je comprend très facilement le besoin du clien et les fonctionnalité voulu.

Si tu deviens CDP alors oublie le code, tu n'en feras pas ou très peu sur des petits projets mais pas sur des gros.

Si tu acceptes alors que tu n'es pas prêt, demandes à être coaché ou formé car tu dois apprendre à dire NON comme on l'a cité plus haut et avoir une méthode ITIL ou PMP serait la bienvenue.

Et puis après c'est sur le terrain que tu apprends et que tu acquiers de l'expérience et tu me sembles bien parti.

[billclinton]

pourquoi toujours idée reçue qu'un chef de projet ne fait pratiquement plus de code ?
il peut très bien toucher aussi au code, c'est d'ailleurs ce qu'il vaut mieux faire car il est quand même responsable de la qualité du développement donc déjà il doit regarder comment l'appli est branlée à l'intérieur :
- si les développeurs n'ont pas codé le plus vite possible et n'importe comment
--> très important pour les montées en charge
- si les conventions de développement et règles de nommage ont été respectées
il doit savoir expliquer comment est développée l'appli (par exemple si l'équipe de développement est changée entièrement alors que lui reste en place)
en règle générale, un développeur devrait pouvoir compter techniquement sur son cdp
c'est comme les personnes qui veulent à tout prix faire du fonctionnel en n'y connaissant pas grand chose à la techno du projet
-> ça donne assez souvent des résultats catastrophiques en terme de délais

[HerQuLe]

pourquoi toujours idée reçue qu'un chef de projet ne fait pratiquement plus de code ?
il peut très bien toucher aussi au code, c'est d'ailleurs ce qu'il vaut mieux faire car il est quand même responsable de la qualité du développement donc déjà il doit regarder comment l'appli est branlée à l'intérieur :
- si les développeurs n'ont pas codé le plus vite possible et n'importe comment
--> très important pour les montées en charge
- si les conventions de développement et règles de nommage ont été respectées
il doit savoir expliquer comment est développée l'appli (par exemple si l'équipe de développement est changée entièrement alors que lui reste en place)
en règle générale, un développeur devrait pouvoir compter techniquement sur son cdp
c'est comme les personnes qui veulent à tout prix faire du fonctionnel en n'y connaissant pas grand chose à la techno du projet
-> ça donne assez souvent des résultats catastrophiques en terme de délais

J'y connais pas grand chose mais il me semble avoir lu a plusieurs reprises que ceci n'est vraiment pas recommandé au contraire...

Un chef de projet doit savoir faire confiance a son équipe, savoir déléguer, ne pas vouloir tout contrôler et faire les choix techniques pour ses devs... c'est pas son rôle...
D'ailleurs il y a de tres bons chefs de projet qui ne sont pas du tout techniques.



Après bien sur, sur des petits projets, y a parfois des devs/archis qui ont aussi le role de CDP. Mais sur des gros projets j'ai encore jamais vu le CDP venir coder avec les développeurs...

[gueulederack]

bien bien bien, merci pour ces conseils, je les retiens . Je ne peux qu'approuver vos posts

[billclinton]

J'y connais pas grand chose mais il me semble avoir lu a plusieurs reprises que ceci n'est vraiment pas recommandé au contraire...

Un chef de projet doit savoir faire confiance a son équipe, savoir déléguer, ne pas vouloir tout contrôler et faire les choix techniques pour ses devs... c'est pas son rôle...
D'ailleurs il y a de tres bons chefs de projet qui ne sont pas du tout techniques.

Après bien sur, sur des petits projets, y a parfois des devs/archis qui ont aussi le role de CDP. Mais sur des gros projets j'ai encore jamais vu le CDP venir coder avec les développeurs...

j'ai jamais dis qu'il devait tout vérifier en permanence, un douanier ne vérifie pas tout les cartons mais en prends quelques un au hasard, évidemment si tu as un développeur sur un projet depuis 1mois et qu'il a jamais posé soucis dans les vérifications tu peux te passer de vérifier son job quand même

sur des gros projets j'ai déjà vu des cdp venir coder avec les dev, bien sûr ce n'est pas à 100% car il y a aussi le rôle de relation avec le client, mais pour des coups de bourre c'est pas mal de savoir que l'on peut aussi compter dessus

[edit]
en même temps sur de gros projets, il y a souvent plusieurs chefs de projet :
- technique
- fonctionnel
- et celui qui organise l'équipe

[Robin56]

j'ai jamais dis qu'il devait tout vérifier en permanence, un douanier ne vérifie pas tout les cartons mais en prends quelqu'un au hasard, évidemment si tu as un développeur sur un projet depuis 1mois et qu'il a jamais posé soucis dans les vérifications tu peux te passer de vérifier son job quand même

sur des gros projets j'ai déjà vu des cdp venir coder avec les dev, bien sûr ce n'est pas à 100% car il y a aussi le rôle de relation avec le client, mais pour des coups de bourre c'est pas mal de savoir que l'on peut aussi compter dessus

Je plussoie HerQuLe. Ce n'est pas son rôle. Justement sur de gros projets, il devient encore moins possible d'avoir l'occasion de toucher au code. Il doit déléguer cette phase à un architecte du projet ou référent technique. C'est à lui d'assurer cette casquette.

[Nachalnikov]

Je rejoins Billclinton. J'ai travaillé comme CDP avec des équipes de 5,7 et 15 personnes. A chaque fois, j'ai contrôlé la qualité de code et le respect des standards... et à chaque fois, j'ai bien fait.
Ca m'a permis de partir d'erreurs concrètes pour expliquer aux équipes quelles sont les règles de l'art. Très honnêtement, je pense que les personnes à qui j'ai apporté ces connaissances m'en sont reconnaissantes. Trois d'entre eux sont d'ailleurs devenus des CDP ou des leaders techniques et je sais qu'ils essaient aussi de faire preuve de pédagogie avec leurs équipes.

Un autre aspect, c'est que ça te permet d'être plus crédible auprès des clients quand tu discutes chiffrages. T'as pas toujours des experts en support pour te seconder...

Enfin, un CDP doit être reconnu comme "leader" par ses équipes... Sinon, ça va pas bien se passer... on a jamais une équipe homogène de devs super motivés
Et etre leader... Soit c'est naturel (le chef charismatique), soit c'est parce qu'il est plus compétent (le guide éclairé) soit c'est parce qu'il fouette son monde (le dictateur). Tout le monde n'a pas la chance d'être charismatique et je déconseille fortement la méthode "dictateur" qui mène inévitablement au putsch.
La seconde méthode me semble donc la plus adaptée... et pour cela, il faut être techniquement bon.

Bon allez, j'arrête de me répandre sur ce forum

[Golgotha]

Nachalnikov, pouce en l'air

Je pense que c'est bien résumé, j'ajouterais qu'il faut de la confiance et de la transparence entre l'équipe et son chef de projet, discuter tout les matins quelques minutes pour échanger les points de blocage par exemple, et une chose assez important à mes yeux, c'est que le chef de projet ce batte pour ces développeurs, si quelques chose ne va pas (ne pas laisser tombé son équipe si c'est la merde ^^).

[billclinton]

Nachalnikov, pouce en l'air

bah et moi ?
je crois bien que je vais pleurer

[Nasky]

J'ai pas lu vos discussions qui partent dans tous les sens pour rien mais par rapport à celui qui a posté le message d'origine, dis-toi que dans la vie TOUT est une question de destin, rien n'arrive au hasard. Chaque malheur a une signification... Dans ton cas, ça t'a permis de trouver mieux ailleurs, chose que tu n'aurais peut-être pas eu l'occasion d'avoir si t'étais resté dans la boite.

Parfois ça prend du temps, parfois c'est très rapide... Un pote s'est fait viré un jour de son poste d'analyste financier, il sort de banque, conduit, fait un accident et là rencontre un mec qui l'embauche pour un boulot de rêve qui l'a rendu millionnaire en 2 ans. C'est le destin, c'est comme ça.

Mais pour ton entreprise, si tu veux leur faire payer, c'est pas sur Developpez qu'il faut poster mais sur Twitter. C'est la référence pour descendre une entreprise en cas d'abus.

[phili_b]

Ce n'est pas le destin ce sont le hasard, les opportunités, les choix et les rencontres. Les significations on les trouve après coup. Mais bon ça devient philosophique.