聲明一下哈：這是裝逼，不是PMP課程，所以只吹我自己的實際經(jīng)驗，不要拿什么理論來套，我這人不跟書呆子說話的。

以下正文：

----------------------------

所謂任務分解也就是把一個項目的工作細分成具體的任務項，給任務項分配資源和時間，形成書面計劃的過程。

形成出來的文檔最常見的形式是甘特圖，不過不同的企業(yè)對它的稱呼五花八門，有叫甘特圖的，有叫schedule的，我見過的最奇葩的稱呼是管它叫：BOM，還不是一家，好幾家制造業(yè)的大企業(yè)都這么叫，他們好像喜歡把一切分解的東西都叫BOM，我也沿用這個稱謂吧，越是奇葩的越有逼格嘛。

形式誰都知道，PM都得做這個，不過水平那就是天上地下了。

至少有一半的PM做BOM純粹是因為要有個BOM交差，所以根本就是胡嘞的，他自己從一開始就沒打算按照這個執(zhí)行，如果甲方?jīng)]在項目開始時要求他先提交，他甚至會把這個東西拖到最后項目驗收時再編一個湊數(shù)。從骨子里他們就不認為任何項目是有可能按照計劃執(zhí)行的。

剩下一半的PM雖然是打算定一個可行的計劃的，但是做出來的東西看著事無巨細，一執(zhí)行起來完全控制不住。

任務細分的顆粒度特別重要，到底應該細分到什么程度？

菜鳥PM訂的計劃分解得特別細，恨不得細到每天上午干什么，下午干什么，中間幾點吃飯，幾點拉屎。然而，這樣的計劃是完全沒法嚴格執(zhí)行的，稍有一點意外計劃就偏離了，很快大家就發(fā)現(xiàn)幾乎每一件事都不可能按照計劃完成，反正偏離是常態(tài)，也就無所謂了，于是計劃就成了廢紙。

我一般會從幾個角度控制細分的顆粒度：

一是可度量性，也叫可交付性。一個任務項完成沒完成不能僅靠主觀判斷和口頭報告，你不能是只問一句：那個什么什么你干完了嗎？程序員跟你說：搞定了，那十有八九會豁邊。最好是能有個多邊形成的不能抵賴的書面文檔，比如一段程序的代碼，我會選擇以測試報告作為交付物，程序員提交了，測試組通過了，雙方簽字，這個活算干完。所以，工作計劃太細了就有問題了，你不能幾點鐘去拉屎也簽個拉屎報告吧？文檔過多，雙方都很煩，項目也會陷入繁文縟節(jié)，效率低下。

二是應該與你的項目檢查周期相匹配。所有的項目都應該有固定的項目檢查周期，有的是每天開例會，有的是每周開，甚至還有的每月開。如果連這個都不搞的PM那就該去死了，不過，講真，根據(jù)我的經(jīng)驗，真的有七成以上的項目真的沒有這個制度。沒這個制度咱就沒話講了，能堅持這個制度的咱們可以繼續(xù)往下說。

假定你一天開一次例會，而你分解出來的任務項的周期也就半天一天，結(jié)果是什么？例會中每一個報告的問題都一定已經(jīng)逾期了?。∷?，再怎么說任務項也應該有至少三天的周期：頭天開會報告說有困難，第二天你安排資源支持，齊心協(xié)力努力，第三天把問題克服了，一看，正好把進度追平，計劃三天，實際三天達成，幫忙的有成就感，被幫忙的進度趕上包袱卸了也如釋重負，完美。

所以，我一般會把顆粒度控制到每個任務項的周期大約在三倍到五倍檢查周期之間。太粗了沒壓力，問題暴露不出來，一出來就是一堆；太細了，一出問題就超期，根本沒有補救機會。

三是應該任務明確到人，最好一個任務項只有一個執(zhí)行者，責任才明確，三五個人負責一件事，看著人多力量大，實際上出了問題互相推責任，誰也不負責。

另外一個問題是任務怎么分？不同的人有不同的辦法。

如果你本身是領(lǐng)域?qū)＜?，那這事兒簡單，什么時間該干什么你都門兒清，當然很容易就能把計劃定出來。然而萬一你不是呢？其實也不難，那就項目組成員一起商量唄，坐在一塊兒，一起討論，先干啥再干啥，計劃不就有了嗎？

然而，這個世界真的是很奇葩的，真的是有很多牛逼的銷售能把客戶忽悠得團團轉(zhuǎn)，拿到一些自己根本就不會做的項目，項目組的一群人都特么不知道該咋干，你別不信，至少有一半以上的項目都是這樣的，一群人胡屌亂搞，最后想辦法再跟拿單子時候一樣，在KTV夜總會里把客戶搞定，然后也能順利驗收。

然而，總會有個別油鹽不進的客戶，甚至還有拔屌無情的，于是這時候就需要有臨危受命的救場PM出現(xiàn)來拯救地球了。

救場PM的工作環(huán)境險惡程度不是一般人能承受的，經(jīng)常是兩年的項目最后剩一個月了，完成度還不到50%，而客戶的信任度已經(jīng)降到了零，項目團隊成員的心態(tài)則已經(jīng)徹底崩壞，一半多的人已經(jīng)交了辭職報告只是還被公司扣著錢。

我干過三四次這種活，當然，你們碰到這種事不要打我的主意哈，這種事我都是要天價的。技巧我可以跟你們說說，你們自己想辦法，實在想不出辦法愿意出天價了再來找我。

這種時候千萬不能亂，越是危局越不能頭痛醫(yī)頭腳痛醫(yī)腳，你必須在最短的時間內(nèi)制定出一個可行的拯救計劃，并且重新恢復客戶和項目成員的信心，這個計劃一般是issue based。

第一步是搜集問題，我一般是立即召集項目成員和甲方一起review項目，把所有存在的問題匯總出來，開著投影機，打開excel，他們說一個我記錄一項。

第二步是責任到人，每個問題確定一下誰負責，excel加一列，把責任人填在問題后面。

第三步是制定時間計劃，在問題表最前面加一行，然后再責任人后面那一列上填上日期數(shù)字，剩多少天填多少格，然后把這些列拉窄成方格。挨個人問，你打算先做哪一項？需要多少時間，哪天開始哪天完成，然后把對應的單元格設(shè)置成代表他的顏色。

每次我干到這里，客戶都瞪大了眼睛說：excel到你手里就好像活了一樣。

然后就是每天例會review進度，任務開始了，就在對應的格子里填上S,執(zhí)行中填X，暫停填P，完成填F，這樣背景色就是計劃進度，而字母串就是實際進度，完美。

當然，不可能有了計劃就能保證項目完成，不過今天的主題是談任務分解，所以，說到這里可以了。關(guān)于具體執(zhí)行，如果你們愛聽的話，我以后接著吹。

然而，其實不管是用那種方式制定的計劃，如果只是你的計劃，你知道客戶知道顯然是沒用的，你必須跟所有項目成員一起開個會，聽聽他們的意見，如果有不同意見就商量著調(diào)整，其實這個時候可以順著他們一點，只要最終的定出來的計劃能夠滿足周期要求就行，因為這個會的唯一目的是：讓他們買單。

是的，這個時候你需要他們給你一個承諾，承認這個計劃是跟他一起定的，他承諾可以完成，這是日后盯他的基礎(chǔ)，否則日后他一句：“你的計劃是胡定的，狗屁不通，老子根本做不到！”，你咋辦？

今天的內(nèi)容就差不多了，最后不得不說：項目成員，尤其是年輕人，有低估工時的共性，一般他們說一天能完成的事情，你排三天，基本上他緊趕慢趕正好能趕上。老油子偏差小一些，不過除了銷售，我還沒碰到高估工時的。???