最近看到?《構建之法》的“8.6 計劃和估計”這一節，頗多感觸。這些年來，不同的階段，對項目計劃都有不同的認識和掌握。

鄒老師提到了制定計劃的幾個概念：目標、估計和決心。

• 目標：表明一個希望達到的狀態。例如，軟件“五一”之前要投放市場！在建校一百周年之時把我校建成世界一流大學！不論這類目標如何重要，它們未必能夠實現。
• 估計：以當前了解的情況和掌握的資源，要花費多少人力物力時間才能實現某事。
• 決心：保證在某個時間之前完成預先規定的功能和質量。例如：我們跑步前進，全民煉鋼，兩年超英趕美！

?

大二的暑假的時候，從學校BBS上接了個私活，幫人做個辦公OA系統，第一次獨立的去做項目，雇主給了我一個別人的辦公系統，讓我模仿著做一個，功能界面樣式都一樣，給了一個月的時間，結果就是我最后一周連續在機房熬了好多天通宵，在時間點之前趕出來了。現在回頭來看，這其實只有目標和決心，而沒有任何估計，如果目標再大一點，如果不是年輕的時候身體好能熬夜，是不太可能完成的。

但就算有估計，也不代表就能制定合理的計劃。畢業后剛參加工作，在一個項目中，項目經理給我分配了一個比較復雜的功能，讓我估計一下時間，我樂觀的估計了一下，覺得三星期就能搞定，項目經理不放心，給我按一個月時間算上了，結果由于我急于在項目中應用一些不熟悉的新酷技術，沉迷于技術細節中，導致一個月時間到了還是沒能按時完成，導致整體項目延誤，最后項目經理挨了批評。

類似的錯誤我不止犯過一次，也看到很多程序員犯過類似的錯誤：過于沉迷技術，忽視進度，導致計劃不能按期執行，所以后面我嘗試作出了一些改變：

• 對于不熟悉不成熟的技術，盡可能不要應用到項目中，利用項目之外的時間去學習試驗，驗證后再應用。
• 將項目計劃細化，不能說一個功能模塊一周，爭取把計劃的力度細化到天，這樣能及早的發現問題。
• 設置關鍵的時間點，在這個時間點的時候，需要交付一定的東西出來，這樣就逼著自己不敢在某一個細節上浪費太多時間。

?

后來在自己開始去做項目管理的時候，在做項目計劃的時候相對有了經驗，其實自我管理是最難的，管理別人要相對容易得多。但即使如此，在做項目計劃時也遇到很多問題。

遇到的第一個問題就是如何做團隊的項目計劃，以前自己給自己做計劃，相對容易，但如果整個項目的計劃要一起做就比較麻煩了，每個人的能力水平不一樣，預估項目的樂觀程度不一樣，要協調起來可不容易。

最開始的時候，我嘗試按照自己寫代碼的經驗來給大家分配任務和定計劃，比如說這個用戶注冊模塊我覺得我需要三天，給張三做，張三經驗不如我豐富，那么張三應該四天能搞定，給他四天時間。這樣計劃是很快做出來了，但是問題馬上來了：

• 首先是準確度不高，誤差比較大，每個人實際上在做的過程中都會遇到各種各樣的問題，比如前面提到的讓張三四天完成注冊模塊，可能他以前沒做過，而且正好環境不熟悉，那么可能四天根本完不成。還有可能是他直接用一些現有第三方模塊，一兩天就完成了這個功能。
• 然后是當發生計劃不準確的時候，項目成員會有情緒。比如注冊模塊讓張三四天完成，結果功能比預計要復雜，導致張三加班加點才勉強完成，張三就會想，這個功能我當時就覺得四天不夠，你只給四天，這不是故意為難我嗎？

?

于是嘗試做出調整，對功能模塊進行劃分和分工后，讓團隊成員自己去預估時間，在實行一段時間后，大家積極性是提高了，自己定的計劃，含著淚也要按時完成，但又有新的問題：

• 以前計劃都是項目經理一手包辦，而現在需要自己去制定計劃，很多人在定計劃的時候才去了解項目需求，在需求不了解的情況下做出的計劃不靠譜
• 有的人的計劃過于樂觀，完全沒有預估到項目的復雜性，導致最后項目計劃難以完成；有的人比較偷懶，定的計劃總是很松散。

顯然項目經理想當甩手掌柜是不現實的，所以后來在定項目計劃的時候，我一般會分成以下幾步：

第一步，在目標（項目需求）明確后，開始預估項目計劃，這時候精確度不需要太高，精確到周為單位即可。

第二步，對項目需求和團隊成員進行同步，確保項目成員充分理解項目需求，將任務分配下去后，讓項目成員自行評估各自項目計劃

第三步，對項目成員的計劃進行一一核查，參照第一步預估的時間，對過于樂觀的和過于寬松的，都要一起把計劃細化，細節仔細推敲探討，確保計劃科學合理

第四步，完成最終計劃，并確定幾個關鍵里程碑，確保在里程碑的時候能交付一定的內容

?

這樣下來，制定的計劃相對要合理多了，保持進度的跟蹤，尤其是里程碑時間點的把握，基本上不會有太大的問題。

但項目計劃還是很容易受到外部影響的。在《構建之法》里面提到了軟件項目的時間估計可以從兩個方面來看：

自底向上。團隊成員各自估計底層模塊和單個功能（及單元測試）所需的時間，再加上集成及基本測試的時間，就是大概的開發時間。這還沒有考慮各個模塊之間的相互依賴性。

回溯。團隊從整個項目最終交付之日往回倒推。

?

很不幸，我見過的絕大多數項目都是采用的回溯法來制定計劃的，比如客戶說，這個功能我下個月必須上線；比如就算你按照自底向上制定好的2個月項目計劃匯報給老板說，老板說2個月太長了，希望1個月就能看到。

這個問題其實在軟件工程中是個非常典型的問題，有的比較滑頭的項目經理會在上報給老板的進度加個比較大的Buffer，例如本來兩個月可以做完的，報上去是三個月，那么老板壓一壓，還有兩個月時間，這不是皆大歡喜了！不過這畢竟只是“術”，玩多了被揭穿了以后就沒得玩了。

那么什么是“道”呢？在構建之法中有一張“功能/資源/時間的平衡圖”，非常形象的說明了這幾個項目要素的關系。

?

項目管理也是一種平衡之道，現在在資源不變，時間縮短的情況下，要么去犧牲功能，要么去犧牲質量。一般在這種情況下，如果不是一次性產品，我通常會選擇犧牲功能，質量上欠的債終究是要加倍還的，功能可以通過版本的迭代來完善。

?

?

除了被縮短時間導致計劃更改，還有個計劃更改的重要因素是來自需求的變更！據說因為需求老變，產品經理或老板被程序員砍的例子不少！其實需求的變更在軟件項目開發里面是常態，沒必要太過抵觸，但是需要科學的去管理。一般來講，如果項目的周期越長，需求變更帶來的影響越大！所以現在一般互聯網的項目，都比較追求功能精簡，快速上線，上線后持續迭代。

在遇到一些影響項目計劃的問題時，我一般處理原則如下：

對于需要縮短計劃時間的，根據情況減少一些功能或犧牲質量，并承擔相應的后果

對于需求變更的，評估是否對整體進度有較大影響：

• 如果影響不大，則不改變整體項目計劃，只做局部調整
• 如果影響較大，則對重新制定整體項目計劃，走相應的需求變更流程

同時，為了能及時相應需求的變更，需要對每一期項目功能進行合理篩選，合理搭配核心功能和外圍功能，讓項目周期在一個相對可控范圍。

?

項目計劃是項目管理中非常重要的一環，不計劃無管理。不同的項目不同的團隊，項目計劃的方式也各有不同，不過萬變不離其宗，根本還是在于對軟件工程構建之法的掌握和運用。

總結

以上是生活随笔為你收集整理的《构建之法》读后感之项目计划的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。