來源：西西吹雪的部落格
我經常聽到老闆經批評專案經理，做事一點章法也沒有。所謂章法，就好比武術中的招式或套路，做專案沒有章法，就會胡亂出招，專案要取得成功，那就好像猴子用打字機打出莎士比亞的作品一樣希望渺茫。
要說專案管理的招式，最受歡迎的當數美國專案管理協會的《專案管理知識體系指南》（PMBok）了，他們提出的“九大領域、五大過程組和四十二個過程”，風靡天下，不懂一些的話，你不都好意思說你是專案經理。現在PMBok已經成為專案管理界的公認的全球性標準，國際標準化組織（ISO）以它為框架，制定了ISO10006標準。
一、專案經理成長的五個階段
一個優秀專案經理煉成，並不是一朝一夕的事。特別是對於從程式設計師轉型過來的情況，受制於其原有的思維方式、知識體系、管理經驗乃至性格缺陷，往往要經過很長時間的才能逐漸勝任。我將這一過程分為五個階段，每個階段實際上也代表了一種型別的專案經理，以及專案管理的一層境界。
1. 混沌階段
他們剛剛從程式設計師崗位上提拔為專案經理，也沒有學習過專案管理知識，對專案管理完全處於是懵懂無知的狀態。管專案基本上靠被動的等事情做，憑感覺去做，更可怕的是連感覺也沒有。
如果用娃娃學走的來打比方的話，他們現在還是在襁褓中躺著睡覺的狀態。如果專案就是一場馬拉松，他們是沒有機會到達目的地了，最後的結果只能是他的上司抱起他上路了。
2. 覺醒階段
終於睡醒了，工作從被動到主動，這是一個巨大的飛躍。他們往往會維護一個事務列表，雖然這個列表往往只是專案的一部分工作，但比沒有還要強多了。在他們眼裡專案即等於產品，他們會有意識的將產品進行分解，按模組分給其他人做，然後一直往下做，什麼到什麼時候算什麼時候，他們做事沒有計劃性。
他們算是會爬了。爬是慢了點，但總一天會到達終點的——如果有毅力能堅持足夠長時間的話。
3. 入門階段
處於入門階段的專案經理，會有意識將專案劃分為若干階段，確定每階段的可交付成果，並制定專案制定里程碑；有意識制定計劃，並且希望按計劃去做。對專案管理理論有一定了解，但缺乏深入理解。他們會有意識關注三大目標。他們的薄弱環節是控制和領導能力差，自己卻沒有意識到這一點，反倒將專案中的問題歸咎於外部因素。許多有數年專案管理經驗的專案經理仍然停留在這一階段，這是因為他們不求上進的原故，以為天下的專案就只能做成這樣了。
他們會走了。專案最終總是可以幹到驗收的，但返工或重做的現象經常會出現，並且往往員工的士氣欠佳，其戰鬥力並不能充分的發揮出來。
4. 全面發展階段
這一階段專案經理不但具有比較豐富的實踐經驗，而且掌握了完整的專案管理理論知識，通過長期的學習、實踐、思考、領悟、再實踐，各方面的技能已經臻於完善。能顧及到專案中的方方面面，技能也比較全面，對專案控制和團隊領導也頗有心得。
他們會跑了。是的，他們確實已經很優秀了，但我認為，到這一階段才稱得上真正合格的專案經理，你也許會覺得要求太高了，但馬拉松賽場上的選手必須是跑著的，走完是贏不了比賽的。
5. 融會貫通階段
他們邏輯性強，領導能力極強。他們不是照搬書上教導的知識來管理專案，而是憑藉直覺，就能準確的把握專案中潛在的問題，並採取預防措施。他們有著非凡的領導能力，員工不但工作富有成效，而且能工作中得到快樂。到達這種境界，不僅是靠勤奮，還要靠天分。
這一類專案經理，不能用走路來形容他們了，他們就像天上的鳥兒一樣，自由自在的飛翔。
二、把專案管理大卸九塊
PMBok並不是專家們書房裡琢磨出來的神祕東西，而中是將我們日常做事的方法進行提煉而已，專案管理本質是就是一套做事的思想和方法。PMBok將專案管理分為九大知識領域，其實也我們平時做事的思維息息相關。
我第一次參加專案管理培訓的時候，那位老師非常循循善誘。第一天課堂上有一次令人難忘的對話：
老師問：“同學們，現在假設領導把你請到他的辦公室，說請你做一件事事，你會問哪些問題呢？”
學生們紛紛回答：“具體要做什麼事情，要求什麼時候做完，做成什麼樣，還有有哪些人來做”
老師說：“很好。那對於自己做不了的事情，怎麼辦呢？”
學生：“請別人做！”
老師：“Very good!如果很多人一起來做一件事情，最重要的是什麼？”
學生說：“每個人協調一致，統一思想和行動。”
老師：“Excellent!除了上面這些，還有什麼需要考慮的嗎？”
沉默片刻後，有一位學生回答道：“還要考慮一些可能會出現的問題。”
另一位學生接著回答說：“還要對所有的工作進行總體把控。”
老師驚喜的說：“Perfect!同學們，你們已經把專案管理的九大領域給總結出來了！請看下面這張幻燈片…”
老師展示的是這樣的一張圖：
這就是專案管理的九大領域：整合管理、範圍管理、時間管理、費用管理、質量管理、人力資源管理、溝通管理、風險管理、採購管理。
專案管理好像一頭大象，將其大卸九塊之後，要裝進冰箱就容易多了。
看看書上是怎樣解釋這九大領域的：
●整合管理：包括識別、確定、結合、統一與協調各專案管理過程組內不同過程與專案管理活動所需進行的各種過程和活動。●範圍管理：確保專案包括成功完成專案所需的全部工作，但又只包括必須完成的工作的各個過程。●時間管理：包括使專案按時完成必須實施的各項過程。●費用管理：包括涉及費用規劃、估算、預算、控制的過程，以便保證能在已批准的預算內完成專案。●質量管理：包括保證專案滿足原先規定的各項要求所需的執行組織的活動，即決定質量方針、目標與責任的所有活動，並通過諸如質量規劃、質量保證、質量控制、質量持續改進等方針、程式和過程來實施質量體系。●人力資源管理：包括專案團隊組建和管理的各個過程。●溝通管理：包括保證及時與恰當地生成、蒐集、傳播、儲存、檢索和最終處置專案資訊的所需的過程。●風險管理：包括專案風險管理規劃、風險識別、分析、應對和監控的過程。●採購管理：包括從專案團隊外部購買或獲得為完成工作所需的產品、服務或成果的過程。
三、五招四十二式
要把大象裝進冰箱，分成九塊還是太大了，還得切小一點。因此在PMBok第四版中，又將九大知識領域細分為42個過程，這些過程可以分為5個組，啟動過程組、規劃過程組、執行過程組、監控過程組和收尾過程組。這五大過程組42個過程，就是武術中的招式，可以直接用來實戰中了，因此不妨稱之為“五招四十二式”。
這一節牽涉到比較多的專案管理理論知識，如果你完全沒有接觸的過的話，讀起來可能會比較困難，建議先啃一遍PMBok，或者跳過本節。
1. 五大過程組
五大過程組與九大領域一樣，同樣體現了做事的邏輯，只不過角度有所不同：
●啟動：確定是否要做，以及做什麼●規劃：打算怎麼做● 執行：按照計劃去做●控制：做對了沒有●收尾：做完了收工
可以看出，這是一個完整的做事流程。其中啟動和收尾一進一出、一頭一尾，就像我們常說的“做事要善始善終”，而規劃、執行和監控則是專案的主體，與著名的“戴明環”（即PDCA迴圈）相對應，構成了一個迴圈。
在PMBok中用下面這張圖來描述五大過程組：
圖 PMBok中的五大過程組關係圖（出自PMBok）
有人將五大過程組畫成這個樣子：
圖 網上流傳的五大過程組關係圖
這張圖廣泛流傳，但它其實是有問題的，就是把監控弱化了。跟PMBok中的原圖比較，在這張圖中，只有執行屬於監控的範圍，而在原圖中，啟動、規劃、執行和收尾都是監控的物件，很明顯，原圖更加嚴謹。
很多人分不清五大過程組與專案生命週期的關係，兩個概念確實比較容易混淆。生命週期，也是就一件事物從開始到結所經歷的階段，一個人的生命週期包括嬰兒、兒童、少年、青年、中年、老年等幾個階段，專案也可以這樣來分。為什麼五大過程組和專案生命週期容易混淆呢？關鍵在於大過程組看上去很像是專案的幾大階段：啟動→規劃→執行→收尾，然而兩者之間有著巨大的差異：
●生命週期是從時間維度來描述專案管理，而五大過程組則是從職能的維度來理解的，告訴專案經理應該做哪些工作：專案經理你要做專案啟動的工作、你要制定專案計劃、你要組織和指導大家開展實施工作、你要監控專案、最後不要忘了做收尾工作！●五大過程組還體現在了專案的過程化思想，五大過程組本身即具有“輸入-處理-輸出”的關係（啟動為輸入，收尾為輸出），而生命週期僅是前後貫通的時間序列。●生命週期是前後連線的階段，而五大過程組是一個有進有出的環，在專案中大環套小環，有點像套娃娃。整個專案可按五大過程組的思路來開展，每個生命週期的階段也可以，甚至一項細化的開發任務也可以。
圖 專案過程組與生命週期的關係（出自PMBok）
五大過程組與生命週期同時也存在緊密的聯絡。實際上，啟動過程組在專案生命週期的開始階段作用最為強烈，收尾過程組主要作用於接近完成的階段，而規劃、執行和監控過程組則主要作用於專案的建設實施階段，如下圖所示：
圖生命週期與專案過程組的相互作用關係（出自PMBok）
2. 四十二個過程
現在我們知道了專案管理有九大知識領域和五大過程組，那專案經理具體要做哪些事情呢？那就要看專案管理的42個過程了，做什麼、用什麼方法做、做出什麼成果全在這裡，這對於那些像無頭蒼蠅一樣到處亂飛亂撞的專案經理來說，簡直就是雪中送炭啊。然而別高興得太早，早就聽說過PMBok很難啃，它難也就難在這42個過程，每個過程都由輸入、工具和技術、輸出組成，千篇一律，就如同經書一般乏味，估計你看兩個過程就會昏昏欲睡，所有以我也叫它“四十二章經”。
看一看42個過程的分佈情況：
|
知識領域 |
專案管理過程組 |
合計 |
||||
|
啟動過程組 |
規劃過程組 |
執行過程組 |
監控過程組 |
收尾過程組 |
||
|
專案整合管理 |
制定專案章程 |
制定專案管理計劃 |
指導與管理專案執行 |
監控專案工作 實施整體變更控制 |
結束專案或階段 |
6個 |
|
專案範圍管理 |
收集需求 定義範圍 建立WBS |
核實範圍 控制範圍 |
5個 |
|||
|
專案時間管理 |
定義活動 排列活動順序 估算活動資源 估算活動持續時間 制定進度計劃 |
控制進度 |
6個 |
|||
|
專案成本管理 |
估算成本 制定預算 |
控制成本 |
3個 |
|||
|
專案質量管理 |
規劃質量 |
實施質量保證 |
實施質量控制 |
3個 |
||
|
專案人力資源管理 |
制定人力資源計劃 |
組建專案團隊 建設專案團隊 |
管理專案團隊 |
4個 |
||
|
專案溝通管理 |
識別干係人 |
規劃溝通 |
釋出資訊 管理干係人期望 |
報告績效 |
5個 |
|
|
專案風險管理 |
規範風險管理 識別風險 實施定性風險分析 實施定量風險分析 規範風險應對 |
監控風險 |
6個 |
|||
|
專案採購管理 |
規劃採購 |
實施採購 |
管理採購 |
結束採購 |
4個 |
|
|
合計 |
2個 |
20個 |
7個 |
11個 |
2個 |
42個 |
如果你想看每個過程的詳細講解的話，那還是得自己動口、豐衣足食——動口啃PMBok。這裡我們倒是可以對其進行簡要解讀，避免由於食物太硬引起消化不良。
PMBok中有三個重要的詞：生命週期、五大過程組、九大知識領域，其實是看待專案的三個維度，即 ：時間維度、職能維度和管理物件維度。時間維度是要求專案經理將專案分成若干個階段，逐步接近目標，專案更容易控制；管理物件維度是要告訴專案經理管什麼，要關注什麼，即範圍、時間、成本、質量、人力資源、風險等；而職能維度則是代表要做什麼，即要啟動專案、規劃專案等。
42個過程是按照後面兩個維度進行劃分的。為什麼沒有生命週期呢？這是因為不同型別的專案生命週期劃分會千差萬別，例如一個軟體專案和一個房地產建設專案的階段劃分毫無疑問會相去甚遠，而PMBok是適用於不同行業、不同型別專案的通用的指南，不可能將其固定下來。因此假如具體到某個軟體公司，完全可以根據軟體生命週期劃分、參考PMBok中的過程，重新制定合乎本公司實際情況的專案過程，相信大部分軟體公司的ISO9000檔案正是這樣乾的。
主要疑惑點在於“制定專案管理計劃”與“制定進度計劃”、“制定進度計劃”等過程之間的關係。
其實PMBok已經明確說了，它們之間是總子劃和分計劃的關係。在專案管理計劃中，同樣可以包括這些分計劃的內容。也就是說，只要你願意，完全可以把規劃過程組中的所有工作放到“制定專案管理計劃”這一個過程中來完成——總計劃把分計劃中的事全乾了。
監控過程組中一共有11個過程，這11個過程的關係是比較讓人迷惑的。在整合控制中有“監控專案工作”和“整體變更控制”兩個過程，它們與別外八個領域的中的監控過程是什麼關係呢？
通過研究各個過程的輸入和輸出，可以發現“監控專案工作”過程產生的的一個主要成果是批准的變更請求，而該成果又是另外八個領域中的控制過程的輸入，這些控制過程又都有一個重要輸出是請求的變更——該成果又是“整體變更控制”的輸入。由此，各個過程的關係浮出水面，如下圖所示：
從圖上可以看出，“監控專案工作”主要是發現問題，提出變更請求，而“控制範圍”等過程，則是確定怎樣變更，真正的進行專案變更的動作是“整體變更控制”。
啟動過程組在兩個過程：“制定專案章程”和“識別干係人”。按照五大過程組的特點，這兩個過程在專案每個階段之初都需要執行。難道我們在設計階段和編碼階段都需要重新制定專案章程和識別干係人嗎？
這看上去有點奇怪，在實際專案中，專案章程和干係人一般不會有什麼變化，每個階段都要重新做一次這個工作似乎有點牽強。在PMBok中關於專案章程有一段話是這樣說的：“在多階段專案的以後各階段，制定專案章程過程的作用是驗證原來為專案制定與頒發的章程所做的各種決定。這一過程在必要時還核准專案下一階段並更新該章程”。原來如此，簡單來說，就是看原來制定的章程還好不好使，不好使就需要更新了，算是能說得通。
同樣，識別干係人也就是看干係人有沒有變化了，但這與專案監控又存在一定的雷同了。我們可以設想一下，如果幹系人發生了變化，我們一定需要等到一下階段初才對做出相應的對策嗎？顯然不現實，我們會立即做出反應，而能隨時識別變化並做出反應的過程只能是監控過程組了。
曾經在培訓課有一位老師告訴我們，專案經理主要做專案整合管理的工作。個人認為這種說法有失偏頗。
由於整合管理往往涉及多個領域，因此，由專案經理親自把控是有道理的。但專案經理是不是隻需要做專案整合管理，或者可不可以授權其他人來負責整合管理中有一部分工作，這就要視專案實際人力資源情況而定了。
如果你不幸領著一群毛手毛腳的毛頭小子，那上面這個表裡的工作只能全是你的了；如果你有幾個得力干將，那就好辦多了，授權嘛。整合管理中工作同樣是可以授權的，沒有誰規定一定要由專案經理來做。當然授權不等放權，絕不意味著放任不管，至於管到什麼程度，只能由你自己拿捏了。
四、懂章法還要懂點心法
在武俠小說裡，常有爭奪劍譜之事，可是千辛萬苦拿到劍譜，由於不懂“心法”，還是練不成。在專案管理領域，PMBok就好比是一本劍譜，專案經理要做什麼、怎麼做，書裡面都有，但每個人運用起來，威力會大不相同。古人云：“運用之妙，存乎一心”，可見心法的重要性。
下面介紹一些專案管理的入門心法，幫助專案經理理解和運用書中的招式。至於高階心法在後續文章中會逐步介紹。
1. 專案管理是關於做事的方法
專案管理不是什麼神祕東西，要以平常心來看它，它就是人們總結出來的一種有效的做事的方法而已。這種方法有幾個要點：
以客戶為中心，看上去很簡單，卻蘊含著專案管理的終極祕密：讓客戶滿意。記住，是讓客戶滿意，而不是開發一個軟體，或者完成合同內容，也就是說我們的關注重點是客戶需要什麼，而不是軟體本身。為什麼那麼多專案開發了大量強大功能，客戶仍不滿意，就是因為我們沒有把關注焦點放在客戶身上，去琢磨客戶真正需要什麼，而不是客戶說要什麼；去琢磨怎樣滿足客戶的實際應用，讓他們用起來更方便，而不是需求文件寫著什麼。
專案沒有目標，就好像踢球沒有球門，其重要性不言而喻。但是專案的真正目標並不一定等同於招標檔案中提出的目標，招標檔案是檯面上的東西，是比較表面化的，而客戶的真實目的也許並不在於此。因此，專案經理最好對專案的來龍去脈搞清楚，這樣才能更好的把握客戶心理，理解專案的重點，真正使到客戶滿意。
專案計劃在專案中處於非常基礎的地位，專案的實施都應該按照專案計劃來進開展。如果專案沒有制定計劃，或者雖有計劃，卻是說一套、做一套，那麼這不叫專案管理，這叫打亂仗。沒有計劃，專案實施也就失去了依據，也更談不專案監控了，專案管理中的42個過程，也就基本失效了。
專案監控是很多人新任專案經理的薄弱環節，為什麼那麼多人說“計劃趕不上變化”，其原因正是在於控制環節的缺失。專案不是一臺機器，你只要啟動馬達，它就會按你設計的那樣轉個不停。專案的過程中產生偏差是正常現象，甚至是必然的事情，如果不加以控制，計劃就會成為擺設，專案也會越偏越遠，專案完工也就更加遙遙無期了。因此說控制是手段，是保證專案能按計劃達到目標的手段，每個專案經理都必須主動監控專案，用好這一手段。
2. 結構化分析方法
還記得什麼是結構化分析方法嗎？說到它，很多人會想起資料流圖、資料字典等等這些工具，但其內在的精神思想，即“自頂向下、由外到內、先整體後區域性、逐層分解”，這才是它留給人們最寶貴的財富，
其實結構化分析法方不只是用於軟體的分析設計，在人們生活的方方面面都有其用武之地，因為它是對複雜和大型事物的分析方法，符合人們對事物的認識規律。在PMBok中同樣深刻的體現了結構化分析方法的思想。
首先PMBok本身就是一個自頂向下、逐層分解的知識體系。沒有分解之前，專案管理是一個混沌的整體，PMBok將其按不同的維度分解為五大過程組和九大知識領域，然後又進一步分解為42個過程，每個過程又分解為輸入、工作和方法、輸出三個部分，這不正是完美的體現在結構化分析的思想嗎？
專案經理組織專案實施更加離不開結構化思想。42個過程中有一個非常重要的過程是“建立WBS”，所謂WBS，中文名是“工作分解結構”，它其實就是一種按照“自頂向下、逐層分解”的思想建立的一種樹形的專案任務清單，這是整個專案執行和控制的基礎，如果你不會使用WBS，那基本上就也就等於說你不會管專案了。
結構化方法在編寫專案文件以及彙報材料時同樣有其用武之地。專案文件其實也是一種交流彙報的材料，為了能讓別人看懂，我們先要把事情總體的講一下，然後將其分為幾個大點，每個大點可能又分成幾個小點來講，這樣別人就有對你要講的內容搞清楚了。我看過一本專門教別人寫彙報材料的書，叫《金字塔原理》，其實也就是講如何自上而下組織材料，讓彙報變得更有條理。現在你懂了結構化方法，這本書你也就可以省了。
3. 過程思想
ISO9000有八項基本原則，其中一項就是“過程方法”，並將過程定義為：“一組將輸入轉化為輸出的結果”。過程包括三要素：輸入、活動、輸出，對於這三要素，我想這三素對於程式設計師來說肯定不會陌生，因為我們在進行軟體設計時，所使用的IPO圖與它如出一轍，IPO圖的三要素是“輸入、處理、輸出”，兩者其實沒有什麼區別。也就是說，IPO圖其實是表達過程的有效工具。
回到PMBok中五大過程組的那張圖，它其實就是一張IPO圖，它也有由輸入-處理-輸出組成，即啟動-規劃、執行、監控-收尾，由此可見，其實整個專案就是一個大的過程，同樣，專案階段也是過程。五大過程組又包含42個過程，每個過程都是由“輸入、工具和技術、輸出”組成，這與“輸入、處理、輸出”不是一回事嗎？
需要說明的是每個過程並不是個獨立的，而是相互關聯和銜接的，前一個過程輸出成為下一個過程的輸入，從而形成了一個個過程鏈。下圖是一個簡要的過程鏈示意圖：
圖 專案管理中的過程鏈