最近看到 《構建之法》的“8.6 計劃和估計”這一節，頗多感觸。這些年來，不同的階段，對項目計劃都有不同的認識和掌握。
鄒老師提到了制定計劃的幾個概念：目標、估計和決心。
- 目標：表明一個希望達到的狀態。例如，軟件“五一”之前要投放市場！在建校一百週年之時把我校建成世界一流大學！不論這類目標如何重要，它們未必能夠實現。
- 估計：以當前瞭解的情況和掌握的資源，要花費多少人力物力時間才能實現某事。
- 決心：保證在某個時間之前完成預先規定的功能和質量。例如：我們跑步前進，全民鍊鋼，兩年超英趕美！
大二的暑假的時候，從學校BBS上接了個私活，幫人做個辦公OA系統，第一次獨立的去做項目，僱主給了我一個別人的辦公系統，讓我模仿着做一個，功能界面樣式都一樣，給了一個月的時間，結果就是我最後一週連續在機房熬了好多天通宵，在時間點之前趕出來了。現在回頭來看，這其實只有目標和決心，而沒有任何估計，如果目標再大一點，如果不是年輕的時候身體好能熬夜，是不太可能完成的。
但就算有估計，也不代表就能制定合理的計劃。畢業後剛參加工作，在一個項目中，項目經理給我分配了一個比較複雜的功能，讓我估計一下時間，我樂觀的估計了一下，覺得三星期就能搞定，項目經理不放心，給我按一個月時間算上了，結果由於我急於在項目中應用一些不熟悉的新酷技術，沉迷於技術細節中，導致一個月時間到了還是沒能按時完成，導致整體項目延誤，最後項目經理捱了批評。
類似的錯誤我不止犯過一次，也看到很多程序員犯過類似的錯誤：過於沉迷技術，忽視進度，導致計劃不能按期執行，所以後面我嘗試作出了一些改變：
- 對於不熟悉不成熟的技術，儘可能不要應用到項目中，利用項目之外的時間去學習試驗，驗證後再應用。
- 將項目計劃細化，不能說一個功能模塊一週，爭取把計劃的力度細化到天，這樣能及早的發現問題。
- 設置關鍵的時間點，在這個時間點的時候，需要交付一定的東西出來，這樣就逼着自己不敢在某一個細節上浪費太多時間。
後來在自己開始去做項目管理的時候，在做項目計劃的時候相對有了經驗，其實自我管理是最難的，管理別人要相對容易得多。但即使如此，在做項目計劃時也遇到很多問題。
遇到的第一個問題就是如何做團隊的項目計劃，以前自己給自己做計劃，相對容易，但如果整個項目的計劃要一起做就比較麻煩了，每個人的能力水平不一樣，預估項目的樂觀程度不一樣，要協調起來可不容易。
最開始的時候，我嘗試按照自己寫代碼的經驗來給大家分配任務和定計劃，比如說這個用戶註冊模塊我覺得我需要三天，給張三做，張三經驗不如我豐富，那麼張三應該四天能搞定，給他四天時間。這樣計劃是很快做出來了，但是問題馬上來了：
- 首先是準確度不高，誤差比較大，每個人實際上在做的過程中都會遇到各種各樣的問題，比如前面提到的讓張三四天完成註冊模塊，可能他以前沒做過，而且正好環境不熟悉，那麼可能四天根本完不成。還有可能是他直接用一些現有第三方模塊，一兩天就完成了這個功能。
- 然後是當發生計劃不準確的時候，項目成員會有情緒。比如註冊模塊讓張三四天完成，結果功能比預計要複雜，導致張三加班加點才勉強完成，張三就會想，這個功能我當時就覺得四天不夠，你只給四天，這不是故意爲難我嗎？
於是嘗試做出調整，對功能模塊進行劃分和分工後，讓團隊成員自己去預估時間，在實行一段時間後，大家積極性是提高了，自己定的計劃，含着淚也要按時完成，但又有新的問題：
- 以前計劃都是項目經理一手包辦，而現在需要自己去制定計劃，很多人在定計劃的時候纔去瞭解項目需求，在需求不瞭解的情況下做出的計劃不靠譜
- 有的人的計劃過於樂觀，完全沒有預估到項目的複雜性，導致最後項目計劃難以完成；有的人比較偷懶，定的計劃總是很鬆散。
顯然項目經理想當甩手掌櫃是不現實的，所以後來在定項目計劃的時候，我一般會分成以下幾步：
- 第一步，在目標（項目需求）明確後，開始預估項目計劃，這時候精確度不需要太高，精確到周爲單位即可。
- 第二步，對項目需求和團隊成員進行同步，確保項目成員充分理解項目需求，將任務分配下去後，讓項目成員自行評估各自項目計劃
- 第三步，對項目成員的計劃進行一一覈查，參照第一步預估的時間，對過於樂觀的和過於寬鬆的，都要一起把計劃細化，細節仔細推敲探討，確保計劃科學合理
- 第四步，完成最終計劃，並確定幾個關鍵里程碑，確保在里程碑的時候能交付一定的內容
這樣下來，制定的計劃相對要合理多了，保持進度的跟蹤，尤其是里程碑時間點的把握，基本上不會有太大的問題。
但項目計劃還是很容易受到外部影響的。在《構建之法》裏面提到了軟件項目的時間估計可以從兩個方面來看：
- 自底向上。團隊成員各自估計底層模塊和單個功能（及單元測試）所需的時間，再加上集成及基本測試的時間，就是大概的開發時間。這還沒有考慮各個模塊之間的相互依賴性。
- 回溯。團隊從整個項目最終交付之日往回倒推。
很不幸，我見過的絕大多數項目都是採用的回溯法來制定計劃的，比如客戶說，這個功能我下個月必須上線；比如就算你按照自底向上制定好的2個月項目計劃彙報給老闆說，老闆說2個月太長了，希望1個月就能看到。
這個問題其實在軟件工程中是個非常典型的問題，有的比較滑頭的項目經理會在上報給老闆的進度加個比較大的Buffer，例如本來兩個月可以做完的，報上去是三個月，那麼老闆壓一壓，還有兩個月時間，這不是皆大歡喜了！不過這畢竟只是“術”，玩多了被揭穿了以後就沒得玩了。
那麼什麼是“道”呢？在構建之法中有一張“功能/資源/時間的平衡圖”，非常形象的說明了這幾個項目要素的關係。
項目管理也是一種平衡之道，現在在資源不變，時間縮短的情況下，要麼去犧牲功能，要麼去犧牲質量。一般在這種情況下，如果不是一次性產品，我通常會選擇犧牲功能，質量上欠的債終究是要加倍還的，功能可以通過版本的迭代來完善。
除了被縮短時間導致計劃更改，還有個計劃更改的重要因素是來自需求的變更！據說因爲需求老變，產品經理或老闆被程序員砍的例子不少！其實需求的變更在軟件項目開發裏面是常態，沒必要太過牴觸，但是需要科學的去管理。一般來講，如果項目的週期越長，需求變更帶來的影響越大！所以現在一般互聯網的項目，都比較追求功能精簡，快速上線，上線後持續迭代。
在遇到一些影響項目計劃的問題時，我一般處理原則如下：
- 對於需要縮短計劃時間的，根據情況減少一些功能或犧牲質量，並承擔相應的後果
- 對於需求變更的，評估是否對整體進度有較大影響：
- 如果影響不大，則不改變整體項目計劃，只做局部調整
- 如果影響較大，則對重新制定整體項目計劃，走相應的需求變更流程
同時，爲了能及時相應需求的變更，需要對每一期項目功能進行合理篩選，合理搭配核心功能和外圍功能，讓項目週期在一個相對可控範圍。
項目計劃是項目管理中非常重要的一環，不計劃無管理。不同的項目不同的團隊，項目計劃的方式也各有不同，不過萬變不離其宗，根本還是在於對軟件工程構建之法的掌握和運用。