軟件開發人員常常不喜歡制定開發計劃，因為擔心計劃不準确，一旦承諾了不能按時完成任務會被領導死磕。有人認為計劃隻對領導有用。有人認為計劃趕不上變化，那要計劃還有何意義？

的确，制定有效項目計劃是項目經理的一項重要職責。但是，計劃對項目和團隊的重要性不言而喻，即算一個爛計劃也比沒有計劃好。一個項目一定有項目目标，有起始和結束時間，有一個要完成項目目标的團隊。計劃就為團隊以怎樣的進度達成目标提供了依據，是項目管理的重要手段。

項目計劃依目的不同而有不同的展現形式。比如項目路線圖，隻列出大的關鍵裡程碑和交付物（轉測時間點，版本發布時間等）。這個方便給領導或客戶彙報使用。團隊内部日常管理跟蹤得有更詳細的計劃。計劃主要反應：誰什麼時間做什麼事，什麼時候完成，交付物是什麼。而且，更重要的是通過制定計劃本身，可以促使團隊分析思考要達成目标所必須要完成的事情（任務），分析其中的風險或上下遊、内外部依賴，以提前做好應對措施，管理風險。

如果計劃不切實際不可行，那是沒有用的。筆者之前碰到有人魚和熊掌想兼得，導緻計劃不可落地，兩個重要目的都沒達成，魚和熊掌一個也沒抓到。

為了讓項目計劃能落地可執行，一般采用漸進明晰、遠粗近細的方法。對遠期的隻有高層的粗略計劃，對近期的制定詳細計劃（比如：一個月内的或兩星期内的任務）。

如何制定有效計劃？

1. 分解 制定計劃中一個重要步驟是評估，評估完成某一件事需要花費的人力/時間。這個評估的準确度直接影響了你的計劃是否靠譜，是否可執行。對任何複雜任務，如果沒有相同或類似經驗常常難以準确評估。對此，一個有效方法是分解。将目标分解成一個一個小的任務，再對小任務評估。分解成多小才算合适？一般估計工作量在半天到一天内能完成就可以，最長不要超過兩天。最好用小時來度量，最長不超過16小時。
2. 記錄實際時間 評估很難百分之百準确，為了度量預估時間與實際時間之間的偏差，自然需要記錄完成每個任務的實際用時。然後按周或雙周或月度分析總結差異所在，尤其是相差很大的根本原因是什麼。是碰到預料外的技術難題或者被意外事情打斷進展，又或是要解決新發現的重要bug。如此在團隊内持續運行一段時間，比如一個月或三個月，建立起團隊效能數據庫，作為後續評估參考的重要曆史數據。

關于制定計劃的一些要點

1. 應該讓完成具體任務的程序員給出評估時間 任何想當然的由領導拍腦袋給出的評估時間常常會失敗。華為任總有句話是：讓聽到炮火聲音的人做決定，就是要尊重一線人員的專業能力。在軟件項目中也應該這樣。有人肯定擔心喜歡劃水的程序員會給自己的評估很多水分。這個有很多方法可以解決。你可以用德爾菲法，找三個不同的程序員對同一任務分别給出評估，記錄下來。首先要信任團隊，如果成員劃水你也應該很快發現。可以直接面談溝通。如後續仍有此情況，你可以直接砍掉水分，或者降低其績效記錄，甚至最後直接移出你的團隊。
2. 将解決Bug的時間也計入你的任務實際完成時間 因為你任務的完成意味着是已測試的代碼，交付可工作的軟件，而不是一堆bug的代碼。有些人為了号稱自己是敏捷交付快速響應，一周發布多次版本，結果兩天寫完的代碼需要三天甚至一周時間來改bug，完全是本末倒置。
3. 經理們盡量不要壓縮開發人員的評估時間 這個前提是你的團隊已經磨合成熟，團隊成員誠實地給出合理的評估。領導和項目經理常常喜歡壓縮開發人員的時間。主要原因是在商務談判時常常給客戶過度樂觀地承諾，承諾3個月可以完成的産品，實際可能需要12個月。這樣項目實際開始時，客戶肯定會不高興，經理們為了讓客戶高興就常常壓縮開發人員的時間。
4. 計劃表像木盒 如果你有一堆小木盒想裝入一個大木盒卻裝不下，你隻有兩個選擇：要麼找一個更大的木盒，要麼扔掉一些小木盒。比如就你要在六個月内發布版本，但要12月才能完成所有開發。你要麼延期，重新規劃交付計劃；要麼砍掉一些不重要的需求。當然你也可以考慮加人和加班。加班對短期沖刺更有效，對長期的效率和質量都沒有保證。加人也有邊際效益，因為新人的加入需要培訓，也會影響已有成員的效率，亦會增加溝通成本和管理成本。

當然，計劃未必是一成不變的，根據項目實際情況需要持續監控管理或調整，在與相關幹系人（客戶、領導）達成一緻後可以修訂并簽字後成為新的基線。

總之，切實可行的時間計劃表是創建優秀軟件的關鍵。 它迫使您首先開發最重要功能，并允許您對構建内容做出正确的決定。 這樣可以使您的産品更好，老闆更快樂，使客戶滿意，最重要的是更大可能讓你團隊按時下班回家。（這個對習慣于996的“碼農”來說幾乎成了癡人說夢）

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!