一個良好的計劃對項目的管理至關重要，看到過很多介紹軟件項目計劃制定的文章，但主要還是依據項目管理的要點來進行，總感覺理論性過強，不便于操作，下面則根據個人經驗來討論一下軟件項目計劃的制定。

　　筆者認為制定計劃的意義是在于可以真實客觀的反映項目全貌，及時的發(fā)現問題，糾正問題，確保項目可嚴格按照計劃執(zhí)行，項目的進展是由眾多因素來構成的，所以，如何快速的了解項目的真實情況，并加以控制，制定計劃是一個最好的手段，但并不意味著制定了一個良好的項目計劃，就可以成功的完成項目，前面說過項目是由眾多因素構成，制定了項目計劃僅僅是項目的開始。所以，項目應該有個好的開始，并努力朝著好的方向發(fā)展。(項目計劃的意義在于通過制定計劃來預測在現有的資源情況下你能否完成項目的目標，你完成項目目標的把握程度和主要風險，將大項目目標進行分解和細化，以對項目有更加深入的理解。同時項目計劃是后續(xù)項目跟蹤控制的基礎，可以及時發(fā)現偏差并糾正;最后項目計劃是項目管理持續(xù)改進的基礎，在項目結束進行復盤的時候可以總結和分析和計劃的差異，分析各種數據和偏差，及時改進我們的方法和過程，積累數據。最后不能因為計劃不準確而不做計劃。)

　　一、了解制定計劃的先行因素

　　簡單的講項目計劃的先行因素是你在制定項目計劃中所依據的內容：包括項目范圍、項目資源及質量標準。以一個最簡單的任務來分析，至少要具備這三點因素，任務的執(zhí)行時間如何確定?任務由誰來完成?如何判斷此任務已經真正的完成?

　　如果再進一步分析，則需要風險管理計劃，針對在項目過程中出現的各種風險進行評估、分析、應對及補救。其他的內容從一定的程度上可以制定在計劃中完成，譬如測試計劃。

　　任何一個項目的啟動通常情況下都會先制作項目范圍說明書，只是有時候名稱會有所不同，此類文檔可以支撐計劃的制定，譬如，項目需要完成的內容、項目完成的約束時間、項目資源的評估、項目費用的估算、項目質量的考核標準、及項目最終驗收的標準。但此類文檔通常情況下不能夠很明細，所以，建議將此類文檔中的內容進行摘要，并制定在計劃中逐一落實。

　　總結:項目計劃的先行因素應該是項目的可行性分析，對項目的目標和范圍的理解，對項目可能面臨的風險的深刻理解，對你項目所處于的環(huán)境的認識，對項目各方干系人的初步認識和分析。

　　二、開始制定計劃

　　第一：要明確項目中到底需要做哪些工作內容，這也是通常所說的活動定義。譬如：針對軟件項目而言會存在系統(tǒng)設計、編碼、測試等工作內容，這些都屬于項目活動，但可能還會有前面提到的需要細化的內容。通常情況下軟件項目會有需求調研、需求分析、概要設計、詳細設計、編碼、測試、集成、試運行等內容(注意此處對應在確定了項目的目標和范圍，假設和約束后，需要首先確定的就是項目選擇的生命周期模型和項目管理方法論)。在此基礎上，將業(yè)務需求進行自上而下的分解，然后制定出最基本的項目工作內容。當然除此之外，還有很多工作要做，這則需要根據項目的實際情況來進行確認了。

　　在談到活動定義中，不得不說的就是WBS(工作分解結構)。實際在確定有哪些工作內容的同時，也是在制定你自己的工作分解結構。(注:當確定了軟件開發(fā)生命周期模型后，一般就有比較成熟的項目WBS結構模板和進度模板可以借鑒。)

　　第二：制定好工作內容后，則需要對這些工作內容進行排序，即活動排序，排序過程需要明確的有：工作內容的優(yōu)先級，前后完成的順序及工作內容之間的依賴關系。

　　就好像編碼需要依賴于設計的成果，而設計又依賴于需要的分析，需求分析又依賴于需求的調研結果和用戶的要求，這是一個前后的次序，同時又存在一定的依賴性。有時候這種關系會復雜一些，譬如用戶的要求可以分解為對業(yè)務功能的補充和系統(tǒng)考核要求，這樣，這種依賴關系就會產生分支，業(yè)務功能的補充會作為需求調研成果進行完善，而系統(tǒng)要求則作為質量計劃進行最終的系統(tǒng)考核。同時，如果結合業(yè)務需求進行考慮，這種前后的依賴關系和順序將更為復雜。(注意產生分支的原因是大的子系統(tǒng)或模塊，我們會進行分解為更細的功能單元以便進行并行開發(fā)，因此后續(xù)自然會涉及到這些單元的集成問題。在CMMI三級中有專門的PI產品集成過程域可以借鑒。)

　　但有些任務也并非完全一定要依賴于另一項任務，所以在確定其依賴關系的時候要將此種情況考慮進去。實際很多項目經理已經這樣做了，當需要趕進度的時候，通常就會打破這種依賴關系讓任務先行的運行起來。

　　針對外部依賴關系的工作內容，筆者不認為有特別好的辦法可以進行控制，只能是通過加強風險意識，提早制定風險計劃以應對此類事情的發(fā)生。畢竟PM的權限是有限的，而且也需要PM要有很好的協(xié)調處世能力。這也是PM面臨的實際問題。(并行的前提是實現約定各種接口以便于后續(xù)的集成，如果前期沒有這種約定后續(xù)集成會發(fā)生大量的問題。)

　　第三：則需要明確里程碑，不要小看這個東西，里程碑是嚴格用于控制項目計劃的重要指標。里程碑如果出現了變更，則表示項目出現了重大問題，有可能直接導致最終項目無法按照指定要求完成。

　　第四：重點討論一下進度的制定和資源的分配，即安排活動資源，制定時間計劃。這是彈性最大的一個過程。或者說這是人為因素最大的一個過程。很多項目都是在已知了最終的項目提交時間的情況下來制定的項目計劃，所以，時間計劃的制定是通過倒推來完成的，當然也存在根據時間計劃制定最終的項目驗收時間的情況，但通常在計劃的制定過程中，無法細化項目中的很多內容，故制定的最終進度計劃也可能會出現很大的偏差，或者是甲方無法接受的情況。最終還是要通過項目提交時間來進行倒推。經常聽到的一句話就是以市場為導向，所以項目也好、產品也罷最終要為市場服務，既然為市場服務，則需要根據市場的時間來安排了。但并不是說時間可以壓縮人力就可以無限增加，所以，這個過程通常是一個比較痛苦的過程。(倒排進度也是在進度和資源緊張情況下做進度計劃的一種方法，但是倒排進度不能破壞游戲規(guī)則。推薦的方式是根據最后期限確定幾個大的里程碑點，然后在里程碑點里面仍然是正排進度計劃，當超出了期限的時候再進行資源負載的重新分配和協(xié)調。)

　　1) 首先應該進行工作量的核算，針對工作量的核算，可以采用用例點估算法，或者經驗法的方式來進行。在這個過程中不建議考慮到任何的限制條件，只需要你考慮工作量的核算，作為項目經理而言自己心里一定要知道工作量到底有多大，這是一個底線，只有明確工作量的大小，才好完成項目，不要通過實際的行動來告訴你工作量的大小，那樣就遲了。但無論采用何種方式，工作量的大小并非完全可以在項目制定計劃的階段就可以完全計算出來，即便采用了用例點估算的方式，也只是一個大概，所以，計劃的制定本身就是一個循序漸進的過程，不斷的完善，不斷的細化，不斷的調整。但大概的工作量一定要估算出來，這樣才好作后續(xù)的工作。(估算是在軟件項目計劃中一個比較重要的概念，估算方法有專家法，三點法和功能點法等。用例點估算是結合用例估算和功能點估算的一些優(yōu)點，用例點最終得到的是軟件需求的規(guī)模，然后在根據軟件需求的規(guī)模和需求生產率，歷史項目的工作量比例分布等等到項目各個階段的工作量，在這里我們要注意的是在WBS確定后在軟件項目中會先開展估算活動，確定項目的規(guī)模和工作量，然后再來進行活動定義和排序，活動資源分配，進度表的制定。)

　　2) 其次，充分考慮關鍵技術的難度及最終應用環(huán)境的技術難度?，F在一個項目通常會用到很多的技術，甚至是一些新技術。所以，一定要認真對待這個問題，PM很多都是技術出身，所以本身對新技術的探索就有一定的興趣，但不要忘了你是在管理項目，新技術需要攻關、團隊的熟悉掌握，最終才可應用到你的項目中，這其中每個環(huán)節(jié)出了問題都會影響項目進度或質量，所以，這種風險一定要提前預知。我曾經做過一個項目就遇到過此類問題，因此以后在做項目規(guī)劃書的時候都會將應用到的關鍵技術進行獨立介紹，以引起大家的重視。由于對關鍵技術掌握不足而導致項目嚴重超期的例子并不少見。(首先是為了保證項目的可預測性不推薦使用各種新技術和不成熟的技術，其次當確實需要一些新技術的時候應該是在項目開始前提前識別風險和進行風險應當，安排相應的成員對新技術進行預研，明晰風險。)

　　3)人力資源安排，在安排人力資源之前，一定要對你的團隊每個人都要有充分的了解，這樣有助于項目的進展。每個人員的技術能力是否可以滿足要求?每個人員的獨立解決問題的能力是否很強?每個人員對技術的探索欲望是否也很強?哪些人員渴望掌握新技術?哪些人員又渴望采用成熟的技術來完成?這些都對你進行人力的安排有幫助。最重要的就是你安排給的任務是否可以完成?(這里面強調兩點，一個是瓶頸資源必須要用倒關鍵的任務和活動上，一個是要充分考慮倒個人的技能和任務的匹配度。在安排人力資源之前我們需要首先確定兩個東西，一個是項目內各個成員的技能評估，一個是成員的崗位和職責分工。)

　　4)制定時間計劃，人力資源安排完成后，結合工作量的分析，時間計劃就會自然而然的制定出來，當然在這個過程中還需要考慮到一些外部因素，譬如業(yè)務的復雜程度、技術應用的復雜程度等。這個過程可以在工作量核算的時候作為調節(jié)因子進行計算，也可以在時間計劃中給予調節(jié)。(在排進度的時候注意采用固定工時的方式，由于有些任務比如會議，評審等沒有嚴格的關聯依賴關系，因此當我們用項目管理軟件擬制完進度計劃后仍然需要進行資源平衡。)

　　三、計劃的調整

　　結合前面所有的介紹包括工作內容的制定、排序、里程碑的制定，到此基本上一個完整的計劃就可以完成了，但并非項目計劃就已經完成，此時需重新分析整體計劃是否可以滿足項目要求，如果不滿足，開始進行調整。實際計劃的調整就是在保證質量的前提下，在資源不變的情況下，壓縮時間。但在此過程應重點結合風險計劃來共同完成。

　　1)從項目進展來看，每個人員的工作效率是會逐步提高的，因為先期的任務帶有一定的技術難度和不熟悉程度，但當項目進展到一定程度的時候，工作也就會慢慢熟練起來，所遇到的問題會越來越少，這樣效率自然就會提高。而且在項目不斷的推進過程中，可復用的內容也會越來越多，工作量也會降低，自然工作效率也會提高。所以，從時間的安排來講，可以在此多做一些工作。而且項目整體壓力來看也應該是先緊后松，不是項目越做壓力就越大。

　　2)前面提到過，針對活動排序，要進行分析，哪些活動是存在必須的依賴關系，哪些是存在可斟酌處理的依賴關系，這些活動時候可以跳過這些依賴內容而直接進行，節(jié)約的人力是否可以安排到其他活動中以加快項目進展。(還是需要識別關鍵路徑，關鍵和瓶頸資源)

　　3)活動的排序通常是一個順序型的，但也要認真分析，哪些任務可以并行展開，項目在開始初期，并非所有人力都可達到飽和狀態(tài)，此時，是否有些任務可以先行開始。也就是說這種排序關系是否可以在合理的范圍內進行調整，為人力資源的充分利用做一定的讓步。

　　4)通過以上調節(jié)還是無法完成項目指定要求，那就需要申請新的資源了，或者需要斟酌項目提交時間了。不建議項目計劃在制定初期就將項目的壓力加的很大，這樣會將后期調整的空間壓縮的很小，不便于對變更、風險等突發(fā)情況進行處理。

　　到此，可以說計劃初步制定完成。但計劃的制定決不是一蹴而就的事情，需要不斷的完善，不斷的修正才可真實的去反映項目的實際情況。

　　(注:本文很多內容沒有談及到，比如質量計劃，人力資源計劃，風險計劃等和整個進度計劃的關系，如何保證質量和成本目標的達成等，但是對應進度計劃的擬制過程還是很明晰的。我們要注意不是在項目進度計劃擬制完成了才開始考慮制定這些計劃，而是對人力的考慮，風險的識別和分析，對質量目標理解后轉換為的評審，測試等各種WBS項和任務，對風險識別后的應當措施安排的，這些都和項目進度計劃的編制密切相關。因此項目管理計劃是綜合考慮進度，質量，范圍，成本，風險，人員等各種要素后的計劃。) http://blog.mypm.net

　　四、其他問題

　　1.實際前面并沒有涉及一個重要的內容就是質量，質量標準的高低也將直接影響到項目的實際進展情況。盡管在項目初期已經有了質量考核指標，但無法對項目內部很多工作內容的交付成果進行質量考核，所以，質量計劃尤為關鍵，最好可以在項目初期就制定完成，來指導項目的進展。在計劃制定過程中，也要充分考慮到質量考核標準的因素。

　　2.PM只是計劃的一個起草人而已，不要認為計劃制定是PM一個人的事情，計劃要與團隊充分的溝通才可很好的完成。而且筆者建議計劃一定要透明，因計劃的后期維護、跟蹤管理是要靠團隊共同完成，所以，計劃的制定不是PM一個人的事情，是團隊的所有人都應承擔的責任。

　　3.工具的使用首推MS Project及MS Project Server。