这仍然是一篇关于绩效考核的文章
但是，
这次我们来聊点更实际的
如何让自己
在横向比较的绩效考核中
脱颖而出？
故事一
在一个很重视质量，重视自动化测试的部门，有这么个团队，花了3年的时间，终于将项目做到了100%的自动化测试覆盖率，但是在接下来的绩效考核中，成绩垫底。
我最近刚刚接手教练工作的一个团队，时值他们的大boss从美国千里迢迢的赶来，团队精心准备了一个成果展示会(Showcase)，其中展示的重点，是他们在过去2年里如何花了大量的时间和精力，在这个大型的，复杂的，技术债累累的项目里最终实现了自动化测试率100%的覆盖。
然而Boss看完后，反映并非如团队期待的那样---给予赞许。而是大脸一沉，很严肃的问了两个问题：
你们花了多少时间和精力来做这件事情？
所有的代码都值得去做自动化测试麽？
团队负责人此时看着boss严肃的脸有点慌乱了，他能看出Boss不太满意，但又不明白，为什么"100%自动化测试覆盖率"这样一个好结果，却招来不满。
于是他开始解释，团队加了多少班，平时在工作之余做了多少学习调研工作，100%的自动化测试覆盖率在业界多么难以做到等等，试图提出更多的"功劳"和"苦劳"来佐证这个"成果"。
但是Boss很不耐烦的打断了团队负责人，阐述了自己在这个事情上的观点：
1： 这个复杂的系统里只有30%的功能属于业务重点，几乎90%的用户活动和业务更新需求都集中在这30%的功能里面。其余70%的功能点很少被用到，然而自动化测试覆盖它们需要花费巨大的精力和时间，但是回报很低。
2：质量很重要，但是0 bug 从来不是他和客户追求的目标。事实上，他们可以容忍在一定范围内的质量问题， 但是希望将更多的人力和时间投入到新的需求的研发，以及那些可能带来增长的业务的尝试上。
3：团队在攻克"100%测试覆盖率"这个技术问题上获得的知识和经验，对Boss和客户来讲价值很少。因为团队现有的技术对于维护和支持这个项目来讲，已经够用了。 再进行技术技能的提升，对Boss和客户来讲是一件投资回报比下降的事情。技术团队应该将更多的学习精力放在"提高业务分析能力"这种当前是短板，提高了之后会带来明显收益的方向上。
大Boss走后不久，这个团队就在部门绩效考核中垫了底，而且带来了一个后果，就是业务方在给团队分派新的业务需求的时候，态度明显强势了很多， 对于工作量和工期的讨价还价上，团队也明显处于了劣势。 这个行为传递出来一个信息---Boss认为，团队以前有些精力是浪费在了其他地方，他们还有能力承担更多的新业务开发工作。所以，给他们更多的工作！
聪明的你或许已经能从这个case里看出这个团队的问题所在 ---他们努力的方向与Boss的期待不符。
当我们一讨论到如何考核研发团队，测试团队的时候，很多方法论里都能看到一些指标，比如交付速度，交付质量，自动化测试覆盖率，bug数量等等。有的团队考核还增加了学习，创新等指标。还有各种复杂的综合指标图表。这些指标当然可以用来定义一个"合格的研发团队"。但是，这些指标都是从团队的角度出发，而不是从你的老板，客户角度出发。
想象一下，假如你花钱买一个工具，帮你完成一个任务。你是希望花大价钱买一个"完美"的工具，还是花适当的钱买一个"性价比高"的工具？
客户和公司选择团队，打造团队，本质上是在选择和打造自己的工具。如何评估一个工具的好坏，这就取决于工具使用者的目标，以及自身能做出的投资， 甚至价值取向，特殊偏好。 这些满足了， 工具使用者就会竖起大拇指，贴上"好工具"的标签。
上面的粗体部分，才应该是绩效考核标准制定的来源， 而不是所谓的"行业标准"，"技术指标"等等。
上面提到的这个团队里面，有人质疑 "追求测试覆盖率，是为了追求质量呀，客户也认为质量很重要啊。我们这么做不也是满足了他的需求么？"
团队觉得最好达到100%自动化测试覆盖率，但是客户认为，自动化测试率30%就够了，他可以容忍一步质量问题，把团队剩下的精力投入到ROI更高的地方去。
所以绩效评估不单单要从客户的"需要"出发，更要弄清楚这个需要的"程度"在哪里。大部分时候，团队和客户都会同意某些评估指标是好的，但是两者对"应该好到什么程度"，理解起来差别却很大。
想象一下你手握2000块，要买一部智能手机，你会怎么面带苛刻的挑选和平衡拍照，存储，速度等各种参数，就能理解客户关于"需要"和"程度"的感受了。
另外，还有非常重要的一点，当我们在讨论绩效考核的时候，似乎总是关注应该在绩效考核里设置哪些条目，设置该条目下应该有哪些数字或者百分比，采用什么公式来计算。似乎这是评定团队表现的唯一方式。
但是在现实操作中， 我往往发现，绩效考核的最终成绩，永远是由两部分组成：客观数字+主观印象。甚至有的时候主观印象占的比例更大。这个主观印象来自于评分者，可能是客户，可能是Boss，可能是其他重要干系人。而他们能给出多少分，取决于他们的真实需求得到了哪种程度上的满足，这就是进一步说明了，团队制定绩效考核标准时，出发点一定不能是行业标准，而是为团队买单的人。买单人需要什么，我们就考核什么。
所以，你可能觉得公司的绩效考核体系漏洞很多，也可能觉得Boss不理解敏捷工作方法，测试覆盖率，代码规范等等的重要性。但是由于他们是"团队"这个工具的使用者，并为之买单，所以优先满足他们的需求，永远是你能在绩效考核中脱颖而出的捷径，也是你应该去做的正确的事情。
故事二
努力工作的团地，在考核中总输给能说会道的团队？ 错，方向永远比程度重要。
有个部门的团队，分部在三个国家，分别由中国团队，印度团队，墨西哥团队组成。中国团队给人的感觉是，干活最多，出了问题响应最快，钻研技术最刻苦，但是说的少。而墨西哥团队和印度团队，很多时候是发言积极，表达意见积极，但是实际工作做的少。考核的时候，虽然大Boss对每个团队的工作都表示满意，团队间横向比较的时候，往往是中国团队垫底。
作为一个第三方的教练，我通过一段时间参加他们的会议，观察他们的邮件后，得出一个结论---
中国团队倾向于对Boss的需求大概了解之后，迅速开始埋头苦干，干出来的结果往往与Boss的真实期望有偏差，需要再做工作来纠正偏差。或者是干的"过度"，引来boss关于"浪费"不满。
而印度和墨西哥团队，恰恰是因为"积极发言"，在看似无用的"聊天"的过程中，把Boss到底想要什么，想要到什么程度搞清楚了，最后做"适当"的工作，就可以精准的满足Boss需求并获得赞许。
所以看上去一边说的少，做的多。另外一面说的多，做的少。但是考核成绩却截然不同，这背后，深层次的原因，是你有没有满足打分者的需要。
上一个故事中，我们说到，绩效考核永远都有两部分组成：客观数字+打分者的主观印象。客观数字很明朗，但是打分者的主观印象，则需要一定的技巧去了解的。很多打分者都不能够清晰明确的描述出自己的喜好，程度等等，这些都是在不断的对话，沟通中浮现出来的。
这个故事里的中国团队，所面临的问题在于，他们总是想快速的开始工作，而忽略了"聊天" 的重要性。绩效考核的时候，在"主观印象"这一栏里失分严重。
最后高度总结概括一下本文的观点：
1：绩效考核的设计要围绕客户或者重要干系人(统称绩效考核打分者)的需要来制定，而不是围绕团队"自我证明"的角度，或者行业标准。
2：制定绩效考核标准时，不光要考虑到打分者的"需要"，还要考虑"需要的程度"，过多和过少都会影响最终的成绩。
3：绩效考核永远分为"客观分数+主观印象"两部分，搞清楚打分者的"主观印象"喜好，需要重视聊天，会聊天。
祝每位读者都能在绩效考核里脱颖而出。
看完这篇文章后你感觉昏昏欲睡，
身子越来越轻，
逐渐脱离了大脑的控制，
拇指不听使唤，
做了今年最神奇的两件事情：
1
死死按住了下面这张二维码，情不自禁进行关注。
2
鬼使神差的将此文分享到了朋友圈，
并配文：不转不是社会主义接班人。
等你醒来，为时已晚。
网友评论