軟件項目管理的矛盾平衡[2]

       軟件項目管理的矛盾平衡[2]  軟件項目管理

　　關鍵字：項目管理 矛盾平衡

　　工作分解咋控制?

　　“計劃趕不上變化!”一個項目經理感嘆道。

　　的確，項目中有相當多的不確定因素，項目經理辛辛苦苦做的WBS(工作分解結構)，可能因為客戶的改變，甚至領導的一句話，就分崩離析了。一些公司高層沒有經過仔細考慮，也沒有充分征求各個方面的意見，在制定總體計劃時比較隨意，修改起來更是“信手拈來”。項目經理也常常借口工作忙等理由，拖延制定詳細的WBS，甚至有項目經理認為，不應該制定詳細的WBS. 而沒有詳細WBS的危害也是明顯的：造成計劃與控制管理脫節，無法進行有效的進度控制管理，最終導致項目延期或成本上升?？梢哉f，沒有WBS或者是隨意的不負責任的WBS的項目是一種無法控制的項目。面對各種潛在的變化，項目經理應該怎樣制定WBS呢?

　　首先項目經理應該對WBS有正確的認識，制定WBS就是一個對項目逐漸了解掌握的過程，通過這個過程，項目經理可以知道哪些要素是明確的，哪些是要逐漸明確的，通過漸近明細不斷完善。漸近明細也是項目的一個特點，因此WBS的制定需要在一定條件的限制和假設之下采用漸近明細的方式進行不斷完善。

　　再者，制定WBS需要有一個現實的方法。一個大型的軟件開發項目，通常是采用二次WBS方法。即根據總體WBS，在需求調研階段結束、概要設計完成后，再專門針對詳細設計或編碼階段制定二次WBS .

　　一個方面，需求的顆粒度在一開始往往是比較粗的，因此根據功能點對于整體項目規模的估計誤差范圍也是比較大的，只能據此制定總體的WBS.另一個方面，需求和編碼工作分解不是一一對應的，一個需求的功能點可能對應多個代碼模塊，而多個需求的功能點也可能只對應一個或少數代碼模塊。只有在概要設計完成以后才能準確地得到詳細設計或編碼階段的 二次WBS.

　　例如，漢中市龍崗中學數字化校園建設項目中。合同規定8月28日之前系統必須投入試運行。由于但是項目準備時間十分的短，公司要求在2天時間內預算材料和聯系組織人員開工，項目經理組織大家制定了簡單的項目的WBS，并制訂了本項目的進度計劃，簡單描述如下

　　1. 應用子系統：7月1日～7月5日需求分析，7月6日～7月26日現場布線工作完成，7月20日～7月26日公司技術人員在公司對系統軟件進行調試，7月27日～8月18日所有設備安裝并進行系統現場測試;

　　2.系統整體調試：8月18日～8月25日完成完成網絡和系統功能的集成工作;

　　3.網絡子系統：8月25日～8月26日設備所有功能進行聯調;

　　4.系統整體調試、驗收：8月26日～8月27日試運行，8月27日系統驗收

　　在工程進行到8月15日的時候由于校方施工環境和原合同中的描述不一致，導致工程需要延時。但由于工程在開始階段時間過緊，編制的這個WBS比較粗糙，不適合作為編織項目計劃的基石。只有一個項目的大概框架和子系統各部分的期望完成時間。從該WBS上面可以看出最底層任務的工期至少也在半個月左右。如果任何一個任務出現了問題，就必然會出現這樣的問題，即延期和延期發生了較長時間才知道。

原文轉自：http://www.anti-gravitydesign.com