8 年前我們如是做：開發任務分配的雙向選擇

Bi-directional Task Assignment

8 年前，張恂帶領的團隊就做到了員工任務的自願/自主分配。在這一點上，可以說，我們在 8 年前就做到了敏捷，而且是中國式的敏捷。

問題

在 InfoQ 的這份報告 中，兩個失敗案例都明顯在 'daily' scrum 和任務分配上犯了常見的錯誤。

一種情況是，管理者“熱心”過度，天天盯著任務分配，結果讓軟體開發工作變得索然無味，甚至令人噁心。

每個員工都要在早上固定時間開Daily Scrum，然後把當天的任務告訴給他，讓他來決定工作是不是飽滿。這個把彈性工作制直接給破壞了，引起很多人反感；另一點就是很多人認為這樣的Daily Report太頻繁太低效，而且還有壓榨員工的嫌疑。

第二種情況是，管理者熱度不夠，恣意放羊，結果讓專案開發偏離正軌，一撒不可收拾。

以上兩種情況，恰好形成兩個極端，名義上號稱敏捷，實則背離了敏捷的基本原則。由外行“專家”來領導敏捷實施，必然是這種結果。

當今的西式敏捷方法非常強調員工的自願工作，主動性不受干擾，同時提倡團隊文化和集體主義精神（whole-team）。那麼，我們本土的中式敏捷又是如何做的呢？以下僅舉一例。

具體做法

作為管理者和架構師，我把周任務根據難易程度，分別打上不同的分值（比方 1-10 分），把任務表貼在開發現場 open space 的白板上，在開周例會的時候，由團隊成員自主選擇。

這些每週的開發任務是由大家 brainstorming 共同討論出來的，當然主要部分由架構師建議，最後由管理者綜合大家的意見定奪。

為了防止出現任務分配上的不均、不合理情況，在員工自主選擇的基礎上，我們還設定了一些指定任務，由管理者根據員工的實際情況和專案需要分配給員工。

因而這實際上是一種員工任務分配的“雙向選擇”。

考核

員工每月完成任務的數量和質量情況，是績效考核的基礎和主要指標。

有了員工任務的自主選擇，月末考核就方便多了，有了更公平、公開和客觀的依據。我們把員工每月完成的有效任務分值累加起來，就是他完成的月總工作量。這一結果是完全公開、透明的，誰完成的任務數多，質量好，誰的總分就高。

為了在任務考核中反映質量要素，計算有效任務分值，我們加上了質量因子。設原任務分值為 5 分，如果完成得好，達到了質量要求，那麼質量因子為 1，有效任務分還是 5 分；如果完成效果不好，質量因子只有 0.7，那麼有效任務就只有 3.5 分。

管理者還可以根據需要，新增其他的權重因子和靈活措施。比方，為了鼓勵員工之間的緊密合作，互幫互助，我們還約定，任務分值可以贈送，別人幫助你完成工作，你可以把相應的分值送給他，記在他名下。另外，根據團隊文化建設的需要，我們還設立了一些額外的獎勵分。在實踐中，贈送分、獎勵分應用得也較為普遍。

當然，最重要的一點，這整套任務分配和考核辦法是由管理者提議，所有團隊成員大家共同協商討論，認為公平、合理之後，一致通過和支援的，這樣就有了良好的群眾基礎，並且在實施中得到了不斷改進和完善。

效果

您可能很關心我們實施的效果怎麼樣，回答是：出奇的好！

有了這樣一種機制，必然會在員工中間形成一種攀比，比誰完成的任務分值高，而這種攀比恰恰符合團隊的整體利益，也是管理者所樂見的。

與其他採取傳統措施的團隊相比，張恂團隊的同事們參加計劃會議的熱情非常高，每次都是搶著要任務，而且往往勇於挑戰分值較高的任務，每個人都生怕自己的任務不飽和，影響了個人月底考核的總成績（間接地影響 bonus）。

關鍵一點，我們把原本看似枯燥乏味的軟體開發工作，變成了一種近似體育競賽的團體合作遊戲，結果導致每個人在工作時都熱情飽滿，興致勃勃，這也算是實施此方法後的一種意外收穫。

顯然，這與過去由經理們主觀生硬地（尤其是根據 WBS）設計任務，向員工指派任務，而月末考核客觀依據又不足的局面大不相同，可以說是一種徹底的轉變。

我想這種措施的成功，由專案管理者絞盡腦汁生硬地把任務指派給員工，到員工積極地想任務、要任務、搶任務（這一現象真的就發生在張恂的團隊中），其實也是一種逆向思維驅使下，管理方法創新的成功。

讀者朋友，您在團隊任務的分配方面是怎麼做的，有什麼創新的好方法、好思路？歡迎來信交流。

敏捷 OO 教練 張恂
www.zhangxun.com
2008 版權所有

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13633641/viewspace-235561/，如需轉載，請註明出處，否則將追究法律責任。