Peut-on postuler en tant que chef de projet sans avoir une grande experience en developpement?
Ou faut-il d'abord être un dev confirmé pour pouvoir occuper ce poste?
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
Peut-on être chef de projet sans etre un crack en dev
Peut-on postuler en tant que chef de projet sans avoir une grande experience en developpement?
Ou faut-il d'abord être un dev confirmé pour pouvoir occuper ce poste?
Oui, c'est possible de devenir un chef de projet sans être un crack du developpement.
Mais un employeur va se demander pourquoi il te confierait un poste de management de projet si tu n'as pas au minimum une expérience qui plaide en ta faveur.
Après, est-ce que tu as les compétences pour être chef de projet? Es-tu capable d'encadrer et de diriger des personnes? Es-tu capable de gagner leur respect? Qu'est ce que tu apportes à l'équipe? Es-tu capable de négocier avec des équipes, des managers, des clients? Sais-tu structurer une approche de travail et imprimer un rythme d'exécution à une équipe? Te sens tu capable d'endosser la responsabilité d'un projet qui se casse la figure?
Oui
C'est bien la toute la question.Envoyé par Caro999
Soit tu veux etre chef de projet pour de bonnes raisons, c'est a dire parce que tu es competent a ce poste, soit c'est pour de mauvaises raisons, et dans ce cas je plains ton equipe.
Sinon, va en SSII, tu verras pleins de mauvais chefs de projets (c'est a dire qui ne savent pas faire ce travail, souvent par manque de formation).
J'ai vu des programmeurs nullards devenir d'excellents chefs de projets. Et l'inverse. Et les autres cas aussi.
Ca aide d'avoir pratiqué - parcequ'on connait les contraintes et les possibilités - mais ça n'est pas nécéssaire, ni suffisant. Ca n'est simplement pas le même métier.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Salut,
j'abonde dans ce qui a pu être dit.
Attention aussi, le fait d'être excellent techniquement ne doit pas t'imposer en tant que CdP de mettre la main à la pâte.
Un manager préférera (espérons le) avoir la personne la plus efficace à un poste plutôt que de faire monter systématiquement en hiérarchie les meilleurs pour driver les autres.
Les postes de dev et de CdP sont 2 choses clairement différentes sur les tenants et les aboutissants du poste.
A noter que le poste de CdP a une dimension "politique" que n'a pas nécessairement celui de dev
Cycle de vie d'un bon programme :
1/ ça fonctionne 2/ ça s'optimise 3/ ça se refactorise
Pas de question technique par MP, je ne réponds pas
Mes ouvrages :
Apprendre à programmer avec Access 2016, Access 2019 et 2021
Apprendre à programmer avec VBA Excel
Prise en main de Dynamics 365 Business Central
Pensez à consulter la FAQ Excel et la FAQ Access
Derniers tutos
Excel et les paramètres régionaux
Les fichiers Excel binaires : xlsb,
Autres tutos
chef de projet POUR QUEL POSTE
chef de projet ,ca veut dire tout et n'importe quoi. On peut etre chef de projet BI, java, AMOA, technique, fonctionnel, SAP.... y autant de CP que de techno et métiers existant au monde
Je suppose que c'est chef de projet technique pour une techno particuliere? Si oui, je répondrais
1) les qualités principales pour être CP n'ont absolument rien à voir avec la programmation
2) si c'est du chef de projet en gestion d'équipe, c'est ton équipe qui va développer, mieux vaut savoir ce qu'elle fait, donc la connaissance du langage est obligatoire mais pas d'être "un crack"
3) si c'est pas de la gestion d'équipe parceque le projet est externalisé, faudra savoir décoder un peu les dev, regarder le code, mais surtout tester, valider les délais, arbitrer les décisions, communiquer. Encore moins besoin de connaitre le code que pour le 2)
4) dans tous les cas rien ne t'empeche de postuler, c'est à l'employeur de décider s'il pense que ton CV correspond ou non au poste ...
de toutes facon les compétences de CP s'acquierent avec l'expérience, comme tout. De préférence, en ayant eu comme modele un (bon) chef de projet et en ayant appris quelques méthodes avant... Sinon, effectivement, ton équipe va prendre cher
"Fais le c'est tout, je veux pas savoir comment ou ce qu'il y a comme probleme, mais fais le pour demain c'est tout!"
Un chef de projet
Dernière modification par Invité ; 04/07/2013 à 19h14.
Y a bien qu'en informatique où l'on peut se contenter d'un CDP qui ne connaît pas son domaine d'activité et après on s'étonne que les projets se cassent la figure. Beau foutage dde gueule.
Enfin quand ion voit certains commerciaux de SSII qui ne font pas mieux, l faut croire que cela fait école.
@+
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Le problème c'est qu'en France si tu veux voir ton salaire évoluer, il faut devenir CDP, sinon t'es qu'un technicien, la culture nationale donne historiquement une connotation péjorative à ce terme.
Il y a des pays où être un bon technicien peut aussi signifier un bon salaire et en réussissent pas moins bien que la France.
Bilan : même les mauvais peuvent grimper, la promotion sociale ne se fait plus au mérite depuis belle lurette.
M E N S . A G I T A T . M O L E M
Debian 64bit, Lazarus + FPC -> n'oubliez pas de consulter les FAQ Delphi et Pascal ainsi que les cours et tutoriels Delphi et Pascal
"La théorie, c'est quand on sait tout, mais que rien ne marche. La pratique, c'est quand tout marche, mais qu'on ne sait pas pourquoi. En informatique, la théorie et la pratique sont réunies: rien ne marche et on ne sait pas pourquoi!".
Mais Emmanuel Kant disait aussi : "La théorie sans la pratique est inutile, la pratique sans la théorie est aveugle."
Je pense qu'il y a deux choses assez distinctes, les connaissances techniques et les connaissances fonctionnelles.
A mon avis le CDP doit être un crack au niveau des connaissances fonctionnelles, mais pas forcément au niveau technique!
Il n'est pas forcément un crack au niveau fonctionnel ... Par contre il doit être bon en communication, politique et gestion de planning/personnes.
Je suis d'Accord avec ton choix, si on définit un bon chef de projet comme quelqu'un qui fera une bonne carrière.
Aprés, un chef d projet efficace dans son boulot, vaut mieux qu'il soit bon au niveau fonctionnel. Qualité techniques, ca peut pas faire de mal, mais j'en suis à penser (pour un poste de CDP "générique") qu'il vaut mieux maitriser le fonctionnel - au sens large - que la technique.
Je suis d'accord. Et puis cela peut aussi lui éviter de passer pour une bille en comité de projet ou pilotage.Je suis d'Accord avec ton choix, si on définit un bon chef de projet comme quelqu'un qui fera une bonne carrière.
Aprés, un chef d projet efficace dans son boulot, vaut mieux qu'il soit bon au niveau fonctionnel. Qualité techniques, ca peut pas faire de mal, mais j'en suis à penser (pour un poste de CDP "générique") qu'il vaut mieux maitriser le fonctionnel - au sens large - que la technique.
oui, parceque encore une fois un "chef de projet" c'est très large en titre
Un CP technique en aura rien (ou presque) à faire du fonctionnel.
Bien sur, il est censé connaitre de quoi on parle, il apprendra forcément l'environnement fonctionnel general, mais ca vient avec le projet, ca n'est pas un "pré requis", sauf cas particulier pour des métiers ou on demande parfois même aux technique une spécificité métier
Ca dépend toujours des projets, des structures, mais dans un environnement de gros projet on peut avoir un CP technique, un CP fonctionnel, les deux se parlant directement ou non (potentielle via un AMOE / AMOA)...
C'est vaste, chaque projet et surtout chaque entreprise est structurée différemment. Seules les contraintes du type cite Darkzinus sont communes à toutes je pense (avec organisation, management, etc etc)
Les chefs de projet sont des programmeurs ratés
T'as toutes tes chances.
Il y a surtout des dev qui ne savent pas manager qui deviennent CP par la logique de l'experience passé en dev (une sorte de promotion)
Non, ce n'est vrai que pour les chefs de projet qui ont ete promu pour de mauvaise raisons (principe de Peter, principe de Dilbert).Les chefs de projet sont des programmeurs ratés
Il existe aussi de vrais bons chefs de projets, qui sont competents a leur poste, qui savent mener un projet et gerer une equipe. Il se trouve que tous ceux que je connais sont aussi tres bons en developpement, meme s'ils ne developpent plus depuis plusieurs annees.
C'est quand même fréquent, hélas. Le pire, c'est que parfois ça marche : le mauvais développeur devient un bon chef de projet.
+1
Moi pas. J'ai connu au moins 2 CdP de bon niveau qui n'avaient JAMAIS développé, et une qui était une quiche en développement(j'ai eu à maintenir son code, ouille ouille ouille). La troisième avait l'avantage de comprendre nos "gros mots", mais tous 3 étaient capables de nous motiver, d'identifier quand nous faisions fausse route, de nous faire confiance pour les détails, de nous cornaquer sur les points importants, d'adapter le planning en fonction des contraintes et de l'avancement, de jongler avec les caprices de la MOA, etc.....tout ce qui fait d'un chef un bon chef.
Encore une fois, la compétence technique est un plus - ça permet de comprendre pourquoi, en MVS, on va décharger les tables SQL dans des fichiers plats avant de faire tourner des moulinettes, plutôt que de faire de belles requêtes, par exemple. Un bon chef qui ne connait pas, il faudra lui expliquer(en gros, c'est une question de performances). Et ça peut, parfoir, ralentir certaines décisions.
Mais il comprendra, et on ira dans la bonne direction. Un mauvais chef, au contraire, va piquer sa crise, accuser tout le monde de se foutre de sa gueule et d'être idiots, imposer une solution "evidente et moderne"(faire des requêtes SQL avec 15 jointures sur des tables gigantesques), et se retrouver avec un monstre qui tourne pendant deux siècles(je parle de MVS, sur d'autres environnements, je m'abstiendrais de donner des leçons).
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Tout à fait d'accord avec le message ci-dessus sauf:
>> Un bon chef qui ne connait pas, il faudra lui expliquer(en gros, c'est une question de performances). Et ça peut, parfoir, ralentir certaines décisions.
Une équipe de projet, ce sont des experts qui bossent ensemble, chacun apportant son expertise et chacun étant capable de communiquer, voire de vulgariser un peu son savoir pour se mettre à la portée de l'autre personne qui bosse sur le projet et qui possède une expertise sur un autre sujet.
Est-ce que vous voudriez que l'expert fonctionnel en Collateral Management lève les yeux au ciel chaque fois que vous lui demandez une précision parce que il faut vous expliquer? Ou l'expert en calcul scientifique? Ou celui qui gère les AAA du réseau?
Je suis désolée mais oui, il faudra expliquer mais c'est le B.A.BA du travail en équipe. Et puis il faudra probablement vulgariser encore plus si vous êtes convoqué à une réunion de comité de pilotage pour expliquer au PDG du client en quoi le problème consiste.
Personne ne peut et ne doit s'attendre à ce que le chef de projet connaisse toutes les spécialités et composantes du projet. Sinon on n'arriverait pas à staffer les projets.
C'est vous qui savez, alors vous communiquez, vous expliquez, vous contribuez. C'est ce qui fait de vous autre chose que de simples pisseurs de code. C'est une bonne nouvelle, non?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager