BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

敏捷团队中测试工程师的绩效管理

| 作者 段念 关注 4 他的粉丝 发布于 2011年6月4日. 估计阅读时间: 9 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

在正文开始之前,首先感谢张凯峰编辑不厌其烦的提醒,没有他坚持不懈的提醒,就没有本文的面世:)

在本专栏的前几篇文章中,我们提到了敏捷测试的概念、组织,以及敏捷测试中的自动化测试组织方式。在这篇文章中,我试图来讨论一个更加困难的话题——敏捷测试中工程师的绩效管理。众所周知,绩效管理从来都不是一个容易的工作。甚至,我认识一位测试经理,他视绩效打分和沟通为畏途,每到季度结束需要为员工做绩效的时候就格外紧张。

为什么绩效工作不容易?从我自身的感受以及听到的抱怨中,主要有两个方面的原因。首先是评价标准的确定。对测试工程师团队来说,通常测试工程师都会分散在不同的项目中,追求建立一个“公平的”标准非常困难;其次是在对绩效工作的理解上,绩效工作包括目标设定、绩效评价、绩效跟踪、绩效沟通几个主要部分,但不少测试管理者仅仅把重点放在绩效评价上,忽略了目标和基于目标的沟通,导致绩效工作变成了一个单纯的打分,这样自然引入了许多的问题。

首先来看看测试工程师的绩效管理。设定绩效目标是绩效管理的第一个环节。我以为,对绩效目标正确的理解是建立合理的绩效评价原则和体系的前提。例如,“发现的缺陷数”和“编写的用例数”大概是最多的测试组织对测试工程师绩效评价的标准,那么这个标准是否合理?实际上,在实践中,“发现的缺陷数”并非一个好的衡量成员工作的指标:首先,不同的项目中,缺陷数量本来就不同,发现缺陷的难易度也不同;其次,并非每个缺陷都有相同的价值,发现缺陷的数量多不见得意味着发现的缺陷的质量高。既然这样,为什么“缺陷数”仍然成为了大多数组织的绩效衡量标准?我想,主要的原因,恐怕在于这个数据具有典型的“量化”特性,在一定程度上反映了测试工作的状况,且具有表面的“公平”的特性。

1. 设定绩效目标

在讨论这种方式是否合理之前,我们先讨论绩效目标本身。为什么要为测试工程师设定绩效目标?答案可以是“为了发奖金”,但在我看来,奖金的发放只是对绩效完成好的员工的奖励,而绩效目标本身是对团队成员的一种指引。简单的说,设定绩效目标是为了让员工明白“组织期望你做什么”,通过这种设定来达成组织的目标和期望。所以,设定一个绩效目标的目的不是为了“绝对的公平”,而是为了让所有的团队成员都明白“怎么做才是组织期望的”。设定“发现的缺陷数”作为主要的绩效指标只能导致一个后果:所有的团队成员都把自己的价值定位在“发现更多的缺陷上”。表面上看,这样并没有问题:测试团队的工作不就是发现缺陷吗?这里有一个有趣的虚拟场景(这个场景是我最喜欢的,用来挑战这种衡量标准的场景):

测试团队成员A加入了P项目,在开始的一个月中,平均每个版本他能发现50个缺陷;半年后,A可以在每个版本中发现100个缺陷。你认为他应该得到很高的评价吗?

从“发现缺陷的数量”上看,显然,成员A做得非常出色。但是,如果从项目的角度来看呢?这个项目的质量显然越来越糟糕了。这样岂不是非常危险的信号:“测试团队所期望的目标和组织的期望是背道而驰的”?太糟糕了。

为组织中的测试成员设定什么样的绩效目标才合理?简单的说,取决于组织的目标是什么。在敏捷环境下,我们期望整个测试组织能够持续的提升生产率,能够持续的提高产品质量,因此,在设定绩效目标的时候,需要把员工的绩效目标与组织的这些目标牢牢的绑定在一起。此外,目标本身需要是可度量和衡量的,因此,从生产率和提高产品质量等角度入手,可以考虑以下这些绩效目标:

  1. 提高生产率
    • 更短的产品的发布周期
    • 更短的测试周期
    • 更少的产品测试迭代次数
  2. 提高产品质量
    • 更少的线上缺陷
    • (同样测试覆盖率下)更少的系统测试中缺陷数量
    • 促进更好的代码质量
  3. 促进可测试性
    • 单元测试覆盖率
    • 接口和系统的自动化测试覆盖率
    • 促进更好的可测试性

2. 绩效跟踪和打分

设定绩效目标之后,依据绩效目标跟踪测试工程师在整个绩效周期中的工作,保证TA的方向的正确性,这是一般意义上的绩效跟踪工作。通常情况下,绩效目标的完成情况可以通过定期的一对一会议或是通过工作日志、周报等来获取信息。一旦发现员工在完成绩效目标方面存在困难,或是目前的方向有偏差,管理者就需要及时指出并和员工讨论如何改善之。在某些情况下,管理者甚至需要为员工设定明确的以周为单位的分解后的绩效目标。

在绩效周期结束的时候,为员工在一个绩效周期内的打分主要依据绩效目标的完成情况来决定。除了绩效目标的完成情况外,员工在反馈、沟通、响应变化等方面的表现也是对员工进行评价的因素。因此,除了对照绩效目标的完成情况外,从测试工程师所在项目或产品的干系人(Stakeholders)得到该工程师的反馈也是很重要的。这方面的内容可以参照360度考核的具体方式,可以采用正式和非正式的方式从干系人除获得对员工的反馈。

3. 绩效面谈

设定目标与打分完成后,你是否可以松一口气,告诉自己“嗯,这个季度的绩效考核终于完成了“?不然,最残酷的考验还没有到来呢。愿意回忆一下你最近一次的绩效面谈是怎么开展的吗?

“现在我们开始绩效面谈。你这次的评价是B,因为……。有什么问题吗?没有问题的话,那就下一个”。

大约这是你所能想到的最顺利的面谈了吧,如果遇到不那么配合的员工,对话通常会演变成这样:

“现在我们开始绩效面谈。你这次的评价是B,因为……。有什么问题吗?没有问题的话……”。

“有问题。我觉得我这个季度工作表现还不错,为什么只是这么低的评价?”

“呃,是这样的。这个季度的绩效目标中,你完成了第一项和第三项,但是第二项完全没有完成……”

“第二项没有完成不是我的问题啊,是XX没有及时提供文档给我,这个情况你是知道的。”

“呃,对。我知道,但是……”

“既然不是我的问题,为什么你要把这个责任算在我的头上?我觉得这个不公平。”

“你看,我们的绩效原则就是这么定的,这个也不是我定的……”

“你的意思是,我们就是这样的,即使不合理也要按照这种方式来做,是吗?”

“……”

节节败退。一旦你搬出“这个原则不是我定的”这个理由时,你就已经一败涂地了。至此,员工已经100%确认了你对他的评价是不公平的。你的绩效工作在TA身上彻底失败。那怎么才能避免这种情况呢?招一堆小绵羊似的员工,或是干脆不要做绩效,都能让你不会陷入这种境地。但是,对一个的负责任的管理者来说,这两种都不是好选择。

冲突,在绩效上与员工的冲突并不罕见。我猜想,即使是最好的管理者,也一定遇到过这种类似的被员工挑战的情况。退回到“公平”的底线,和员工讨论绩效原则是否“公平”并不是一个好的策略(记得我在前面提到过,绩效不是为了“公平”的目的而设定的吗?)。

绩效面谈是一个极好的认可你的团队成员的工作、和他共同探讨如何改进自己工作的机会。绩效面谈的重点不是和你的团队成员纠缠在每一个0.1分的得失上,也不是要让他认为你是绝对公平的上帝,重点是和他共同探讨如何改进自己的工作。所以,一旦对话开始纠缠在公平、0.1分的具体分差上,立刻当机立断,引导话题到改进工作和展望下一个绩效周期吧。

要能够正确的评价敏捷环境下的测试工程师,除了设定合理的评估体系外,评估者本身是否具有足够的技能来对工程师进行评价也是一个重要问题。Michael Lopp在《软件人才管理的艺术》这本书中建议,技术管理者应该“不要停止写代码”,这样才能保持敏锐的技术触觉,以及更好的弄清楚“如何帮助和支持工程师”。在敏捷的环境下,这一点尤其关键。如果一个测试团队的管理者不能深入了解每个项目的状况,改进,问题,那就不可能真正合理的评价在该项目中工作的测试工程师。管理者不仅需要了解测试工程师在每个项目中的任务,还必须能够深刻理解工程师在项目中采取的促进质量提高的方法,并能在方向和具体方法上对其进行指引。不管怎么说,你的团队成员是你最大的财富,尽一切努力让他们有目标,有方向,有成就感吧。

关于作者

段念:Google中国高级测试经理,毕业于华中科技大学,先后在通讯、嵌入式软件、互联网等多个行业的国内外知名公司中从事软件开发与测试工作。对软件测试中的技术和管理工作有独到见解,对软件测试团队管理、自动化测试、性能测试与开发测试有较多研究。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

别装了 by wang jie

别装了,搞绩效。
这个就是公司老板想少给工资的借口。我还从来没有发现过因为绩效给多发了。更可恨的是,进入公司时谈的工资时跟本不和你说绩效。进来后再和你说,还是将你工资的一部份那还作绩效。
这太无耻了。
当然这可能只在中国资本家身上有。

官僚体系里呆久了的人就是没办法接受一个现实 by 熊 节

在团队工作的环境中,针对个人的绩效考核就是扯淡。

抛开是不是真的需要所谓“测试工程师”这么一个物种的话题不谈。怎么管理测试工程师的绩效?简单。项目经理挑人,项目发奖金大家一起拿,项目交付失败大家一起挨罚。项目经理平时在一起聊聊天,某些测试工程师(以及程序员啦分析师啦等等)渐渐就没有项目经理愿意选,你需要做的就是直接fire这些人完事。

Re: 官僚体系里呆久了的人就是没办法接受一个现实 by 段 念

回复的内容有意思,标题没意思。你的臆测十分不准确。各有所见吧,纯粹的项目制度当然没问题,问题是,每个人是否只有面向项目的目标的产出才有价值?如果是这样,google的20%就是个笑话。

Re: 别装了 by 段 念

我不负责给你发绩效公司,所以“别装了”这种话,说给你老板听:)如果你干过的所有企业都是这副你描述的模样的话,建议你赶紧走人吧,至少我们公司谈的所有offer上的数字,只是基本工资,必然能拿到手的,和绩效有关的是季度的绩效奖金。

敏捷团队中的“绩效考核”值得实践和深入研究! by 高 翌翔

文中全面讨论了“敏捷团队中的绩效考核”应该如何做以及谁来做的问题。

通常被广大同行所“深恶痛绝的绩效考核”只有季度或年终绩效打分,而目标恰恰就是“为了发奖金”,并未对团队成员起到任何指引作用,其后果自然就是团队成员牢骚满腹、离职率居高不下。

而“敏捷团队中的绩效考核”的管理目的是为了让员工明白“组织期望你做什么”,这直接导致了绩效指标以及后续一系列考核活动的变化。从而使“绩效考核”成为传达组织期望的风向标,并持续跟踪员工对于组织期望的执行状况。

文章最后作者还提到“评估者本身是否具有足够的技能来对工程师进行评价”的问题,真可谓一针见血,值得深思!

最后,感谢作者段念和 InfoQ 广大编辑的辛勤工作!

有启发 by qiu ricky

[设定一个绩效目标的目的不是为了“绝对的公平”,而是为了让所有的团队成员都明白“怎么做才是组织期望的”。] 这一点很有启发。之前只要想到绩效,第一个考虑的就是公平不公平,如果不跳出这个问题,很难。Thanks!

Re: 别装了 by wang jie

哈哈,看来作者比较激动呀。这个评论只是对事不对人。这是我从业这几年来,做过的公司里面都有的问题。只在借着这编文章来说一下自己的看法而已。

不过有点怀疑的是,作者这么容易激动。你本人是怎么公正的去给你的团队作绩效的呢。

删除题目中的“敏捷团队中”几个字如何? by 景 志刚

《敏捷团队中测试工程师的绩效管理》
如果将题目中的“敏捷团队中”几个字删除,对于文章可能更贴切。
然而,还能再次发表吗?

Re: 删除题目中的“敏捷团队中”几个字如何? by law noel

同意上面的观点, 干嘛什么东西都和敏捷扯一块呢,不敏捷就不搞绩效考核吗

讲得很不错! by 牡丹 金

简单的说,设定绩效目标是为了让员工明白“组织期望你做什么”,通过这种设定来达成组织的目标和期望。所以,设定一个绩效目标的目的不是为了“绝对的公平”,而是为了让所有的团队成员都明白“怎么做才是组织期望的”。
----说的很好,现在完成1、2、3任务的绩效太多了,是所有的设定绩效人都要改善的。

基本认可,但有些地方不认同 by 王 东

绩效考核的目标说得很好,但让团队成员坚定明确的向目标前进不一定要用绩效考核的方式吧,敏捷方式已经把目标很明确很细化了的。
举的例子不当:那只能说明开发水平LOW,反而说明测试水平高啊,怎么就不能得到高评价呢?难道报告更少的缺陷才能得到高评价么?
本人虽然也是测试经理,但不搞绩效考核,团队照样很强很好。真正有能力的领导是靠自己的人格魅力,超牛的技术和能力征服下属,而不是靠绩效考核。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

11 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT