该怎么给程序猿定 KPI ？ 第1页

好问题。为什么要定KPI？

我认为定KPI的原因，是因为团队管理者并不清楚每个人具体的工作情况，所以借助KPI来量化。

为什么很难给程序员定KPI？

因为必须要一个足够懂行的领导，才能搞清楚每个程序员做了什么，做得怎么样，做的事情有多大价值。而事实上没有一个KPI能帮助程序员领导做到这一点。

如果一帮程序员的带队者没有足够的能力理解每个程序员的工作效果，那么就算定了KPI，也只会把事情弄得更糟糕。

再换句话说吧：AI或者冰冷的KPI数据，没有办法担当或者取代一个合格的程序员团队领导的职责，所以程序员没有办法定出KPI。

先问问自己：为什么要定KPI？

定KPI无非是一个核心目标，那就是通过“奖勤罚懒”来引导员工，使得他们努力工作——当然企业没有罚款权，因此一般会变通为“定一个较低的基本工资，其它算到奖金上；然后只有A级卓越奖、B级优秀奖、C级合格奖和D级无奖”。说白了还是一回事，朝三暮四的把戏而已。

然后呢，怎么识别勤快/懒惰的员工呢？

很简单，计件。A一天装配了10个轮胎，B只装了8个，C只有6个，D装了3个还歪了一个……

那么，如果单件工资是X的话，给A的报酬就应该是10X，B是8X，C 6X，D 2X。

很遗憾。这个看起来天经地义一般的解决方案是傻子才会搞的——如果你发现手下有个管理者这样管生产线工人，嘉奖他；但如果他这样管技术类工种，请尽快撤他的职。

这是因为，技术类工作，产出是独一无二的。压根不能像流水线工人那样评估。

甚至于，技术类工作，产生的“量”和“质”往往是背道而驰的。

当你只顾考察他的量时，你只能得到一堆垃圾——而且技术类成果会有很多很多的衍生效应，比如会造成其它同事工作对接困难、比如会导致本来普通计算机10%CPU占用就能搞定的工作你得掏大钱砸几十上百台电脑进去搞一个集群……

但在你眼里，后者玩的那可是集群！高科技！而前者嘛……一个512M内存的破机顶盒级电脑有什么好玩的！

很遗憾。前者那才是真正的高科技。那叫算法优化。

后者嘛，那叫一将无能，累死千军。

这并不是笑话。我就遇到过这样的神人。他把一个大型交易系统的数据库查询复杂度“优化”到了O(N^3)级别——但实际上给真正懂行的技术人员，这个复杂度就应该做到O(N)！

当然，你可能看不懂大O标记法。简单说就是：一个原本打算支持2000万用户的系统，如果给靠谱人设计，那么搞个服务器水平扩展架构然后按需增加机器即可，至多几百台服务器就能搞定（线性增长嘛）；但一旦搞成O(N^3)，这个系统就会随着用户数增长指数级增长——于是，100个用户，这个系统几秒钟就能完成盘点；500用户，这个系统盘点一次要半小时；当用户达到1000人时，这个系统盘点一次就要六个小时……依此类推，当用户数真的达到两千万时，公司就需要组织一支军队，把全世界已经生产出来的电脑全部抢过来、再奴役三星台积电等半导体厂让它们啥都别干先专心造八十年芯片再说……

什么？这样能不能满足要求？没那事，你得给别人找点事做，不让就显得你无能了。折腾他们八十年，你死之后哪管洪水滔天。

可想而知，这会对公司造成多大的损失——但看KPI，谁能比他更忙、做的事情更多吗？！

作为对比，那个把事情做对的人，实际做了什么？

答案是什么都没做。除了数据库表设计从一开始就没搞那么复杂、使得将来围绕着数据库开发时，大家都不用做太多事之外。

换句话说，这种情况下，一个技术人员的价值，恰恰体现在他没有做那些多余的错事上。

从头追查这件事，就会发现，优秀开发人员和滥竽充数者的价值差异，运气非常好的时候，也只会在两年之后才让你发现——当后者问题爆发时，就会知道他吹的天花乱坠的玩意儿……不过是驴粪蛋外面光。

但是，如果真到两年后问题爆发时你才知道他是草包……砸进去的几千万甚至上亿开发费用已经打了水漂。

身为股东，你可能只剩两个选择。一是家大业大扔点没啥，二是破产自杀。

不想扔也不想自杀？那就难办了……

不过也不是没办法。古人已经有解决方案了：

齐宣王使人吹竽，必三百人。南郭处士请为王吹竽，宣王说之，廪食以数百人。宣王死，湣王立，好一一听之，处士逃。

没错。这就是办法。别让人吃大锅饭，一个个考察。从小项目开始识人、提拔，找到合适人再慢慢组织团队搞中大型项目。

你可能会说：但是现在我已经有一个五百人的团队了啊……

这就是软件工程的重要性了：真正会做工程的，一定是把一个大项目拆成一堆中型项目、中型项目再拆成小项目、小项目拆成函数来做的——合格的技术专家眼里就不存在大项目，只有基本函数库构成的小项目、一堆小项目构成的小项目以及小项目构成的一堆小项目构成的小项目……

换句话说，考察你的中上层项目经理，看他们有没有本事把一个大项目三言两语说清楚、分成简单清晰、各自独立的几个模块——没这能耐？请他吃铁板炒鱿鱼吧。

类似的，考察你的每个程序员，看他们能不能清晰简洁的实现自己的任务、能不能把自己的任务实现的边界清晰、便于复用——然后，这些边界清晰的一个个小项目，你还考察不了他们的完成速度、效率、可靠程度吗？别整来整去，最该吃鱿鱼的是你自己吧？！

软件开发就要用软件开发的方式管理。软件工程不会？没有金刚钻，谁给你的勇气揽这瓷器活。

综上，KPI只是你关于软件流程管理、开发人员能力评估等专业知识的外在体现——事实上，这KPI还就是当年引进的、国外软件企业的先进管理理念。

但这玩意儿想玩转，要么你是管理和技术两手一起抓，两手都要硬；要么呢，公司内部两条线，一条技术线，一条管理线。

技术线里面的负责人叫项目经理，他必须是一个软件工程高手，具体技术可以不精，但总体性的把握能力必须有。他负责识人、把工程师带好，确保项目保质保量按时完成。

管理线里面的负责人是业务经理，他掌管资源调配等工作。软件团队立项，要告诉他大概需要多少人多久时间开发、需要的软硬件投资额等信息；他来判断这个项目有没有前景、能不能挣到钱，决定要不要上、最高可以投资多少钱做研发。

将来，软件团队要对按时保质保量完成开发任务负责，业务经理则对项目能否赚钱负责——更复杂的模型里面还要有市场部/客户部/客户代表、产品经理等角色：市场部/客户代表提出需求，软件部决定能不能做、需要多少人月；产品经理确保人机界面设计合理……但最终，要不要上马项目、可以给多少开发经费，这还是要业务经理拍板。

注意各自负责的范围以及职责。尤其注意合作流程非常关键——如果你让客户经理/产品经理直接干预了开发过程，那么造成的延误该谁负责？

现实是，绝大多数产品经理、客户经理、项目经理是不合格的——而他们的不合格，是因为业务经理乃至更高层领导不合格。

因为他们的不合格，很容易出现：

• 项目经理不懂软件开发规划，尸位素餐当甩手掌柜
• 客户经理/产品经理作威作福，直接指挥开发人员，任意改变既定目标
• 最终，所有人疲于奔命，忙死忙活却不出成果
• 病急乱投医，找KPI、OKR之类“灵丹妙药”，试图一抓就灵
• 结果是，灵丹妙药不仅不解决问题，反而成了各方推脱责任的借口……
• 为了推脱责任，劣质经理们不得不带领一伙人“表演式加班”，甚至把表演式加班本身当成KPI

你看，问题的关键压根不是什么“如何定KPI”，而是你，你的同事，你们这一干人，究竟懂不懂开发？懂不懂管理？

如果懂，那么你怎么搞怎么对——无论是散养、KPI还是OKR，你总是能保质保量按时完成任务、且团队成员还轻松惬意按时上下班。

但如果不懂，你搞什么都是和尚念经。

再说一遍：问题的核心是经理的能力，不是外在的具体表现。能力到了，怎么玩怎么对；能力不到，越是东施效颦，死的越难看。

程序员的劳动价值属于非常典型的“只能定性，不能定量”的。

代码行数也好，bug数量也好，功能模块也好，解决问题数也好，都不可以。

最根本的问题在于：一行代码的经济价值和一行代码的技术难度是完全不相关的。

因为代码的经济价值和技术难度不成正比，所以，所有说可以定制KPI的人，都是外行瞎逼逼。

哪怕这个人有1000年的经验，还是瞎逼逼。

只有偶尔的一些情况下，技术水平会和经济价值挂钩。

譬如，的确有一些门槛很高的0day漏洞，

可能可以卖到几万到，乃至几十万刀（传说，我也没见过那么贵的）。

但毕竟这也不是常态，常态是啥？

常态就是大多数程序员平时就在增删查改，并且，其实你看我上一个回答下面的评论就知道了。

这群增删查改的老手，一样可以获得很高的收入，

还能凭借很高的收入自我感觉良好地对计算机知识体系指手画脚。

你要说他们劳动价值低，那是不对的，毕竟每天都在解决公司的各种问题。

你要说他们劳动价值高，那更不对，一点底层都不会只会做调包侠的人，哪儿都能找。

那么，怎么给他们定KPI呢？

定不了的。

有些人写一年代码，可能是为了提升公司员工10%的工作效率，值多少钱？

有些人一个月泡茶看屏幕，最后发现了一个成年屎山代码里偶尔出现的bug，值多少钱？

有些人一样泡茶看屏幕，结果发现了特斯拉为什么刹车失灵的bug，值多少钱？

有一些说可以定KPI的人，当然可以把KPI定得很细，细到覆盖了上面所属的情况。

但你要知道，我就是随便举个例子，而这样的例子我能举无数个。

KPI能制定到无穷细吗？

不可能。

所以，放弃给程序员定KPI，才是科学的做法。

那么，有一些太监部门着急了，这样CTO不就翻了天了吗？

那可不成啊，我们东厂部门必须是最强的。

……

……

……

放心，不会的。

你不能给程序员定KPI，但是你可以给整个开发部门制定KPI啊。

客户投诉数量；

需求部门满意度；

预定战略目标达成情况；

等等等等；

这些大目标都是可以一定程度量化的，而且是直接和经济价值正相关的。

然后，整个部门的考评，就是每个人的考评。

至于部门内部怎么分……

让他们自己卷起来就好了。

听俺一句，当老板的不要屁事都管，你又不会，不会就少插嘴。

找个会的来，让他和你的东厂部门撕逼。

---

  feng-xue-76 网友的相关建议: 
      

凡是制定不出kpi的公司往往问题出在不明白制定kpi是为了解决自己的什么问题，而是想单纯的做个最完美的kpi制度。

没有评价标准，你会发现你做什么都是对的，也是错的。

举个例子，如果你执行kpi，是为了强化程序员环节的执行效率和风险降低，那你可以拿事故率和delay率等指标去定。如果你是要提高程序产出，那就去定工作量方面的指标。

但是，当你为了解决某个问题去制定kpi的时候，你会发现kpi是一个很蠢的方法，因为你不是用员工的责任心在驱动自己工作，而是用亏损心在驱动，这慢慢会导致有能力的员工离职。

---

  Scorpiour 网友的相关建议: 
      

提出这个问题说明你想到了一个事情：

技术人员是难以定制KPI的

实际上别说程序员，所有的技术类、甚至是脑力类工种 —— 从作家编辑、到设计师工程师、再到医生、律师、研究人员……当然也包括了程序员在内，做的都是无法进行“短期内量化考核”的工作。

你能给医生定KPI吗？说一周不看多少个病人就不合格？

你能给作家定KPI吗？说一天不写出多少字就不合格？

而这个短期指的是“几年之内”。

既然几年之内的成绩都难以量化考核，就更不要说以年、季度甚至月度来进行量化考核了。

事实上，KPI只适用于“可重复性的”、“易培养的”的低技术水平工种 —— 就连高级别的销售顾问都很难用KPI考察。

这也是为什么在过去十年内许多科技公司用OKR取代KPI的原因：

制定一个大的目标，这个目标包含几个关键性的达成点，至少放手让“团队”去做就好了，不要去考核团队中每个成员的细节。

---

  liustein 网友的相关建议: 
      

给程序员制定KPI问题很多，有些关键技术问题，谁都搞不定，就某个人搞定了，说出来都是无关紧要的，好像不难。其实除了懂的人，没人知道这个技术难点，这个怎么算？

恰恰还就是这个人，承包了组内大部分难题。那么问题来了，给他定kpi ，最后他帮所有人解决各种奇奇怪怪的问题，影响了自己的kpi ，评分还低于别人？弄的不好人家直接走人了，好的情况，他还干着，但是学乖了，再也不帮助其他人，结果全组项目进展受阻……

道理其实很简单，写程序是非常强调沟通和cooperation的，而KPI是对组内成员互相帮助的抑制，如果每个人都只关心自己的KPI，这个组最后肯定搞不好。

如果KPI是用来评价的，那你每天和组员在一起工作，谁贡献大，谁贡献小自己不清楚么？如果你居然搞不清楚组员的贡献，还得依赖于KPI，那你这管理者也别当了。如果KPI是用来motivate组员的，那你这管理者也别当了，连你自己都无法motivate组员，还想着靠KPI，这不是开玩笑么。

在高水平的管理者眼中，一个团队是一个有机的整体，是一个个独特的人组成的；在平庸的管理者眼里，团队只是一部机器。

---

有个来割韭菜的答主把所有人批判了一番，然后装模作样的答了一通，那答案给我看笑了，他的帖子总结一下就是：“我的办法好用，遇到不好用的情况不用就是了，来啊找我咨询吧” 真是一个机智的韭菜收割机呢！

---