甚至愿意为了公司利益牺牲团队利益（有些情况

　　激励体系的问题，是很多企业共有的。

　　下面，我们说一下典型的KPI问题，先从技术领域说起。

　　1.以工作量为考核目标。

　　据说某公司用代码行数作为考核目标。

　　这个策略实际上是激励大量的垃圾代码。优秀的代码都是简洁优雅的，高复用、低耦合是追求的目标。如果考核员工的代码行数，菜鸟程序员绝对开心，你不需要考虑架构，不需要考虑复用，大量的复制粘贴很容易堆砌大量代码。我在最初编程的时候，也会有这样的习惯，把以前的代码直接粘贴过来改写，而这实际上是复用性很差的表现。

　　2.以解决问题为考核目标，比如处理实际问题数，修补BUG数。

　　这个听上去合理一些，但我以前举过这样的例子，两个项目组，第一个组长水平很高，写出来的项目代码非常稳定可靠，上线后什么问题都不出，项目团队变得无所事事。第二个组长，稍逊一些，写出来的项目代码上线后，经常出一些奇怪的问题，结果疲于奔命，各种加班，各种救火，结果第一个小组团队全部被调往支援第二个小组，第二个小组组长因卓越的工作积极性、大量的问题处理表现和持续性的加班奋斗而被领导赏识，升职，第一个组长只能成为其下属。

　　很多企业都会犯这样的错误，这样的案例其实也有不少。

　　3.以专家小组的考核为准。

　　技术的事情，让技术专家去评定，有些大公司有非常优秀的技术专家，就组成评委会，技术工程师需要申请升级的时候，去报告自己的工作表现、所使用的技术、所完成的工作量，所达到的目标，技术专家根据其表现决定是否升职加薪。听上去很合理对不对？

　　然而并不是，十年前，我遇到过这样的问题。我需要处理一个线上的问题，这个处理方案不复杂，按照我的方案做很快就能完成，和我搭配的工程师人蛮好的，水平也很高，但是就跟我抱怨了：“对不起啊，我上次评高级工程师没过呢，说我工作技术价值太低，这个方案我工作考核肯定上不去啊，我有个什么什么算法，你看行不行？”都是打工族，你好意思难为人家吗，本来一两天的事情，现在要做一两周，说实话，这还是非常照顾产品需求，很容易沟通的程序员，如果有那种以自我为中心的，出个需要做一两月的技术方案也没辙啊。

　　今天我说一句可能有些人不服气的话，很多大公司，存在大量技术过剩的情况，就是因为这种技术考核体系，小题大做，没必要的技术方案，没必要的过度架构，很多是为了满足技术评级和升职的需要，而这一切，除了人力和资源的浪费外，更导致了产品迭代缓慢，市场应对能力缓慢。

　　其实我们看很多创业小公司，乃至个人，可以很短时间内发布很有意思的产品，包括一些Hackathon（编程马拉松）的活动，36～48小时做出来的产品也都有模有样，但是大公司做一些同类产品动辄几百人团队，半年以上时间。有人会说，你不懂，大公司性能要求高、复杂度高。这个我还真的略懂。

　　而更可怕的是，某些管理职能的人为了能升职，一些本来不需要很多人的岗位，也要硬造出一堆工作任务来，招一堆人来满足一些根本没太大实际意义的事情，手下人多了，自然职位也就上去了。

　　4.基于犯错率考核。

　　这种思路是，考核你工作中出现的问题数，BUG数和相关故障数。

　　嗯，其作用大家都知道，多做多错，少做少错，不做不错。

　　程序员都已经习惯做“背锅侠”了。

　　5.基于团队目标。

　　单独的技术实在难以考核，只好基于团队目标，和你的项目团队共进退，虽然存在不公平，比如优秀的技术如果配到了一个不靠谱的产品经理手里，可能就被拖累了，但是好歹也是一种弊端较少的方案了吧。

　　然而，我们知道，大公司最怕的是什么，部门藩篱，有些热心的技术牛人，愿意和更多人分享，愿意帮助其他人分析问题、解决问题，愿意辅导更多年轻人，然而，这一切，都没有任何激励。很多大公司在KPI的导向下，部门利益高于公司利益，甚至不同部门明争暗斗，抢项目，抢资源，抢话语权。

　　如果有个员工，是以公司利益为重，甚至愿意为了公司利益牺牲团队利益（有些情况下是需要的，比如，公司有个特别重要的项目，比这个部门当前的项目价值大很多，一个优秀的技术，在与本部门管理者沟通确认后，去紧急支援人家的项目，就比按时完成本部门项目对公司价值更大，我个人是非常鼓励这种行为的），那在这种考核目标下，简直就是要被淘汰的典型了。

　　可怕不？

　　技术岗不好评定，那么其他岗位呢，设计师岗位类似技术岗，做得多不如做得好，一个好的设计，胜过1000个平庸的设计，然而好这个评定，如何定量？

　　在产品和设计领域，KPI的问题在于，只能考核已知的东西，如何评估未知的东西，而互联网行业、IT行业，要经常面对未知的场景，提出新的观点、新的构思和新的产品特性，那么，在这些东西提出来之前，我们的KPI原则是