对开发团队的人员进行绩效管理

kekek

4 f/ g/ E4 J& r7 u) O8 J( p其实我经历的各厂，包括我自己带的团队的时候，考核方式基本都是披着KPI皮的OKR。
* v+ X1 @) N8 j说道OKR这个东西，其实挺诡异的，说白了就是管理者把制定量化指标和衡量的工作也下放，比如说我说今年研发效率提升50%，看上去特别的可度量，但是实际统计口径最后是我自己出的。换句话说，在OKR考核下，我要做的事其实是“吹个牛逼让老板觉得牛逼，并且最后证明我做到了（并不一定实际做到）”。目前来看，因为研发过程的极度复杂性，还没有找到更好的做法，这比统计代码量、bug密度之类的鬼东西靠谱太多了。
当然作为这个问题的答案，只说到要用OKR的话，基本等于啥都没说。后面说正经的，量化这件事，考核研发人员的指标，总体方向其实非常明确，一是产出，二是质量。
% D2 f; V4 i% t1 C: P0 {研发人员的产出的认知，又有几个流派，比方说有的leader认为研发的产出是业务结果，业务结果衡量的主要标准就是规模和收入，按照普遍认知的逻辑，UV啦、PV啦、转化率、在线时长什么的都是可以视为业务结果的考核，虽然目前行业对这个业务数据的认知比较粗糙，但是基本也可以凑合用了，这个流派优点是结果比较容易考核，更重要的是它和投资人/公司高管的认识是一致的，所以这么定KPI/OKR可以确保管理责任最小，缺点就是商业逻辑其实本身就很复杂，一个业务结果涉及的太多了，容易产生大牛选了坑的业务，或者小白跟着坐车的事，而且大部分公司研发人员都没什么自己选业务的机会。另一个流派是认为研发的产出是产品，这就比较麻烦了，以产品产出来考核，重点是产品的实现难度，这又是一个几乎没法量化的东西，所以这个流派，往往产出这块的判断也是凭借主观感受。这个流派与前一种其实无分对错，都是比较主流的思考方式，我个人倾向于一，但也不认为二有问题。至于认为研发的产出是代码，数行数或者字符数的leader，我只能呵呵了。
8 A. x; H- Z% K1 h/ l3 r质量这块，量化难度太大，但也不是完全没法量化，它有一部分是可以量化的，在我看来，质量可以分成三部分：

• 代码质量：代码本身的质量决定了对后续开发的友好程度
• 研发质量：研发阶段产生的bug
• 运维质量：产品上线以后的故障情况和资源消耗情况
  & \7 g; x2 D' x' e* U) }

其中，第一类，我认为没法量化，我的做法是不考核，只作为努力提高的方向和主观考核依据，因为它产生的成本可以通过自己后续的努力重构来弥补，原则上应该谁挖的坑谁填（这样还是会有问题，可能导致"透支"，即坑越挖越大最后人跑了留下个烂摊子，但我没找到更好的办法了，摊手）。第二类，很难用bug数量来衡量研发质量，所以这块我比较倾向于用红线的形式来考核：冒烟bug、build break、低级bug和regression做记录，其它bug视为正常研发中的沟通。第三类我认为是可以量化的，通过线上服务器消耗、故障恢复时长等来做考核，这种考核的优点同样是投资人和老板看得见，不需要担心指定的KPI偏离了大方向。
  `6 C9 w: M9 x. L总之呢，技术管理这事其实挺复杂的，现在这个发展阶段，很多问题都没答案，我觉得我能给的最重要的建议是“不要瞎搞”，宁肯全用主观评价，也不要引入错误的量化指标。


1 I, g( e, d5 [. z# L

nkkopd

考核方式基本都是披着KPI皮的OKR