这是芃篙君的第325篇原创
本文大概2400字，阅读需要8分钟。
你好呀，我是芃（péng）篙，一个相信思考和努力能够拿到结果的家伙。
之前在聊KPI工具的时候，其实有聊过这个工具在软件行业上应用的难点。今天再延伸一些讨论，但在此聊的，可以认为是一个阶段性的讨论过程，而不是一个可直接应用的结果。
01 绩效评估的难点
对于工厂生产来说，KPI这玩意可以搞得很明确、很量化。生产效率是多少、不良率是多少，很直观。但是，到软件开发这个维度，就很难直接应用起来。
一个月写多少行代码？每千行代码的BUG数量？似乎也可以这么去定义，但是工业生产，原材料、机器基本上都可以是固定的。但是软件开发就完全不同，软件的需求来源、消化效率、生产周期，相对工业“硬件”生产来说，最大的特点就是灵活。灵活的反义词就是，标准化，也就是说，软件的生产很难像硬件生产那样可量化。
典型的情况是，一个生产线的工人，每天工作8小时，只负责拉线上某一个工位上的固定操作就好了；但是，一个软件工程师，可能周一周二在做班车迭代的需求；周三周四在班车迭代提测的同时，又开始搞定制项目的需求；周五又把时间重点花在了大客户反馈的问题上。
对应的情况就是，工业生产就是标准的产品生产，售后维护是另外一条链路；软件开发一般来说生产和维护是一拨人，即便可能有些公司有FAE这样的组织，但是应该也解决不了所有的软件问题。另外就是，工厂生产可以通过工艺工程标准化；软件生产却因为其灵活的需求规模和不同的设计方案，导致生产投入不同的工程师，会有不同的效果。同一个需求，不同的方案，不同的工程师，可能给出的评估时间和实际投入人日，都完全不一样。
即便不跟工厂生产来比较，只是从软件工作的日常来衡量，哪些工作投入更有价值，就是一个十分让人迷惑的问题。
是写业务需求代码更有价值，还是写基础库代码更有价值？
是写代码更有价值，还是协同解决客户问题更有价值？
是写公共知识文档更有价值，还是优化协作流程更有价值？
从这个角度讲，对应的问题是什么？就是软件开发人员每个人都可能设定不同的绩效目标，但是如果大家都完成了，还需要相互比较排序时，排序的逻辑是什么？
常见的表现是，大家在KPI定义时，写的头头是道，但是真的需要绩效结果排序的时候，管理者往往就根据自己脑子里印象给出一个排序，再返回到KPI定义中去找排序的合理性。这样的思路，就是KPI走了个过场，实际的结果大部分取决于管理者的主观印象。
02 人治与法治
员工的绩效结果取决于管理者的主观判断并不完全是一件坏事，但是也绝对算不上是什么好事。因为，如果过于依赖管理者的主观判断，那么对管理者的要求是有点高的。
管理者会不会被固有印象所蒙蔽？
管理者会不会被远近亲疏所影响？
管理者会不会无法辨识基本公平之上的激励逻辑，从而导致赏罚不公？
都有可能。
那么，如果管理者的主观判断有一定的偏差，一定会出什么大问题吗？
也不一定。因为团队成员的情况不同，管理者的其他方面能力不同，大组织层面的要求可能也不同。就会导致，日子精细过有精细过的过法，粗犷过有粗犷过的过法。只要组织还在跑，还能有增长、还能出业绩，这些细节，不见得是紧急问题；是不是重要问题，也需要具体问题具体分析。
整体上看，就是管理上存在很大空间的“人治”的模糊地带，人治的效果，当然依赖于管理者和员工互相认同的具体情况。可以好到爆发，也可以坏到崩盘，更可以模棱两可凑合着过。
KPI作为一个绩效工具，最大的意义是通过工具把员工的贡献和激励形成一定的有迹可循的逻辑关系。某种程度上，是通过绩效管理的标准化，降低管理者主观失误的可能性。但是在软件技术团队这里，至少是不能搞拿来主义。在管理者人治的空间之下，有没有可能，争夺出一些法治的空间，让激励这一块更加有效呢？
03 更全面的评估框架
只要有问题，就有解法。至少可以做一定的思考。
软件开发难以直接应用KPI的核心问题在于软件工程师的工作很难量化出价值，那么，对应的解法就应该是想办法把价值量化出来。但是又不能回到写了多少行代码和BUG的思路上去。
量化的事情可以做吗？不一定。还是需要看日常工作的属性情况。一般而言，同一个叶子节点下的团队中的成员，工作内容的复杂度和强度应该是相近的，存在一定的可比较空间。但是对于团队规模比较有限的组织而言，可能每个人负责的方向就是不一样的，对应的复杂度也是不一样的，就很难去衡量比较。但是，反过来讲，规模很小的公司，也没有必要搞精细化的绩效考核操作。
具体要怎么去量化，其实需要看管理者如何定义团队内的工作情况。怎么去定义不好讲，但是要规避哪些问题，是值得探讨的。
其一是，需要顾及基本的公平性。量化标准的定义，一定是为了让管理者对员工的工作贡献具备更全面、客观的认知，至少是对原本主观评价上的有效补充。所以，就需要兼顾团队的所有情况，至少要做到基本的公平性；
其二是，需要考虑到量化采集的成本。咱也不是需要分多大的财产，需要把考核周期内所有的大事小情都拎得清清楚楚明明白白。如果做评估投入产出贡献量化的成本，已经远远超出其他项目推进、人员状态管理的投入，那就需要反思，是不是把精力错投到了没必要的地方；最后是，只要有规则的定义，那么就一定会带来大家基于规则的做事准则，这种影响是必然的。那么，最需要戒备的是，不能让细化的规则，影响到团队的创新能力。这可能很难，但主要还是看如何定义与执行。
总之，我们考虑的更多的是能够更加客观的评估出团队成员在考核周期的贡献情况，尽量公平的根据团队的发展方向需要，做出考核激励。不至于KPI工具沦为仅仅是走个流程的工具，也不至于让团队考核，完全受制于管理者个人。这是让组织，往更加健康方向发展的一条路径。
相关链接
关注芃篙君⬇️，每日获取思考与践行的认知更新...
可获取软考备考资料；
亦可加微信探讨开发者、职场与管理、IoT行业等话题；
共同成长，穿越周期！
