摘要：
計畫趕不上變化，計畫還要不要寫呢？專案工期限死，估算有什麼價值呢？只有專案經理緊張專案，其他人是打工心態，怎樣辦呢？pmp的知識能搭救專案嗎？如何才能做出乙個按期交付的完美計畫呢？所有問題，將在這一篇中大爆發！
說明：
什麼叫挨踢專案？
it專案，特別是軟體開發專案，都屬於「挨踢」專案的範疇。挨踢專案的幾大特點：
1.需求不確定。
2.技術不確定。
3.工期限死。
4.預算限死
兩大不確定和兩大限死，你想不「挨踢」都難！
什麼是專案計畫？
計畫其實就是為了實現專案的目標，對專案各項工作的統籌安排。
那什麼是專案的「各項工作」呢？
計畫對加速工期有多大幫助？
有朋友問了乙個計畫應該如何寫的問題。這位朋友已經有幾年的軟體研發一線工作經驗，專案經理的工作也不是第一天幹的，問出這樣的問題我覺得有點怪。但我仍然說了一通專案計畫的「大道理」供他參考。然後他說：專案成員技能不足，計畫怎樣寫？
後來我才發現，他的真正問題是：如何寫好計畫以保證工期！
我給出的回答竟然是：計畫本身對加速工期並沒有幫助！
要加速專案工期，主要在於兩方面：
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大戰需求分析》作者
軟體知識原創基地創辦人
挨踢專案求生法則 計畫篇，計畫趕不上變化！
摘要 計畫趕不上變化，計畫還要不要寫呢？專案工期限死，估算有什麼價值呢？只有專案經理緊張專案，其他人是打工心態，怎樣辦呢？pmp的知識能搭救專案嗎？如何才能做出乙個按期交付的完美計畫呢？所有問題，將在這一篇中大爆發！說明 什麼叫挨踢專案？it專案，特別是 軟體開發專案，都屬於 挨踢 專案的範疇。挨踢...
挨踢專案求生法則 設計篇
摘要 知道什麼是挨踢專案吧？什麼！不知道？那it專案知道了吧？為了不讓客戶踢 不讓老闆踢 專案組成員之間不互相踢，俺為大家分享一些減少被踢機會的心得體會。就算不能讓專案成功，也至少不會死得那麼慘吧！我將分戰略篇 團隊建設篇 需求篇 設計篇 編碼篇 測試篇 實施篇和計畫篇為你分享。什麼叫挨踢專案？it...
挨踢專案求生法則 需求篇
摘要 知道什麼是挨踢專案吧？什麼！不知道？那it專案知道了吧？為了不讓客戶踢 不讓老闆踢 專案組成員之間不互相踢，俺為大家分享一些減少被踢機會的心得體會。就算不能讓專案成功，也至少不會死得那麼慘吧！我將分戰略篇 團隊建設篇 需求篇 設計篇 編碼篇 測試篇 實施篇和計畫篇為你分享。作者 張傳波 www...