靈活開發績效管理之四：為團隊設立外部績效目标（目标管理，外向型績效）

這是靈活開發績效管理的第四篇。

最近在看德魯克的書，發現其中很明确地寫着“企業的績效隻存在于外部，而企業内部隻有成本”的概念和說法，下面結合靈活開發團隊的績效考核展開談談。

靈活開發有很多“外向型”思維，比如：關注客戶價值，認為可傳遞的産品才是真正能表征工作進展的因素等等，但尚未直接與目标管理接軌。外向性思維可以防止部門間壁壘或踢皮球，而轉而共同讨論對外傳遞價值，從下面的對比可以看出這點。

“内向型”績效及其導向

進度：“各階段按時完成率”會導緻分析和設計人員草草結束工作，而将大量不确定工作推給開發人員；開發人員則如法炮制，把延期踢給測試人員。

品質：“千行代碼缺陷率”會導緻開發人員在很多“是否是缺陷”問題上與測試人員争執不下，另外一些次要的如使用不便、不直覺等問題則被長期擱置。

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

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

此外還有一些更可怕的資料，比如“每月生産的代碼行數”“每月生産的功能點或故事點數”（這個很有迷惑性）“每月修改的缺陷數”等，都是不恰當的績效。德魯克“企業内部隻有成本”的理念指出，無論是文檔，代碼，可運作軟體乃至最終産品，若尚未被銷售，都隻是成本的一部分。

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

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

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

外向型績效

下面是一些潛在的“外向型”績效，由于之前提過不同企業乃至産品的外向型績效差别很大，請靈活運用。

産品研發型

進度：

“與競争對手相比同檔産品的上市日期比較”适合消費電子類産品。

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

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

需求和設計人員為了能讓開發人員提前開工，可以采取分段寫需求和設計的方法，把最影響架構又最不會發生變化的部分先寫出來，讓開發人員提前開工幹活；而開發人員也可能會采取同樣的政策，階段式地釋出産品，讓測試人員可以提前測試，防止最後缺陷太多導緻産品延期；而需求和設計人員又回過頭來用開發的進度和測試的缺陷率，來判斷産品應該消減功能換取上市時間，還是增加更多功能以換取競争力。

可見一個為外部目标奮鬥的團隊，會很容易地團結起來，共同思考提升績效的最佳政策。

品質：

“每月待處理品質問題數”咨詢過的一家ERP公司的實際資料（但他們尚未用這個資料考核），此資料一般符合瑞利分布，是以可預測未來的品質問題數量。

“每月終端使用者投訴數”适合消費電子、網絡遊戲等與客戶比較緊密的行業。

“每月分銷商投訴數”适合管道比較強勢的情況。

“每月論壇缺陷提出數”适合……我在的一家企業使用BBS免費處理缺陷。

用最終使用者提出的抱怨作為外部品質目标的政策，不是說大家不用測試了，把缺陷留給使用者。而是：用我們測試了但仍漏給客戶讓其發現的缺陷，來修訂我們對缺陷的認識，修訂發現缺陷的方法。

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

成本：

“産品實際投入産出”适合很長的戰線。

試想如果是手機研發，應該在開發階段就做好測試、維護、重刷系統等接口，另外應該優化性能以選擇低端硬體，否則整個産品極難保障盈利。

而且還會發生若軟體做得好（但軟體的研發成本要上升），則可以節省一些硬體資源或減免某些專用硬體的情況。這時候若要分别考核軟體部門和硬體部門，就很難實作了。

需求：

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

“客戶尖叫度（Customer Screaming Rate）”蘋果成功的标志性績效名額，不談需求，因為他要超越需求。要學習這個很難，但要了解并展現其精神。

“軟體與硬體需求比對度”适合消費電子，比如若硬體與軟體研發平行，則最終傳遞産品中傳遞的軟體和硬體應該比對，而不能“18個功能中，硬體完成了12個，軟體完成了13個，但其中6個不重合（就是說這些功能傳遞不了）”，這樣軟硬體部門才會共同配合。

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

項目開發型

産品做的多，項目做的少，不敢多說，請各位補充吧！

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