程序员的收入是广受关注的问题，很多人从业3～5年之后就会遇到这个收入瓶颈。尽管物价不断上涨，程序员尤其是初、中级程序员的收入不升反降。即使上次在某个文章中看到有中国第一程序员之称的某位，月薪也只有3万，尽管这个数字已经很高了，但这个“中国第一”，也只有众多小型软件企业总监级别的收入而已。为什么这么高水平的技术人员在公司中的位置仍然显得与日俱降？本文会分析其中的原因，并依据原因给出相应的建议，为收入遇到瓶颈的程序员找到出路。
       要理解一个人能赚多少钱，先要理解钱的流转规律。对于程序员，总是认为若自己能力提升了，自己的收入就应该相应提升。不过，请先读一下任正非写给华为员工的邮件中的一段文字：
       因此，没有责任心，不善于合作，不能集体奋斗的人，等于丧失了在华为进步的机会。那样您会空耗了宝贵的光阴，还不如试用期中，重新决定您的选择。进入华为并不意味着高待遇，因为公司是以贡献定报酬的，凭责任定待遇。对新来员工，因为没有记录，晋升较慢，为此十分歉意。如果您是一个开放系统，善于吸取别人的经验，善于与人合作，借助别人提供的基础，可能进步就会很快。      从中可以看出，先要替公司赚到钱，承担责任，一个员工才能拿到钱。

    分析

      若一个程序员技术水平一个顶十个，在他替公司赚钱的道路上还有哪些障碍呢？典型障碍有很多，比如：

1. 这个程序员开发的功能中有50%客户不常使用

      因此，客户要么没有选择这个产品，要么只愿意付出更低的价格。“这怪产品经理啊，为什么怪我？”错。若赚到了钱，论功行赏的分配方法有很多；但若赚不到钱，分配方法就一种：大家都没钱。也就是在一家产品方向失败的公司，即使最顶级的程序员，也赚不到钱；或者说，他赚到的钱，可能还不如一个产品方向正确的公司的一个普通程序员。

2. 这个程序员开发的底层库中，有50%不被调用

      很多顶级的程序员都迷恋编写底层库，认为这才是施展技术实力的地方；他们多数不愿意参与业务级别的工作，认为工作过于简单还要和客户打交道。这时候编写出来的东西，经常会出现“需求镀金”，就是最终代码中充斥着大量的无用的功能。本人做过一段这种事情，所编写的一个库，可能几年后使用率也不超过一半。

      如果这两个问题不解决，我们表面上看到的看到的10倍的能力，真正能转化到生产力上的不足25%。公司的钱赚不来，个人收入低的问题也就很好理解了。

3.顶尖高手在公司内部的位置已经不再重要

      现在已经不是当年两个修自行车的能造飞机的英雄时代了。现在的软件很少像当年KV300、WPS一样可以由一个高手独立写成，多数都依托于一个十多人乃至近百人的大型团队。如果这个团队的整体实力很强，里边一个顶三、五个的程序员大有人在，那么单个的能顶十个的程序员贡献能有多大，就值得商讨了。

      在10年前参与的一家公司中，有一位自己躲在自己办公室的“扫地僧”，功力超过我们团队的最顶级的程序员还要数倍。不过，他却在独立开发一个与公司方向不符的小产品，由于他是老板的朋友，老板也执拗不过，就随他去了。几年后公司上市，不过是因为我们所在的25人团队的产品占据市场份额60%以上。毕竟这种规模的团队，如果技术和管理又能跟得上（这个团队就是本人第一次遇到松结对编程、139团队的那个团队），生产力不是一个两个游击队员能够相比的。如果不能把自己的能力转化为企业的盈利，收入就无从谈起。

   答案

     有了这两个分析，就不难得到答案，整体上分两个方向，最后我们再总结两个截然不同的方向的共同点。

     一个方向，是转向关注业务。具体说来，包括成为产品经理，或称为对产品需求负有责任的技术兼业务高手。

      为何产品经理的收入很高？三星刚刚重奖了GalaxyIII的产品经理，而腾讯、阿里的产品经理也久负盛名，而他们的所谓“高级程序员”一般都默默无闻。原因就是产品经理是“掌舵”的，不是“划船”的，他对团队生产力的贡献，不是加法，而是乘法。国内征途以几十人团队每年几亿的收入，腾讯以9千人超过中国电信5万人的营业额，国外Apple及FB的崛起，靠的不是技术高手的加法，而是产品经理的乘法。

      作为纯技术高手，可能直接转为产品经理很难，或者不愿意转，那么，至少要变成关心需求的技术兼业务高手。也就是不能只沉迷技术，而要关心是否正在开发客户关注的核心需求，业务实现是否有效、友好，与竞争对手定位于功能比较等内容。

      作为掌舵的人，更容易帮助团队把技术能力转化为生产力，提升绩效，也更容易获得更高的收入。

      第二个方向，是作为技术领导，将自己的技术与管理结合起来，提升整个团队的战斗力。

      技术高手作为团队的领导具有得天独厚的优势，毕竟软件管理是个复杂的过程，需要结合技术、团队、过程的各方面才能做好。

      比如设定这样一个目标：“促进团队的代码复用，以提升进度和质量。”个人参与过的几个项目都证明做好这件事情意义非比寻常，然而做好却很难。个别技术高手可以以1/4代码写出相同的功能，然而整个团队却很难做到，原因是缺少恰当的团队管理方法。而作为纯管理出身的项目经理，又不理解应该建立何种复用结构，如何分工。要让纯管理的人跨越技术壁垒是比登天，而让技术高手帮助进行管理则只是一念之间的事情（虽然也很难！）。

      如果一个高手，能够帮助自己身边的三、五个程序员提升水平，那么很容易再获得相当于几个人的生产力，这是他个人提升所很难再获得的。本人在十年前遇到一位高手，跟他学了一年，感觉自己提升了三四倍的水平（从完成任务所需的功能量缩减而言，何况还有技术、质量方面的提升），而身边另外几个师兄弟，也都长进迅速，有一两个甚至都超过了师傅的水平。除了传授技术之外，这个团队后来在这位高手带领下，还改善了管理结构，演进成为一个松结对和1-3-9团队，在不到一年时间从5人扩展到25人，而产品质量没有明显的下降，后来市场占有率更是达到60%以上。

      两个方向有一个共同点，就是把自己卓越的技术能力对团队的贡献，从加法变成乘法。高手必须认识到自己对团队和企业的最大贡献，不是自己独立承担的那点任务，而是影响产品和影响团队的能力。

最后一个常见问题：

      “我传授了徒弟，最后却被一脚踢掉怎么办？”这是很多技术高手所担心的事情。其实，老板都是很聪明的人，技术、管理、业务可能都一般，但识人、用人绝对超过我们，否则怎么会我们给他打工呢！一个高手如果被踢掉，更可能是因为沉迷技术逐渐变得钻牛角尖、封闭，最终变成无用之人。