時間都去哪了？　　

　　“不是在開會就是在去開會的路上”這是很多職業經理人工作的真實縮寫。然而事實往往是忙碌了一天，拖著疲憊的身軀回到家，回頭想想這一天雖然處理了不少事，但沒有一樣是真正完成的，所有的工作都是在進展中，而且越來越趨于復雜，依賴因素也越來越多。對于實現安排的完成日期也越來越沒有信心。

　　為什么會這樣？我們的團隊是不是哪里出了問題，導致效能這么低？在項目初期就給團隊樹立了明確的目標，但團隊都把時間用到哪里去了？

　　帶著這個問題，我們將一起探索團隊效能的問題癥結在哪，該如何提高團隊效能。

　　很多人會把效率和績效作為一個概念來評價團隊，其實它們是兩個完全不同的概念。

　　首先高效不是績效，也不應該是績效的考核指標。效率是用來評價一個人或團隊的工作效率，即完成每個任務的時間成本是多少。這是不會因為加班加點而提高的。

　　績效如果排除其他考核因素，僅從工作任務完成情況來看，績效是通過統計員工完成任務的總量和預期目標比較所得到的結果。管理者往往會忽略團隊成員到底花了多少時間完成那些任務，甚至鼓勵員工付出額外勞動來按期按質地實現任務，因為績效完全是結果導向的（這樣的管理者也往往是效能提高的最大障礙）。因此我們可以得出如下兩個效率和績效的公式：

　　效率 = 計劃完成的工作總量 / 實際時間成本

　　績效 = 周期內實際完成的工作總量 / 周期內計劃完成的工作總量

　　如果仔細比較，我們可以發現如果是在一個周期內，效率×績效=周期內實際完成的工作總量/實際時間成本，而這個值我們稱之為工作預估偏差。

　　到這里，估計大家能想到我們其中一部分時間去哪了。那就是工作預估偏差值（計劃工作總量－實際時間成本），如果這個值為負值，說明我們在加班；如果為正值，說明我們團隊效率不錯，還有多余時間。

　　看上去是這樣的道理，但上面這個公式不一定總是正確的。原因是當團隊面臨很多技術難題或者其他因素時，會增加任務緩沖值，從而讓估算偏差看上去總是正值。所以很多人會質疑這個值的可依據性。在敏捷開發模式里提出了一個很好的概念：故事點。

　　高效實踐一：故事點

　　故事點估算是敏捷項目任務的估算方法的一種，它是一種相對值，而且不是連續數也不和實際工作時間有直接關聯（具體可查看故事點介紹）。在敏捷開發模式中，特別是多團隊協作的情況下，項目經理可以把某個簡單任務設置為參照物，估算點為1。每個迭代周期之初，安排各團隊對所要開發的任務和參照物對比進行故事點估算。

　　通常情況下各個團隊的故事點分配總數是接近的，因為它是相對值，對于任務估算中的緩沖時間被同步放大或者縮小。因此項目經理通過故事點的管理比工時管理更為可靠，而且宏觀。

　　有了故事點，我們可以把團隊的績效用故事點來衡量。拋開這個不確定因素，我們的效率值或者估算偏差值就變得十分可靠。而讓估算偏差變為正值是我們建立高效團隊的目標。　　

　　如何改進估算偏差？

　　看過《一分鐘經理人》這本書的人，一定記得管理大師布蘭佳關于“一分鐘目標”這個說法：只花一分鐘的時間，就往往決定了這一天80%的工作內容，這是一個多么神奇的計劃。于是很多人也去嘗試做一分鐘的目標，然而并沒有描述的那么奏效，隨之就放棄了。事實上，很多人忽略了這是一個持續性的計劃，其實80%也是個人計劃中需要去達成的一個目標。這種計劃方法對于一個團隊，即使是大型團隊，花很少的時間來做一個當天目標設置其實同樣十分有效。而關鍵在于計劃的持續性和長期、中期、短期計劃的關聯。

　　這本書給我們另一個很好的概念：多短計劃。

　　高效實踐二：多短計劃（站會）

　　在我帶過的團隊里，都會采用多短計劃，每天早上或晚上進行15分鐘的短會。目的是讓每個團隊成員了解我們一天要進行的任務有哪些，有什么樣的問題需要相互協作解決，并確認是否存在計劃偏差。

　　事實上，團隊管理者更多關注的是任務的依賴性和計劃偏差；團隊成員關注的是當天任務計劃和存在問題。當團隊較多或每個團隊中人數較多時，對于團隊的每日狀態管理就是難點了。如果每個團隊有7個人，每個人平均有5個任務在進行（包括需求分析中、開發中、測試中、交付待確認等），任務之間存在相互依賴關系。那么對于管理者來說要掌握35個任務的進展狀態和他們的問題在哪里，同時還要關注任務之間的優先級關系。如果每個任務需要10分鐘，那么管理者可能花費將近350分鐘（將近6小時）的時間來查看或處理所有的任務項。這是多么恐怖的現狀！

　　對于每個團隊成員來說，除了自己關心的任務之外，還要關心對于別人的依賴任務和依賴別人的任務。如果每個人各有一項依賴和被依賴項，每天也至少花費20分鐘來處理。那對于團隊來說也存在至少140分鐘的溝通討論。

　　是否管理者和團隊的這些時間是必不可少的呢？答案當然是否定的。在團隊中，我們可以用看板很好地管理這些任務，幾乎可以在站會中一起解決這些事情。

　　高效實踐三：看板

　　看板來源于日本，是豐田精益生產中的一個工具。其原理是只有當下游的任務發出原材料請求時，上游工序才開始生產該原材料。如此形成了拉動式的制造工序，并努力實現零庫存。引入軟件開發工程后，生產過程中的材料就被轉化為工作任務項。每個任務要經歷準備→開發中→開發完成→測試→測試完成→部署這幾個階段。每個人員或者每個任務會形成一條自己的“泳道”（任務需要通過的路徑）。通過看板我們可以解決以下一些問題。

　　所有團隊成員的任務狀態清晰明了。

　　哪個階段積攢任務過多，說明是瓶頸所在。

　　集體更新的機制減少團隊1對1溝通次數。

　　可以收集過程數據，進行團隊效率改善。

　　看板所帶來的好處遠不止這些。但在看板使用過程中也要十分注意一個關鍵詞——WIP（Working inProgress）。它代表的是團隊在某個活動下同時進行的工作項的數量。從科學的角度，每個任務的完成周期（Cycle Time）越短，其從事這項工作的工作效率越高。而對于管理者注重的人員使用率（Utilization）來說，當一個任務較大時（Cycle較高），其Utilization也會降低。而無限細化任務會大大提高分析時間和溝通成本，因此作為統計值，每個人同時有2個任務時，其工作效率是最高的，如圖1所示。　　

　　影響效率的因素

　　有了一些實踐方法，并不一定能馬上提高團隊的效率，因為影響因素是多方面的，需要綜合長期的情況來看待效率問題。研發團隊中，效率的主要障礙來自以下幾個方面：

　　為快速交付積累的技術債；

　　團隊人員T形技術能力；

　　不穩定的開發節奏；

　　管理者的微觀管理；

　　低效的溝通成本，包括手工流程執行；

　　代碼質量。

　　此外還可能來自組織自身的因素，如部門壁壘、區域分布和文化差異等。對于任何影響效率的因素都值得重視。很多團隊就因為被其中一兩個因素羈絆住，而導致整體效率的下降。這種時候不能期待依賴于其他問題的改善來提升整體效率，這和木桶原理一樣。如果能夠正確快速地識別原因，那么剩下的就是如何解決問題了。

　　建立高效團隊的目標是發現消極因素，針對性地提出改進措施。管理者需要不斷地思考這些因素給團隊帶來的影響，以及和交付目標之間的平衡。對于發現的問題，刺激我們的是發現問題的原因。這需要借助系統思考（System Thinking）的一些技巧，即把事務的邏輯關系和來龍去脈進行分析，打破影響因素的環路。例如圖2的技術債問題，可以在任何環節中引出分支，即可消除滾雪球效應。

圖2 借助系統思考分析邏輯關系

　　通常，我們可以為此可以重點監控一些下面的過程數據，以便于對阻礙因素的改進：

　　UAT缺陷率；

　　缺陷周期長度；

　　版本開發和維護投入比；

　　各類會議所占開發時間比；

　　周期內知識共享和代碼走查次數；

　　自動化測試比例。

　　收集數據的目的不是為了根據現狀去設定目標，否則就是本末倒置了。其真正目的是可以用來做改善方向的依據。例如發現缺陷周期超過一周，說明一個缺陷從代碼簽入開始一周以后才能被檢測到，這是多么糟糕的事情。管理者應該思考如何加強對新簽入代碼的功能的檢測，如何在還沒有被集成到系統代碼之前，讓這樣的缺陷可以被修復。這樣才能減少不必要的溝通和二次發布的浪費。

　　管理者應該善于發現團隊浪費，但同時也要允許浪費。寧可讓團隊完成任務后打游戲來培養團隊協作能力，也不允許對于一個已經發現過的錯誤，再出現第二次。對此，一定要有個精神潔癖和偏執狂般的執著，才能給團隊帶來持續不斷的效率改進。

　　鄭立