軟件開發項目管理計劃的8大問題分析

引導語： 項目管理計劃是項目的主計劃或稱為總體計劃，它確定了執行、監控和結束項目的方式和方法，包括項目需要執行的過程、項目生命週期、里程碑和階段劃分等全局性內容。下面是yjbys小編為你帶來的軟件開發項目管理計劃的8大問題分析，希望對你有所幫助。

項目管理計劃是其它各子計劃制定的依據和基礎，它從整體上指導項目工作的有序進行。

在軟件開發項目實踐中，關於計劃主要有以下一些常見問題

　　1、制訂計劃時沒有進行充分的溝通

項目經理制訂計劃時沒有和項目主要成員和主要項目干係人共同討論協商，達成共識;或者最終計劃沒有發佈到所有相關的項目干係人，取得他們的認同、理解，最重要的是對計劃中共同責任、目標和各自責任、目標的承諾;由此而造成的後果是項目管理計劃缺乏項目組成員的支持，沒有成為項目組成員的共識，沒有使每個項目組成員努力實現在項目管理計劃中所作的承諾。因此項目經理制訂計劃時首先要分清或確定主要項目成員和主要項目干係人，然後與他們進行充分的溝通協商，使項目管理計劃是一個大家都認同的，形成共識的有效文件。

一種更為嚴重的情況是遺漏了重要的項目干係人。在制定計劃時沒有考慮到所有項目干係人，特別是那些對於項目的成敗有重要影響的項目干係人，在制定計劃時要和他們進行充分溝通取得對項目進度、資源、驗收標準等計劃的共識和保證。

　　2、對編寫計劃的過程在思想意識上重視不夠

實際上是對項目管理計劃的重要性認識還不夠充分，雖然大家都知道知道“作計劃”很重要，是項目成功的關鍵，但又認為計劃就是寫文檔，也許是因為一些人善於寫程序但不善於寫文檔，所以有些項目經理會認為寫文檔是一種走形式，或對繁瑣的文檔有一種排斥心理。其實不能把計劃當成僅僅是寫一個計劃文檔的問題，而是要通過編寫計劃文檔的過程，理清項目目標、項目範圍、項目所需資源、制定合理的項目進度、制定完成項目所需的各種約定(溝通、變更)、制定應對風險的有效對策。對於這一問題的解決，首先應當提高項目經理的計劃意識，採用項目管理計劃制定相關各種知識、技術、工具，加強對開發計劃、階段計劃的有效性進行事前事後的評估與評審工作。

　　3、項目任務分工或進度計劃表的顆粒度太大

常見的現象有對任務持續時間進行不切實際的估計;或未考慮到任務的.相互依賴關係而造成遺漏工作。其主要原因是軟件工程的分析與設計經驗的不足，無法細化系統需求，並從需求推導出設計，根據設計去分配任務。根據細化的需求也可以分配任務，但是由於需求中的功能點和設計中的模塊往往不是一一對應的，如一個需求功能點需要一系列的模塊來實現，多個需求功能點也可以共用同一組模塊加上不同的設置參數來實現。所以根據設計來確定程序代碼階段的任務分配比較合理。需求是整個項目的基礎、需求的清晰顆粒度對後面的工作及工作計劃的準確性至關重要。項目管理計劃的準確度是以一開始以需求(包括設計層需求)為基礎得出的工作結構分解的完整性、清晰性為基礎的。如果沒有這個基礎，項目管理計劃就不可能做得很準確。在無法準確制定項目管理計劃的情況下，對其風險要足夠重視，並制定出具體可行的對策。如果對整體的需求或工作結構分解無法一次完整的清晰，就應當把它先分解為幾個大塊，分塊進行，已經清晰的先制定本塊(階段)計劃，下一環節的工作也可以開始(分塊)進行。再項目開始階段往往還沒有得到詳細的需求成果，因此根據項目管理計劃漸進明晰的特點，在需求調研分析階段過後，需求成果清晰是，應當及時細化項目管理計劃，在概要設計完成時，要更進一步地細化後面編碼測試階段的詳細計劃。

　　4、對總體計劃、階段計劃的作用認識不足

項目經理認為計劃不如變化快，項目中也有很多不確定的因素，做計劃是走過場，因此制定總體計劃時比較隨意，不少事情沒有仔細考慮，或者是有一種等一下再説的想法;階段計劃因工作忙等理由經常拖延，造成計劃與控制管理脱節，無法進行有效的進度控制管理。那些號稱“所見即所得”的OA，邊做、邊提需求、邊改、邊完善的“四邊形”的所謂“快速”軟件開發也可能竟然是本企業週期延續最長的項目，因為無休無止的需求變更而永無止境。從項目管理計劃階段來看，因為邊做、邊提需求、邊改、邊完善，所以他們首先就對計劃沒有信心，基本上計劃對他們來説只是應付，久而久之，對計劃方面的鍛鍊意識不如其他項目，甚至養成不容易改掉的習慣。

　　5、遺漏重要的假設或約束條件

如一些政府機關的管理信息系統軟件開發項目隱含的需求是必須遵守一系列的國家和行業標準，但由於沒有考慮到這些要求，致使項目管理計劃失敗，開發出某些功能、性能或數據不符合國家和行業標準的軟件，造成返工。所以應當儘可能地將將任何設想和約束編入文檔。做項目管理計劃時應該儘可能地把假設條件和約束條件考慮清楚，這些假設和約束可以是樂觀的、悲觀的或者是最可能的估計。例如，可以假設能夠及時獲得應用程序服務器的新發行版，或可以得到熟悉項目正在採用的技術和技巧的開發人員;還可以假設，項目能在一些約束下工作，如影響計劃的強制截止期限或資源限制等等。應該把這些假設和約束條件編入計劃文檔中，在項目的實施過程中，當項目管理計劃需要細化和調整時，就應該考慮到這些約束條件，而不是以一種“無限資源”的方式做計劃。一般來説，假設、約束和風險的區別是假設、約束是一些比較明顯、明確、已經發生或肯定會發生的情況，而風險這是不一定會發生的，具有不確定性。

　　6、項目管理計劃沒有突出重點

軟件開發涉及到方方面面的工作，有些是主要的，有些是次要的，項目管理計劃應當反映有價值的工作任務、環境條件。項目管理計劃不能寫成一個大雜燴，也不能寫成一個包羅萬象的百科全書。在項目管理計劃中要簡潔精確地反映對項目有價值的事情、任務和活動，避免羅嗦。項目管理的理論方法、成功的項目管理經驗都是在實施項目時應該參考的。但是，每個項目是特殊的，具有“唯一性”的，一次需要為每個項目做專門的計劃，選擇適合的項目，適合的團隊的方式和方法。

　　7、忽視次要工作任務對項目的影響

軟件開發項目管理計劃不僅要安排需求分析、概要設計、必要時的詳細設計、系統實施和測試與維護等實際的重要工作，而且還應該安排項目中的支持性輔助活動，這些支持性輔助活動雖然不能成為關鍵活動，但是它們卻對項目的進展又作重大的影響。這些輔助活動包括體系結構定義、文檔評審後文檔編寫的返工甚至是需求調研的返工，測試之後的編碼返工、系統交付、與軟件複用相關的活動、項目組內溝通交流、休假和法定假日、培訓和教育、團隊成員的生活(如飲食、住宿、交通等)、項目規劃、人員管理等管理活動、會議和回覆電子郵件，等等。做項目管理計劃時應當儘可能完整地列出這些影響項目的活動，或者按照固定的模板進行計劃的制訂，免得遺漏必要的計劃內容。有時候，小的疏忽會帶來大的問題，次要矛盾會成為或引發主要矛盾。例如，加班安排不當，會引起員工的厭倦甚至離職，造成軟件項目的人力資源問題，從而影響項目的進度，甚至導致項目失敗。

　　8、工作任務的分解不便於人員分工

在確定了系統構架之前應該考慮在編寫文檔的同時是否有些其他基礎性的工作可以先做，如是否在需求分析的同時進行部分的系統概要設計;是否可以先進性技術預研，環境架構搭建、後台數據庫框架搭建、軟件系統框架搭建等等。迭代法使得在上一階段的部分任務完成後，下一階段的對應工作就可以投入進行。在確定了系統構架之前之後工作任務的分解都要考慮模塊編碼獨立性、開發編碼工作的負載均衡、編碼進度安排優化、預防人員流動(如生病、其他更緊急的任務、離職等)對開發的影響一個好的項目管理計劃同時應有助於減少項目組的壓力和緊張，提高軟件開發效率。

為了創建並整合一個很好的項目管理計劃，項目經理必須運用項目整合管理技巧，因為需要來自項目管理知識領域方方面面的信息。與項目團隊以及其他的干係人一起工作來創建項目管理計劃將幫助項目經理指導項目的執行並理解整個項目。