作者:winter
链接:https://www.zhihu.com/question/19995922/answer/138897200
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

讲真,那些用代码数、bug数什么的当指标的,你们真的觉得每个bug都是一样的?至少乘个优先级啊(虽然也不对),而且代码和bug这么灵活的东西,可以做的文章太多了,比如微信扫码功能挂了,开1个bug也就可以描述了啊

其实我经历的各厂,包括我自己带的团队的时候,考核方式基本都是披着KPI皮的OKR。

说道OKR这个东西,其实挺诡异的,说白了就是管理者把制定量化指标和衡量的工作也下放,比如说我说今年研发效率提升50%,看上去特别的可度量,但是实际统计口径最后是我自己出的。换句话说,在OKR考核下,我要做的事其实是“吹个牛逼让老板觉得牛逼,并且最后证明我做到了(并不一定实际做到)”。目前来看,因为研发过程的极度复杂性,还没有找到更好的做法,这比统计代码量、bug密度之类的鬼东西靠谱太多了。

当然作为这个问题的答案,只说到要用OKR的话,基本等于啥都没说。后面说正经的,量化这件事,考核研发人员的指标,总体方向其实非常明确,一是产出,二是质量。

研发人员的产出的认知,又有几个流派,比方说有的leader认为研发的产出是业务结果,业务结果衡量的主要标准就是规模和收入,按照普遍认知的逻辑,UV啦、PV啦、转化率、在线时长什么的都是可以视为业务结果的考核,虽然目前行业对这个业务数据的认知比较粗糙,但是基本也可以凑合用了,这个流派优点是结果比较容易考核,更重要的是它和投资人/公司高管的认识是一致的,所以这么定KPI/OKR可以确保管理责任最小,缺点就是商业逻辑其实本身就很复杂,一个业务结果涉及的太多了,容易产生大牛选了坑的业务,或者小白跟着坐车的事,而且大部分公司研发人员都没什么自己选业务的机会。另一个流派是认为研发的产出是产品,这就比较麻烦了,以产品产出来考核,重点是产品的实现难度,这又是一个几乎没法量化的东西,所以这个流派,往往产出这块的判断也是凭借主观感受。这个流派与前一种其实无分对错,都是比较主流的思考方式,我个人倾向于一,但也不认为二有问题。至于认为研发的产出是代码,数行数或者字符数的leader,我只能呵呵了。

质量这块,量化难度太大,但也不是完全没法量化,它有一部分是可以量化的,在我看来,质量可以分成三部分:


  • 代码质量:代码本身的质量决定了对后续开发的友好程度

  • 研发质量:研发阶段产生的bug

  • 运维质量:产品上线以后的故障情况和资源消耗情况

其中,第一类,我认为没法量化,我的做法是不考核,只作为努力提高的方向和主观考核依据,因为它产生的成本可以通过自己后续的努力重构来弥补,原则上应该谁挖的坑谁填(这样还是会有问题,可能导致"透支",即坑越挖越大最后人跑了留下个烂摊子,但我没找到更好的办法了,摊手)。第二类,很难用bug数量来衡量研发质量,所以这块我比较倾向于用红线的形式来考核:冒烟bug、build break、低级bug和regression做记录,其它bug视为正常研发中的沟通。第三类我认为是可以量化的,通过线上服务器消耗、故障恢复时长等来做考核,这种考核的优点同样是投资人和老板看得见,不需要担心指定的KPI偏离了大方向。

总之呢,技术管理这事其实挺复杂的,现在这个发展阶段,很多问题都没答案,我觉得我能给的最重要的建议是“不要瞎搞”,宁肯全用主观评价,也不要引入错误的量化指标。



作者:winter
链接:https://www.zhihu.com/question/19995922/answer/138897200
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。



本文版权归作者,欢迎转载,但未经作者同意必须在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。