摘要：
計劃趕不上變化，計劃還要不要寫呢？專案工期限死，估算有什麼價值呢？只有專案經理緊張專案，其他人是打工心態，怎樣辦呢？PMP的知識能搭救專案嗎？如何才能做出一個按期交付的完美計劃呢？所有問題，將在這一篇中大爆發！
說明：
這是“挨踢專案求生法則”系列文章，之前已經為大家分享了戰略篇、團隊建設篇、需求篇、設計篇、編碼篇、測試篇、實施篇，這篇是計劃篇。
什麼叫挨踢專案？
IT專案，特別是軟體開發專案，都屬於“挨踢”專案的範疇。挨踢專案的幾大特點：
1.需求不確定。
2.技術不確定。
3.工期限死。
4.預算限死
兩大不確定和兩大限死，你想不“挨踢”都難！
什麼是專案計劃？
實際工作中計劃應該在前面就寫了，為什麼本系列文章直到第8篇才寫計劃這個主題呢？
計劃其實就是為了實現專案的目標，對專案各項工作的統籌安排。
那什麼是專案的“各項工作”呢？
各項工作包括團隊建設、專案分析、需求分析與管理、軟體設計、編碼、測試、實施等，本系列前面的文章逐一分享了”各項工作“（當然專案的”各項工作“不止這些，後文會補充說明）。各項工作的最佳實踐，將會直接決定計劃的質量。為什麼在第8篇才分享“計劃”這個主題，原因也是如此。
計劃對加速工期有多大幫助？
有朋友問了一個計劃應該如何寫的問題。這位朋友已經有幾年的軟體研發一線工作經驗，專案經理的工作也不是第一天干的，問出這樣的問題我覺得有點怪。但我仍然說了一通專案計劃的“大道理”供他參考。然後他說：專案成員技能不足，計劃怎樣寫？
後來我才發現，他的真正問題是：如何寫好計劃以保證工期！
我給出的回答竟然是：計劃本身對加速工期並沒有幫助！
要加速專案工期，主要在於兩方面：
1）提升需求分析與管理能力，能為客戶帶來價值的前提下，儘量將需求控制在一定範圍內並儘量簡單。
2）提升軟體的設計能力，讓專案的整體工作量下降。
如果專案小組能力不足，並且不重視上述兩個方面，那麼這個計劃怎樣寫都是寫不好的，寫計劃不是紙上談兵啊。
而通常情況我們的工期是限死的，所以我們的計劃是“倒推法”寫出來的，計劃中的關鍵節點基本上通過倒推法已經卡死，我們能做的事情就是想辦法讓事情變得更簡單、工作量更少和提升我們的能力，以便在工期內完成專案！
所以計劃及計劃跟蹤的問題，並不是僅僅本篇就能解決的，你還需要再認真看看前面的幾篇文章，理解專案的”各項工作“是做好計劃的根本。
法則1：專案管理首先是一門技術活
作為新上任的專案經理，如何寫計劃指導大家工作呢？
首先請做這兩條自測題：
1）你熟悉這個專案需求嗎？
2）你熟悉這個專案需要用到的開發語言、資料庫和相關技術嗎？
如果上述兩條題目的回答都是NO，你是無法開展工作的。
軟體專案管理首先是一門技術活，如果你不懂需求、不懂技術，你將會：
1）無法拆解工作；
2）無法和專案組成員溝通；
3）無法與客戶溝通。
當然大部分專案經理是技術出身的，這方面的問題就不太嚴重；但有些專案經理是“外行”出身的，如果又不願意去學習需求和技術，那麼只能說祝你好運了……
法則2：專案經理需要周身刀並且每把刀都要鋒利
中國的專案經理，通常要幹以下事情：
1）專案管理（這個不用說了，廢話）；
2）需求分析與管理；
3）軟體設計，包括資料庫設計；
4）寫程式碼；
5）測試軟體；
6）和客戶溝通；
……
或者這樣說會更合適一點，專案經理不幹的事情有哪些？結果你發現：沒有！
專案經理必須是全才，而且各方面能力都需要數一數二！
當然你會說：你當我是齊天大聖啊，可以三頭六臂地幹活！
以下一些實用建議供你參考：
1）有機會要儘量每方面都學習一下鍛鍊一下，專案經理確實是需要全才；
2）如果專案規模不大，那麼你一個人兼任”管理+需求+設計”是可以的；
3）如果專案規模比較大，你可以兼任“管理+需求”或“管理+設計”；
4）哪怕專案規劃超級大，不建議你幹“純管理”的事情，你至少要兼任“管理+需求”。“純管理”其實是幹不了事情的，還需要其他人“服侍”你，你才能“純管理”。
法則3：積極提升專案成員水平
我做過這麼多專案，沒有試過專案小組從一開始具備了完成這個專案所需要的全部能力，這種情況估計以後也不會發生。提升專案成員的能力和水平，是按期交付的重要因素，甚至是決定性因素。
員工離職的兩個重要因素，一個是薪金，另外一個就是學不到東西。專案經理可能還無法直接提升專案成員的薪金，但你可以創造學習機會和環境，甚至是親自傳授知識給專案成員，讓他可以學到提升薪金的技能。如果你的下屬離職了，原因是一直學不到東西，那麼你們兩個可以抱頭痛哭了！
法則4：應對變化的最好辦法就是計劃
計劃趕不上變化，所以計劃寫了也沒有用！果然如此嗎？
你可能覺得軟體專案“兩大限死兩不確定”很恐怖，其實有更恐怖的專案呢，那就是戰爭指揮！
打仗要不要寫作戰計劃？戰爭中資訊千變萬化，你會因為這樣而不準備作戰計劃嗎？情況越複雜，不確定因素越多，其實越需要計劃！
法則5：估不準總比不估算要好！
估算很恐怖，很多人不願意估算，主要原因有：
1）“兩大限死“，估了等於沒估；
2）“兩不確定”直接導致無法估算；
3）估算就是一種承諾，我可不願意自己限死自己啊。
其實在我們軟體開發屆，估算偏差達到100%是很常見的事情，甚至是200-300%都很正常，但如果不估算，你的誤差就是無窮大！
勇敢的跨出第一步，估不準總比不估算要好，估算和實際工作量之間總會有個譜，只要跨出第一步，我們就有改進基礎了！
法則6：計劃需要近期細，中長期粗，並持續細化和優化
曾經負責某專案，專案工期3個月，領導要求我寫出3個月的詳細計劃。我很鬱悶，死活寫不出來，我不想紙上談兵、不想浪費時間寫這些沒有用的計劃，所以我還去和領導理論這樣的做法是不合理的。軟體專案存在這麼多不確定因素，一般來說幾周後的具體工作是很難計劃出來的，所以法則6很重要。計劃並不是僵化的東西，需要持續細化和優化。
其實比較怕遇到外行的領導，外行領導監督工作的辦法就是讓你寫計劃，然後根據你的計劃來檢查你，而這個計劃的工期是卡死的。如果有人用這個你無奈而寫的計劃來卡死你，你肯定不願意寫這樣的計劃。
開明的領導是這樣做的：
1）計劃寫出來了，我會全力支援你完成計劃，包括：提供各種資源、協調各部門、協調客戶等等；
2）計劃可以變，可以推遲，但你要儘早告訴我；
3）我不會用計劃作為你工作成績的檢查標準，也不會以此來績效考核。
法則7：人人都是專案管理者
很多專案經理都有這樣的感觸：好像整個專案小組當中，就只有自己最緊張專案的成敗，其他人的心態就是完成工作的打工心態。其他人似乎從來不會主動彙報工作，主動思考專案的風險與問題等。
專案管理是每一個人的事情，而不僅僅是專案經理的事情，每一個人至少需要做到：
1）全力完成工作，要保證工作質量；
2）要主動報告進度，遇到風險和問題要主動提出來；
3）要主動管理好自己的工作產品；（做好自己工作產品的配置管理）
4）要主動協助同事完成工作；
5）要主動溝通。
每一個人至少要做到能管理好自己的工作，如果自己的工作還需要別人來管理，這樣的工作水平是不及格的！
法則8：計劃的執行在於每一天！
我們都知道以下大道理：
1）專案的問題都是通過一天天積累的；
2）問題越早發現，解決成本越低。
但我們往往在計劃跟蹤上節省時間，結果得不償失，在臨近專案死期（釋出日），進入正式測試階段時問題大爆發：
1）某些需求沒有實現；
2）某些缺陷無法改，需要改動資料庫底層或軟體架構才能搞定；
3）軟體整體的使用者體驗很差，但這些問題已經遍地都是了，沒有時間去改；
4）一大堆不符合編碼規範的程式碼；
……
每天的計劃跟蹤能解決上述問題，並且能加速專案成員的能力提升。
跟蹤計劃的最有效方法是眼見為實，就是直接編譯程式看看執行效果，同時檢查程式碼與資料庫實現。
法則9：通用專案管理知識的對專案的幫助不大
我在大學時曾經學過“施工進度管理”的課程（我大學學的專業是城鎮建設），當時學了很多專案管理的知識，例如：前置任務後置任務、關鍵路徑、單代號網路圖、雙代號網路圖、甘特圖、流水施工等等概念，開闊了很大的眼界，發現專案管理確實是一門高深的學問。後來我的課程設計就是要寫一個施工進度計劃，我紙上談兵地完成了這個課程設計，結果我感覺良好，以為自己就是專案管理大牛了！
幸好我舅父給我潑了冷水，讓我浮躁的心安靜下來。當時舅父帶我到某建築工地見識一下，我見到工地的辦公室中有一張很大的甘提圖（進度計劃），我問這個圖有用嗎？我舅父說：這個圖只是擺出來應付檢查的！
從事軟體研發工作後，儘管我學過一些專案管理知識，但確實發現這些知識對專案管理基本上沒有實質性的幫助。剛學習時，你確實會有“哇呀”這樣的感覺，專案管理居然可以這樣！實際上如果你沒有豐厚的一線研發工作經驗，軟體專案管理是做不好的。
關於通用專案管理知識的學習建議：
1）公司報銷或者你是土豪，並且你有很多空餘時間，建議去考一考PMP，這個過程還是學到一些知識的；
2）沒有銀兩，但你有很多時間，可以去自學一下，考證就不是必須的了；
3）這些通用的專案管理知識不要硬套到軟體專案上。
還有會有SQA篇、SCM篇和維護篇
之前剛寫完“實施篇”的時候，有朋友問什麼時候寫“SQA篇”？
確實我原來沒有計劃寫“SQA篇”，“計劃篇”就是最後一篇。
但計劃趕不上變化，計劃是可以調整的！我打算將來再為大家分享SQA篇、SCM篇和維護篇。
你有任何想法和建議，歡迎提出來！
如果本文對你有幫助，麻煩點一下“推薦”啦，謝謝！
作者：張傳波
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
CMMI首席專家
《火球——UML大戰需求分析》作者
軟體知識原創基地創辦人