項目管理（一）任務分配 - freeflying－IT工程師數位筆記本

文章出處

之前寫過一篇，不滿意，重寫如下：

管理一般說來，就三件事：管人，管事，還有管錢。而這三者其實又是聯系起來的，比如，我們可以說：讓合適的人做合適的事，并給他合適的錢。那么，問題就轉化為：怎么才算“合適”呢？

困境

有一些人的管理工作隨意散漫，但他們振振有詞，“管理是一門藝術”。我覺得，他們應該仔細區別一下，錯落有致和雜亂無章，簡約清爽和粗枝大葉……

或許他們還信奉權謀之道，用人嘛，“打個巴掌，給個棗吃”。你在用驢呢？稍微有點想法的就會不服，憑什么打我一巴掌？稀罕你這顆棗子呢？把爺當傻子耍？去你媽的！

利益面前誰都不傻，靠陰謀算計小心思，只會造成管理者和被管理者之間的復雜博弈。簡單點說，就是勾心斗角陽奉陰違。你以為你在玩他，他其實悄悄在玩你，搞成了宮斗權謀，一片烏煙瘴氣。

我們從一個最簡單的例子說起。一件功能，交給張三去完成，給他三天時間。提前完成了有獎，超時罰錢扣工資。任務布置得清晰明了，而且賞罰分明，是不是？管理就這么簡單。

凡是這么想的人，一定是沒有搞過管理工作的。

中間可能出現的突發情況太多了。三天過后，任務還沒有完成。你火了，問為什么？一堆的理由：任務難度太大，工作量太多，李四不配合，理解錯了你的意思，中間出現了什么突發情況……反正都不是他的責任。他說得這么有道理，你處罰試試看？沒過幾天你就孤家寡人光桿司令一個。所以，最可能的情況是，問一下原因，埋怨兩句，給他擦干凈屁股，然后照樣稀里糊涂的過日子吧！

胸有成竹

上述管理者困境的一個重要原因，就是管理者自己都不清楚：分配下去的任務，難度有多大，工作量有多少，可能出現的情況有哪些……自己都是一本糊涂賬，怎么可能管好別人？

我們常常說管理人員要有威信。威信是怎么建立起來的？工作起來要胸有成竹，而不是稀里糊涂的把任務布置下去之后，遇到問題一問三不知，瞎指揮窮折騰。這樣次數多了，下面的人自然不服，“聰明”點的就開始動心思糊弄了……

話是這么說，但具體到我們軟件開發中的項目管理，胸有成竹就不那么容易了。

以項目預算為例，我從來沒看到過一份清清爽爽的軟件項目預算表。

先看報價。都是做工程，比如建筑工程，根據圖紙，材料人工，一項一項的清單報價，不管多大的工程，價格算出來都是精確到分的，比如1080732.76元；但軟件開發，合同能精確到百，都不錯了，一般都是20萬、 3500之類的，感覺在價格就是隨口喊出來的一樣。

再說工期。建筑工程，誤了工期，時間稍微長一點，違約金都賠不起。軟件開發，延期延期再延期，才是常態，是吧？即使勉強交貨，那都是蒙人的，里面bug一大堆，先交了貨，再慢慢“維護”吧！

想來主要有兩點原因：

開發工作本身是一種創造性勞動。不像流水線上的工人擰螺絲釘，或者建筑工地上的工人砌墻搬磚，都是重復性勞動。雖然我們很多同學自嘲其工作為搬磚，但我們搬磚過來之后還是要砌成不同形狀花樣的，而不是千遍一律的一堵墻。所以，很多問題，只能在開發過程中才會暴露出來，解決的難度工作量都是一個未知數。
不斷的需求變更。這個就不多說了，大家都懂的。

所以項目負責人對項目的細節沒有切實的把控，只能憑著“經驗”或者“想象”來大致的“估算”項目的工作量。而事實證明，這種估算是相當不靠譜的。

切分

處理一個復雜的事物，最常用的手段，就是把他切分成一個一個簡單的部分。針對項目管理而言，我們推薦的，就是做任務切分。

這其實是一個必須得做的工作！區別只在于你是主動還是被動，是認認真真還是敷衍了事的在做。別說是一個團隊，必須得分工配合；就算是你一個開發，先做什么再做什么，你心里也得有個數吧？

只是很少有人專門花時間和精力，有意識的來做這件事。因為我們對于項目管理中“計劃安排”的理解還不夠深刻。

根據我的項目實踐經驗，深入細致的任務切分，能夠幫助我們：

真正的厘清需求。在“切”任務的過程中，以前朦朦朧朧的概念，才會一點點的清晰起來。
能夠“糾錯”。清晰過后，一些疏漏錯誤也就自然而然的暴露出來了。就應該相應的調整進度計劃等。
合理的安排人手。團隊中每個人的水平都是參差不齊的。任務切分之后，簡單的重復性工作分配給新手，復雜的有挑戰性的給大神，大家都滿意，開發成本也能隨之降低。但如果沒有有效切分，難的和簡單的混在一起，是區分不出來的。
對開發人員有指導作用。我用的都不是高手大牛，但他們新人也可以順著這個路子一步一步的做下去，至少其中一些簡單的部分可以做起來，復雜的幫幫忙就行了。

總之，切分完任務，對這個項目，基本上就心中有數啦。如果說“管理藝術”，游刃有余的分配安排任務，像庖丁解牛一樣，“以無厚入有間”，游刃有余，這才能給人一種愉快的藝術享受！

精細化

我極力主張：把任務要切分到盡量小的的粒度，比如一個任務20分鐘左右，最多不超過60分鐘。當然，很多同學擔心這樣做的成本太高，是不是項目經理一天到晚就切任務去了，不用干別的了？

這是一個值得討論的問題。粒度越細，可控性越高；但是也要考慮成本，過猶不及。這個應該是根據項目具體情況，靈活掌握。

這里我只分享一下我的一個變通處理實踐：你也可以讓開發人員自己進行任務切分，你在任務驗收時同時核查任務的難度、工作量等。（如果你需要考核的話，因為這時候代碼都已經提交review了，算是水落石出，做復核工作量其實很少了，所以開發人員一般也不會亂來）

但這里有一個小問題，就是開發人員開始可能會抵觸這種做法。他們會認為切分任務和寫文檔、寫注釋、寫日報周報一樣，是無用的工作。

道理當然要講，但最好還是事實說話。

我隨你的便，但只有一個要求，你先把你要花多少時間告訴我。他說行，比如一個功能點，他信心滿滿的說，“2小時夠了”。結果夠個屁！哈哈，他兩天都搞不出來。我就要找他說為什么了呀？東一榔頭西一棒，他怎么說得清楚？焦頭爛額之后，他自己去體會。多嘗試幾次之后，外加他技術水平的逐步提高（切任務不是個簡單活，很考功力的），最后他也養成了習慣：敲代碼之前，先切任務。其實這就是一個理思路的過程，哪怕是純coding，做之前思路清晰了，也能事半功倍。“磨刀不誤砍柴工”，說的就是這個道理。

應對變化

有人覺得這樣做不值得。你辛辛苦苦的分任務，做計劃，需求變了呢？或者出現了其他情況呢？計劃是不是就白費了？越完善詳盡的計劃越不可能實現……

這些倒都是經驗之談。現實確實如此，“計劃永遠沒有變化快”！但是不是就可以證明，我們不需要計劃了呢？讓我們靜下心來仔細分析一下。

首先，無論如何，首先肯定要有一個計劃。公司要簽合同要有金額工期，項目經理要報項目安排，程序員也要在deadline之前完成手頭的工作……無論你愿不愿意，這是一個客觀要求，很難逃避的東西，是不是？

那么，為什么我們很多人提起計劃就頭痛，特別反感計劃呢？我覺得，很大一個原因是因為：計劃被濫用。

比如被要求寫這些日計劃周計劃月計劃，寫的時候就不情愿，感覺多此一舉；更何況要是沒能按計劃完成，還要被要求說為什么！太多為什么了，怎么說得完？真要說呢，又會被批評“為失敗找借口”，煩死啦！所以就做個假計劃大計劃空計劃之類的東西敷衍一下完事……

這種做法有幾個問題：

僵化的看待計劃。管理者認為計劃一旦指定，就一成不變的、必須絲絲入扣的完成；甚至把計劃當成了監督鞭策員工努力工作的東西。這肯定是行不通的，其實，既然是計劃，就意味著它還沒有被實現；需要制定計劃，就說明實現是有不確定性的。很確定性的東西，比如明天早上8點鐘我要到公司上班，這種事情根本不需要計劃；下周我要去海南島環島游，從來沒去過，可能有很多突發情況，這才需要計劃！這個計劃就可能受天氣、自己的身體狀況等一系列的因素影響而無法百分百實現；但無論有無突發情況，我有機會肯定比沒計劃強。為什么就大家自己想一想吧？
計劃制定者指定不當。讓能力一般的底層工作者指定計劃，實在是有些強人所難。計劃不是那么好制定的，讓你制定一個攀登珠穆朗瑪峰的計劃靠譜么？雖然說coding是程序員的工作，但他們很多時候，編碼還是在摸著石頭過河，走一步看一步而已。所以，制定計劃這種走一步看三步的工作，還是項目經理，或者經驗豐富的程序員來做更貼切一些。

所以，我們必須明白：計劃制定出來，就是被破壞的。計劃沒能按預期執行，并不說明他們沒有用。實際情況發生了變化，計劃就應該相應的調整；但這種調整應該是有序的可控的，而不是胡亂的調整。有序的調整能夠最終保證大任務的順利完成；而無序的調整，只會把事情搞得一團糟。怎么樣才能夠有序？還是要有計劃！一份計劃，就像一張圖紙一樣，出了情況，鋪開圖紙，圈出出相應的部分，結合周圍的情況，考慮一個妥善的解決的辦法……而不是一堆人你一句我一句，天馬行空，公說公有理婆說婆有理，亂哄哄的不可開交。

任務管理系統就能夠幫助我們及時迅速的應對各種變化。除了可以提供自動化的統計分析以外，更因為項目已經被有效的切分。

如果你的計劃是一個不可分割的整體，犬牙交錯，牽一發而動全身的那種，那么當然，每一次改動必然都是一次傷筋動骨的大折騰。

但通過良好組織的任務切分，改動就可以被有效的對應到相應的計劃部分。這時候，每一次的改動就是一個局部的改動，是非常容易被重新計量評估的。比如，某次改動，會影響原任務3098-4012，原任務3876-3879，任務量共計480分鐘；改動新增任務 5678-5894，任務量共計300分鐘；所以任務總量減少180分鐘，非常清晰。