引導語： 專案管理計劃是專案的主計劃或稱為總體計劃，它確定了執行、監控和結束專案的方式和方法，包括專案需要執行的過程、專案生命週期、里程碑和階段劃分等全域性性內容。下面是yjbys小編為你帶來的軟體開發專案管理計劃的8大問題分析，希望對你有所幫助。
專案管理計劃是其它各子計劃制定的依據和基礎，它從整體上指導專案工作的有序進行。
在軟體開發專案實踐中，關於計劃主要有以下一些常見問題
1、制訂計劃時沒有進行充分的溝通
專案經理制訂計劃時沒有和專案主要成員和主要專案干係人共同討論協商，達成共識;或者最終計劃沒有釋出到所有相關的專案干係人，取得他們的認同、理解，最重要的是對計劃中共同責任、目標和各自責任、目標的承諾;由此而造成的後果是專案管理計劃缺乏專案組成員的支援，沒有成為專案組成員的共識，沒有使每個專案組成員努力實現在專案管理計劃中所作的承諾。因此專案經理制訂計劃時首先要分清或確定主要專案成員和主要專案干係人，然後與他們進行充分的溝通協商，使專案管理計劃是一個大家都認同的，形成共識的有效檔案。
一種更為嚴重的情況是遺漏了重要的專案干係人。在制定計劃時沒有考慮到所有專案干係人，特別是那些對於專案的成敗有重要影響的專案干係人，在制定計劃時要和他們進行充分溝通取得對專案進度、資源、驗收標準等計劃的共識和保證。
2、對編寫計劃的過程在思想意識上重視不夠
實際上是對專案管理計劃的重要性認識還不夠充分，雖然大家都知道知道“作計劃”很重要，是專案成功的關鍵，但又認為計劃就是寫文件，也許是因為一些人善於寫程式但不善於寫文件，所以有些專案經理會認為寫文件是一種走形式，或對繁瑣的文件有一種排斥心理。其實不能把計劃當成僅僅是寫一個計劃文件的問題，而是要通過編寫計劃文件的過程，理清專案目標、專案範圍、專案所需資源、制定合理的專案進度、制定完成專案所需的各種約定(溝通、變更)、制定應對風險的有效對策。對於這一問題的解決，首先應當提高專案經理的計劃意識，採用專案管理計劃制定相關各種知識、技術、工具，加強對開發計劃、階段計劃的有效性進行事前事後的評估與評審工作。
3、專案任務分工或進度計劃表的顆粒度太大
常見的現象有對任務持續時間進行不切實際的估計;或未考慮到任務的.相互依賴關係而造成遺漏工作。其主要原因是軟體工程的分析與設計經驗的不足，無法細化系統需求，並從需求推匯出設計，根據設計去分配任務。根據細化的需求也可以分配任務，但是由於需求中的功能點和設計中的模組往往不是一一對應的，如一個需求功能點需要一系列的模組來實現，多個需求功能點也可以共用同一組模組加上不同的設定引數來實現。所以根據設計來確定程式程式碼階段的任務分配比較合理。需求是整個專案的基礎、需求的清晰顆粒度對後面的工作及工作計劃的準確性至關重要。專案管理計劃的準確度是以一開始以需求(包括設計層需求)為基礎得出的工作結構分解的完整性、清晰性為基礎的。如果沒有這個基礎，專案管理計劃就不可能做得很準確。在無法準確制定專案管理計劃的情況下，對其風險要足夠重視，並制定出具體可行的對策。如果對整體的需求或工作結構分解無法一次完整的清晰，就應當把它先分解為幾個大塊，分塊進行，已經清晰的先制定本塊(階段)計劃，下一環節的工作也可以開始(分塊)進行。再專案開始階段往往還沒有得到詳細的需求成果，因此根據專案管理計劃漸進明晰的特點，在需求調研分析階段過後，需求成果清晰是，應當及時細化專案管理計劃，在概要設計完成時，要更進一步地細化後面編碼測試階段的詳細計劃。
4、對總體計劃、階段計劃的作用認識不足
專案經理認為計劃不如變化快，專案中也有很多不確定的因素，做計劃是走過場，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮，或者是有一種等一下再說的想法;階段計劃因工作忙等理由經常拖延，造成計劃與控制管理脫節，無法進行有效的進度控制管理。那些號稱“所見即所得”的OA，邊做、邊提需求、邊改、邊完善的“四邊形”的所謂“快速”軟體開發也可能竟然是本企業週期延續最長的專案，因為無休無止的需求變更而永無止境。從專案管理計劃階段來看，因為邊做、邊提需求、邊改、邊完善，所以他們首先就對計劃沒有信心，基本上計劃對他們來說只是應付，久而久之，對計劃方面的鍛鍊意識不如其他專案，甚至養成不容易改掉的習慣。
5、遺漏重要的假設或約束條件
如一些政府機關的管理資訊系統軟體開發專案隱含的需求是必須遵守一系列的國家和行業標準，但由於沒有考慮到這些要求，致使專案管理計劃失敗，開發出某些功能、效能或資料不符合國家和行業標準的軟體，造成返工。所以應當儘可能地將將任何設想和約束編入文件。做專案管理計劃時應該儘可能地把假設條件和約束條件考慮清楚，這些假設和約束可以是樂觀的、悲觀的或者是最可能的估計。例如，可以假設能夠及時獲得應用程式伺服器的新發行版，或可以得到熟悉專案正在採用的技術和技巧的開發人員;還可以假設，專案能在一些約束下工作，如影響計劃的強制截止期限或資源限制等等。應該把這些假設和約束條件編入計劃文件中，在專案的實施過程中，當專案管理計劃需要細化和調整時，就應該考慮到這些約束條件，而不是以一種“無限資源”的方式做計劃。一般來說，假設、約束和風險的區別是假設、約束是一些比較明顯、明確、已經發生或肯定會發生的情況，而風險這是不一定會發生的，具有不確定性。
6、專案管理計劃沒有突出重點
軟體開發涉及到方方面面的工作，有些是主要的，有些是次要的，專案管理計劃應當反映有價值的工作任務、環境條件。專案管理計劃不能寫成一個大雜燴，也不能寫成一個包羅永珍的百科全書。在專案管理計劃中要簡潔精確地反映對專案有價值的事情、任務和活動，避免羅嗦。專案管理的理論方法、成功的專案管理經驗都是在實施專案時應該參考的。但是，每個專案是特殊的，具有“唯一性”的，一次需要為每個專案做專門的計劃，選擇適合的專案，適合的團隊的方式和方法。
7、忽視次要工作任務對專案的影響
軟體開發專案管理計劃不僅要安排需求分析、概要設計、必要時的詳細設計、系統實施和測試與維護等實際的重要工作，而且還應該安排專案中的支援性輔助活動，這些支援性輔助活動雖然不能成為關鍵活動，但是它們卻對專案的進展又作重大的影響。這些輔助活動包括體系結構定義、文件評審後文檔編寫的返工甚至是需求調研的返工，測試之後的編碼返工、系統交付、與軟體複用相關的活動、專案組內溝通交流、休假和法定假日、培訓和教育、團隊成員的生活(如飲食、住宿、交通等)、專案規劃、人員管理等管理活動、會議和回覆電子郵件，等等。做專案管理計劃時應當儘可能完整地列出這些影響專案的活動，或者按照固定的模板進行計劃的制訂，免得遺漏必要的計劃內容。有時候，小的疏忽會帶來大的問題，次要矛盾會成為或引發主要矛盾。例如，加班安排不當，會引起員工的厭倦甚至離職，造成軟體專案的人力資源問題，從而影響專案的進度，甚至導致專案失敗。
8、工作任務的分解不便於人員分工
在確定了系統構架之前應該考慮在編寫文件的同時是否有些其他基礎性的工作可以先做，如是否在需求分析的同時進行部分的系統概要設計;是否可以先進性技術預研，環境架構搭建、後臺資料庫框架搭建、軟體系統框架搭建等等。迭代法使得在上一階段的部分任務完成後，下一階段的對應工作就可以投入進行。在確定了系統構架之前之後工作任務的分解都要考慮模組編碼獨立性、開發編碼工作的負載均衡、編碼進度安排優化、預防人員流動(如生病、其他更緊急的任務、離職等)對開發的影響一個好的專案管理計劃同時應有助於減少專案組的壓力和緊張，提高軟體開發效率。
為了建立並整合一個很好的專案管理計劃，專案經理必須運用專案整合管理技巧，因為需要來自專案管理知識領域方方面面的資訊。與專案團隊以及其他的干係人一起工作來建立專案管理計劃將幫助專案經理指導專案的執行並理解整個專案。
