敏捷的绩效评审

现有体制的不足之处

总的来说，大多数公司的年度绩效评审机制都有欠考虑。每年只对绩效进行一次有意义的谈话来决定该年度的绩效结果，这本身就很可笑。然而，很不幸，这种做法在如今大多数公司中都很盛行。大多数管理者除了怨天尤人之外似乎找不到其他方法，更要命的是很少有公司愿意去改变。

相比之下，更悲哀的是，当今盛行的专家建议仅仅是简单地摒除绩效评审。正因为你只有两个选择：要么保留现行的绩效评审机制，要么摒除它，我猜想你可能会选择后者。而这篇文章恰恰给出了解决问题的第三种方案。

客观评审的弊端

对于那些愿意接受改变的公司而言，不幸的是他们经常因为选择的方向错误而无疾而终。他们的确听到种种来自员工的关于现行流程不合理的抱怨，并试图列出一堆客观标准，作为评审的依据以示公正。

这种做法主要存在两个问题：首先，那些容易被度量的关键绩效指标很少是你真正关心的方面。比如说，你觉得销售指标该成为你销售团队绩效评审的一部分吗？如果你的某个销售仅仅因为完成一个订单而答应客户一些产品中没有的特性，你认为这样做妥当吗？但我认为通过这种手段他们可以达到你所要的销售指标，但会给公司惹下大麻烦。因此即便他们达到了你所制定的销售指标，你不会赞同这样做是优秀的员工。

另一个问题是，即便你果真能够找到衡量绩效的具体标准，我们还是会主观地依据这些关键绩效指标去做评审，以得出不同成绩的绩效。我是说，只要评判存在主观性，这都会影响到所谓的客观标准。

我完全可以认同我们努力寻求客观事实的初衷，但我也坚定地认为，在绩效评审上追求客观事实本身就是种错误。除此之外，你也必须考虑到，企业组织中存在着大量不同的角色，用相同的客观标准去衡量每个角色是不可能完成的任务。你必须为每个角色创建不同的关键绩效指标，而这样做会带来巨大的工作量。最终的情况有可能变成这样：不同员工胜任工作的品质会完全不同。在绩效评审中加入客观事实做标准，这种做法本身就费力不讨好，最终会失败。

从关键绩效指标（KPI）到自由反馈形式

我们与其根据关键绩效指标一行一行地为员工打分，不如尝试为他们的工作表现进行有意义的反馈。我们可以把公司关注的方面作为结果，然后把能够导致这些结果的行为作为对员工反馈的标准，给予正面的或负面的反馈。这些反馈必须能够关联到行为，并且便于理解让员工清楚哪些是公司期望的行为，哪些不是。同时你自己要明白，公司关注这些行为的依据。

另一方面，为了能够使反馈达到最好的效果，你要尽可能地给出所观察到的行为作为依据。这意味着所有出现在员工评审上的结果必须是与员工讨论过的。如果员工对某个反馈有疑问，作为管理者的你就有义务解释清楚，帮员工搞清这条反馈的缘由。

主观评审的益处

由于我们没有办法在评审中完全排除主观感受，我建议你考虑采用更主观的评审方法。不同于为每项工作提供具体的评审标准，你可以尝试为员工提供正面的或负面的反馈。这些反馈可以基于公司的使命、愿景与核心价值观。以下是一些例子：

问题：员工的何种行为是积极、正确的？

• 当我们需要为客户提供 QCP 方案时，你主动表达愿意学习新技术的意愿并最终完成方案。这是不断提升自我价值的表现。
• 当技术支持的电话变得遥遥无期时，你不小心听到客户说她饿了然后为她点了匹萨送到她的办公室。这是让客户满意的表现。
• 当客户安装在服务器上的软件与系统不兼容时，你和团队共同协作找到了解决方案。这是不断创新的表现。

问题：怎样能够帮助员工打破常规？

• 你虽然不乐意参加客户的技术支持电话，但考虑到支持代表有时的确需要开发人员协同解决问题，你还是加入了电话。这是视公司事务为己任的表现。

目标、目标、还是目标

目标是有效的绩效评审的另一个重要部分。有关目标的活动通常有两类：对前次绩效评审设定的目标打分；设定新目标。你必须留出时间和精力放在目标设定上，因为这些能够帮助员工和管理者发展专项技能。

作为管理者，你不该为员工直接设定目标，你应该坐下来和员工一块儿讨论商量出这些目标。

我确信我们都知道，目标应该是 SMART（明确的、可度量的、可达到的、现实的、有时间限制的）的。但我们真的需要目标吗？我个人认为，如果员工能够清楚地理解其工作的期望，他们就会成功。我不会强迫任何人制定主观臆断的数字或专业发展的目标。毫无疑问，我希望员工能够得到发展并超越那些普通的职责，但能够满足预期的员工已经是成功的员工。

然而，成功的员工与“得力”的员工或“出众”的员工之间还是有明显的区别。如果我选择把业余时间花在陪孩子玩耍上，而不是参加关于领导力的培训或阅读，我不觉得这样做该受到惩罚。我仍然能够开展工作，并把工作做好。

同级之间的反馈

绩效评审的重要信息来源就是来自同级们的反馈。我们有很多方法来收集和提交反馈信息，但我通常使用匿名的方式，为的是鼓励真诚与坦白。当然，这不意味着你可以随便乱说别人一通，然后装作什么都没发生过。如果你无法为你的反馈提供明确的行为依据，你并不是在帮忙而只是在抱怨。抱怨不能成为评审的一部分。

同级间的反馈的另一个好处在于，它能够帮助改进评审机制。这能帮助管理者确认评审中是否有遗漏的部分，并且能够提供更多明确的例子。

征求同级的反馈通常比较容易做到，但你必须在最终绩效评审进行前的三到四个星期结束反馈的收集工作。这样做能够给予人们足够的时间为管理者提供有用的反馈，同时也允许管理者有时间追踪有疑问的反馈。

你必须认识到，并不是所有人都愿意为他们的同级提供反馈。有些人只提供正面的反馈；有些人提供的反馈则非常模糊（没有帮助）；有些人甚至不给你反馈。这个时候，切勿咄咄逼人。你应该花点精力培养组织中的员工，教授他们提供反馈的方法。与此同时，你必须保证反馈是匿名的，以求得到坦白真诚的反馈。也许你要花上几个评审周期，才能够让每个人都愿意提供反馈，但这样做的结果毫无疑问非常值得。

我们仍然需要排名

尽管我们不情愿，但我们最终还是不得不依据制定的尺度为员工排名。我曾经试过很多种尺度，其中我最喜欢的是五分尺度法。五分尺度法分为失败、改进、成功、得力以及出众。居中的一个等级是“成功”，意味着你每天按时来上班，达到预定的期望，完成对应的工作，不多不少。这样当然完全没有问题，但肯定是有改进的空间。

失败的员工仅仅表示无法完成分配的工作，并通常在工作环境中制造紧张气氛。一般来说，很少有员工在正式的评审中得到“失败”的评价，因为这样的员工通常在正式评审进行之前就已经从组织中脱离。

需要改进的员工能够在某些方面做得很好，但某些地方就不那么好。这类员工通常也不会在组织中长久存在，因此我们也很难在评审中看到“改进”的等级。可以肯定的是同一名员工不会连续两次评审都得到“改进”的等级，因为没有进步的“改进”员工就是组织不需要的员工。

得力的员工在大多数时间内都表现得相当优秀。这不仅仅意味着他们能够把本职工作做得出色，他们还会不断地努力突破自己界限。

最后，出众的员工在每个方面都做得无可挑剔，并会鼓励他人追求卓越。出众的员工通常也很少见。

绩效评审样本

评审期间：2011 年第三——第四季度

员工：周杰伦

（译注：原文为 Sir Mix-A-Lot，90 年代美国说唱乐歌手 Anthony Ray 的艺名，下同）

诚实守信。

客户关系良好。

创新精神。

视公司事务为己任。

遇挫折不离不弃。

不惧困难、但行事谨慎。

能够在工作中找到快乐。

结果点评

当产品研发团队开始采用 Scrum 方法时，你早早地加入了团队并极力推行新流程的实施。当很多人害怕改变时，你主动接纳了改变。你表现出了不惧困难、但又行事谨慎并时刻保持自我价值提升。

当我们开始在大型软件开发过程中采用更多工程实践时，你又一次加入进来并开始着手进行自动测试、结对编程以及重构。你表现出了时刻保持自我价值提升及不断创新的精神。

当其他业务部门需要支持时，你总会尽全力帮助他们。你总是第一个愿意协助的志愿者，特别是在客户支持解决问题方面。你能够满意客户并维持良好的客户关系。

你的积极态度总能为团队成员带来快乐，你通常能轻描淡写地化解紧张情况。你总能守时并不时地妙语连珠。你能够让自己和他人在工作中感到快乐。

建议与意见

我建议你能够在社区实践方面变得更主动并担当领导角色。现在你已经做到积极参与并提升社区实践，但我希望能够看到你更进一步担当起领导团队并通过新的历练。这关系到不惧困难、但又行事谨慎以及在工作中感受快乐等方面。

快速遍历测试脚本的不足之处在于，你无法考虑周全。为了最大程度地保证产品质量，我希望你能够更全面地考虑测试。你可以通过增加脚本的测试用例或改进你较自由的测试风格。我们期望的目标不仅仅是执行测试脚本，而是需要通过测试保证产品特性的质量。这关系到保持自我价值提升。

因为你在质量保证领域表现出的兴趣，我希望能够和你一起商量关于参加质量保证流程及技术正规培训的事宜。我相信我们会有很多机会找到新的、更好的方法来测试我们的产品并让测试变得更有效与高效。这关系到保持自我价值提升以及不断创新

成就：

毫无疑问，你已经接受了新的开发流程并开始充满激情地进行实践。如果没有你的帮助，我们没法像现在那么成功。

对于新的开发流程，你已经能够非常好地执行。这不仅仅是因为你帮助产品工程团队做好了过渡，同时你也对新流程做好了过渡。此外，你不仅仅是新流程的积极参与者，同时还非常积极地参与到流程改进中，并且为流程改进提出真正有建设性意义的方案。

同时，我祝贺你在所参与的校园开发者活动中赢得 Windows 手机。很少有人愿意把自己的工作展示到同级面前，更不用说为此赢得奖励了。干得不错，继续努力！

既定目标：

尺度等级：

• 不适用
• 未达到
• 达到
• 超越

目标 1： 首先就是提出质量改进的计划并改进质量的方面。这包括独立编写测试用例，以及通过正式的指导或结对评审过程，帮助团队成员提高编写单元测试的能力。这还包括编写集成测试，帮助改进测试脚本、测试用例的结构，推进流程改进，落实更好的版本控制系统（SVN），提出架构改进建议等一系列事情。比如你推动质量改进计划，请将你所做的存档并写成博客（如果没有博客的话，也可以给我发邮件）让我知道你所做的工作，以及这对团队和 Qualtrax 质量的影响。 成绩： 超越 解释： 毫无疑问，你通过自身工作和结对工作推动了质量改进计划。我能够看到你花时间在单元测试，集成测试，用户界面测试以及重构上。你甚至更进一步，已经开始带领团队在 Qualtrax 的架构上展开更深层次的讨论。 目标 2： 进一步学习有关面向对象软件设计模式及其应用。从“四人组”（GoF——设计模式：可重用的面向对象软件设计元素）一书中选择至少三个模式并进行研究。你可以选择或为每个设计模式写一条博客（如果没有博客则可以给我写邮件），或向其余的团队成员讲解这三条设计模式。 成绩： 达到 解释： 这个目标我们今年开始得有点晚了，但我还是很喜欢你所做的。从《Head First 设计模式》开始研究是个很好的开端。学习设计模式的确是件有趣的事，但我们更需要了解何时何处如何应用设计模式。我建议从创建小的应用实例来帮助学习设计模式，这也是你所正在做的。 目标 3： 学习新的 User eXperience (UX) 技术来改进 Qualtrax 用户界面的整体效果。我所听到的关于 Qualtrax 用户界面的抱怨之一就是系统管理模块很难使用。任何你能做的减少问题的工作都会有帮助，我对在未来六个月里解决该问题的某些方面充满自信。学习有关原型、一致性原则、可用性案例、人物角色甚至是 jQuery 的用户界面工具都是能够帮助我们解决问题的方向。这个目标比较难以度量，我将请求 Ken 对你所做的工作提供指导和衡量。 成绩： 不适用 解释： 尽管我们都认为 Qualtrax 的许多方面都需要 UI 和 UX 的改进，但这个评审阶段的重点在于开发团队按时发布产品的 4.3 版本。这就使得所有与修复 bug 及完成测试不相关的工作都没法进行。更遗憾的是，我没法完成所承诺的事情，让我们在下个评审阶段重新审视这个目标。 目标 4： 关于如何运用 MVC 框架（特别是.NET MVC 框架）解决我们的问题，积累更多功能性知识。利用书籍、博客及与人交流（尽管跟我约时间来讨论 MVC）学习 MVC 框架。跟团队交流看如何在我们现有的产品中运用 MVC 框架。发给我关于如何在 Qualtrax 产品中运用 MVC 的提案。 成绩： 未达到 解释： 在过去的六个月内，这不是产品优先需要解决的问题，我们并没有时间花在研究 MVC 中。在下次评审期间，我们重新来审视这个目标。## 新目标:

目标 1： 改进控制反转（IoC）原则并用容器来实现。接下去的三个月，我们将集中在这个目标上。你必须能够提供可展示的材料，展现我们是如何在 Qualtrax 内部运用 IoC 容器的。你必须能够为团队展示这样做的益处。 目标 2： 关于如何运用 MVC 框架（特别是.NET MVC 框架）解决我们的问题，积累更多功能性知识。这个目标在前次评审阶段中没有完成，但这是个非常有趣和重要的目标，我们可以试着在这次评审阶段中完成。利用书籍、博客及与人交流（尽管跟我约时间来讨论 MVC）来学习 MVC 框架。跟团队交流，看如何在现有的产品中运用 MVC 框架。把关于如何在 Qualtrax 产品中运用 MVC 的提案发给我。 目标 3： 创建并追踪质量度量数据。为了能够让我们对 Qualtrax 产品上质量改进部分的工作一目了然，我们需要找到并追踪有意义的度量数据。最终我会让你来决定需要哪些度量数据，但现在我想要见到的是追踪以下各项数据：已提交的 bug 报告，团队在开发的何种阶段提交的这些 bug（越早越好），现有测试脚本已覆盖或未覆盖的 bug 数等等。我将通过以下手段对此进行度量：你发送邮件给整个团队告诉大家哪些是我们将要追踪的度量数据，我们将如何追踪，我们这样做将对产品质量起到何种推动作用，以及为什么度量数据很重要。此外，如果你能在任务白板上显示这些度量数据以及趋势图就更好了。我希望在这次评审阶段结束时看到至少三个新的度量数据。 目标 4： 提高对 MVC 框架的理解及应用。这个目标也是我们后三个月集中要做的。你必须提供关于 Qualtrax 中应用 MVC 的可展示材料。你应当为 Qualtrax 中选取的若干界面用 MVC 重写，并展示给团队看我们是如何有效地运用 MVC。## 来自同级的反馈：

对周杰伦的反馈结果点评？

• 他极具团队合作精神。
• 他对于新事物具有强烈的求知欲。
• 他对于软件开发充满激情。
• 他乐于结对编程。
• 他风趣幽默并能够感染周围的人。
• 他是测试脚本“杀手”。
• 他深入学习测试并研究事务出错背后的缘由。
• 他在评审测试脚本方面表现出色并能够发现脚本中的错误。我曾发给过他我认为正确的测试脚本，他总能找到问题。
• 他为团队带来欢乐并能够化解严峻局面。
• 总的来说，他是该产品开发团队中最资深的成员。关于产品特性与代码，你可以问他任何问题，他都能对答如流。
• 他乐于助人。
• 他是我们最棒的开发经理。在搭建新服务器与开发环境方面，他也做得异常优秀。

对周杰伦的意见与建议？

• 建议学习支持团队所遇到的重复问题已帮助开发者在未来工作中避免犯同样的错误。
• 他需要改进他对他人的沟通方式。有时，他的评价可能会被错误的理解为是对队员的冒犯。我认为他并不是有意为之，但他说话的口气与风格会引起误解。
• 有时候我向他请教问题，但我不能完全理解他的解答。当我第二次询问他时或请求他解释得更详细时，他似乎对我没法马上理解而感到不快。他并不是一直这样，但有时候让我感到他的愠怒。
• 他似乎花了很多时间研究团队的绩效数据。希望他能把更多的时间花在研究流程的自动化工具上。
• 希望能见到他更多地与支持团队协作。我并不是经常见到他与支持团队的协作，但凡他这样做时都能得到很好的结果。学习支持团队所遇到的重复问题能帮助他更好地进行开发工作。

总体评分：“出众”

尺度：

• 失败 —— 员工无法达到工作期望。
• 改进 —— 员工无法持续地达到工作期望。
• 成功 —— 员工达到工作期望。
• 得力 —— 员工达到工作期望并在某些方面超越。
• 出众 —— 员工在所有方面超越工作期望。

解释：

在你从事的所有工作中，你都能够超出预期。你能提供解决方案，而不是遇到困难畏缩不前。在你每天的工作中，你都能够接受并表现出公司的核心价值。

签署：

我已经与我的经理共同讨论，我已阅读并理解这次评审的有关信息。

员工姓名 日期

经理姓名 日期

员工评价：

关于作者

在过去的十多年中，

Ryan Hagan曾担任软件开发经理一职，并投身于提高软件开发水准的事业中。他非常看重把工作做对做好的理念。在敏捷的软件开发流程及大型开发实践中，他推行的是非教条主义。除了软件开发的本质工作，他还倾注于提升领导力活动以及培养领导者方面。Ryan 对于创建伟大的工作环境充满着热情，因为他自己就希望在伟大的公司工作。 如果你有任何疑问，你可以通过给

Ryan 写邮件或访问他的

LinkedIn page 主页得到解答。

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。