話說有一天，魔鬼抓到了兩個專案經理張三和李四，他決定吃掉一個，剩一個來給他做專案。張三驕傲地說：“我有PMP證書，我精通CMMI、軟體工程，還會敏捷、Scrum。”魔鬼一口就把他吃掉了，“額，你知道的太多了。”
1. 你知道的太多了
有3個游泳教練在教人游泳。第一個教練推薦學生看兩本書《游泳工程》和《游泳理論大全YYBOK》，看完了考試，考完試頒發《游泳證書》，可以自由下水游泳了，注意教練不對結果負責。第二個教練會先讓學生在岸上按照《游泳YYMMI》規範把動作練到完美，同時結合兩本書《游泳工程》和《游泳理論大全YYBOK》，並且在學生下水後嚴格按照《游泳YYMMI》執行，不能變形。第三個教練很殘酷，讓學生在岸上練習了一會動作，就讓學生帶著浮板下了水。如果學生想靠邊，教練會把他打到池中去。在一到兩週時間內，學生就學會了游泳，但學生完全不知道啥是《游泳工程》，啥是《游泳理論大全YYBOK》。對於繼續深造的學生，教練才開始《游泳工程》和《游泳理論大全YYBOK》的講解，並且每講一部分就讓學生在游泳中多體會糾正。（還有一種，無師自通的狗刨。）
相信大家都很熟悉上面的內容，哈哈。有一個行業一直是第一種和第二種教法，教出了不少水鬼，這就是軟體行業。也許他們對《游泳工程》和《游泳理論大全YYBOK》的理解非常到位，也許他們的動作完美符合《游泳YYMMI》規範，他們甚至遊得很快，唯一的區別就是他們再也不需要換氣了。（我真該慶幸我女兒是跟第三個教練學游泳。）
“如果你的世界中只剩一種工具錘子，你會不會試圖把所有東西都變成釘子？”雖然很想說不，但是對大多數人來說，答案是會。學到更多的知識有時是一種負擔，一旦被洗腦成功，滿地找釘子的人大有人在。
2. 其實只有兩種專案管理
其實只有兩種專案管理，一種是預言式專案管理，另一種是適應性專案管理。在軟體專案中，當前預言式專案管理在行動上佔上風，適應性專案管理在話語權上佔上風。
2.1 預言式專案管理
預言式專案管理相信專案是可以清楚瞭解並預測的。預言式專案管理注重前期的計劃，並認為專案無非是計劃的執行過程，並在執行過程中控制變數。預言式專案管理視變化為威脅，要求嚴格的變更管理。因為人是帶來變化的主體，所以更是威脅。
在預言式專案管理中，人員變成了角色，互動變成了過程和文件。客戶變成了需求，領導變成了報告，開發人員變成了人月。從此，專案中的一切均可量化管理。
2.2 適應性專案管理
適應性專案管理相信專案是無法準確預測的，要不斷適應變化，響應變化。因為人是變化的主體，所以適應性專案管理特別注重人的作用。適應性專案管理通常採用迭代和增量式工作方式來進行探索和校準。
3. 無責任評專案管理
在上一篇《13給新手的建議》中，我建議新手專案經理找到至少一位同公司的專案管理導師。因為導師就是你們的教練和浮板，他能在出現意外的時候保證你的人身安全（別變水鬼），他能讓你把注意力集中到你當前要練習的地方，而不是面面俱到。
但是每一位新手專案經理都想學到更多專案管理知識。應該學哪些呢？其實我更推薦直接在專案中學，跟著導師學。
3.1 專案管理知識體系PMBOK
專案管理知識體系PMBOK是美國專案管理學會（PMI, Project Management Institute）開發的一個關於專案管理的標準，是PMP認證的基礎。它把專案管理劃分為9個知識領域，即：範圍管理，時間管理，成本管理，質量管理，人力資源管理，溝通管理，採購管理，風險管理和綜合管理。
無責任亂評：
PMBOK偏向於預言式專案管理，希望理清專案中穩定的那些因素，控制和限制不穩定因素，例如人。
另外，對新人來說，直接看PMBOK容易陷入區域性的理解，而不瞭解專案的整體。所以PMP考試的要求是至少3年以上的專案管理經驗，雖然現在貌似交錢就可以考。
如果PMP證書對找工作有幫助，就學吧，但注意不要被洗腦了哦。如果已經有了不少經驗，希望更加全面的對專案的各個方面有個瞭解，PMBOK也是不錯的參考資料。
3.2 軟體工程
軟體工程是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。
無責任亂評：
軟體工程界長期以來偏向於預言式專案管理，也是希望理清專案中穩定的那些因素，控制和限制不穩定因素，例如人。近期軟體工程書籍上開始引入敏捷。（也有人認為敏捷本來就是軟體工程的一部分。）
因為過於全面，對新人來說，知識量太大，不建議開始就細讀。
軟體工程的優點是比較全面，如果希望更加全面的對專案的各個方面有個瞭解，軟體工程是不錯的參考資料。
3.3 CMMI
CMMI是一種過程改進方法，它的目的是幫助組織改進他們的績效。CMMI認證是軟體企業的流行認證，一度被認為是“銀彈”。
無責任亂評：
CMMI的本質是用於檢查組織的軟體開發能力的，這一點沒錯。但是有一點有問題的是，CMMI本身沒有能力提供真正的改進，它的改進必須依賴於預言式專案管理或適應性專案管理。換言之，CMMI就是醫院的檢驗科，它能提供檢驗報告，但是看病治病你還是得找醫生。所以相信CMMI能看病的人都被騙了。用CMMI就像去大醫院治病，會帶來昂貴的檢驗報告和昂貴的醫生診治費用，不過大醫院養活著很多醫生。
另外CMMI帶來了大量的檢驗和昂貴的檢驗成本，本身就會影響專案成敗。如果一個人每天都花錢去醫院檢驗，他就有三種風險，一是無力承擔昂貴的檢驗費用，另一種是過量的X光檢驗會致癌，第三種是檢驗佔用的時間成本太大，沒時間鍛鍊。不如改善生活態度，積極鍛鍊身體，定期去檢驗為好。
CMMI也許對公司拿專案，撐門面比較有意義。但是作為個人，尤其是新手，CMMI基本毫無意義。因為你讀不懂檢驗報告，讀懂了你也不會看病治病。還是專心把專案做好來得實在。
3.4 RUP
Rational統一過程（RUP）是Rational軟體公司（現在Rational公司被IBM併購）創造的軟體工程方法。在2000年左右，沒用RUP，你出門都不好意思給人打招呼，掉份兒。
無責任亂評：
RUP是典型的預言式專案管理，它那繁瑣的流程定義，事無鉅細的交付文件，和眾多的角色分工都深深的出賣了它。但是沾了迭代兩個字的光，它堂而皇之的混入了適應性專案管理的陣營。
它的優點是比較全面，如果希望更加全面的對專案的各個方面有個瞭解，是不錯的參考資料。
3.5敏捷和Scrum
敏捷軟體開發又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對於“非敏捷”，更強調程式設計師團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文件更有效）、頻繁交付新的軟體版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的程式碼編寫和團隊組織方法，也更注重做為軟體開發中人的作用。
Scrum是典型的敏捷軟體開發方法學，目前在所有敏捷方法學中採用率最高。
無責任亂評：
敏捷是典型的適應性專案管理，Scrum當然也是。最大的缺點是理論與哲學很不“科學”，包含了很多人性化的部分，可變性很大，難於把握。在這一點上，預言式專案管理有很大的優勢。因此敏捷極其簡單又非常複雜。
敏捷更接近傳統工匠文化中的手藝傳遞，特別需要師傅的指引。自學的，無論學了多少理論，都很難有好結果，這也是推薦專案經理導師的重要原因。