为什么业务分析师和项目经理的薪水比程序员高？ [关闭]

#1 楼

作为一个班级，项目经理的薪水是否比程序员和业务分析师的薪水更高，这完全取决于您所生活的软件世界。

这个问题的简单答案是“因为在我们的社会中，我们仍然认为薪水与层次结构中的职位有关。”但是，这个答案虽然反映了人们根据其感知的价值获得报酬这一事实，但这并不能解释为什么PM和BA在许多软件组织中处于层次结构的顶部，以及为什么管理层首先将层次结构作为选择的结构对于软件项目团队。这是两个似乎值得提出的问题。

广义上讲，有两类软件制作组织。我将它们称为“小工具工厂”和“电影摄制组”。

小工具工厂诞生于管理学派，围绕着动机由麦克格雷格（McGregor）提出的理论X：员工懒惰，需要持续的控制和监督，工作是经理们以薪水支票名义持有，总是能够将其下属的工作做到更高或至少相同的标准。这种想法落在了一个很自然的想法上，那就是整个团队可以很容易地由经理代替并由其代表-团队中的所有其他人都是可以轻松替代的，或者仅仅是为了增强经理完成任务的能力。因此，层次结构是一种结构，而是横向的工作角色。

小部件工厂管理的假设是，可以通过在结束时运行的明确定义的流程，根据业务分析师制定的规范来制造软件。项目经理的监督。通过为项目配备足够的合格但可互换的编程和测试资源来照顾制造。工作由PM和BA编制的初始业务案例根据预先安排的预算来驱动。

只要关注这些人的交谈方式，就可以轻松地发现运行Widget Factory的管理人员。它们可能涉及以下方面：资源（包括指代团队成员时），流程，运营效率，一致性，可重复性，对资源使用的严格控制，明确的工作角色以及定义的流程输入和输出。在尝试传达理想软件开发操作的图像时，他们会随意提及实际的工厂隐喻。

然后是Film Crews。他们基于这样的观念，即人们聪明，有上进心，非常努力地工作，并且喜欢孩子们喜欢玩的游戏。电影摄制组认识到，由于专业化，个人贡献者的能力可能远远超过组织，协调和指导工作的人的能力。由于经理不能再替代所有人，所以层次结构不能很好地发挥作用-人们必须以更加扁平和复杂的形式进行合作才能完成工作。乔布斯角色本身往往更加垂直-从头到尾-涉及到各种各样的技能。这种管理思想是由麦格雷戈（McGregor）的理论Y支撑的。并帮助团队凝聚和合作。她的职责是激发，捍卫愿景，提供指导并集中精力。每个人都很重要，因为“主管”相信软件是世界观和所有参与者的能力相结合的结果，也是该小组共同开展工作的独特方式。每个人从一开始就认识到让明星加入团队的重要性–明星表演者增加了获得成功的机会。愿景推动预算并吸引资金。

当涉及到补偿时，Widget Factories认为，最大的价值来自项目经理和业务分析师的工作，他们工作在层次结构的顶部，必须相应地得到补偿，团队的其余部分并没有那么重要只要他们具有将要求转换为工作代码的正确资格。 PM和BA努力通过限制团队其他成员自由访问项目信息源来保持自己的地位。在没有正式访问主要信息源的情况下，团队很难做出任何价值判断或提出好的解决方案，程序员只能从上面接受命令，并按照PM和BA的定义来解决问题。这种情况进一​​步强化了Widget Factory的观念，即程序员类似于工厂车间的工人，尽管技术上复杂，但能够机械地执行，但是仍然是标准任务。

与电影制片厂相比，Film Crew的作用更多。平均主义的形成;成员可以不受限制地访问主要信息，鼓励他们进行价值判断，并可以自由选择行动方案以实现并促进愿景。领导力结构基于能力而不是团队中的特定角色。薪酬反映出让特定人员参与该项目的可取性，它通常与人们对以下事实的认识有关：如果可以说服该人员将精力投入到创建该软件上，那么最终结果将变得更有价值。在这种环境下，项目经理的角色变得不太重要，因为他不太可能成为创意领导者。作用主要归结于行政支持和对外关系。业务分析师的职责部分被有远见的职位（我称她为她以前的“董事”）取代，部分由其他团队成员承担。

现在，大多数内部软件开发团队和一些咨询公司都是在小部件工厂依靠流程来生产一致无聊的软件的情况下运行的，这不足为奇。正是在这样的环境中，项目经理和业务分析员通常会获得比程序员更高的报酬，前提是他们认为，在相应构造的环境中能够带来最大的价值，这使得程序员难以证明管理是错误的。成功的软件公司倾向于采用Film Crew的观点，任何其他哲学都会阻碍他们吸引如此之多的人来生产出色软件的能力。在这种情况下，您不太可能会看到业务分析师的角色，而项目经理却没有那么出色，并且通常不会像优秀的程序员那样获得一般的报酬。

#2 楼

因为在我们的社会中，我们仍然认为工资与层次结构中的职位有关。

分析师或项目经理在层次结构中较高，因此应该给他们更高的工资。

让我告诉您一个真实的故事，说明为什么这是一个问题。


一个好朋友开始在一家大医院当程序员。由于他的辛勤工作和奉献精神，他迅速成为Oracle DBA，这在数据既敏感又有价值的公司中是至关重要的职位。

医院按层次工作。级别取决于您在层次结构，遗产和文凭中的位置。

我的朋友提出了一个建议，成为另一家不使用薪水级别的公司的DBA。他的薪水可以增加很多。因为他喜欢并尊重他工作的医院，所以他决定与老板交谈，要求加薪。

老板拒绝了。由于级别的原因，这是不可能的，工会也不允许这种情况发生。

我的朋友离开了。

医院最终雇用了外部顾问（不受级别限制），在他们的网站上发布了一份工作。该顾问对现有的基础设施一无所知，因此他的学习曲线很大。因此，医院损失了很多钱。

医院确实损失了很多。外部顾问的薪水是我朋友要求的五倍之多，他们找不到合适的员工来代替他。

差不多三年前。我的朋友仍然在他的新地方，并且按照自己喜欢的方式快速攀登等级阶梯。

医院仍然支付5倍的费用。


恕我直言，薪水应与您提供给公司的价值有关。

更新：在层次结构中上移时，会发生杠杆效应。因此，实际上，您为自己带来的价值而获得报酬。但是，无论他们在该层次结构中的位置如何（通常在最底层），生产力高出10倍的杰出程序员都应多付10倍的报酬。这就是我要强调的。

#3 楼

他们比程序员承担更多的风险。他们必须根据我们提供给他们的任何信息做出决定，然后在达不到他们的期望时面对利益相关者的严厉批评。部分薪酬待遇可以弥补这种风险。

另一个因素可能是准备可以适当计划，估计和缓解项目经理的经验。从某种意义上说，细致入微的项目经理会通过失败进行培训，这使其成为一项昂贵的技能。一旦达到资历级别，公司可能就不愿意放开这种有价值的人员。

编辑：

风险比财务或人身伤害还要多。例如，考虑被经理或客户谴责的风险。尽管没有造成任何实际伤害，但是我们仍然必须采取适当的行为以免发生这种后果，这仍然是不可取的。但是，管理人员必须始终做出良好的决策，并且必须根据公司的利益来平衡各种风险，而不是根据个人喜好。

#4 楼

从某种程度上讲，编程可能会更困难，但也更令人愉快。您只需坐在那里，解决漂亮的编程难题，而经理则要处理下属，客户，老板和利益相关者之间的各种杂物。这就是为什么很少有理智的人真正想要成为经理的原因，所以您必须支付更多的薪水来弥补这一点。

编程比较困难，但是管理却很麻烦。

认为某人对公司的价值的方法是想象该人离开公司后的情况。通常，从这个意义上讲，经理比程序员更有价值。 Java的创建者James Gosling最近离开了Oracle。有人可能会认为这是巨大的损失，但您猜怎么着？其实没关系。它对Java或Oracle几乎没有影响。狗吠，但大篷车在继续。

顺便说一句，我（认真地）认为dust夫和清洁工的薪水应该比程序员高。清洁别人的垃圾是一项艰巨且必不可少的工作。

#5 楼

减少管理工作以创建图表和编写文档就像在说编程是打字。

对每个人来说，但是对我来说编程比管理人员容易得多。

#6 楼

这里的每个人都专注于负面因素。我从未见过喜欢办公室政治的程序员，优秀的经理可以使您免受此类垃圾的困扰。在我们主要客户中与很多人进行互动之后，其中一半人精神错乱，我很高兴能有我的PM来为我吸收这种精神错乱。如果他们付了很多钱，那很好。他或她需要这种药物来进行不可避免的治疗。

#7 楼

当然，这是有争议的，但是背后的重要原因是，如果项目失败，他们将承担项目的责任，而不是程序员。他们可能会给您提早提起某些事情的机会，但是他们面临着更高权力的批评。他们负责计划和估算。

管理需要非常多方面的技能：人际交往能力，领导能力，估算成本和时间的能力。要做到这一切，他们还需要与您保持联系（例如，从技术上来讲，对您正在做的事情有所了解），或者成为非常好的品格判断者。

如果需求定义不正确是他们的错。

如果测试计划定义不正确是他们的错。

如果您去度假或断腿或浪费在星期六晚上或在没有给予足够通知的情况下离开，他们必须找到替换产品或<某些原因在这里>，您无法完成工作并且产品不能（按时或根本没有交付），仍然是他们的错。

还要注意，当我指的是他们承担责任时，它会影响他们上方和下方的人们。如果他们搞砸了，那可能就是您团队的工作即将开始。 PS：另外，我不知道我是否会说编程比做甘特图更难（重用您提到的示例）。我不了解您，但是我发现编程（通常，对于行业中需要完成的80％的工作）非常容易。如果弄砸了，可以修复它。如果您的老板搞砸了他的甘特图或成本估算，那么与将!= null转换为== null相比，这将是一个更大的问题。小错误对他们更重要。当然，大多数情况下，如果您在上线的嵌入式医疗应用程序中进行了类似的测试，那也是一个大问题。但是他们会比您遇到更多的问题！

#8 楼

供求是确定市场价格的经济模型。结论是，在竞争市场中，特定商品的单价将一直变化，直到达到消费者需求的数量（按当前价格）等于生产者提供的数量（按当前价格）为止。价格和数量的经济均衡。
供求的四个基本定律是：


如果需求增加而供应保持不变，则均衡的价格和数量更高。
如果需求减少且供给保持不变，则均衡价格和数量较低。
如果供应增加且需求保持不变，则均衡价格和数量较低。
如果供应减少且需求保持不变，则价格更高且价格更低数量。

在这种情况下，原因之一是开发人员过多。

#9 楼

在整个职业生涯中，我一直在开发人员和PM角色之间转换。我的项目开发人员的收入是我的两倍，其他人的收入是我的一半。高薪者得到的报酬是因为：
A）他们是“摇滚明星”开发人员。
B）他们与客户互动，以易于客户解释的方式解释产品
C）他们指导着从事多个项目的开发人员团队。
D）他们总是有空并且渴望取悦。

他们扮演角色开发人员，PM和BA的能力各不相同。通常，如果您将90％的时间花在降低代码上，那么您的价值就不会那么高，很容易被替换。如果您想赚更多的钱，那么您需要承担更多的责任...并且可能不得不寻找另一家公司，该公司将为您支付更多的费用。

#10 楼

理由是，项目经理的职责范围（通常）是在计划预算内按可接受的质量按时交付整个项目。通常会有很多钱危在旦夕，因此自然而然的优秀项目经理通常比程序员的薪酬更高。

但是，我不认为业务分析师的平均薪水比程序员高得多。我的感觉是，公司的薪水水平是由等级而不是由员工的价值决定的，这种情况越来越少见了。

#11 楼

我的经历可能有所不同（或者我生活在物理定律失真的不同宇宙中），但是我见过的大多数业务分析师和项目经理（不是程序经理，而是项目经理或PMP）的职位都处于或略低于

与软件工程师的平均工资相比，工资差距开始扩大（有利于软件工程师）。与高级EE或高级软件工程师相比，差距更大。几乎没有高级业务分析师或高级PMP会与高级EE或高级/主要软件工程师一样。

程序经理（与PMP不同）会比别人赚得多（原因应该很明显。）


当我看到这些关于薪水的抱怨时，最让我感到烦恼的是作为程序员（特别是初中/企业中的入门级程序员），我们（或不是）那么特别。刚离开学校的入门级程序员中，没有什么值得火箭科学家付薪的。不。

我们所有从事软件工作的人都从零开始。我们都做到了。

如果我们真的很诚实，我们很清楚我们不懂胡扯。能够完成我们的本科CS课程负载只是一个起点。它并没有使我们如此特别或ZOMG！超级爱因斯坦人。真的，不！

但是（由于互联网泡沫的不景气时期），我们希望不仅能赚到更多，而且比其他受过大学教育的人能赚得多因为OH WOW，我们是程序员，而他们只是业务分析师和PMP。

您能拼出自大吗？新闻快讯-对于企业中的大多数编程任务，您甚至都不需要4年制学位。真的很严重。

花费时间，积累从高级编程到软件工程（或相关工程）的经验。然后，您可以要求获得比业务分析师和PMP更大，更多，更多的收益。

付诸东流-我们中有些人（或曾经）被高薪。


搁置：业务分析师和/或PMP与尚未积累成为中高级软件所需的时间和专业知识的程序员接近或相似的工资的原因工程师（或尚未在高度需求的利基领域开发专业知识的工程师）：

业务分析师是软件和系统人员与业务人员/业务流程之间的联络人（这是证明它们是负责以有条理，分析的方式分解业务流程的人员，这些人员可以根据自己的需求来形成需求。他们确保您将大部分时间都花在编程上，而不是在处理业务细节。

许多人认为业务很简单。如果您真的认为这是真的，那么上帝会帮助您。

项目经理是负责处理多个项目的人（而您在任何给定时间最多只能处理一个或两个）。 ）他是你的保护伞，也是必须要做的肮脏工作的人，大多数其余未洗的群众都不想做-追赶人们，确保他们做好工作或消除工作上的障碍。

他会问你“你在做什么？你在做什么来帮助推进项目？你在工作中遇到问题吗？你遇到的障碍是什么？你需要什么？谁可以给你？给你吗？” ...

然后他会去找其他人问同样的难题，确保消除障碍，并确保自己在项目上占了上风（如有必要）。

第一大问题我曾在许多失败的项目中看到缺乏PMP或对PMP的不尊重（特别是对开发人员的不尊重）。我很少看到项目由于PMP不称职而失败，但是人们不得不怀疑为什么许多程序员都渴望超过就是这样。

评论

---

除了程序员不仅仅因为我们很特别（不比其他任何人）而要求大笔薪水，而是因为我们可以拿到他们而要求高薪。这不是真正的普通人才，需求量很大。

– David Thornley
2011年2月9日在20:45

---

@David-的确，这不是一个普通的才华……甚至在程序员中也不是。这就是我的意思。我们企业中的程序员过多（感谢dot-com和java / .net大学）。而且，企业上的许多编程工作还不够复杂，无法获得火箭科学的薪水。供求与更简单的需求（以及我们仍未大幅改进软件编写方式的事实）相结合，然后告诉我们，我们当中许多人都很特别（因为许多人没有或已经开发了这种稀有人才），并且因此，他们付出了高昂的代价。

–luis.espinal
2011年2月9日在21:13

---

@ luis.espinal：大多数人要求他们能获得的最高薪水。问题不在于他们是否拥有道德权利（是否有人在道德上享有比其他人更高的酬劳？），而是市场是否能够使他们得到。

– David Thornley
2011年2月9日在21:35

---

您的帖子过长，我在第一页之后停止阅读。

–匿名类型
2011-02-10 4:38

---

@Anonymous Type-下次我将尝试将其哑化。

–luis.espinal
2011-02-10 4:45

---

#12 楼

我从事金融业，我认为大多数非高科技企业的心态都相似：

薪酬与职业风险成正比

除非完全解雇某个团队或团队中，低级程序员始终保持工作。这是工作的性质，程序员充分了解他们承担的零风险是进入工作的。如果有错误，那不是他们的脑袋。

在更高的层次上，如果有东西弄坏了，那么您就是第一个去。我有一个下属，他犯了一个很小的印刷错误，导致我们赔了钱，所以我有很多经验，我为此付出了很大的努力（不是真正的程序员犯了错误）。

很简单，报酬与风险相称。从另一方面讲，程序员不一定在游戏中有任何皮肤。

#13 楼

如果您的问题是“为什么X和Y的薪水比我公司的程序员高”，我可能会回答“您可能在错误的公司工作。”

公司在软件方面的成功业务比其他任何人都更依赖于程序员的能力。与意识到这一点的公司相比，不认识这一点的公司自然处于劣势。雇用最好的程序员并照顾好他们是最好的选择。优秀程序员与其他程序员在工作上的差异是巨大的。比他们命令的薪水差异大得多。但是，如果您坚持不付给程序员低薪的薪水，您将得到所付的钱。

话说，业务中的所有其他角色都很重要。伟大的管理者产生了巨大的影响。其中很多是通过吸引优秀的程序员并使他们满意。关于业务分析，市场营销，销售，测试和支持，可以说类似的话。

如果您是一个优秀的程序员，但没有得到丰厚的回报，那么可以去其他地方。再说一遍，您可能不是一个优秀的程序员。不幸的是，如果您不是很出色，很难理解为什么。如果您知道为什么，那么您可以改变并变得很棒，对吗？

我曾经是一名程序员，而我曾经是一名人事经理。我曾与许多优秀的程序员合作，但只有少数优秀的经理。当我是经理时，我并不出色，但至少我知道。我的人民比我应得的加薪更多。

#14 楼

它与技能和工作关系不大，我的意思是经济上与人们应得的收入无关。

应当赚更多的钱只是一个短暂的想法，每个人都认为他们应该赚更多的钱。

尽管这可能不公平，但经理们赚更多的钱仅仅是因为业务业主更加信任他们。经理通常会获得更高的薪水，只是为了避免在不方便的时间突然找到新工作。

#15 楼

我认为您在此问题上的全部基础都是有缺陷的。

管理人员的报酬必须高于其下属。公司的资历通常以薪水为基础，初级员工没有办法指挥高层。

领导人才是一种专业技能。并非每个人都可以成为项目经理（PM）。随着员工人数的增加，这项任务越来越困难。作为技术项目经理角色，项目经理需要掌握有效地领导技术的知识-否则他们将不会得到下属的尊重和支持。

#16 楼

在许多专业中，一项核心技能是销售东西的能力。而要卖东西，你需要卖自己。您需要买家信任您，并尽可能多地重视您提供的产品或服务。该技能可以完全转移到薪资谈判中。

#17 楼

我遍历了每篇文章，我敢说大多数人都在尝试比较苹果和香蕉。

首先，我相信一个说“管理是小菜一碟”的人，除了自己的日程安排之外，别无他法。另一方面，说“任何人都可以编写任何代码”是愚蠢的（出于上帝的缘故，这是在错误的论坛上！）。

我特别喜欢rwong和luis.espinal asnwers，尽管我相信还有其他事实也需要引起注意。

我不相信等级制是一个答案-时至今日-尽管它在过去的10.000年中非常合适。我们在一个社会中生活了几个世纪，在这个社会中，您的利润越高，您的权力就越高（反之亦然）。我不认为这种方式适用于我们的世界（特别是在我们所在的地区）。

回到主要问题，我相信经理们通常会赚更多，因为他们更有价值对一家公司而言，不是因为他在层次结构上更高，而是因为他已经从以前的经验中学到了所有知识（通常程序员比一般的管理人员要少）。 >能够同时管理多件事情（程序员要完成一项任务或一个任务列表，而经理则必须管理自己的任务
他们是他们管理的项目的主要联系人原因是万一出了问题，他们是第一个“目标”。如果您是经理，更容易失业；
作为开发人员，您有“重做某些事情的许可证”。这就是“风险” '是每个人都提到的因素。
开发人员是整个项目生命周期的一部分。我相信，当我们在这里谈论“程序员”时，我们也在思考测试人员，技术作家以及其他对项目成功至关重要的人。
在这个主题的一些帖子中，我只有看到一些东西：领导力。成为经理将要知道如何与人保持联系，进行谈判，保持每个人的积极性，在每个人情绪低落时创造协同作用。

我认为，领导因素是高薪的主要原因，因为它为公司和领导层周围的每个人带来了巨大的长期业绩。

顺便说一句，作为团队负责人，我只有很少的经验（远不是项目负责人！），我知道领导者的工作，也知道我要做的工作。

编辑：忘了强调：沟通技巧对我们大多数人而言不是强项，但对于领导者来说是必不可少的。
此外，我想在Coding Horror上分享一篇非常好的文章，内容涉及优秀的程序员和沟通技巧-> http://www.codinghorror.com/blog/2011/02/how-to-write -without-writing.html

#18 楼

这样考虑，熟练的经理人数少于熟练的程序员人数，因此经理对公司更“有价值”。

#19 楼

这取决于您如何定义“难度”。即使，我想知道您是否知道项目管理的内容以及业务分析师应该做什么。我从您的问题中学到了很多挫败感，所以我认为您的经历很糟糕。不管怎样，我想尝试回答您的问题。

项目经理和业务分析师在担任这些职位时通常“比较老”。在开发人员的职业生涯很年轻的时候（大约20多岁），大多数项目经理和分析师的年龄都在30岁左右（仅按年龄计算，这已经在支付方面产生了差异）。他们也是面对顾客的人，这意味着他们必须到现场旅行，花费数小时的酷刑来倾听顾客的声音（尤其是当一个项目错了时），并征求他们的愿望/需求。他们必须小心自己的承诺，尤其是在什么范围内（交货时间）。即使从您的角度来看，他们所做的只是记录在案，但仍对业务分析师进行了教育以分析业务需求，并且项目经理在保护项目的计划。

它们充当了两者之间的防火墙。客户和开发人员。技术角度不同于销售角度。大多数业务分析师和项目经理也面临着各种各样的客户-他们暴露无遗，因此拥有“潜在客户”。他们的网络由决策者组成，因此，公司更希望将拥有此类网络的人员放在可及的范围内；毕竟销售就是销售。

关于难度？创建一个公司，有十个开发人员，然后尝试管理一个项目。头痛是免费提供的。这样做一年，然后再次查看您的答案。对于学士学位？争取这样的机会。与拥有1974年AIX机器的客户坐下来，该系统的设计者已死/退休/垂死/老年痴呆，开发人员需要知道是否已产生一定的价值或具有某些神秘的公式。尝试在3天之内说服20个人使用Powerpoint解决方案。如果记录是那么“容易”，Linux早在1997年就已经风靡全球。确实，请尝试每月为非技术人员（认为Facebook是计算领域的一场革命）编写技术白皮书。

我是一名销售工程师。这意味着我可以开发，但是我的专长是原型和演示。而且我的收入比业务分析师或项目经理还多。并不是因为我有一个网络（虽然我有），而是因为我放弃了态度，更加专注于业务视角，获得了认证并教了自己一些软技能。在加班方面，了解“不”的经验也是答案。

#20 楼

简单的答案：它们对公司比程序员更有价值。

为什么？因为它们可以确保项目完成，即使他们自己不进行编程也是如此。这意味着它们的价值（纯粹是对公司的货币价值）比单个程序员更大。公司不相信不受管理的程序员是有生产力的，因此也不有价值。...只有经理才能使他们如此。

很糟糕，我们可能不喜欢它，但这就是公司支付费用的原因他们更多。

他们的职位（正如其他人所指出的）有缺点，但是：如果他们未能在一定时间内完成项目，那是他们的错，而不是程序员。他们肩负着更多的责任，并且极有可能因失败而被解雇（除非存在某些BS公司的裙带关系）。

所以，实际上，他们不允许犯错误，对他们施加更大的压力他们，并且拥有更多不稳定的工作...但是不要感到困惑：这不是为什么他们会得到更高的报酬-公司不会给您带来巨大压力，压力如何波动你的位置是这样的他们只关心您为公司带来的价值。时期。

伙计们，这是资本主义。

#21 楼

我不知道一年中需要更新多少次甘特图知识。
但是进行编程时，您需要使用新技术进行更新，而随着年龄的增长，这将变得不那么容易。

学习新技术需要耗费大量时间，如果您足够聪明，就可以吸收。

多年编程工作中获得的技能在当前的公司文化中并未得到太多重视。

将新毕业的程序员的薪水与拥有10年以上经验的程序员的薪水进行比较是一个可悲的故事。

将一个新的PM与一个10年的PM进行比较是一个好故事，该PM可能会在担任董事后10年的经验。

那为什么还有那么多人想在大学里学习IT？
我不明白。是否已适当告知他们？

我不明白当今人们如何看待技能。

#22 楼

出于完全相同的原因，CEO的收入是普通工人的263倍。

#23 楼

管理并不总是比工程人员多。高级工程人员应积极参与业务水平分析和决策，并为公司制定技术路线图。在这种情况下，高级技术人员的收入比他们每天工作的业务经理高得多。

一个普遍的商业神话是，经理的薪水应高于经理的薪水。他/她管理的人。海事组织，您发现这种观念比实用的敏捷团队更扎根于公务员制度。

换句话说：薪酬应该反映一个人对公司的贡献的价值。有出色的业务经理和一般经理，也有出色的工程师和一般工程师。如果您有一位杰出的工程师来开发赚钱技术并且对公司的技术有深入的了解，那么与正好管理这位杰出工程师的普通业务经理相比，更积极地补偿这个人，这不是公司的最佳利益吗？由于您忽略了这一宝贵资源，失去工程专业知识和技能的机会成本是多少？

#24 楼

一个月前，我开始了我的第一个项目作为PM。在我成为程序员之前。 （顺便说一下，我得到的钱和以前一样。）

我发现，成为一名优秀的PM意味着成为一名具有丰富经验的优秀程序员。您应该能够从一个团队成员转到另一个团队成员，并使用您的实践经验来讨论他们所遇到的问题，从而通过提供不同的观点来帮助他们理解问题。除其他任务外，您的任务是管理接口。 PM就像导体。您可以拥有最好的音乐家，但是如果您没有一个很好的指挥家，他不擅长演奏元乐器乐团，那么您只会一团糟。

对方是专家。这是能够解决难题的程序员，因为他对问题领域有深入的了解。如果他们的谈判能力足够好，这些经验丰富的人通常也会获得高薪。不幸的是，专家们经常是书呆子，对金钱或对赚很多的交易不那么感兴趣。

#25 楼

程序员不会将薪水放在第一位（假设薪水合理）。想象一下两个工作机会，其中一个具有较高的薪水，相同的时间投入，但需要技术支持，严格的工作时间，着装要求，编写用户文档，以过时的语言处理旧代码，希望您再也不必使用了，您需要更多薪水吗？

#26 楼

如果您在一家尊重编程，数学，解决问题以及任何技能的公司工作，那么您可能会从两件事上赚到更多：


做更多的困难工作
承担更多的责任

仅仅因为医院没有向熟练的DBA支付太多费用（请参阅第一个答案中的示例），并不意味着每个公司都一样。

#27 楼

好吧，我对答案感到有些惊讶，所以就到这里了。但是在此之前，我只想澄清一下我是一名程序员，除了编程之外，我没有什么比我更喜欢的了。那就是说，我对合格的PM和BA具有良好的尊重和尊重。我意识到我们很多人都讨厌PM和BA，因为与编程不同，没有必要的能力水平（办公室政治，西装革履等）就可以在他们中脱颖而出。

但是项目管理和业务分析都是软件开发的关键组成部分。

每当我们想到软件开发时，我们中的许多人就会倾向于只专注于编程，而排斥其他一切。

开发的首要目标是创建一个实际解决并解决客户问题的软件。这意味着首先要真正弄清楚客户的需求（因为客户可能不确定自己想要什么），这只有通过详细分析客户操作的领域和各种工件（无论是人员，技术基础结构）的结构来实现或流程），然后再开发合适的业务解决方案（及其与技术的集成）来满足这些要求。

同样，如果没有有效的管理，任何规模较大的项目也绝对无法工作。现在我不知道其他地方的情况如何，但是到目前为止，我的经验是，PM通常是从程序员队伍中提拔出来的，因此他们确实对组织和执行项目需要什么有所了解。 >
总结一下，BA和PM都是开发的抽象层。

#28 楼

许多人在这里说，编程更加困难，这就是为什么它应该赚更多的钱。那是非常浪漫的观点。事实是，在正常，健康的公司中，付款是根据责任来进行的，这意味着该人的增加值以及风险。通常，如果程序员在难以完成的工作中失败，则可能会增加一些成本，但仅此而已。不会有10％的工人会失业或类似的事情。风险非常低。

我也不同意大多数商人收入更高的想法。我敢打赌，普通的商务人士的收入要比大多数理学/工程学士学位的收入少。例如，作为一个本科假期度假编码员，我的收入几乎与同一家公司的一些全职业务人员一样。

最后但并非最不重要的一点，为什么项目经理不是工程师？通常，项目经理是一个在他管理的项目主题上处于领先地位的人，这意味着在编程工作中，它将是一位经验丰富的程序员，他是项目经理。

#29 楼

在公司环境中，命令和控制模式或中心辐射型通信模式占主导。在这些组织中，经理和首席沟通者通常是同一个人。这使管理人员成为单点故障-错误沟通或翻译损失的任何负面影响都会被放大。因此，这些环境要求具有广泛技术背景的人员作为经理来确保准确性。组织更好的团队通常会任命首席传播者来减轻这一责任。实施知识管理的组织不会在沟通中出现任何单点故障。在这些组织中，经理和首席沟通者要求提供信息并促进讨论。这些信息将被捕获和处理以供内部共享。需要一套不同的社交技能。

同样，业务分析师通常是客户与公司技术人员之间的单点联系。

#30 楼

这并非总是如此。当我在计算机科学公司（CSC）工作时，大多数经理的收入都低于“创造有用的东西的人”。就CSC而言，我认为这是因为该公司是由一群程序员创办的。

那时（1970年），洛杉矶有另一家软件公司，我忘了这个名字有一个有趣的薪水表。程序员的年薪为25,000美元，支持人员的年薪为15,000美元。想法是，如果您是最差的程序员，那么被替换就不会感到惊讶。