本篇文章是摘取 nickname= 段念 的，http://www.infoq.com/cn/news/2011/06/dn-agiletest-performance-manage/
在正文開始之前，首先感謝張凱峰編輯不厭其煩的提醒，沒有他堅持不懈的提醒，就沒有本文的面世：）
在本專欄的前幾篇文章中，我們提到了敏捷測試的概念、組織，以及敏捷測試中的自動化測試組織方式。在這篇文章中，我試圖來討論一個更加困難的話題——敏捷測試中工程師的績效管理。眾所周知，績效管理從來都不是一個容易的工作。甚至，我認識一位測試經理，他視績效打分和溝通為畏途，每到季度結束需要為員工做績效的時候就格外緊張。
為什么績效工作不容易？從我自身的感受以及聽到的抱怨中，主要有兩個方面的原因。首先是評價標准的確定。對測試工程師團隊來說，通常測試工程師都會分散在不同的項目中，追求建立一個“公平的”標准非常困難；其次是在對績效工作的理解上，績效工作包括目標設定、績效評價、績效跟蹤、績效溝通幾個主要部分，但不少測試管理者僅僅把重點放在績效評價上，忽略了目標和基於目標的溝通，導致績效工作變成了一個單純的打分，這樣自然引入了許多的問題。
首先來看看測試工程師的績效管理。設定績效目標是績效管理的第一個環節。我以為，對績效目標正確的理解是建立合理的績效評價原則和體系的前提。例如，“發現的缺陷數”和“編寫的用例數”大概是最多的測試組織對測試工程師績效評價的標准，那么這個標准是否合理？實際上，在實踐中，“發現的缺陷數”並非一個好的衡量成員工作的指標：首先，不同的項目中，缺陷數量本來就不同，發現缺陷的難易度也不同；其次，並非每個缺陷都有相同的價值，發現缺陷的數量多不見得意味着發現的缺陷的質量高。既然這樣，為什么“缺陷數”仍然成為了大多數組織的績效衡量標准？我想，主要的原因，恐怕在於這個數據具有典型的“量化”特性，在一定程度上反映了測試工作的狀況，且具有表面的“公平”的特性。
1. 設定績效目標
在討論這種方式是否合理之前，我們先討論績效目標本身。為什么要為測試工程師設定績效目標？答案可以是“為了發獎金”，但在我看來，獎金的發放只是對績效完成好的員工的獎勵，而績效目標本身是對團隊成員的一種指引。簡單的說，設定績效目標是為了讓員工明白“組織期望你做什么”，通過這種設定來達成組織的目標和期望。所以，設定一個績效目標的目的不是為了“絕對的公平”，而是為了讓所有的團隊成員都明白“怎么做才是組織期望的”。設定“發現的缺陷數”作為主要的績效指標只能導致一個后果：所有的團隊成員都把自己的價值定位在“發現更多的缺陷上”。表面上看，這樣並沒有問題：測試團隊的工作不就是發現缺陷嗎？這里有一個有趣的虛擬場景（這個場景是我最喜歡的，用來挑戰這種衡量標准的場景）：
測試團隊成員A加入了P項目，在開始的一個月中，平均每個版本他能發現50個缺陷；半年后，A可以在每個版本中發現100個缺陷。你認為他應該得到很高的評價嗎？
從“發現缺陷的數量”上看，顯然，成員A做得非常出色。但是，如果從項目的角度來看呢？這個項目的質量顯然越來越糟糕了。這樣豈不是非常危險的信號：“測試團隊所期望的目標和組織的期望是背道而馳的”？太糟糕了。
為組織中的測試成員設定什么樣的績效目標才合理？簡單的說，取決於組織的目標是什么。在敏捷環境下，我們期望整個測試組織能夠持續的提升生產率，能夠持續的提高產品質量，因此，在設定績效目標的時候，需要把員工的績效目標與組織的這些目標牢牢的綁定在一起。此外，目標本身需要是可度量和衡量的，因此，從生產率和提高產品質量等角度入手，可以考慮以下這些績效目標：
- 提高生產率
- 更短的產品的發布周期
- 更短的測試周期
- 更少的產品測試迭代次數
- 提高產品質量
- 更少的線上缺陷
- （同樣測試覆蓋率下）更少的系統測試中缺陷數量
- 促進更好的代碼質量
- 促進可測試性
- 單元測試覆蓋率
- 接口和系統的自動化測試覆蓋率
- 促進更好的可測試性
2. 績效跟蹤和打分
設定績效目標之后，依據績效目標跟蹤測試工程師在整個績效周期中的工作，保證TA的方向的正確性，這是一般意義上的績效跟蹤工作。通常情況下，績效目標的完成情況可以通過定期的一對一會議或是通過工作日志、周報等來獲取信息。一旦發現員工在完成績效目標方面存在困難，或是目前的方向有偏差，管理者就需要及時指出並和員工討論如何改善之。在某些情況下，管理者甚至需要為員工設定明確的以周為單位的分解后的績效目標。
在績效周期結束的時候，為員工在一個績效周期內的打分主要依據績效目標的完成情況來決定。除了績效目標的完成情況外，員工在反饋、溝通、響應變化等方面的表現也是對員工進行評價的因素。因此，除了對照績效目標的完成情況外，從測試工程師所在項目或產品的干系人（Stakeholders）得到該工程師的反饋也是很重要的。這方面的內容可以參照360度考核的具體方式，可以采用正式和非正式的方式從干系人除獲得對員工的反饋。
3. 績效面談
設定目標與打分完成后，你是否可以松一口氣，告訴自己“嗯，這個季度的績效考核終於完成了“？不然，最殘酷的考驗還沒有到來呢。願意回憶一下你最近一次的績效面談是怎么開展的嗎？
“現在我們開始績效面談。你這次的評價是B，因為……。有什么問題嗎？沒有問題的話，那就下一個”。
大約這是你所能想到的最順利的面談了吧，如果遇到不那么配合的員工，對話通常會演變成這樣：
“現在我們開始績效面談。你這次的評價是B，因為……。有什么問題嗎？沒有問題的話……”。
“有問題。我覺得我這個季度工作表現還不錯，為什么只是這么低的評價？”
“呃，是這樣的。這個季度的績效目標中，你完成了第一項和第三項，但是第二項完全沒有完成……”
“第二項沒有完成不是我的問題啊，是XX沒有及時提供文檔給我，這個情況你是知道的。”
“呃，對。我知道，但是……”
“既然不是我的問題，為什么你要把這個責任算在我的頭上？我覺得這個不公平。”
“你看，我們的績效原則就是這么定的，這個也不是我定的……”
“你的意思是，我們就是這樣的，即使不合理也要按照這種方式來做，是嗎？”
“……”
節節敗退。一旦你搬出“這個原則不是我定的”這個理由時，你就已經一敗塗地了。至此，員工已經100%確認了你對他的評價是不公平的。你的績效工作在TA身上徹底失敗。那怎么才能避免這種情況呢？招一堆小綿羊似的員工，或是干脆不要做績效，都能讓你不會陷入這種境地。但是，對一個的負責任的管理者來說，這兩種都不是好選擇。
沖突，在績效上與員工的沖突並不罕見。我猜想，即使是最好的管理者，也一定遇到過這種類似的被員工挑戰的情況。退回到“公平”的底線，和員工討論績效原則是否“公平”並不是一個好的策略（記得我在前面提到過，績效不是為了“公平”的目的而設定的嗎？）。
績效面談是一個極好的認可你的團隊成員的工作、和他共同探討如何改進自己工作的機會。績效面談的重點不是和你的團隊成員糾纏在每一個0.1分的得失上，也不是要讓他認為你是絕對公平的上帝，重點是和他共同探討如何改進自己的工作。所以，一旦對話開始糾纏在公平、0.1分的具體分差上，立刻當機立斷，引導話題到改進工作和展望下一個績效周期吧。
要能夠正確的評價敏捷環境下的測試工程師，除了設定合理的評估體系外，評估者本身是否具有足夠的技能來對工程師進行評價也是一個重要問題。Michael Lopp在《軟件人才管理的藝術》這本書中建議，技術管理者應該“不要停止寫代碼”，這樣才能保持敏銳的技術觸覺，以及更好的弄清楚“如何幫助和支持工程師”。在敏捷的環境下，這一點尤其關鍵。如果一個測試團隊的管理者不能深入了解每個項目的狀況，改進，問題，那就不可能真正合理的評價在該項目中工作的測試工程師。管理者不僅需要了解測試工程師在每個項目中的任務，還必須能夠深刻理解工程師在項目中采取的促進質量提高的方法，並能在方向和具體方法上對其進行指引。不管怎么說，你的團隊成員是你最大的財富，盡一切努力讓他們有目標，有方向，有成就感吧。
關於作者
段念：Google中國高級測試經理，畢業於華中科技大學，先后在通訊、嵌入式軟件、互聯網等多個行業的國內外知名公司中從事軟件開發與測試工作。對軟件測試中的技術和管理工作有獨到見解，對軟件測試團隊管理、自動化測試、性能測試與開發測試有較多研究。