? 這是敏捷開發績效管理的第四篇。 ? 最近在看德魯克的書，發現其中很明確地寫著“企業的績效只存在于外部，而企業內部只有成本”的概念和說法，下面結合敏捷開發團隊的績效考核展開談談。 敏捷開發有很多“外向型”思維，比如：關注客戶價值，認為可交付的產品才是真正能表征工作進展的因素等等，但尚未直接與目標管理接軌。外向性思維可以防止部門間壁壘或踢皮球，而轉而共同討論對外交付價值，從下面的對比可以看出這點。 ## “內向型”績效及其導向 進度：“各階段按時完成率”會導致分析和設計人員草草結束工作，而將大量不確定工作推給開發人員；開發人員則如法炮制，把延期踢給測試人員。 質量：“千行代碼缺陷率”會導致開發人員在很多“是否是缺陷”問題上與測試人員爭執不下，另外一些次要的如使用不便、不直觀等問題則被長期擱置。 成本：“與計劃相比的人員超支率”會導致項目經理很不愿意接受變更，即使是那些顯然能給客戶帶來巨大價值的。 功能：“需求規格中需求的完成比例”會導致開發組思維局限于當年編寫需求規格時期的認識，而不能在整個漫長的開發過程中不斷精化需求。 此外還有一些更可怕的數據，比如“每月生產的代碼行數”“每月生產的功能點或故事點數”（這個很有迷惑性）“每月修改的缺陷數”等，都是不恰當的績效。德魯克“企業內部只有成本”的理念指出，無論是文檔，代碼，可運行軟件乃至最終產品，若尚未被銷售，都只是成本的一部分。 多數采用內向型績效的公司和團隊，其績效結果都不好。究其原因，單個部門/工種/個人各自追求自己的績效，并不會導致整個項目外部績效的提升（這稱為“合成謬誤”）。 某些內向型績效甚至是互斥的，處于零和狀態。比如測試團隊人均發現的缺陷數（測試團隊的績效）與開發人員人均缺陷數（是開發團隊的負績效）并存，則**兩個團隊無論如何都無法同時提升績效**，導致他們永遠無法像一個團隊一樣互相幫助。若你的公司有這樣的績效，則研發人員與測試人員打架就不用奇怪了。 其他多數內向性績效，都存在潛在的互斥關系。比如前面提到的個階段按時完成率即內部存在互斥，而“需求規格中需求的完成比例”必與“客戶需求響應率”互斥。 ## 外向型績效 下面是一些潛在的**“外向型”績效**，由于之前提過不同企業乃至產品的外向型績效差別很大，請靈活運用。 **產品研發型** **進度：** “與競爭對手相比同檔產品的上市日期比較”適合消費電子類產品。 “響應分銷商需求的時間”適合渠道比較強勢的情況。 這些外向型績效應該作用在整個團隊上，換言之不管哪個環節導致了進度差，都一起得到底的績效。從而促使整個團隊一起思考如何提升績效。 需求和設計人員為了能讓開發人員提前開工，可以采取分段寫需求和設計的方法，把最影響架構又最不會發生變化的部分先寫出來，讓開發人員提前開工干活；而開發人員也可能會采取同樣的策略，階段式地發布產品，讓測試人員可以提前測試，防止最后缺陷太多導致產品延期；而需求和設計人員又回過頭來用開發的進度和測試的缺陷率，來判斷產品應該消減功能換取上市時間，還是增加更多功能以換取競爭力。 可見**一個為外部目標奮斗的團隊，會很容易地團結起來，共同思考提升績效的最佳策略。** ? **質量：** “每月待處理質量問題數”咨詢過的一家ERP公司的實際數據（但他們尚未用這個數據考核），此數據一般符合瑞利分布，因此可預測未來的質量問題數量。 “每月終端用戶投訴數”適合消費電子、網絡游戲等與客戶比較緊密的行業。 “每月分銷商投訴數”適合渠道比較強勢的情況。 “每月論壇缺陷提出數”適合……我在的一家企業使用BBS免費處理缺陷。 用最終用戶提出的抱怨作為外部質量目標的策略，不是說大家不用測試了，把缺陷留給用戶。而是：**用我們測試了但仍漏給客戶讓其發現的缺陷，來修訂我們對缺陷的認識，修訂發現缺陷的方法。** 有很多產品，收到的客戶關于易用性的抱怨，遠遠多于對功能和常規缺陷的抱怨，就應該將“易用性差”作為核心的質量問題，進而作為質量重點。我在下載一款總體評價4星半的Android短信軟件時，發現近期的評價很多都是“越來越難用了”“沒用的功能越來越多”甚至“更新太頻繁了（給了1星）”等等，最近的一些評分平均估計會下降到4星以下。這些抱怨應該當作質量管理的最終考核標準，因為下載者無疑會根據這些評價來決定是否安裝軟件，而不是看那些“千行缺陷率”“測試人員發現缺陷數”。 **成本：** “產品實際投入產出”適合很長的戰線。 試想如果是手機研發，應該在開發階段就做好測試、維護、重刷系統等接口，另外應該優化性能以選擇低端硬件，否則整個產品極難保障盈利。 而且還會發生若軟件做得好（但軟件的研發成本要上升），則可以節省一些硬件資源或減免某些專用硬件的情況。這時候若要分別考核軟件部門和硬件部門，就很難實現了。 **需求：** “每月待處理需求數”咨詢過的一家ERP公司的實際數據，如果產品試銷售過程中此數據很大而且消退很慢（符合瑞利分布），則表明產品與客戶的需求不符。估計也能呈現一些易用性方面的因素。 “客戶尖叫度（Customer Screaming Rate）”蘋果成功的標志性績效指標，不談需求，因為他要超越需求。要學習這個很難，但要理解并體現其精神。 “軟件與硬件需求匹配度”適合消費電子，比如若硬件與軟件研發平行，則最終交付產品中交付的軟件和硬件應該匹配，而不能“18個功能中，硬件完成了12個，軟件完成了13個，但其中6個不重合（就是說這些功能交付不了）”，這樣軟硬件部門才會共同配合。 某手機廠商很擅長上一條，他們一年的200個項目中，只有3個延期，就是很好地利用了功能排序-軟硬件對齊的方法，犧牲次要功能保證上市時間。 **項目開發型** 產品做的多，項目做的少，不敢多說，請各位補充吧！ **為團隊設立外部績效目標的目的，是對齊團隊的不同角色、工序、人員的目標，從而互相幫助提升共同的績效。** 外部目標多數可以被客戶、用戶或市場明確感知，其提升幾乎意味著帶來收入的增加。如果想在測試人員發現Bug的時候發獎金但卻發現賬上沒有錢，那就改到客戶很少抱怨的時候發吧，那時候賬上肯定有錢。? ? 注：這是一篇舊文，因符合本系列的內容，在進行了很大改動后重新編輯發布在這里。 ? ?**本人正在參加CSDN博客之星評選，如果讀完并喜歡這篇文章，歡迎投票：**[http://vote.blog.csdn.net/item/blogstar/cheny_com](http://vote.blog.csdn.net/item/blogstar/cheny_com) ? 點擊下載免費的敏捷開發教材：《[火星人敏捷開發手冊](http://blog.csdn.net/cheny_com/article/details/6616794)》