這是敏捷開發(fā)績效管理的第四篇。（之一，之二，之三，之四，之五，之六，之七）

?

最近在看德魯克的書，發(fā)現(xiàn)其中很明確地寫著“企業(yè)的績效只存在于外部，而企業(yè)內(nèi)部只有成本”的概念和說法，下面結(jié)合敏捷開發(fā)團隊的績效考核展開談?wù)劇?/p>

敏捷開發(fā)有很多“外向型”思維，比如：關(guān)注客戶價值，認為可交付的產(chǎn)品才是真正能表征工作進展的因素等等，但尚未直接與目標管理接軌。外向性思維可以防止部門間壁壘或踢皮球，而轉(zhuǎn)而共同討論對外交付價值，從下面的對比可以看出這點。

---

“內(nèi)向型”績效及其導向

進度：“各階段按時完成率”會導致分析和設(shè)計人員草草結(jié)束工作，而將大量不確定工作推給開發(fā)人員；開發(fā)人員則如法炮制，把延期踢給測試人員。

質(zhì)量：“千行代碼缺陷率”會導致開發(fā)人員在很多“是否是缺陷”問題上與測試人員爭執(zhí)不下，另外一些次要的如使用不便、不直觀等問題則被長期擱置。

成本：“與計劃相比的人員超支率”會導致項目經(jīng)理很不愿意接受變更，即使是那些顯然能給客戶帶來巨大價值的。

功能：“需求規(guī)格中需求的完成比例”會導致開發(fā)組思維局限于當年編寫需求規(guī)格時期的認識，而不能在整個漫長的開發(fā)過程中不斷精化需求。

此外還有一些更可怕的數(shù)據(jù)，比如“每月生產(chǎn)的代碼行數(shù)”“每月生產(chǎn)的功能點或故事點數(shù)”（這個很有迷惑性）“每月修改的缺陷數(shù)”等，都是不恰當?shù)目冃А５卖斂恕捌髽I(yè)內(nèi)部只有成本”的理念指出，無論是文檔，代碼，可運行軟件乃至最終產(chǎn)品，若尚未被銷售，都只是成本的一部分。

多數(shù)采用內(nèi)向型績效的公司和團隊，其績效結(jié)果都不好。究其原因，單個部門/工種/個人各自追求自己的績效，并不會導致整個項目外部績效的提升（這稱為“合成謬誤”）。

某些內(nèi)向型績效甚至是互斥的，處于零和狀態(tài)。比如測試團隊人均發(fā)現(xiàn)的缺陷數(shù)（測試團隊的績效）與開發(fā)人員人均缺陷數(shù)（是開發(fā)團隊的負績效）并存，則兩個團隊無論如何都無法同時提升績效，導致他們永遠無法像一個團隊一樣互相幫助。若你的公司有這樣的績效，則研發(fā)人員與測試人員打架就不用奇怪了。

其他多數(shù)內(nèi)向性績效，都存在潛在的互斥關(guān)系。比如前面提到的個階段按時完成率即內(nèi)部存在互斥，而“需求規(guī)格中需求的完成比例”必與“客戶需求響應率”互斥。

外向型績效

下面是一些潛在的“外向型”績效，由于之前提過不同企業(yè)乃至產(chǎn)品的外向型績效差別很大，請靈活運用。

產(chǎn)品研發(fā)型

進度：

“與競爭對手相比同檔產(chǎn)品的上市日期比較”適合消費電子類產(chǎn)品。

“響應分銷商需求的時間”適合渠道比較強勢的情況。

這些外向型績效應該作用在整個團隊上，換言之不管哪個環(huán)節(jié)導致了進度差，都一起得到底的績效。從而促使整個團隊一起思考如何提升績效。

需求和設(shè)計人員為了能讓開發(fā)人員提前開工，可以采取分段寫需求和設(shè)計的方法，把最影響架構(gòu)又最不會發(fā)生變化的部分先寫出來，讓開發(fā)人員提前開工干活；而開發(fā)人員也可能會采取同樣的策略，階段式地發(fā)布產(chǎn)品，讓測試人員可以提前測試，防止最后缺陷太多導致產(chǎn)品延期；而需求和設(shè)計人員又回過頭來用開發(fā)的進度和測試的缺陷率，來判斷產(chǎn)品應該消減功能換取上市時間，還是增加更多功能以換取競爭力。

可見一個為外部目標奮斗的團隊，會很容易地團結(jié)起來，共同思考提升績效的最佳策略。

?

質(zhì)量：

“每月待處理質(zhì)量問題數(shù)”咨詢過的一家ERP公司的實際數(shù)據(jù)（但他們尚未用這個數(shù)據(jù)考核），此數(shù)據(jù)一般符合瑞利分布，因此可預測未來的質(zhì)量問題數(shù)量。

“每月終端用戶投訴數(shù)”適合消費電子、網(wǎng)絡(luò)游戲等與客戶比較緊密的行業(yè)。

“每月分銷商投訴數(shù)”適合渠道比較強勢的情況。

“每月論壇缺陷提出數(shù)”適合……我在的一家企業(yè)使用BBS免費處理缺陷。

用最終用戶提出的抱怨作為外部質(zhì)量目標的策略，不是說大家不用測試了，把缺陷留給用戶。而是：用我們測試了但仍漏給客戶讓其發(fā)現(xiàn)的缺陷，來修訂我們對缺陷的認識，修訂發(fā)現(xiàn)缺陷的方法。

有很多產(chǎn)品，收到的客戶關(guān)于易用性的抱怨，遠遠多于對功能和常規(guī)缺陷的抱怨，就應該將“易用性差”作為核心的質(zhì)量問題，進而作為質(zhì)量重點。我在下載一款總體評價4星半的Android短信軟件時，發(fā)現(xiàn)近期的評價很多都是“越來越難用了”“沒用的功能越來越多”甚至“更新太頻繁了（給了1星）”等等，最近的一些評分平均估計會下降到4星以下。這些抱怨應該當作質(zhì)量管理的最終考核標準，因為下載者無疑會根據(jù)這些評價來決定是否安裝軟件，而不是看那些“千行缺陷率”“測試人員發(fā)現(xiàn)缺陷數(shù)”。

成本：

“產(chǎn)品實際投入產(chǎn)出”適合很長的戰(zhàn)線。

試想如果是手機研發(fā)，應該在開發(fā)階段就做好測試、維護、重刷系統(tǒng)等接口，另外應該優(yōu)化性能以選擇低端硬件，否則整個產(chǎn)品極難保障盈利。

而且還會發(fā)生若軟件做得好（但軟件的研發(fā)成本要上升），則可以節(jié)省一些硬件資源或減免某些專用硬件的情況。這時候若要分別考核軟件部門和硬件部門，就很難實現(xiàn)了。

需求：

“每月待處理需求數(shù)”咨詢過的一家ERP公司的實際數(shù)據(jù)，如果產(chǎn)品試銷售過程中此數(shù)據(jù)很大而且消退很慢（符合瑞利分布），則表明產(chǎn)品與客戶的需求不符。估計也能呈現(xiàn)一些易用性方面的因素。

“客戶尖叫度（Customer Screaming Rate）”蘋果成功的標志性績效指標，不談需求，因為他要超越需求。要學習這個很難，但要理解并體現(xiàn)其精神。

“軟件與硬件需求匹配度”適合消費電子，比如若硬件與軟件研發(fā)平行，則最終交付產(chǎn)品中交付的軟件和硬件應該匹配，而不能“18個功能中，硬件完成了12個，軟件完成了13個，但其中6個不重合（就是說這些功能交付不了）”，這樣軟硬件部門才會共同配合。

某手機廠商很擅長上一條，他們一年的200個項目中，只有3個延期，就是很好地利用了功能排序-軟硬件對齊的方法，犧牲次要功能保證上市時間。

項目開發(fā)型

產(chǎn)品做的多，項目做的少，不敢多說，請各位補充吧！

---

為團隊設(shè)立外部績效目標的目的，是對齊團隊的不同角色、工序、人員的目標，從而互相幫助提升共同的績效。

外部目標多數(shù)可以被客戶、用戶或市場明確感知，其提升幾乎意味著帶來收入的增加。如果想在測試人員發(fā)現(xiàn)Bug的時候發(fā)獎金但卻發(fā)現(xiàn)賬上沒有錢，那就改到客戶很少抱怨的時候發(fā)吧，那時候賬上肯定有錢。?

?

注：這是一篇舊文，因符合本系列的內(nèi)容，在進行了很大改動后重新編輯發(fā)布在這里。

?

?

?

點擊下載免費的敏捷開發(fā)教材：《火星人敏捷開發(fā)手冊》

轉(zhuǎn)載于:https://www.cnblogs.com/wodeyitian/archive/2011/08/23/2459987.html

總結(jié)

以上是生活随笔為你收集整理的敏捷开发绩效管理之四：为团队设立外部绩效目标（目标管理，外向型绩效）...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。