敏捷Team Dev績效管理與目標管理：關於如何為團隊設立外部目標

作者：陳勇

出處：blog.csdn.net/cheny_com

 

最近在看德魯克的書，發現其中很明確地寫著“企業的績效只存在於外部，而企業內部只有成本”的概念和說法，下面結合敏捷Team Dev的績效考核展開談談。

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

 

“內向型”績效及其導向

進度：“各階段按時完成率”會導致分析和設計人員草草結束工作，而將大量不確定工作推給開發人員。

筆者給一家銀行做諮詢的時候其獨立測試團隊就多次提到開發組會擅自延長開發工期，而不可延遲的交付點會將測試工期大大壓縮。

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

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

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

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

 

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

產品研髮型

進度：

“與競爭者相比同檔產品的上市日期比較”適合消費電子類產品。

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

品質：

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

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

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

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

成本：

“產品實際投入產出”適合很長的戰線，試想如果是手機研發，應該在開發階段就做好測試、維護、重刷系統等介面，另外應該最佳化效能以選擇低端硬體，否則整個產品極難保障盈利。

需求：

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

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

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

 

項目開發型

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

 

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