众所周知，绩效管理从来都不是一个容易的工作。为什么绩效工作不容易？从我自身的感受以及听到的抱怨中，主要有两个方面的原因。首先是评价标准的确定。对测试工程师团队来说，通常测试工程师都会分散在不同的项目中，追求建立一个“公平的”标准非常困难；其次是在对绩效工作的理解上，绩效工作包括目标设定、绩效评价、绩效跟踪、绩效沟通几个主要部分，但不少测试管理者仅仅把重点放在绩效评价上，忽略了目标和基于目标的沟通，导致绩效工作变成了一个单纯的打分，这样自然引入了许多的问题。
首先来看看测试工程师的绩效管理。设定绩效目标是绩效管理的第一个环节。我以为，对绩效目标正确的理解是建立合理的绩效评价原则和体系的前提。例如，“发现的缺陷数”和“编写的用例数”大概是最多的测试组织对测试工程师绩效评价的标准，那么这个标准是否合理？实际上，在实践中，“发现的缺陷数”并非一个好的衡量成员工作的指标：首先，不同的项目中，缺陷数量本来就不同，发现缺陷的难易度也不同；其次，并非每个缺陷都有相同的价值，发现缺陷的数量多不见得意味着发现的缺陷的质量高。既然这样，为什么“缺陷数”仍然成为了大多数组织的绩效衡量标准？我想，主要的原因，恐怕在于这个数据具有典型的“量化”特性，在一定程度上反映了测试工作的状况，且具有表面的“公平”的特性。
1. 设定绩效目标
在讨论这种方式是否合理之前，我们先讨论绩效目标本身。为什么要为测试工程师设定绩效目标？答案可以是“为了发奖金”，但在我看来，奖金的发放只是对绩效完成好的员工的奖励，而绩效目标本身是对团队成员的一种指引。简单的说，设定绩效目标是为了让员工明白“组织期望你做什么”，通过这种设定来达成组织的目标和期望。所以，设定一个绩效目标的目的不是为了“绝对的公平”，而是为了让所有的团队成员都明白“怎么做才是组织期望的”。设定“发现的缺陷数”作为主要的绩效指标只能导致一个后果：所有的团队成员都把自己的价值定位在“发现更多的缺陷上”。表面上看，这样并没有问题：测试团队的工作不就是发现缺陷吗？这里有一个有趣的虚拟场景（这个场景是我最喜欢的，用来挑战这种衡量标准的场景）：
测试团队成员A加入了P项目，在开始的一个月中，平均每个版本他能发现50个缺陷；半年后，A可以在每个版本中发现100个缺陷。你认为他应该得到很高的评价吗？
从“发现缺陷的数量”上看，显然，成员A做得非常出色。但是，如果从项目的角度来看呢？这个项目的质量显然越来越糟糕了。这样岂不是非常危险的信号：“测试团队所期望的目标和组织的期望是背道而驰的”？太糟糕了。
为组织中的测试成员设定什么样的绩效目标才合理？简单的说，取决于组织的目标是什么。在敏捷环境下，我们期望整个测试组织能够持续的提升生产率，能够持续的提高产品质量，因此，在设定绩效目标的时候，需要把员工的绩效目标与组织的这些目标牢牢的绑定在一起。此外，目标本身需要是可度量和衡量的，因此，从生产率和提高产品质量等角度入手，可以考虑以下这些绩效目标：
提高生产率
更短的产品的发布周期
更短的测试周期
更少的产品测试迭代次数
提高产品质量
更少的线上缺陷
（同样测试覆盖率下）更少的系统测试中缺陷数量
促进更好的代码质量
促进可测试性
单元测试覆盖率
接口和系统的自动化测试覆盖率
促进更好的可测试性
2. 绩效跟踪和打分
设定绩效目标之后，依据绩效目标跟踪测试工程师在整个绩效周期中的工作，保证TA的方向的正确性，这是一般意义上的绩效跟踪工作。通常情况下，绩效目标的完成情况可以通过定期的一对一会议或是通过工作日志、周报等来获取信息。一旦发现员工在完成绩效目标方面存在困难，或是目前的方向有偏差，管理者就需要及时指出并和员工讨论如何改善之。在某些情况下，管理者甚至需要为员工设定明确的以周为单位的分解后的绩效目标。
在绩效周期结束的时候，为员工在一个绩效周期内的打分主要依据绩效目标的完成情况来决定。除了绩效目标的完成情况外，员工在反馈、沟通、响应变化等方面的表现也是对员工进行评价的因素。因此，除了对照绩效目标的完成情况外，从测试工程师所在项目或产品的干系人（Stakeholders）得到该工程师的反馈也是很重要的。这方面的内容可以参照360度考核的具体方式，可以采用正式和非正式的方式从干系人除获得对员工的反馈。
3. 绩效面谈
设定目标与打分完成后，你是否可以松一口气，告诉自己“嗯，这个季度的绩效考核终于完成了“？不然，最残酷的考验还没有到来呢。愿意回忆一下你最近一次的绩效面谈是怎么开展的吗？
“现在我们开始绩效面谈。你这次的评价是B，因为……。有什么问题吗？没有问题的话，那就下一个”。
大约这是你所能想到的最顺利的面谈了吧，如果遇到不那么配合的员工，对话通常会演变成这样：
“现在我们开始绩效面谈。你这次的评价是B，因为……。有什么问题吗？没有问题的话……”。
“有问题。我觉得我这个季度工作表现还不错，为什么只是这么低的评价？”
“呃，是这样的。这个季度的绩效目标中，你完成了第一项和第三项，但是第二项完全没有完成……”
“第二项没有完成不是我的问题啊，是XX没有及时提供文档给我，这个情况你是知道的。”
“呃，对。我知道，但是……”
“既然不是我的问题，为什么你要把这个责任算在我的头上？我觉得这个不公平。”
“你看，我们的绩效原则就是这么定的，这个也不是我定的……”
“你的意思是，我们就是这样的，即使不合理也要按照这种方式来做，是吗？”
“……”
节节败退。一旦你搬出“这个原则不是我定的”这个理由时，你就已经一败涂地了。至此，员工已经100%确认了你对他的评价是不公平的。你的绩效工作在TA身上彻底失败。那怎么才能避免这种情况呢？招一堆小绵羊似的员工，或是干脆不要做绩效，都能让你不会陷入这种境地。但是，对一个的负责任的管理者来说，这两种都不是好选择。
冲突，在绩效上与员工的冲突并不罕见。我猜想，即使是最好的管理者，也一定遇到过这种类似的被员工挑战的情况。退回到“公平”的底线，和员工讨论绩效原则是否“公平”并不是一个好的策略（记得我在前面提到过，绩效不是为了“公平”的目的而设定的吗？）。
绩效面谈是一个极好的认可你的团队成员的工作、和他共同探讨如何改进自己工作的机会。绩效面谈的重点不是和你的团队成员纠缠在每一个0.1分的得失上，也不是要让他认为你是绝对公平的上帝，重点是和他共同探讨如何改进自己的工作。所以，一旦对话开始纠缠在公平、0.1分的具体分差上，立刻当机立断，引导话题到改进工作和展望下一个绩效周期吧。
要能够正确的评价敏捷环境下的测试工程师，除了设定合理的评估体系外，评估者本身是否具有足够的技能来对工程师进行评价也是一个重要问题。Michael Lopp在《软件人才管理的艺术》这本书中建议，技术管理者应该“不要停止写代码”，这样才能保持敏锐的技术触觉，以及更好的弄清楚“如何帮助和支持工程师”。在敏捷的环境下，这一点尤其关键。如果一个测试团队的管理者不能深入了解每个项目的状况，改进，问题，那就不可能真正合理的评价在该项目中工作的测试工程师。管理者不仅需要了解测试工程师在每个项目中的任务，还必须能够深刻理解工程师在项目中采取的促进质量提高的方法，并能在方向和具体方法上对其进行指引。不管怎么说，你的团队成员是你最大的财富，尽一切努力让他们有目标，有方向，有成就感吧。
原文地址：http://www.infoq.com/cn/news/2011/06/dn-agiletest-performance-manage
