Les bons chefs de projet ont-ils besoin d'une formation en programmation? [fermé]

Parfois, je ne peux pas le supporter lorsque les chefs de projet me demandent d'estimer le temps nécessaire pour effectuer diverses tâches. Une estimation est une supposition et les suppositions peuvent être fausses. Généralement, de mauvaises exigences et de la documentation entraîneront de mauvaises suppositions.

Je me demande donc souvent si les chefs de projet ont été à ma place pour essayer de deviner combien de temps les tâches X et Y prendront, et combien il est difficile de lui attribuer un numéro en fonction du peu d'informations connues et collectées auprès du client.

Ma question est alors: les bons chefs de projet doivent-ils avoir une formation en programmation?

Ou peut-être que la question devrait être: les bons chefs de projet doivent-ils avoir été un bon programmeur avant? Y a-t-il une corrélation?

La gestion de projets informatiques n'est certainement pas la même chose que la gestion d'autres types de projets. J'ai entendu parler d'un chef de projet sans expérience informatique. Il a fini par frustrer les programmeurs et les effrayer.

D'un autre côté, un programmeur qui devient chef de projet peut devenir un monstre de contrôle, pensant qu'il peut réparer les choses s'il ne parvient pas à faire en sorte que les programmeurs le fassent correctement (cela a été mon problème dans des situations similaires)

Un manager avec une solide formation technique comprend généralement mieux comment son équipe «pense». C'est toujours mieux d'avoir un manager qui vous comprend, non?

Non. Deux compétences complètement différentes. Un mauvais chef de projet n'est pas nécessairement quelqu'un qui ne comprend pas l'informatique, et vice versa.

Être raisonnable, rationnel, organisé, comprendre les objectifs du projet et les entreprises associées , et une bonne motivation ne dépendent pas du tout de la capacité de programmer.

Toutes choses étant égales par ailleurs, je préférerais un chef de projet avec une solide expérience technique à jour . Cependant, dans le monde réel, les programmeurs qui obtiennent leur diplôme en gestion de projet à temps plein sont plus susceptibles de permettre à leurs compétences de devenir obsolètes et obsolètes, ce qui n'est pas beaucoup mieux qu'ils n'ayant aucune formation technique.

J'ai travaillé avec de bons chefs de projet et certains terribles, et je peux honnêtement dire que j'ai vu peu de corrélation entre leur capacité de gestion et leur formation technique. Le facteur le plus important n'est pas le contexte technique, mais l'expérience acquise dans la gestion de projets logiciels . Si deux personnes gèrent leur premier projet, le programmeur diplômé en gestion de projet sera tout aussi mauvais que le chef de projet sans formation informatique. Les deux vont passer par un processus d'apprentissage abrupte.

L'argument sur la capacité des chefs de projet sans formation technique me le rappelle un peu:

Je pense honnêtement que la réponse est non. Il y a tout un bagage de compétences nécessaires pour être un bon chef de projet et être programmeur n'en fait pas partie. Un bon chef de projet pourrait gérer n'importe quel projet de n'importe quel type étant donné qu'il y a de bonnes personnes dans l'équipe de projet qui savent ce qu'elles font. La principale qualité qu'un chef de projet devrait avoir est ses compétences en communication . Le travail d'un chef de projet consiste à coordonner les tâches du projet et à maintenir la communication entre le client, les équipes de projet et toutes les autres parties prenantes. Il / elle doit savoir à tout moment les progrès de l'équipe et s'ils rencontrent des obstacles, mais n'a pas besoin de savoir quel est le problème ou ce que vous devez résoudre, sauf si cela implique une autre personne de l'équipe dont le temps sera doivent être ajustés pour aider à résoudre le problème.

Quant aux estimations, c'est une réalité de la vie dans n'importe quel emploi. Vous ne pourriez jamais faire construire une maison à temps si l'électricien ne pouvait pas vous dire combien de temps il lui faudrait pour faire le câblage - quand sauriez-vous réserver votre type de murs? Je suis d'accord cependant qu'il est vraiment difficile en informatique de donner des estimations en raison du nombre élevé d'impondérables. Les clients ne savent pas toujours ce qu'ils veulent et ils ont tendance à oublier de vous dire un tas de choses. Ce que j'avais l'habitude de faire était d'estimer approximativement le temps que je pensais que cela prendrait, puis de le multiplier par 2! Et un bon gestionnaire de programme ne devrait pas vous crucifier lorsque votre estimation s'avère erronée, cela lui causera quelques maux de tête pour réorganiser le planning, parler au client, expliquer aux patrons que ça va coûter plus cher, etc ... Mais cela fait partie de leur travail - encore une fois, sont surtout ce qui est requis.

Et je dirais même que le fait de ne pas avoir de compétences en programmation est encore mieux - un ancien programmeur pourrait tenter de faire l'estimation de lui-même ou de deviner vos estimations. Et nous savons tous que les compétences informatiques deviennent obsolètes très rapidement. Vous devez commencer à poser des questions lorsque votre chef de projet est plus intéressé par la façon dont vous allez effectuer une tâche que par le temps que cela peut prendre et quand vous aurez terminé. Ils pourraient vous demander d'évaluer des alternatives et de vous laisser hacher les détails, mais l'essentiel est de savoir comment vous allez affecter le calendrier du projet.

Enfin, je ne dis pas qu'aucune compétence informatique n'est nécessaire pour gérer un projet informatique - les informaticiens étant du type qui ne semblent tout simplement pas pouvoir vulgariser ce qu'ils disent pour les gens du commun (!), Cela aide à connaître le jargon de base pour pouvoir communiquer avec eux! Il est également essentiel de connaître les étapes de base - vous devez configurer un serveur avant d'exécuter un site Web dessus. Je ne pourrais pas gérer un projet de construction si je ne savais pas que l'électricien devait finir le câblage avant de fermer les murs !!

Un PM a vraiment besoin de savoir ce que le projet fera, ce qui nécessite probablement des connaissances techniques mais pas de développement.

A part ça, c'est une question de respect du terrain et des développeurs, plus que de connaissances réelles. Un PM doit prendre les développeurs au sérieux, ce dont ils ont besoin, ce qu'ils peuvent faire, ce qu'ils ne peuvent pas, combien de temps cela prendra. Un PM qui a une idée de ce qu'il ne sait pas peut être très efficace. Un PM qui pense avoir toutes les réponses est mauvais. Il peut s'agir d'un ancien développeur qui pense qu'il sait tout et ne sait pas, ou qui n'a jamais développé et ne pense pas qu'il ou elle ait besoin de connaissances techniques particulières pour gérer.

Je ne pense pas qu'un chef de projet d'un projet informatique nécessite une formation informatique. Mais il / elle doit absolument comprendre l'informatique et doit savoir comment fonctionnent les projets informatiques.

Bien que l'expérience informatique soit un avantage supplémentaire, son absence ne fait pas d'un chef de projet informatique pas si bon. Avoir également une formation en informatique n'est pas le facteur décisif.

J'ai travaillé avec les deux types, et chacun avait son ensemble unique de qualités et de problèmes.

Avec le backround informatique:
- Comprendrait quand on dit erreur de performance car le code n'est pas multi-thread
- Mais, dans certaines situations, dirait "hé allez, c'est juste ajouter 4 lignes de code, vous pouvez le faire en 10 jours"

Sans fond informatique:
- Serait très à l'aise de négocier pour changer un délai confortable
- Pour un projet sans aucune exigence (du tout, encore), dirait parfois "peut-on donner une estimation approximative de 100 jours et mentionner un tampon de 30%.

Je pense qu'ils ont besoin de connaissances en programmation. Si ce n'est pas le cas, ils feront toujours pression sur les programmeurs pour que leurs tâches soient rapides et s'attendent à ce que cela se fasse en quelques heures, alors que la tâche nécessite beaucoup de réflexion et de dévouement. Ces qualités sont connues et bien maîtrisées par les programmeurs, donc si le chef de projet a une formation en programmation, il comprendra combien de temps une tâche spécifique prendra et il n'y aura pas d'arguments au sein du département et donc au final un bon projet évoluera.

@NimChimpsky Je suis d'accord.

C'est une question de quoi , pas de comment (l'écoute active est un bon outil).

L'estimation fonctionne pour les petites tâches techniques, mais pour la planification, vous devez travailler ensemble pour voir toute la complexité. Et vous n'êtes pas rivaux.

Ce serait certainement utile, surtout si ce n'est pas un bon gestionnaire de projet. Pour un bon chef de projet, cela compte vraiment.

Non.

Un bon chef de projet est quelqu'un qui peut comprendre et comprendre les besoins, les préférences et les capacités de son équipe, que ce soit sur le chantier, dans l'atelier de fabrication ou dans la maison de développement de logiciels.

Un bon ou un mauvais chef de projet peut avoir n'importe quel type d'expérience:

Les mauvais gestionnaires ayant des antécédents techniques auraient pu être des programmeurs ace qui n'apprécient pas la difficulté rencontrée par les novices lorsqu'ils traitent de concepts banals et "faciles" comme les pointeurs.

Un bon gestionnaire pourrait être ce programmeur moyen qui n'était pas aussi brillant ou aussi intelligent que ses collègues mais qui avait une compréhension approfondie de la structure du projet, des exigences et qui comprenait par cœur les leçons du Mois de l'homme mythique parce qu'il avait lui-même vécu de mauvais jours de codage et a été mâché pour ne pas avoir terminé ses livrables à temps.

Un bon manager pourrait être ce vendeur de logiciels qui a découvert que ses amis codeurs ne pouvaient pas sortir avec lui le week-end en raison des promesses irréalistes qu'il avait lui-même faites au client.

Les connaissances techniques ne prédéterminent pas les qualifications d'un programmeur en tant que gestionnaire, car les compétences requises dans les deux emplois sont totalement différentes. Donc non.

Je n'ai jamais vu un chef de projet sans expérience informatique capable de gérer un projet de développement logiciel non trivial qui en valait la peine. J'ai vu très peu de chefs de projet ayant une expérience informatique qui pouvaient le faire non plus, mais ils semblaient moins gâcher.

D'après mon expérience, la gestion est une communication et une prise de décision efficaces. Dans cet esprit, il est logique que quelqu'un qui comprend les métiers (au moins les concepts de base et la terminologie) utilisés par les personnes qu'ils gèrent, soit mieux adapté pour être un gestionnaire que quelqu'un qui a moins de compréhension, mais il y a certainement pas de corrélation. J'ai vu des gestionnaires avec une expérience en programmation réussir et échouer, tout aussi souvent que des gestionnaires sans expérience en programmation.

Soit extrême est mauvais, à mon avis; Les personnes ayant trop peu d'expérience en programmation peuvent faire aveuglément confiance à leurs programmeurs (Shepard suit les moutons); Les personnes ayant trop d'expérience peuvent continuellement remettre en cause les efforts de leur équipe (micro gestion).

Personnellement, je pense que quelqu'un qui a une bonne compréhension des concepts de programmation de base, mais qui se rend compte qu'ils ne sont pas un "hot shot", est le type idéal de gestionnaire.

Absolument.

Je dois être prudent avec celui-ci car il est basé sur des histoires vraies mais j'essaierai d'expliquer ma douleur.

Je travaille comme ingénieur logiciel et nous avons un chef de projet avec qui je travaille beaucoup ces derniers temps. Il n'a aucune formation technique et il semble que cela ne l'intéresse pas du tout mais ce n'est pas le problème (tout le monde a ses propres intérêts). Si vous n'aimez pas avoir un savoir-faire technique parce que c'est un peu "bizarre" que le vôtre MAIS si c'est votre travail de parler avec le client au niveau technique, il est essentiel d'avoir un savoir-faire technique qu'il n'a pas avoir.

Quoi qu'il en soit, il y a ce type qu'il ne comprend rien au fonctionnement d'un serveur, au fonctionnement d'une page Web, au fonctionnement de la programmation, etc. Parfois, j'ai l'impression qu'il ne sait rien. Donc, chaque fois que j'essaie de lui faire comprendre ce que nous devons faire maintenant ou quel est le problème, ce que nous avons en ce moment, il ne comprend rien. ET ce n'est pas ce genre de gars qui dirait "Attendez une seconde. Pouvez-vous répéter que je ne le comprends vraiment pas.". Non, c'est ce genre de gars qui ne veut pas montrer qu'il n'a rien compris dans toute la conversation.

Mais cela ne s'arrête pas là car il appelle ensuite le client et lui parle de quelque chose qui n'est fondamentalement pas vrai. Et finalement, nous devons appeler le client ensemble pour que cela soit à nouveau clair.

C'est pourquoi je dis qu'il est vraiment ESSENTIEL d'avoir une formation technique de base et un savoir-faire technique. Il ne devrait pas être capable d'écrire du code mais il devrait être capable de comprendre ce qui se passe et quels processus doivent être effectués.

BTW depuis que je travaille avec lui, mon travail n'est plus amusant.

Je dirais que oui, il devrait avoir une formation en programmation. Si le gestionnaire n'a pas la moindre idée de ce que c'est que de programmer, il se retrouvera avec des estimations irréalistes pour le développement et la correction de bogues. De plus, il ne comprendrait pas assez bien un problème technique pour prendre une décision. Les programmeurs de l'équipe pourraient lui mentir et il ne se rend peut-être pas compte, les programmeurs peuvent aussi lui dire un problème et il peut penser qu'ils font des conneries

Les compétences techniques ne font pas un bon gestionnaire, de bonnes compétences en gestion le font. Il peut être utile si un gestionnaire a fait son temps dans les «tranchées», car il peut apprécier le processus que les profanes ne peuvent pas avoir. Cependant, il peut également en résulter une sorte de freakery de contrôle que même les managers profanes de contrôle n'ont pas. Ils peuvent essayer de faire tout le travail eux-mêmes ou examiner le vôtre d'une manière extrêmement inconfortable.

D'après mon expérience personnelle, le meilleur manager que j'ai jamais eu était assez ignorant de la technologie, mais il savait que les gens qui travaillaient sous lui connaissaient leur métier, et il savait comment gagner la loyauté et le respect de son équipe. J'ai travaillé sous ses ordres pendant quatre ans et je n'ai quitté l'entreprise que parce qu'il était parti et avait été remplacé par un manager qui n'était pas aussi bon.

L'un des pires gestionnaires que j'ai eus est versé dans le codage (sinon la conception de logiciels) et fait tellement de travail lui-même qu'il nous laisse un peu plus que des notes, la correction de bugs ou les projets qu'il ne veut pas se faire.

Il semble y avoir une certaine confusion:

Le PM n'est pas le patron des développeurs . La personne responsable de l'équipe de développement (chef d'équipe, gestionnaire) et de l'embauche et des évaluations devrait décider si vous travaillez assez dur.

Les estimations ne sont pas parfaites. Je pense que le PM comprend cela plus que vous ne le pensez. Vous attendez-vous sérieusement à ce que personne ne vous demande jamais combien de temps il faudra pour faire quelque chose? Tout le monde veut savoir quand c'est fait et c'est le travail du PM de le suivre.

Vous pouvez être un PM si vous: A) comprenez comment gérer des projets B) comprenez le processus de développement. Aucun de ces éléments ne nécessite de connaissances en codage, mais cela peut aider.

Déterminer si les programmeurs en font assez n'est pas le travail du PM à moins qu'il ne se double du chef d'équipe. Pour savoir si quelqu'un «souffle de la fumée» ou non pour terminer une tâche, un gestionnaire aura toujours un avantage s'il comprend ce qui est impliqué.

Les estimations s'améliorent avec des programmeurs expérimentés qui ont l'habitude de travailler sur un type de projet particulier. Personne ne s'attend à ce qu'ils soient parfaits, mais ils s'attendent à ce que vous vous rapprochiez et que vous vous amélioriez au fil du temps.

Je me souviens du vieil adage: "il n'est pas nécessaire d'être fou pour travailler ici, mais ça aide".

La réponse courte est qu'une expérience pratique de codage n'est pas une condition requise pour un bon gestionnaire de logiciel, mais elle est généralement préférée. Ce qui est essentiel pour être un PM compétent, c'est de comprendre le processus de développement (quelle que soit la méthodologie utilisée) et d'avoir confiance que les développeurs sont désireux et capables de faire leur travail. L'expérience de développement donne une connaissance pratique de ce processus, donc cela aide. Les PM qui gravissent les échelons dans une entreprise connaissent en outre la culture d'entreprise (et la base de code) et entretiennent des relations avec les autres membres de longue date de l'équipe de développement.C'est pourquoi l'OMI promeut les meilleurs PM de l'intérieur d'être amené de l'extérieur. Si quelqu'un à l'extérieur de l'entreprise peut mieux gérer l'équipe que quelqu'un de l'intérieur, les choses vont TRÈS mal.

Une chose que j'ai mentionnée est un rapport entre le PM et l'équipe de développement. C'est à la fois au niveau interpersonnel et technique. La clé ici est la communication; les développeurs doivent sentir qu'ils peuvent apporter des problèmes, à la fois techniques et interpersonnels, au PM, et le PM doit comprendre les membres de l'équipe de développement lorsqu'ils décrivent un problème.

Quant à la nature spécifique de votre question, une estimation est exactement cela; une supposition éclairée quant à une quantité (par opposition à une hypothèse, qui est une prédiction plus générale du résultat d'un événement futur). Le gestionnaire appliquera généralement mathématiquement ou intuitivement un modificateur, basé sur vos estimations récentes par rapport aux délais réels. Agile intègre cela dans le processus d'estimation; le client estime intuitivement la complexité des exigences, puis les développeurs font de même, puis les développeurs sortent et développent la solution, donnant au gestionnaire des points de données pour calculer un rapport des points d'exigences aux points de développement et des points de développement à l'homme -exigences d'heure.

En bref, un gestionnaire ne prendra votre estimation à sa valeur nominale que dans l'un des trois scénarios:

• Vous avez été assez précis avec vos estimations de tâches similaires dans le passé.
• Il est sous pression pour livrer, et votre estimation est meilleure qu'il ne le pensait.
• Il cherche une raison de vous virer.

Si c'est cette dernière situation, il y aura de nombreux autres indices autour du lieu de travail que vous devriez peut-être foutre le camp.

Je n'en ai aucune idée mais ma crèche a besoin de quelques connaissances techniques. Il est parfois impossible de l'expliquer.