Pourquoi les analystes commerciaux et les chefs de projet reçoivent-ils des salaires plus élevés que les programmeurs?
Nous devons admettre que la programmation est beaucoup plus difficile que de créer de la documentation ou même de créer un diagramme de Gantt et de demander des progrès aux programmeurs. Donc, pour nous qui sommes naïfs, sachant que la programmation est généralement plus difficile, pourquoi les analystes commerciaux et les chefs de projet reçoivent-ils un salaire plus élevé que les programmeurs? Qu'est-ce qui fait de leur travail un travail bien rémunéré alors que même la plupart du temps, ce sont les programmeurs qui rentrent tard à la maison?
MISE À JOUR
Excusez mon ignorance, de certaines réponses, il semble que la raison pour laquelle les BA et les PM reçoivent un salaire plus élevé parce que ce sont eux qui sont généralement responsables des programmeurs du mess. Mais au bout du compte, ce sont les programmeurs qui se salissent les mains pour réparer les dégâts et travailler plus dur. Cela n'a donc toujours pas de sens.
Que les chefs de projet obtiennent des salaires plus élevés que les programmeurs et les analystes commerciaux existent en tant que classe dépend carrément du monde logiciel dans lequel vous vivez.
ne réponse simple à cette question serait "parce que dans nos sociétés, nous pensons toujours que le salaire est lié à la position dans la hiérarchie". Mais cette réponse, tout en reflétant le fait que les gens sont payés en fonction de leur valeur perçue, n'explique pas pourquoi PM et BA sont au sommet de la hiérarchie dans de nombreuses organisations de logiciels et pourquoi la direction opte pour la hiérarchie en premier lieu comme structure de choix pour l'équipe de projet logiciel. Ce sont les deux questions qui semblent vraiment mériter d'être posées.
D'une manière générale, il existe deux catégories d'organisations de création de logiciels. Je les appellerai Widget Factories et Film Crews.
Les usines de widgets sont nées d'une école de pensée de gestion qui tourne autour Théorie de la motivation X proposé par McGregor: les employés de rang sont paresseux et nécessitent un contrôle et une supervision constants, les emplois sont occupés au nom d'un chèque de paie, les gestionnaires sont toujours en mesure de faire le travail de leurs subordonnés au niveau supérieur ou, au moins, le même. Cette réflexion aboutit à une idée naturelle que toute l'équipe peut facilement être remplacée et représentée par le manager seul - après tout le reste de l'équipe est facilement remplaçable ou simplement pour améliorer la capacité du manager à accomplir des tâches. D'où la hiérarchie en tant que structure et les rôles de travail plutôt horizontaux.
La gestion de Widget Factory repose sur l'hypothèse que les logiciels peuvent être fabriqués à partir d'une spécification préparée par un analyste métier via un processus clairement défini exécuté sous la supervision étroite d'un chef de projet. La fabrication est prise en charge en dotant le projet de suffisamment de ressources de programmation et de test qualifiées mais interchangeables. Le travail est conduit par un budget préétabli basé sur l'analyse de rentabilisation initiale préparée par PM et BA.
La gestion qui gère une usine de widgets est facile à repérer simplement en faisant attention à la façon dont ces gens parlent. Ils sont susceptibles de porter sur les ressources (y compris en ce qui concerne les membres de l'équipe), les processus, l'efficacité opérationnelle, l'uniformité, la répétabilité, le contrôle strict de l'utilisation des ressources, les rôles de travail clairs et les entrées et sorties de processus définies. Ils mentionneraient avec désinvolture la métaphore réelle de l'usine lorsqu'ils tentent de transmettre l'image de l'opération de développement logiciel idéale telle qu'ils la voient.
Ensuite, il y a les équipes de tournage. Ils sont basés sur la notion que les gens sont intelligents, motivés, travaillent très dur et aiment leur travail autant que les enfants aiment jouer. Les équipes de tournage reconnaissent qu'en raison de la spécialisation, les capacités individuelles des contributeurs peuvent dépasser de loin les capacités des personnes à organiser, coordonner et diriger le travail. Étant donné que le gestionnaire ne peut plus se substituer à tout le monde, la structure hiérarchique ne fonctionne tout simplement pas si bien - les gens doivent coopérer au sein d'une formation beaucoup plus plate et complexe pour faire avancer les choses. Les rôles professionnels eux-mêmes ont tendance à être beaucoup plus verticaux - du début à la fin - et impliquent une plus grande variété de compétences. Cette pensée de gestion est étayée par Théorie Y de McGregor .
Un réalisateur d'un Film Crew sait que sa vision d'un logiciel ne peut se réaliser que si elle est capable de constituer une grande équipe, de fasciner l'imagination et d'aider l'équipe à se gélifier et à travailler ensemble. Son rôle est d'inspirer, de garder la vision, de fournir une orientation et de concentrer les efforts. Chaque personne est importante parce que le "directeur" croit que le logiciel résulte de la combinaison des visions du monde et des capacités de tous les participants et d'une manière unique que le groupe effectue le travail ensemble. Tout le monde reconnaît dès le départ l'importance de faire en sorte que les étoiles se joignent à l'équipe - les artistes vedettes augmentent toutes les chances de succès. La vision conduit le budget et attire des financements.
En ce qui concerne la rémunération Widget Factories estime que la plus grande valeur est dérivée du travail effectué par le chef de projet et l'analyste d'affaires qui résident au sommet de la hiérarchie et doivent être rémunérés en conséquence, le reste de l'équipe n'a pas d'importance tant qu'ils ont les bonnes qualifications pour convertir les exigences en code de travail. PM et BA travaillent dur pour maintenir leur position au sommet du peloton en restreignant le libre accès aux sources d'informations sur le projet au reste de l'équipe. Sans accès formel aux sources d'informations principales, l'équipe a du mal à faire des jugements de valeur ou à trouver de bonnes solutions, les programmeurs sont relégués à prendre les commandes d'en haut et à travailler sur le problème tel que défini par PM et BA. Cette situation renforce encore la notion de Widget Factory que les programmeurs s'apparentent à des ouvriers d'usine qui ne sont capables d'exécuter mécaniquement que des tâches techniquement compliquées, mais néanmoins standard.
Dans un contraste saisissant, Film Crew agit comme une formation plus égalitaire; les membres ont un accès illimité aux informations primaires, sont encouragés à formuler des jugements de valeur et sont libres de choisir un plan d'actions à réaliser et à contribuer à la vision. La structure de leadership est basée sur la capacité plutôt que sur un rôle spécifique au sein de l'équipe. La rémunération reflète à quel point il est souhaitable de faire participer une personne spécifique au projet, elle est souvent liée à la perception de la valeur encore plus grande du résultat final si cette personne peut être convaincue de consacrer son énergie à la création de ce logiciel. Dans cet environnement, le rôle d'un chef de projet devient moins important car il est peu probable qu'il soit le leader créatif; le rôle se résume principalement au soutien administratif et aux relations extérieures. Les fonctions d’analyste d’affaires sont en partie remplacées par le rôle de visionnaire (je l’appelais plus tôt "une directrice") et en partie absorbées par les autres membres de l’équipe.
Maintenant, il ne sera pas surprenant que la plupart des équipes de développement de logiciels internes et certains cabinets de conseil soient dirigés comme des usines de widgets s'appuyant sur un processus pour produire des logiciels constamment ennuyeux; ce sont ces environnements où les chefs de projet et les analystes commerciaux sont systématiquement payés plus que les programmeurs, en supposant qu'ils apportent le plus de valeur à l'environnement structuré en conséquence, ce qui rend difficile pour les programmeurs de prouver que la gestion est mauvaise.
Les sociétés de logiciels qui réussissent ont tendance à adopter le point de vue de Film Crew, toute autre philosophie entraverait leur capacité à attirer des gens formidables sur lesquels ils comptent tellement pour produire de grands logiciels. Il est peu probable que vous voyiez un rôle d'analyste commercial dans ce contexte et les chefs de projet sont moins importants et sont généralement moins payés que les grands programmeurs.
Parce que dans nos sociétés, nous pensons toujours que le salaire est lié à la position dans la hiérarchie.
Les analystes ou chefs de projet sont plus élevés dans la hiérarchie, donc ils devraient être mieux payés.
Permettez-moi de vous raconter une histoire vraie qui illustre pourquoi c'est un problème.
Un bon ami a commencé comme programmeur dans un grand hôpital. Grâce à son travail acharné et son dévouement, il est rapidement devenu Oracle DBA, qui était une position critique dans une entreprise où les données sont à la fois sensibles et précieuses.
L'hôpital fonctionnait avec des niveaux. Les niveaux sont liés à votre position dans la hiérarchie, l'héritage et les diplômes.
Mon ami a reçu une proposition pour devenir DBA dans une autre entreprise qui n'utilisait pas les niveaux de salaire. Son salaire pourrait être considérablement augmenté. Parce qu'il aimait et respectait l'hôpital pour lequel il travaillait, il a décidé de parler au patron, lui demandant une augmentation.
Le patron a refusé. C'était impossible à cause des niveaux et les syndicats ne voulaient pas que cela se produise.
Mon ami est parti.
L'hôpital a finalement embauché un consultant externe (non lié aux niveaux) et affiché un emploi sur son site Web. Le consultant ne savait rien de l'infrastructure en place, donc sa courbe d'apprentissage était énorme. L'hôpital a perdu beaucoup d'argent à cause de cela.
L'hôpital a perdu beaucoup plus. Le consultant externe a été payé jusqu'à 5 fois ce que mon ami avait demandé et ils n'ont pas pu trouver d'employé qualifié pour le remplacer.
C'était il y a presque trois ans. Mon ami est toujours à sa nouvelle place et gravit les échelons de la hiérarchie très rapidement en faisant ce qu'il aime.
L'hôpital paie toujours 5 fois plus.
À mon humble avis, le salaire doit être relatif à la valeur que vous fournissez à l'entreprise.
UPDATE : Lorsque vous vous déplacez plus haut dans la hiérarchie, l'effet de levier se produit. Donc, en fait, vous êtes payé pour la valeur que vous apportez. Mais les programmeurs brillants qui sont 10 fois plus productifs devraient être payés 10 fois plus, quelle que soit leur position dans cette hiérarchie (généralement tout en bas). C'est ce que je voulais souligner.
Ils prennent plus risques que les programmeurs. Ils doivent prendre des décisions en fonction des informations que nous leur avons fournies, puis faire face aux dures critiques des parties prenantes lorsque leurs attentes ne sont pas satisfaites. Une partie de la masse salariale compense ce risque.
Un autre facteur peut être les années d'expérience nécessaires pour préparer un chef de projet capable de planifier, d'estimer et d'atténuer correctement. Dans un certain sens, un chef de projet nuancé est formé par des échecs, ce qui en fait une compétence coûteuse à acquérir. Une fois le niveau d'ancienneté atteint, une entreprise peut ne pas être prête à abandonner un personnel aussi précieux.
Éditer:
Il existe plus de types de risques que de dommages financiers ou physiques. Par exemple, considérez le risque d'être réprimandé par le manager ou le client. Bien qu'aucun préjudice réel ne soit fait, il est encore assez indésirable que nous adaptions nos comportements afin d'éviter ce type de résultat. Cependant, les managers doivent toujours prendre de bonnes décisions et équilibrer les différents types de risques dans l'intérêt de l'entreprise, et non en fonction de leurs préférences personnelles.
La programmation peut être plus difficile dans une certaine mesure, mais elle est également plus agréable. Il vous suffit de vous asseoir et de résoudre le casse-tête de la programmation de Nice pendant que les gestionnaires gèrent toutes sortes de conneries entre leurs subordonnés, leurs clients, leurs propres patrons et les parties prenantes. C'est pourquoi si peu de personnes sensées veulent réellement être des gestionnaires, vous devez donc compenser cela en payant plus.
La programmation est plus difficile, mais la gestion est plus difficile.
Une façon de penser quelle est la valeur d'une personne pour une entreprise est d'imaginer ce que ce serait si cette personne quittait l'entreprise. Habituellement, les gestionnaires se révèlent plus précieux dans ce sens que les programmeurs. James Gosling , le créateur de Java, a récemment quitté Oracle. On pourrait penser que c'est une perte énorme, mais devinez quoi? En fait, cela n'a pas d'importance. Cela n'a pratiquement aucun effet sur Java ou sur Oracle. Les chiens aboient, mais la caravane continue.
Soit dit en passant, je pense (sérieusement) que les aspirateurs et les nettoyeurs devraient être payés beaucoup plus que les programmeurs. Nettoyer la litière des autres est un travail qui aspire et est indispensable.
Réduire la gestion à la création de graphiques et à la rédaction de documentation revient à dire que la programmation est en train de taper.
Pour chacun, mais pour moi, la programmation est beaucoup plus facile que de gérer les gens.
Tout le monde ici se concentre sur les négatifs. Je n'ai jamais rencontré un programmeur qui aime la politique du bureau et de bons gestionnaires vous protègent de ce genre de déchets. Ayant interagi avec beaucoup de gens chez notre client principal, la moitié d'entre eux sont fous et je suis heureux d'avoir mon PM là pour absorber cette folie pour moi. S'ils les paient beaucoup , ça va. Il en a besoin pour l'inévitable thérapie.
C'est discutable bien sûr, mais une raison importante derrière cela est que ils portent la responsabilité du projet s'il échoue, pas les programmeurs. Ils pourraient vous donner une oreille pour avoir armé quelque chose, mais ils font face à des critiques de pouvoirs encore plus élevés. Ce sont eux qui sont chargés de planification et estimation.
La gestion nécessite un très ensemble de compétences à multiples facettes: compétences humaines, leadership, capacité à estimer les coûts et le temps. Pour faire tout cela, ils doivent également rester en contact avec votre côté des choses (c'est-à-dire avoir une idée de ce que vous faites, techniquement parlant) ou être de très bons juges de caractère.
Si les exigences n'ont pas été définies correctement, c'est leur faute.
Si les plans de test n'ont pas été définis correctement, c'est leur faute.
Si vous partez en vacances ou si vous vous cassez la jambe ou si vous vous perdez un samedi soir ou si vous partez sans en donner suffisamment de préavis, ils doivent trouver un remplaçant ou <une raison ici> et vous ne pouvez pas faire votre travail et le produit ne reçoit pas livré (à temps ou pas du tout), c'est toujours leur faute.
Notez également que lorsque je veux dire qu'ils portent la responsabilité, cela affecte les gens au-dessus et en dessous d'eux. S'ils bousillent les choses, ce sont peut-être les emplois de votre équipe qui sont en jeu. C'est aussi le genre de pression pour lequel vous êtes payé.
PS: De plus, je ne sais pas si je dirais que la programmation est plus difficile que de faire des diagrammes de Gantt (pour réutiliser l'exemple que vous mentionnez). Je ne sais pas pour vous, mais je trouve la programmation (en général, pour 80% des choses que vous devez faire dans l'industrie) assez facile. Si vous vissez quelque chose, vous pouvez le réparer. Si votre patron bousille son diagramme de Gantt ou son estimation des coûts, ce sera maintenant un problème beaucoup plus important que d'inverser un != null pour un == null. Les petites erreurs comptent pour elles à plus grande échelle. La plupart du temps, bien sûr, si vous avez raté un test comme celui-ci dans une application médicale intégrée qui est devenue opérationnelle, c'est aussi un gros problème. Mais ils auront plus de problèmes que vous!
Offre et demande est un modèle économique de détermination des prix sur un marché. Il conclut que sur un marché concurrentiel, le prix unitaire d'un bien particulier variera jusqu'à ce qu'il se stabilise à un point où la quantité demandée par les consommateurs (au prix actuel) sera égale à la quantité fournie par les producteurs (au prix actuel), équilibre économique des prix et des quantités. Les quatre lois fondamentales de l'offre et de la demande sont:
- Si la demande augmente et l'offre reste inchangée, alors prix et quantité d'équilibre plus élevés.
- Si la demande diminue et l'offre reste inchangée, alors baisse du prix et de la quantité d'équilibre.
- Si l'offre augmente et la demande reste inchangée, alors prix d'équilibre plus bas et quantité plus élevée.
- Si l'offre diminue et la demande reste inchangée, alors prix plus élevé et quantité plus faible.
Dans ce cas, l'une des raisons est qu'il y a trop de développeurs.
J'ai changé entre les rôles de développeur et PM tout au long de ma carrière. J'ai des développeurs sur mon projet qui gagnent deux fois plus que moi et d'autres qui gagnent la moitié. Les hauts salaires sont payés ce que ils sont parce que: A) Ce sont des développeurs "rockstar". B) Ils interagissent avec les clients, expliquent le produit d'une manière facile à comprendre pour les clients et agréable. C) Ils dirigent des équipes de développeurs qui travaillent sur plusieurs projets. D) Ils sont toujours disponibles et désireux de plaire.
Ils jouent les rôles de développeur, de PM et de BA à divers titres. Généralement, si vous passez 90% de votre temps tête baissée, à couper du code, vous n'êtes pas incroyablement précieux et vous êtes probablement facilement remplaçable. Si vous voulez gagner plus d'argent, vous devez assumer plus de responsabilités ... et probablement trouver une autre entreprise qui vous paiera plus.
La justification est que le domaine de responsabilité d'un chef de projet est (souvent) de livrer l'ensemble du projet à temps, avec une qualité acceptable, dans le cadre d'un budget prévu. Il y a souvent beaucoup d'argent en jeu, donc les bons chefs de projet ont souvent une rémunération plus élevée que les programmeurs.
Cependant, je ne pense pas que les analystes commerciaux gagnent en moyenne un salaire beaucoup plus élevé que les programmeurs. Et j'ai le sentiment qu'il devient moins courant que le niveau de salaire dans une entreprise soit déterminé par la hiérarchie et non par la valeur d'un employé.
Mon expérience peut être différente (ou je vis dans un univers différent avec des lois de la physique déformées), mais la plupart des analystes commerciaux et des chefs de projet (pas programme managers, mais projet managers ou PMP) que les postes que j'ai vus sont au niveau ou légèrement inférieur au salaire moyen des programmeurs.
L'écart salarial commence à s'élargir davantage par rapport au salaire moyen des ingénieurs logiciels (en faveur de l'ingénieur logiciel). L'écart est encore plus par rapport aux ingénieurs EE ou ingénieurs logiciels seniors. Presque aucun analyste d'entreprise senior ou PMP senior ne fera la même chose qu'un ingénieur logiciel senior EE ou senior/principal.
Un gestionnaire de programme, cependant (ce qui n'est pas la même chose qu'un PMP), cette personne gagnera beaucoup plus que quiconque (et les raisons devraient être évidentes.)
La chose qui me dérange le plus quand je vois ces plaintes concernant les salaires est qu'en tant que programmeurs (spécialement en tant que programmeurs débutants/débutants dans l'entreprise), nous sommes (ou n'étions pas) si spéciaux. Il n'y a vraiment rien dans un programmeur débutant qui sort de l'école qui mérite un salaire de scientifique. Non.
Nous tous qui travaillons sur les logiciels sont partis de zéro. Nous l'avons tous fait.
Et SI nous sommes vraiment honnêtes, nous savons bien que nous ne connaissions pas la merde. Être en mesure de terminer notre charge de cours CS de premier cycle n'est que le point de départ. Cela ne nous rend pas si spécial ou ZOMG !!!! uber-einsténien. Vraiment, non!
Et pourtant (et grâce à la période malheureuse de la bulle Internet), nous nous attendons à faire non seulement plus, mais beaucoup plus qu'une autre personne diplômée universitaire simplement parce que OH WOW, nous sommes programmeurs et ils sont - juste analystes commerciaux et PMP.
Pouvez-vous épeler l'arrogance? Newsflash - pour la plupart des tâches de programmation dans l'entreprise, vous n'avez même pas besoin d'un diplôme de 4 ans. C'est vraiment sérieux.
Mettez le temps sur le Grind et construisez l'expérience pour passer de la programmation à l'ingénierie logicielle (ou l'ingénierie d'ailleurs) au niveau supérieur. Ensuite, vous pouvez exiger de faire beaucoup, beaucoup, pero mucho mucho beaucoup plus qu'un analyste d'entreprise et PMP.
En finir avec - certains d'entre nous sont (ou étaient) surpayés. Période.
Rant apart: raisons pour lesquelles un analyste d'entreprise et/ou PMP rapproche les salaires ou similaire à des programmeurs qui n'ont pas encore accumulé le temps et l'expertise nécessaires pour être des ingénieurs logiciels moyens/supérieurs (ou qui n'ont toujours pas développé d'expertise dans un créneau très demandé) région):
Un analyste d'affaires est la liaison entre les gens des logiciels et des systèmes et les gens d'affaires/processus d'affaires (qui sont ceux qui justifient l'existence de votre salaire, et non l'inverse.) Ce sont eux qui sont responsables de décomposer les processus commerciaux de manière méthodique et analytique, en tant qu'entrée prête à former des exigences, les choses sur lesquelles vous travaillez. Ils s'assurent que vous passez la plupart de votre temps à programmer et à ne pas vous occuper des moindres détails des affaires.
Beaucoup d'entre vous pensent que les affaires sont faciles. Si vous pensez vraiment que c'est vrai, Dieu vous aide.
A chef de projet est la personne chargée de jongler avec plusieurs projets (alors que vous n'avez qu'à jongler avec un ou deux au maximum à un moment donné.) C'est votre parapluie, et c'est lui qui doit faire le sale boulot que la plupart des masses restantes non lavées ne veulent pas faire - pour chasser les gens en s'assurant qu'ils font leur travail ou en supprimant les obstacles à votre travail.
C'est lui qui vous demandera "sur quoi travaillez-vous? Est-ce que vous travaillez pour faire avancer le projet? Avez-vous des problèmes avec votre travail? Quels sont vos obstacles, de quoi avez-vous besoin? Qui peut vous le donner? "...
puis il ira voir les autres poser les mêmes questions difficiles, en s'assurant que les obstacles sont supprimés et en s'assurant que vous pesez sur le projet (si nécessaire).
Le problème numéro un que j'ai vu dans de nombreux projets ayant échoué est un manque de PMP ou un manque de respect envers les PMP (en particulier de la part des développeurs.) Il est rare que je vois des projets échouer en raison de PMP incompétents, et pourtant on doit se demander pourquoi de nombreux programmeurs sont plus que désireux de dire que est le cas.
Je suis dans la finance, et je pense que la mentalité est similaire dans la plupart des tenues non technologiques:
Le salaire est proportionnel au risque de carrière
À moins d'un licenciement complet d'un groupe ou d'une équipe, les programmeurs de bas niveau conservent toujours leur emploi. C'est la nature du travail, et les programmeurs s'y lancent en sachant très bien qu'ils ne prennent aucun risque. S'il y a un bug, ce n'est pas leur tête sur le bloc de coupe.
À des niveaux supérieurs, si quelque chose se dérobe, vous êtes le premier à partir. J'ai eu beaucoup d'expériences avec un subordonné qui a fait une petite erreur typographique qui nous a fait perdre de l'argent, et j'ai pris le feu pour ça (pas le vrai programmeur qui a fait l'erreur).
Tout simplement, la rémunération est proportionnelle au risque. Les programmeurs, en revanche, n'ont pas nécessairement de skin dans le jeu, pour ainsi dire.
Si votre question avait été "pourquoi X et Y reçoivent-ils des salaires plus élevés que les programmeurs dans mon entreprise" J'aurais peut-être répondu "vous pouvez travailler dans la mauvaise entreprise".
Le succès d'une entreprise dans le domaine des logiciels dépend plus des capacités de ses programmeurs que de quiconque. Les entreprises qui ne reconnaissent pas cela sont automatiquement désavantagées par rapport à celles qui l'obtiennent. Embaucher les meilleurs programmeurs et en prendre bien soin est votre meilleur pari. La différence entre le travail des grands programmeurs et le reste est énorme; bien plus que la différence de salaire qu'ils commandent. Mais si vous insistez pour sous-payer vos programmeurs, vous en aurez pour votre argent.
Cela dit, tous les autres rôles dans l'entreprise sont importants. Les grands managers ont un impact énorme. Cela passe en grande partie par l'obtention d'excellents programmeurs et leur satisfaction. On peut dire quelque chose de similaire à propos de l'analyse commerciale, du marketing, des ventes, des tests et du support.
Si vous êtes un grand programmeur et que vous n'êtes pas largement récompensé, allez ailleurs. Là encore, vous n'êtes peut-être pas un excellent programmeur. Malheureusement, si vous n'êtes pas génial, il est difficile de voir pourquoi. Si vous saviez pourquoi, vous pourriez changer et être génial, non?
J'ai été programmeur et gestionnaire de personnes. J'ai travaillé avec beaucoup de grands programmeurs, mais seulement avec quelques bons managers. Quand j'étais manager, je n'étais pas génial, mais au moins je le savais. Mon peuple a obtenu plus de relances que moi, ce qu'il méritait.
Cela a peu à voir avec les compétences et le travail, je veux dire que peu de choses dans l'économie sont liées au nombre de personnes mériter faire.
Mériter de gagner plus d'argent est une idée éphémère, tout le monde croit qu'ils méritent de gagner plus d'argent.
Même si ce n'est pas juste, les gestionnaires gagnent plus d'argent simplement parce que les propriétaires d'entreprise leur font davantage confiance. Les managers obtiennent souvent des salaires plus élevés, simplement pour ne pas prendre un nouvel emploi à l'improviste à un moment gênant.
J'ai parcouru tous les articles et j'ose dire que la plupart d'entre eux essaient de comparer des pommes et des bananes.
Tout d'abord, je crois que quelqu'un qui dit que "gérer est un jeu d'enfant" n'a jamais eu à gérer autre chose que son propre horaire. D'un autre côté, dire que "n'importe qui peut coder n'importe quoi" est idiot (et est dans le mauvais forum, pour l'amour de Dieu!).
J'ai particulièrement aimé les réponses rwong et luis.espinal, même si je crois qu'il y a d'autres faits qui doivent également être notés.
Je ne crois pas que la hiérarchie soit une réponse - pas de nos jours - même si elle correspondait parfaitement aux 10 000 dernières années. Nous avons vécu pendant des siècles dans une société où plus vos profits sont élevés, plus votre pouvoir est élevé (et vice-versa). Je ne crois pas que cela s'applique à notre monde, tel qu'il est (spécialement dans notre région).
Revenons à la question principale, je crois que les managers gagnent généralement plus parce qu'ils sont plus précieux pour une entreprise, non pas parce qu'il est plus élevé dans la hiérarchie, mais il est plus élevé à cause
- toutes les connaissances qu'il a déjà acquises d'expériences précédentes (les programmeurs ont généralement moins d'expérience que les managers en général)
- pour être capable de gérer plusieurs choses à la fois (les programmeurs ont une tâche - ou une liste de tâches - à accomplir, tandis que les gestionnaires doivent gérer leurs propres tâches
- ils sont le contact principal pour le projet qu'ils gèrent, et pour cette raison, ils sont la première "cible" en cas de problème. Il est plus facile de perdre son emploi si vous êtes gestionnaire; en tant que développeur, vous avez la "licence pour refaire quelque chose". C'est le facteur "risque" que tout le monde a mentionné.
- les développeurs font partie du cycle de vie d'un projet. Je crois que lorsque nous parlons ici de "programmeurs", nous pensons également aux testeurs, aux rédacteurs techniques et à toutes les autres personnes qui sont très importantes pour la réussite du projet.
- et il y a quelque chose que je n'ai vu que dans quelques articles sur ce sujet: le leadership. Être manager, c'est savoir être en contact avec les gens, négocier, garder tout le monde motivé, créer une synergie lorsque l'humeur de chacun est en baisse.
À mon avis, le facteur de leadership est la principale raison des salaires plus élevés, car il génère un énorme résultat à long terme pour l'entreprise et pour tous ceux qui sont autour du leader.
BTW, je n'ai eu que quelques expériences en tant que chef d'équipe (loin d'être un chef de projet!) Et autant je sais ce que fait un leader, autant de travail que je réalise que je dois faire.
Edit: J'ai oublié de souligner: les compétences en communication ne sont pas un point fort pour la plupart d'entre nous, mais sont un must pour un leader. En outre, je voudrais partager un très bon article sur Coding Horror, concernant les bons programmeurs et les compétences en communication -> http://www.codinghorror.com/blog/2011/02/how-to-write -sans-écriture.html
Dans de nombreuses professions, une compétence de base est la capacité de vendre quelque chose. Et pour vendre quelque chose, vous devez vous vendre. Vous avez besoin que l'acheteur vous fasse confiance et apprécie le produit ou le service que vous fournissez autant que vous le souhaitez. Cette compétence est entièrement transférable aux négociations salariales.
Je pense que toute votre base pour cette question est défectueuse.
La direction doit être mieux payée que ses subordonnés. L'ancienneté dans une entreprise est généralement basée sur le salaire, et il n'y a aucun moyen pour un employé subalterne d'avoir les moyens de commander ses seniors.
Diriger des personnes est une compétence spécialisée. Tout le monde ne peut pas être chef de projet (PM). La tâche est de plus en plus difficile à mesure que le nombre d'employés augmente. Dans un rôle technique PM, le PM doit avoir une bonne compréhension de la technologie pour diriger efficacement - sinon ils n'auront pas le respect et le soutien de leur subordonnés.
Pensez-y de cette façon, le nombre de managers qualifiés est inférieur au nombre de programmeurs qualifiés, donc les managers sont plus "précieux" pour les entreprises.
Cela dépend de la façon dont vous définissez la "difficulté". Même si, je me demande si vous savez ce qu'est la gestion de projet et ce que les analystes commerciaux devraient faire. J'ai lu beaucoup de frustration dans votre question, donc je pense que vous avez de mauvaises expériences. Néanmoins, je veux essayer de répondre à votre question.
Les chefs de projet et les analystes commerciaux sont généralement "plus âgés" lorsqu'ils occupent ces postes. Lorsque les développeurs commencent leur carrière très jeunes (environ la vingtaine), la plupart des chefs de projet et analystes ont près de 30 ans (ce qui crée déjà une différence de paiement rien que par l'âge). Ce sont également ceux qui font face à l'exposition des clients, ce qui signifie qu'ils doivent voyager sur place, passer des heures de torture pour écouter le client (en particulier lorsqu'un projet tourne mal) et inscrire leurs souhaits/besoins. Ils doivent faire attention à ce qu'ils promettent et surtout dans quel domaine (délai de livraison). Même si, selon vous, ce qu'ils font n'est que de la documentation, les analystes commerciaux sont formés pour analyser les besoins de l'entreprise et les chefs de projet veillent à la planification des projets.
Ils agissent comme un pare-feu entre le client et les développeurs. Une perspective technique est quelque chose de différent d'une perspective de vente. La plupart des analystes commerciaux et chefs de projet sont également confrontés à une grande variété de clients - ils sont exposés et ont donc des "leads". Leur réseau est composé de décideurs et, par conséquent, les entreprises préfèrent garder les personnes ayant de tels réseaux à leur portée; après tout, une vente est une vente.
Concernant la difficulté? Lancer une entreprise, avoir dix développeurs et essayer de gérer un projet. Le mal de tête est fourni gratuitement. Faites-le pendant un an, puis réexaminez votre réponse. Pour les BA? Optez pour une telle opportunité. Asseyez-vous avec des clients qui ont une machine AIX de 1974 et le concepteur de ce système est mort/retraité/mourant/alzeheiming et le développeur doit savoir si une certaine valeur est générée ou a une formule mystique. Essayez de convaincre 20 personnes avec un PowerPoint de votre solution dans un délai de 3 jours. Si la documentation était aussi simple, Linux aurait déjà dominé le monde en 1997. Vraiment, essayez d'écrire un livre blanc technique tous les mois pour les personnes non techniques (celles qui pensent que Facebook est une révolution dans l'informatique).
Je suis ingénieur commercial. Ce qui veut dire que je développe mais ma spécialité est pour les prototypes et les démonstrations. Et je gagne plus qu'un analyste d'entreprise ou un chef de projet. Non pas parce que j'ai un réseau (j'en ai, cependant), mais parce que j'ai quitté l'attitude et que je me suis davantage concentré sur la perspective commerciale, je me suis certifié et j'ai appris quelques compétences générales. Et l'expérience d'apprendre que "non" est aussi une réponse, quand il s'agit d'heures supplémentaires.
Réponse simple: Ils sont plus précieux pour l'entreprise que les programmeurs.
Pourquoi? Parce qu'ils s'assurent que les projets sont terminés, même s'ils ne font pas eux-mêmes la programmation. Cela signifie que leur valeur (purement monétaire pour l'entreprise) est plus qu'un simple programmeur. La société ne croit pas que les programmeurs non gérés soient productifs, et donc précieux ... C'est seulement le gestionnaire qui les rend ainsi.
Suce, et nous ne l'aimons peut-être pas, mais c'est pourquoi l'entreprise les paie plus.
Leur position (comme d'autres l'ont souligné) présente cependant des inconvénients: s'ils ne parviennent pas à terminer un projet avant un certain temps, c'est leur faute, pas les programmeurs. Ils assument plus de responsabilités et sont hautement susceptibles d'être licenciés pour échec (à moins qu'il y ait un népotisme de la société BS en cours).
Donc, vraiment, ils ne sont pas autorisés à faire des erreurs, à avoir plus de pression sur eux et à avoir un travail beaucoup plus volatil ... mais ne vous y trompez pas: Ce n'est pas pourquoi ils sont payés plus - une entreprise ne donne pas le cul d'un rat à la pression que vous subissez, à la volatilité de votre position, à quelque chose comme ça. Ils se soucient seulement de la valeur que vous apportez à l'entreprise. Période.
C'est du capitalisme, les amis.
Je ne sais pas combien de fois les connaissances du diagramme de Gantt doivent être mises à jour en un an. Mais en faisant de la programmation, vous devez vous mettre à jour avec de nouvelles technologies qui ne seront pas aussi faciles avec votre âge.
Apprendre une nouvelle technologie a besoin d'heures de transpiration, si vous êtes assez intelligent pour absorber.
La compétence acquise au cours des années de programmation n'est pas très valorisée dans la culture d'entreprise actuelle.
Comparer le salaire des programmeurs nouvellement diplômés à celui de plus de 10 ans d'expérience est une histoire un peu triste.
En comparant un nouveau PM avec 10 ans PM est une grande histoire, le PM pourrait devenir directeur après 10 ans de expérience.
Alors pourquoi tant de gens veulent-ils encore apprendre l'informatique à l'université? Je ne comprends pas. Sont-ils correctement informés?
Je ne comprends pas comment les gens apprécient la compétence de nos jours.
La direction ne gagne pas toujours plus que le personnel d'ingénierie. Le personnel d'ingénierie de niveau supérieur devrait être activement impliqué dans l'analyse et la prise de décision au niveau de l'entreprise et dans l'élaboration de la feuille de route technique pour l'entreprise. Lorsque c'est le cas, le personnel technique senior peut gagner beaucoup plus que les chefs d'entreprise avec lesquels il travaille au quotidien.
L'un des mythes populaires de l'entreprise est que le gestionnaire devrait être payé plus que les personnes qu'il gère. OMI, vous trouvez cette notion plus profondément ancrée dans les buracracies que dans les équipes fonctionnelles et agiles.
Autrement dit: la rémunération est censée refléter la valeur de la contribution d'une personne à l'entreprise. Il y a des chefs d'entreprise stellaires et des gestionnaires moyens, et il y a des ingénieurs stellaires et des ingénieurs moyens. Si vous avez un ingénieur stellaire qui lance une technologie rentable et qui a une connaissance approfondie des technologies de l'entreprise, n'est-il pas dans l'intérêt de l'entreprise d'indemniser cette personne de manière plus agressive qu'un chef d'entreprise moyen qui gère cet ingénieur stellaire? Quel est le coût d'opportunité de perdre cette expertise et ces compétences en ingénierie parce que vous avez négligé cette précieuse ressource?
J'ai commencé il y a un mois avec mon premier projet en tant que PM. Avant, je travaillais comme programmeur. (au fait, je reçois le même argent qu'auparavant.)
J'ai découvert qu'être un bon PM signifie être un bon programmeur avec une vaste expérience. Vous devriez pouvoir passer d'un membre de l'équipe à un autre et discuter des problèmes qu'ils ont en utilisant votre expérience pratique pour aidez-les à comprendre les problèmes en leur offrant un point de vue différent. Votre tâche est, entre autres, de gérer les interfaces. A PM est comme un chef d'orchestre. Vous pouvez avoir les meilleurs musiciens mais si vous n'avez pas un bon chef d'orchestre qui sache bien jouer de l'orchestre de méta-instrument, vous obtenez seulement un gâchis.
L'homologue est le spécialiste. C'est le programmeur qui est capable de résoudre des problèmes difficiles car il a une connaissance approfondie du domaine du problème. Ces personnes expérimentées sont souvent aussi bien payées si elles sont assez bonnes en négociation. Malheureusement, les spécialistes sont souvent des nerds et peu intéressés par l'argent ou bien pour faire une bonne affaire ...
Pour les mêmes raisons qu'un PDG peut gagner 263 fois autant que son travailleur moyen.
Ce n'est pas toujours le cas. Lorsque je travaillais pour Computer Sciences Corporation (CSC), la plupart des managers gagnaient moins que les "personnes qui ont produit quelque chose d'utile". Dans le cas de CSC, je pense que c'était le cas parce que la société avait été lancée par un groupe de programmeurs.
À l'époque (1970), il y avait une autre société de logiciels à LA dont j'oublie le nom avec un barème de salaires intéressant. Les programmeurs ont été payés 25 000 $/an et le personnel de soutien a été payé 15 000 $/an. L'idée était que si vous étiez le pire programmeur là-bas, vous ne devriez pas être surpris d'être remplacé.
J'ai ma propre petite entreprise de logiciels et je suis à la fois programmeur et chef de projet, je peux donc vous donner les deux points de vue.
Votre hypothèse initiale n'est pas vraie. Permettez-moi de l'écrire:
Gestion de projet et analyse de logiciels =
Créer de la documentation ou même créer un diagramme de Gantt et demander des progrès aux programmeurs.
Si vous pensez vraiment que c'est tout ce qui concerne la gestion de projet et l'analyse de logiciels, il n'est pas étonnant que vous pensiez que la programmation est plus difficile.
Mais c'est une façon ridicule, injuste et non réaliste de définir ces professions. Il se concentre uniquement sur les aspects visuels, comme s'ils ne donnaient pas de valeur.
Que pensez-vous de cette autre définition?
Programmation =
Assis devant un ordinateur et les touches de frappe.
Si la programmation est définie comme ça, PM & SA semble beaucoup plus difficile, même selon votre définition (qui n'est pas correcte).
Ces professions sont mieux payées car elles sont en effet plus difficiles que la programmation.
- Ils impliquent de traiter avec personnes, pas avec des machines. Les gens sont beaucoup plus difficiles à travailler avec, étant donné leur nature non déterministe. Le sous-ensemble appelé clients est particulièrement gênant.
- D'autres l'ont dit, mais permettez-moi de le répéter: responsabilité. Si un programmeur se trompe, c'est au PM de résoudre le problème. Pas seulement de le signaler, à résoudre de le résoudre. Cela peut impliquer de retarder un lancement de 2 semaines. Ou sauter une fonctionnalité.
- La quantité de tâches multitâches PM doit généralement être stupéfiante. C'est un exercice constant d'équilibre entre l'équipe, la direction, les clients et le budget. C'est pas facile.
- Cela implique également la communication "dans l'autre sens" - Non seulement le programmeur doit faire rapport au PM sur l'état; le PM est en charge de communiquer correctement attentes, risques et objectifs. Dans certains cas, ils sont également chargés de la formation.
- Ai-je mentionné de traiter avec des clients?
Si les chefs de projet avec lesquels vous travaillez ne font que des powerpoints, ils ne font pas leur travail correctement. Et c'est triste.
Je pense que vous ne comprendrez pas vraiment pourquoi les chefs de projet gagnent plus que les programmeurs jusqu'à ce que vous rencontriez un bon chef de projet.
Très bien, je suis légèrement surpris par les réponses, alors voilà. Mais avant cela, je voudrais juste préciser que je suis programmeur et qu'il n'y a rien que j'aime plus que la programmation. Cela dit, j'ai un respect et un respect sains pour PM et BA compétents . Je me rends compte que beaucoup d'entre nous ne sont pas satisfaits des PM et des BA car contrairement à la programmation, il est possible d'Exceler sans les requis niveau de compétence (politique de bureau, costumes sympas, etc.).
Cependant, la gestion de projet et l'analyse commerciale sont des composants critiques du développement logiciel.
Chaque fois que nous pensons au développement de logiciels, beaucoup d'entre nous ont tendance à se concentrer uniquement sur la programmation à l'exclusion de tout le reste. Pourtant, il y a plus que du codage.
Premier objectif du développement, qui est de créer un logiciel qui traite et résout réellement les problèmes des clients. Cela implique d'abord de déterminer réellement les exigences du client (car le client peut ne pas être vraiment sûr de ce qu'il veut), cela n'est possible que par une analyse détaillée du domaine dans lequel le client opère et de la structure des divers artefacts (qu'il s'agisse de personnes, d'infrastructures techniques). ou développer), puis développer une solution commerciale appropriée (et son intégration avec la technologie) pour répondre à ces exigences.
De même tout projet de taille significative absolument ne peut fonctionner sans une gestion efficace. Maintenant, je ne sais pas comment cela se passe dans d'autres endroits, mais jusqu'à présent, mon expérience a été que les PM sont généralement promus dans les rangs des programmeurs, donc ils ont une idée de ce qu'il faut pour organiser et exécuter le projet.
Pour résumer, les BA et les PM sont couche d'abstraction au développement .
Les programmeurs n'accordent pas la priorité au salaire (en supposant qu'il soit à un taux raisonnable.). Imaginez deux offres d'emploi où l'une a un salaire plus élevé, un engagement en même temps, mais nécessite un support technique, des heures d'ouverture strictes, un code vestimentaire, la rédaction de la documentation utilisateur, la gestion du code hérité dans une langue archaïque que vous espériez ne jamais avoir à utiliser à nouveau, comment beaucoup plus de salaire auriez-vous besoin?
Si vous travaillez pour une entreprise qui respecte la programmation, les mathématiques, la résolution de problèmes, quelles que soient les compétences, vous pouvez gagner plus pour deux choses:
- Faire un travail plus difficile
- Prendre plus de responsabilités
Ce n'est pas parce qu'un hôpital ne paie pas beaucoup son DBA qualifié (voir l'exemple dans la première réponse) que c'est la même chose dans chaque entreprise.
Beaucoup de gens ont dit ici que la programmation est plus difficile et c'est pourquoi elle devrait gagner plus. C'est une vue très romantique. La vérité est que, dans une entreprise normale et saine, le le paiement est fonction de la responsabilité, cela signifie pour le valeur ajoutée de cette personne et aussi le risque.
Le risque sera souvent oublié. Normalement, si le programmeur échoue dans son travail difficile, il peut y avoir une augmentation des coûts, mais rien de plus. Pas comme 10% des travailleurs perdront leur emploi ou quelque chose comme ça. Le risque est assez faible.
Je veux également être en désaccord avec l'idée que la plupart des gens d'affaires gagnent plus. Je parie que l'homme d'affaires normal gagne moins que la plupart des bacheliers en sciences/ingénierie. Par exemple, en tant que codeur de vacances de premier cycle, j'ai gagné presque la même chose que certains employés à plein temps dans la même entreprise.
Enfin et surtout, pourquoi le chef de projet n'est-il pas ingénieur? Normalement, le chef de projet est un gars avec de nombreuses années à l'avant dans le sujet du projet qu'il gère, ce qui signifie que dans les emplois de programmation, ce sera un programmeur expérimenté qui sera le chef de projet.
Il existe des environnements d'entreprise dans lesquels le modèle de commande et de contrôle ou le hub - le modèle de communication à rayons domine. Dans ces organisations, le gestionnaire et le communicateur en chef sont souvent la même personne. Cela rend le gestionnaire n seul point de défaillance - tous les effets lamentables des mauvaises communications ou des pertes de traduction sont amplifiés. Par conséquent, ces environnements nécessitent des personnes possédant une vaste expérience technique en tant que gestionnaires pour garantir l'exactitude.
Des équipes mieux organisées désignent généralement un communicateur en chef pour se décharger de cette responsabilité. Les organisations qui pratiquent gestion des connaissances n'ont pas un seul point de défaillance en communication. Dans ces organisations, les gestionnaires et les principaux communicateurs sollicitent des informations et facilitent les discussions. Ces informations seront saisies et traitées pour un partage interne. Un ensemble différent de compétences sociales est requis.
De même, les analystes commerciaux sont souvent le point de contact unique entre les clients et le personnel technique de l'entreprise.
Vous pensez que votre langage/compilateur est capricieux? Les gestionnaires traitent avec des compilateurs d'état complexe conscients appelés programmeurs, et les bons gestionnaires les amènent même à produire des logiciels.
Sérieusement, j'aime la réponse widget factory vs film school, qui je pense est probablement la meilleure réponse dans le fil, mais il y a une discussion au niveau méta qu'elle ne traite pas vraiment: peu importe le type d'organisation que vous construisez, vous '' reconstruire une organisation à partir de matériaux aussi capricieux que personnes, et c'est un travail qui est souvent difficile à bien faire. Vous pouvez faire un argument solide selon lequel il est étrange que ces positions paient souvent mieux que ceux du programmeur quand une bonne partie des analystes et des PM et PHB ne font pas du bon travail, mais le fait est qu'il est un travail qui implique de créer des organisations qui font avancer les choses, et c'est un ensemble de compétences qui est sans doute plus difficile à maîtriser que de créer des systèmes logiciels qui font avancer les choses.
Les analystes commerciaux et les chefs de projet ont davantage accès aux responsables de la chaîne. C'est la principale raison pour laquelle ils peuvent être payés plus. Pas tous. Il existe également des organisations qui paient très mal pour les analystes commerciaux, mais elles risquent un taux d'échec très élevé en raison de la forme de bogue la plus coûteuse - un bogue lié aux exigences.
Les programmeurs qui démontrent la capacité de rassembler efficacement les besoins de l'entreprise et/ou de gérer un projet sont payés plus que les trois choix que vous avez énumérés. Il est important de se rappeler que les services techniques sont au service des besoins de l'entreprise dans la plupart des organisations et que les gens ont tendance à faire confiance et à valoriser les personnes qui, selon eux, comprennent leurs besoins.
La gestion des personnes est plus difficile que la gestion du code. Et les bons gestionnaires ont la capacité unique de trouver de bons programmeurs.
en général, les chefs de projet doivent voir le tableau général tandis que les programmeurs ne font que leur propre tâche spécifique,
vous pouvez gérer une entreprise Web réussie avec des programmeurs moyens mais rarement avec des gestionnaires moyens
si vous êtes un manager, vous devez faire les calculs financiers, vous devez travailler sur les questions de personnel et de confiance, avoir votre mot à dire sur les questions de recrutement, etc.