这篇文章的话题是关于研发管理（Research and Development Management），不过我要说的并不是流程控制、质量把关等较为枯燥乏味的内容，而是关于困扰技术管理的根本问题，那就是如何有效的衡量研发工作所创造的价值以及如何更为高效稳定的管理开发工作。
我们经常用数据来进行一系列的考核，但考核的目的却不在于单纯的赏罚，而是要通过制度来调动员工的积极性，让他们能够创造更大的价值，从这个角度上来说，管理其实要做的是如何能够良好的把握人性并作出激励，所以本文也主要从这方面进行探讨而不过多涉及具体制度。
互联网行业是当今时代发展最快的领域，投身其中的人们自然也希望自己能够紧跟时代的步伐快速发展，如果公司的制度能够较为准确的衡量一个员工所创造的价值，并给予相应的升迁与奖励，那就能够符合大多数人的职业愿景，从而保证整个团队的战斗力与稳定性，相反如果只有定额工资，又或是制度流于形式，那人们就会觉得时代在发展而自己却止步不前，那员工的工作热情必然大打折扣，并且会对人员稳定性造成负面影响。
既然要做考核，那就要尽可能精准的把握每一个员工所创造的价值，但问题在于这个世界上总有一些东西是我们无法准确衡量其价值的，比如艺术与爱情、比如道德与生命，比如像梵高那样的艺术家是稀世的，但在他仍在世的年代里，他的作品却没有展现出太高的价值，如果梵高当时是某人的员工，那对这位BOSS来说雇佣他恐怕不是一件愉快的事情，也许这位艺术家是有才华的，但如果他一直不能将艺术转换为经济价值，那从投资的角度来说就是失败的，技术开发也是一样，虽然我们很难完全客观的去衡量技术工作的价值，但无论如何，如果不能有效的将技术转换为经济价值，那同样也是失败的，所谓经济价值说白了就是赚钱的能力，那就让我们尝试从这方面来衡量价值。
有人说，技术并不参与商业行为，怎么赚钱啊，但事实上，大部分互联网公司的商务成本投入是很低的，真正产生成本的重要部分都是在开发阶段，可以说虽然商务将项目拿到手了，但这钱装的是否踏实，还是要靠技术人员，所以让技术人员与项目金额直接挂钩是适合的。虽然从单个项目来看，因为项目金额的不同与开发难度差异，确实不易评估技术所做的贡献，但如果从月度或是更长一些的季度考核，通过多个项目的累计数据来评价技术的工作效率还是较为客观的，比如我们可以用该季度的“项目完成金额/技术开发成本”这样就可以轻易的对比出哪一个人或是哪一个团队的效率更高，如遇大型项目只需用该项目的阶段完成情况以及对应金额进行计算也能达到应有的效果。你说你做的好、水平高，但如果从长期数据来看你的工效却一直没有别人高，那我就有理由认为你还是不够好，或是你的工资有点高了。当然如果一个员工在公司的资历很久，对企业的综合贡献较大，那在计算的时候可以按照岗位级别进行适当加权，这样就更为公平合理。
懂得了如何衡量价值之后，那个雇佣梵高的老板就觉得不能只养梵高这种下蛋很慢的鸡了，所以他就养了一大群鸡，这样总有一些鸡是比较高产的，这样就可以用高效能鸡群来养着低效能鸡群，这就叫做成本覆盖，而这种模式也就是现在油画村的生存状态。又过了几天，老板发现附近也开了一个油画村，并且他们专门模仿一些世界名画，虽然每张都卖的很便宜，但是架不住人家产量大啊，所以销售额远远超过了自己，老板沉不住气了，开始让自己的画家也进行量产型绘画，甚至为了提高效率要求左右手同时画两幅画（这种画法叫做左右游龙），但他仍然保留了一部分有才华的画家进行自由创作，期望他们可以取得突破性成果，这样的经营方式其实就实现了模式化生产以及研发与生产的分离。
技术开发与艺术创作虽然看似是理性与感性的两个极端，但其实在很多方面是有相似之处的，就像绘画可以量产那样，生产型开发如果想要提高效率，那就需要高度的代码复用率，说简单点就是开发人员要能够熟练的COPY，再简单点说就是要会抄，不要觉得这是一件羞耻的事情，因为很多时候不抄不足以保证开发时间，甚至不抄不足以保证产品质量，君不见很多汽车发动机仍然采用的是N年以前的型号？为什么？因为这样会让产品更加稳定且便于生产，从而保证利润最大化。有的技术这时候要说了，抄谁不会啊，用你说？其实我要说的重点是，如何才能最大程度的提高开发效率，请耐心往下看。
我们来看一下一个常规项目的开发流程，需求整理，UE设计，UI设计，技术开发。那么在这四个环节中，如果产品经理非常了解自己的团队，熟悉团队以往的开发成果，那就可以最大程度的保证开发成果的复用率，比如他在对接需求的时候，就可以有意的向熟悉的功能方向引导，在UE,UI定稿的时候，就可以偏向于自己团队的开发习惯，而这些细节的积累产生的连锁效应是，同样的一个项目，开发的时间可以相差数倍（别不相信，很多人其实对模式化开发的力量一无所知），时间对于公司来说，这就是巨大的成本差异，就是利润空间的天壤之别，甚至就是生与死的距离。而要在这一点上做的好，就要求整个团队拥有良好的契合度，就要求团队领导人对自己下属的每一个人都非常的了解，知道每一个人的开发习惯，知道每一个人的能力所在，而这一切的基础是整个团队要有高度的稳定性，简单来说，就是除了无法避免的离职之外，开发人员不能随意调动，只要进了某个开发小组，那他就生是这个组的人，死是这个组的鬼。
如果说在团队开发中技术成果复用靠的是默契与了解，那在一个公司当中，全面的高效运作所要依靠的则是成型的产品，一个好的产品的价值并不仅仅在于它的功能、质量以及市场口碑，它很大程度上也决定着一个公司的生产效率，虽然需求的种类千差万别，但资深的技术都明白，就像盖房子用的水木砖瓦都相似那样，很多需求也都建立在基础功能模块之上，能够复用的地方其实非常之多，所以如果公司产品的模块化质量高，并能够定期在内部组织产品开发培训，那么就能让整个公司的开发效率上升一个台阶，并且能够为公司的产品品质与后期维护创造良好的基础条件。
与生产型开发有较大差异的是研发工作，研发这个词所代表的是无法明确的界定开发时间，甚至无法判断最终能否成功的工作。研发人员的考评可以参考行业内同等功能的开发成本，以及横向对比公司内部同类型岗位的阶段性开发效率，但最为重要的还是绝对的时间效率，在互联网这种瞬息万变的环境里，时间有时就是决定一切的根本，这就像是两军交战必须在某个时间拿下某个制高点一样，只要研发人员能够在既定时间内完成公司赋予的开发任务，达成公司的战略目标，那他就应该得到认可与奖励，虽然他完成的不是直接的商业项目，但他们所做出的贡献却有可能会对公司发展提供至关重要的推动力（可以借鉴美团的开发部与研究院的关系），但要注意的是，并不是任何一个项目都能够叫做研发，比如乔布斯所做的工作就是当之无愧的研发，而库克就更偏向于开发或生产。
对于工效的考评必须要准确落实到团队中的每一个人身上，绝不可以只考核团队领导人，因为这样会让有些人甘做短板甚至鱼目混珠，有人说，一个团队做的项目都一样，要么大家都完成，要么大家都完不成，考核个人有意义吗？我要说，当然有意义，首先一个团队中项目的完成情况并不相同，甚至所做的项目也未必都一样，比如说UE,UI都做完了，但是程序没做完，那就只能去追究后者而不能去考核前者，再如公司里其他团队需要技术支援，需要某个技术单独参与某项开发工作，那他必然会和本团队中其他人所做的工作有所区别，但无论他们做什么，也都必须由这个团队的负责人来进行统一调配而不能交于他人，因为如果一个士兵可以随意换将，那他就不会对任何一个地方任何一任领导保持敬意，也就无法做到令行禁止，也就达不到预期的工作效率，还是那句话，他生是这个团队的人，死是这个团队的鬼。
对人员的团队化管控不仅有助于增强团队凝聚力提高工作效率，同样也是对团队负责人话语权的重要保证，如果做不到这一点，就很难产生由中层力量为企业带来的巨大推动力，这就像是历代明君治理天下的重点是在于用人而不是亲力亲为。
最后再来谈一下团队稳定性的问题，任何一个互联网公司都不希望自己辛辛苦苦培养出来的，对公司产品了解程度很高的技术随意流失掉，但大多数公司却没有适合的措施来解决这一问题，其实最简单的办法就是制定相对公平合理的升迁体系和与之对应的级别与待遇，很多公司会给业务人员指定非常明确的级别与奖励方案，但对技术人员的管理就相对模糊与混乱，业内的很多公司甚至就靠面试洽谈来定薪，这样不仅不能良好的对员工的贡献予以考评，还容易伤害到老员工的感情，干的好不如面的好，这也直接造成了整个行业跳槽现象的盛行，其实如果新入职的员工并非行业资深人士或在某个领域获得过高质量的成就与奖项，那就需要他从基层做起，如果他的能力强，那他必然数据会好，升迁速度自然就快，如果按季度为节点来进行考核，那一年就有四次升迁机会，很快就可以达到他能力所对应的级别与待遇，只有这样，员工才会珍惜他在这个地方所付出的努力，并在新员工面前拥有较高的话语权，这样才能有助于员工产生归属感，从而增强团队稳定性。
但事实上要保证升迁与激励体系的正常运转，一方面取决于制定升迁制度的合理性，尽量保证每个级别都能够匹配公司所期望的员工价值，另一方面则要求公司具备一定的发展扩张速度，如果公司本身不成长，员工也就不可能健康成长，在互联网行业中，四五年就达到上市条件的不在少数，只要公司扩张的快，那对人员与管理干部的需求就永远处于不饱和状态，自然就有足够的提升空间，而谈到扩张，这也是之前谈到给予团队管理人员权限的另外一个关键之处，那就是在互联网行业中，很多得到过充分锻炼的中层其实都有能力为公司开疆拓土，最终促进整个企业的力量大幅增长，其实企业发展的一切都源于思想与格局。
就写到这里吧，闲谈之作，让大家见笑了。