1 概述
通過對項目管理的系統(tǒng)學習，我個人對于工作分解結構在軟件中的應用有很深的感觸，對于工作分解結構在軟件開發(fā)中的應用有一些個人的看法和見解。
首先我們看一下項目分解結構的定義，工作分解結構是進行范圍規(guī)劃時所使用的重要工具和技術之一，是面向可交付成果的對項目元素的分組，它組織并定義了整個項目范圍，未列入工作分解結構的工作將排除在項目范圍之外。它是項目團隊在項目期間要完成或生產出的最終細目的等級樹，所有這些細目的完成或產出構成了整個項目的工作范圍。
從項目分解結構的定義和我們的學習我們知道，項目分解結構主要針對的是可交付物以及工作細分。同時通過學習我們知道，項目分解結構產生于項目計劃階段過程，在項目執(zhí)行過程的控制中對項目進行考核和控制，最后在項目結束階段為整個項目的考核提供參考。但是，我個人認為，如果從軟件開發(fā)的角度來看的話，項目分解結構這個工具在需求定義期間也能起到很好的應用，也是非常有意義的，我將會再下面的示例中進行闡述。下面結合實際工作案例對項目分解結構在軟件開發(fā)項目中的應用作一個簡單的描述。
2 軟件項目存在的普遍性問題
1、工作范圍界定
首先我們來看一下什么是軟件開發(fā)，說白了，軟件開發(fā)其實就是讓電腦在我們設定好路線上行走的一個實現過程。而人的思維是邏輯的、發(fā)散性的，電腦的思維是單一的、指令性的。就此而言，在電腦軟件的實現過程中需要對人的思維和操作方式進行整理，形成一個符合電腦工作的一個流程，在這中間就涉及到了工作范圍界定，和各種信息的綜合篩選。
2、工作量估算
通過幾個軟件項目的完工，我又這樣的一個感觸，一個軟件項目如果完成時間超過預計時間15%以下就算是一個很不錯完成時間。從我接觸的幾個項目上來看，最長的一個項目甚至延期了將近半年的時間，而最初的預期開發(fā)時間只有三個月。從后來對項目最終評估結果看來，除了由于客戶的一些行政和人事原因引起的延時，很大一部分原因還是因為對項目的工作量把握不夠，在一些關鍵的模塊上產生了很嚴重的超時。
3、需求難以明確
在軟件項目啟動階段，不管是甲方還是乙方，對于軟件的估算都是不足的，項目的需求都有一個從模糊到清除的過程，在項目啟動階段，總是需求最模糊的一個階段，而這個階段卻是項目的一個重要階段，明確地需求直接關系到開發(fā)的成本和報價，怎樣與客戶通過溝通得到較為一致且明確地需求就顯得非常重要。
4、軟件開發(fā)過程控制
在軟件開發(fā)過程中，溝通和交流的直接明了非常重要，通暢準確的溝通可以很好的提高開發(fā)效率和明確的得到最終交付物，但是如果光靠通過口頭交流來說的話容易產生一定的偏差，通過文字來交流話又不是很直觀。難以滿足對項目及時調整、管理、甚至決策的需要。
從以上的各個問題來說，事實上我們需要的是一個統(tǒng)一的、規(guī)范的溝通標準，利用此標準可以是項目的各個參與方進行有效的信息溝通，同時可以確保業(yè)余與項目管理方獲得準確實時的項目信息，以便高校的對整個項目的進度、成本、質量進行統(tǒng)一的計劃和控制。
3 工作分解結構的具體應用
在這里我簡單的描述一下項目，該項目是針對電力行業(yè)的一個MIS項目，在項目的執(zhí)行過程中我們事實上沒有完全按照項目管理的規(guī)范來做，但是，在項目的各個環(huán)節(jié)中我們都很多的用到了工作分解結構這樣的一個工具，在這里我們分階段進行應用闡述。
1、啟動階段
項目在最初定義階段，不管是客戶還是軟件開發(fā)人員，對于系統(tǒng)的了解總是基于大模塊的，而對于模塊的局部結構的了即就比較模糊了，在需求定義和明確的過程中，首先通過軟件人員的頭腦風暴形成一個最初的軟件分解結構，然后以此為基礎與客戶進行溝通就比較直觀明了，便于客戶形成直觀的概念。但是，在這個階段里面，項目里面的很多內容往往是不清晰和不確定的，在這里我們就可以很好的利用項目分解結構這個工具來進行有效的溝通。
我們可以從以下的三個圖來說明這種情況，這幾個圖是在對MIS項目就行需求分析時產生的。首先圖一表示的是通過開發(fā)人員的最初調研形成的組織分解結構圖，然后在此基礎上，通過與客戶的交流發(fā)現MIS結構的模塊分布式是上并不是原想的組織結構。我們了解到，電管站的電費最終也是收入到營銷部，從電費歸屬的意義上來說的話，電管站最終也歸營銷部管理，所以我們對組織結構圖進行了再一次的整合和修改。形成了第二個組織結構圖，在大的模塊的到確認的前提下，對其中的各個模塊進行進一步的細分，對各個模塊以最終可交付物為單位形成各個模塊的細分結構，如圖三，其他模塊省略。這樣就同時對軟件開發(fā)人員和系統(tǒng)使用人員都形成了一個直觀可行的模塊印象。
在這里我們可以看出，在需求定義階段，項目分級結構可以作為一個很好的客戶與調研人員溝通的手段，可以更好的對項目的構建形成一個統(tǒng)一的認識，同時界定出項目的模塊范圍，為以后軟件開發(fā)產生需求變更提供參考依據。
同時由于組織分解結構是以最終交付物為單位的，以一人兩周的開發(fā)周期作模塊分解的依據。所以，當最終的項目分級結構形成之后，可以依據項目分解結構計算出項目所需要的工期以及開發(fā)人員資源，并以此為基準計算出項目的可估算成本。
2、計劃階段
雖然在項目啟動中，我們已經生成了一個簡單的項目分解結構圖，但是那其實還是遠遠不夠的，項目分解結構圖紙是項目分解結構的一個部分，在計劃階段，我們需要對項目分解結構進行再次的細分，清楚地定義出項目的各個工作包以及對應的各種資源，同時產生WBS字典。經過這個步驟就可以非常明確的定義出需求，同時可以完成對項目人員的工作具體分配。在這個基礎上做出項目的完整工作計劃。這樣就形成了項目的基線。項目接下來的工作就按照基線按部就班的來完成。
3、項目開發(fā)階段
在項目開發(fā)階段，項目的進度過程中難免出現各種問題，例如項目人員的調動；項目人員沒有按時地完成工作；模塊功能定義時忽略了一些細節(jié)；項目研發(fā)過程中由于一些難以逾越的障礙造成項目時間的延長等等，這些事情都是在所難免的。
由于有了項目分解結構這些問題的控制和解決都變得簡單了許多，我們知道，項目分解結構是基于最小的可交付成果，在項目分解結構定義的過程中都遵循了可定義、可管理、可估計、可估量、獨立、專業(yè)、完整、可適應這么九個原則。在這樣的前提下，通過人員的調整，各種資源的投入，項目經理可以較好的對項目中可能拖后腿的環(huán)節(jié)進行及時的控制，防止開發(fā)時間偏離預計的基線也就是預計的項目分解結構。
同時由于項目分解結構和字典的直觀詳細性，可以很好的為項目組成員對自身工作的認識和把握提供參考，減少了很多溝通上的障礙。
4、項目結束階段
項目分解結構一個項目執(zhí)行過程的基線，他定義了項目的最終可交付物。所以，在項目結束階段，項目分解結構也就自然而然的成為了考核項目成功與否的一個參照，同時也可以作為對項目組成員進行項目考核的一個重要判斷依據。
4 應用軟件分解結構帶來的好處
1、項目團隊效率的提升
通過項目分解結構的制定，項目組成員可以對系統(tǒng)的整個架構有一個比較全面充分的認識，減少在項目過程中的不必要的爭執(zhí)和溝通障礙。同時在項目的執(zhí)行過程中，可以讓項目組的各個成員對自己的工作做到心中有數，便于項目經理對項目的控制。提升編寫代碼的效率。從而在整體的層次上提升整個項目團隊的研發(fā)效率。
2、增進客戶對軟件的認識
通過在調研過程中的多次溝通，客戶與軟件開發(fā)團隊成員形成了一定的默契關系。同時，客戶能夠從軟件人員的描述中了解到軟件開發(fā)的一般性規(guī)律，為后期的工作做好了一定的鋪墊工作。
另外，通過工作分解結構，使得客戶在比較直觀明了的情況下對程序的功能構架有了了解，同時在反復的過程中也引起了客戶自身對軟件功能需求的重新認識和定位，為系統(tǒng)的開發(fā)定出了比較清晰的目標，減少了后期需求變動的可能性。
3、工期預計作用以及比較有說服力的成本概算
通過工作分解結構，我們比較好的定義出了軟件所要實現的具體功能，在這個意義上來說的話，我們同時也就可以從中看出各個模塊所需要的人員以及工期等相關因素。我們在前面已經提到了，這個軟件主要是從打開行業(yè)局面為主要目的，所以我們從人員工資以及相關的工期中就可以比較有說服力的計算出相關成本，然后加上一定的對水系數我們就提出了我們對于客戶的一個相對便宜而對公司來說又可以基本上持平的一個軟件研發(fā)費用。雖然事實上，最終的工期和成本都與計算的有所出入，但是出入不是很大，在25%左右，我們認為這還是一個很有價值的數據，為以后的成本計算提供了比較好的參考值。
4、強有力的質量、成本、時間控制工具
我們知道，項目的三個互相制約的因素是質量、時間和成本，三者之間的平衡是一個項目成功與否的關鍵。項目分解結構是一個項目執(zhí)行的基線，項目經理通過項目各個階段的當前情況與基線進行對比可以發(fā)現項目中出現的偏差，然后根據項目的當前情況對項目中各個環(huán)節(jié)的成本時間進行控制。
5 總結
通過上面的闡述，我們可以看出，項目分解結構這個工具在軟件項目的應用超過了項目管理中定義的范圍，我個人認為可以在需求定義的時候就開始定義。用分解結構對項目中的團隊效率控制，開發(fā)目標定義，過程控制都有非常實際的使用。
從實際工作出發(fā)，一般來說，項目分解結構定義越細致，對完成任務的時間、費用估計也就越準確。但是，任何事物都是對立統(tǒng)一的，在能夠獲得這些好處的同時，過度細分項目分解結構也會造成管理方面的工作量上升加重，因此，在項目的實際實踐過程中，對于這個度的把握就成為了項目經理必須注意的一個問題。
通過對項目管理的系統(tǒng)學習，我個人對于工作分解結構在軟件中的應用有很深的感觸，對于工作分解結構在軟件開發(fā)中的應用有一些個人的看法和見解。
首先我們看一下項目分解結構的定義，工作分解結構是進行范圍規(guī)劃時所使用的重要工具和技術之一，是面向可交付成果的對項目元素的分組，它組織并定義了整個項目范圍，未列入工作分解結構的工作將排除在項目范圍之外。它是項目團隊在項目期間要完成或生產出的最終細目的等級樹，所有這些細目的完成或產出構成了整個項目的工作范圍。
從項目分解結構的定義和我們的學習我們知道，項目分解結構主要針對的是可交付物以及工作細分。同時通過學習我們知道，項目分解結構產生于項目計劃階段過程，在項目執(zhí)行過程的控制中對項目進行考核和控制，最后在項目結束階段為整個項目的考核提供參考。但是，我個人認為，如果從軟件開發(fā)的角度來看的話，項目分解結構這個工具在需求定義期間也能起到很好的應用，也是非常有意義的，我將會再下面的示例中進行闡述。下面結合實際工作案例對項目分解結構在軟件開發(fā)項目中的應用作一個簡單的描述。
2 軟件項目存在的普遍性問題
1、工作范圍界定
首先我們來看一下什么是軟件開發(fā)，說白了，軟件開發(fā)其實就是讓電腦在我們設定好路線上行走的一個實現過程。而人的思維是邏輯的、發(fā)散性的，電腦的思維是單一的、指令性的。就此而言，在電腦軟件的實現過程中需要對人的思維和操作方式進行整理，形成一個符合電腦工作的一個流程，在這中間就涉及到了工作范圍界定，和各種信息的綜合篩選。
2、工作量估算
通過幾個軟件項目的完工，我又這樣的一個感觸，一個軟件項目如果完成時間超過預計時間15%以下就算是一個很不錯完成時間。從我接觸的幾個項目上來看，最長的一個項目甚至延期了將近半年的時間，而最初的預期開發(fā)時間只有三個月。從后來對項目最終評估結果看來，除了由于客戶的一些行政和人事原因引起的延時，很大一部分原因還是因為對項目的工作量把握不夠，在一些關鍵的模塊上產生了很嚴重的超時。
3、需求難以明確
在軟件項目啟動階段，不管是甲方還是乙方，對于軟件的估算都是不足的，項目的需求都有一個從模糊到清除的過程，在項目啟動階段，總是需求最模糊的一個階段，而這個階段卻是項目的一個重要階段，明確地需求直接關系到開發(fā)的成本和報價，怎樣與客戶通過溝通得到較為一致且明確地需求就顯得非常重要。
4、軟件開發(fā)過程控制
在軟件開發(fā)過程中，溝通和交流的直接明了非常重要，通暢準確的溝通可以很好的提高開發(fā)效率和明確的得到最終交付物，但是如果光靠通過口頭交流來說的話容易產生一定的偏差，通過文字來交流話又不是很直觀。難以滿足對項目及時調整、管理、甚至決策的需要。
從以上的各個問題來說，事實上我們需要的是一個統(tǒng)一的、規(guī)范的溝通標準，利用此標準可以是項目的各個參與方進行有效的信息溝通，同時可以確保業(yè)余與項目管理方獲得準確實時的項目信息，以便高校的對整個項目的進度、成本、質量進行統(tǒng)一的計劃和控制。
3 工作分解結構的具體應用
在這里我簡單的描述一下項目，該項目是針對電力行業(yè)的一個MIS項目，在項目的執(zhí)行過程中我們事實上沒有完全按照項目管理的規(guī)范來做，但是，在項目的各個環(huán)節(jié)中我們都很多的用到了工作分解結構這樣的一個工具，在這里我們分階段進行應用闡述。
1、啟動階段
項目在最初定義階段，不管是客戶還是軟件開發(fā)人員，對于系統(tǒng)的了解總是基于大模塊的，而對于模塊的局部結構的了即就比較模糊了，在需求定義和明確的過程中，首先通過軟件人員的頭腦風暴形成一個最初的軟件分解結構，然后以此為基礎與客戶進行溝通就比較直觀明了，便于客戶形成直觀的概念。但是，在這個階段里面，項目里面的很多內容往往是不清晰和不確定的，在這里我們就可以很好的利用項目分解結構這個工具來進行有效的溝通。
我們可以從以下的三個圖來說明這種情況，這幾個圖是在對MIS項目就行需求分析時產生的。首先圖一表示的是通過開發(fā)人員的最初調研形成的組織分解結構圖，然后在此基礎上，通過與客戶的交流發(fā)現MIS結構的模塊分布式是上并不是原想的組織結構。我們了解到，電管站的電費最終也是收入到營銷部，從電費歸屬的意義上來說的話，電管站最終也歸營銷部管理，所以我們對組織結構圖進行了再一次的整合和修改。形成了第二個組織結構圖，在大的模塊的到確認的前提下，對其中的各個模塊進行進一步的細分，對各個模塊以最終可交付物為單位形成各個模塊的細分結構，如圖三，其他模塊省略。這樣就同時對軟件開發(fā)人員和系統(tǒng)使用人員都形成了一個直觀可行的模塊印象。
在這里我們可以看出，在需求定義階段，項目分級結構可以作為一個很好的客戶與調研人員溝通的手段，可以更好的對項目的構建形成一個統(tǒng)一的認識，同時界定出項目的模塊范圍，為以后軟件開發(fā)產生需求變更提供參考依據。
同時由于組織分解結構是以最終交付物為單位的，以一人兩周的開發(fā)周期作模塊分解的依據。所以，當最終的項目分級結構形成之后，可以依據項目分解結構計算出項目所需要的工期以及開發(fā)人員資源，并以此為基準計算出項目的可估算成本。
2、計劃階段
雖然在項目啟動中，我們已經生成了一個簡單的項目分解結構圖，但是那其實還是遠遠不夠的，項目分解結構圖紙是項目分解結構的一個部分，在計劃階段，我們需要對項目分解結構進行再次的細分，清楚地定義出項目的各個工作包以及對應的各種資源，同時產生WBS字典。經過這個步驟就可以非常明確的定義出需求，同時可以完成對項目人員的工作具體分配。在這個基礎上做出項目的完整工作計劃。這樣就形成了項目的基線。項目接下來的工作就按照基線按部就班的來完成。
3、項目開發(fā)階段
在項目開發(fā)階段，項目的進度過程中難免出現各種問題，例如項目人員的調動；項目人員沒有按時地完成工作；模塊功能定義時忽略了一些細節(jié)；項目研發(fā)過程中由于一些難以逾越的障礙造成項目時間的延長等等，這些事情都是在所難免的。
由于有了項目分解結構這些問題的控制和解決都變得簡單了許多，我們知道，項目分解結構是基于最小的可交付成果，在項目分解結構定義的過程中都遵循了可定義、可管理、可估計、可估量、獨立、專業(yè)、完整、可適應這么九個原則。在這樣的前提下，通過人員的調整，各種資源的投入，項目經理可以較好的對項目中可能拖后腿的環(huán)節(jié)進行及時的控制，防止開發(fā)時間偏離預計的基線也就是預計的項目分解結構。
同時由于項目分解結構和字典的直觀詳細性，可以很好的為項目組成員對自身工作的認識和把握提供參考，減少了很多溝通上的障礙。
4、項目結束階段
項目分解結構一個項目執(zhí)行過程的基線，他定義了項目的最終可交付物。所以，在項目結束階段，項目分解結構也就自然而然的成為了考核項目成功與否的一個參照，同時也可以作為對項目組成員進行項目考核的一個重要判斷依據。
4 應用軟件分解結構帶來的好處
1、項目團隊效率的提升
通過項目分解結構的制定，項目組成員可以對系統(tǒng)的整個架構有一個比較全面充分的認識，減少在項目過程中的不必要的爭執(zhí)和溝通障礙。同時在項目的執(zhí)行過程中，可以讓項目組的各個成員對自己的工作做到心中有數，便于項目經理對項目的控制。提升編寫代碼的效率。從而在整體的層次上提升整個項目團隊的研發(fā)效率。
2、增進客戶對軟件的認識
通過在調研過程中的多次溝通，客戶與軟件開發(fā)團隊成員形成了一定的默契關系。同時，客戶能夠從軟件人員的描述中了解到軟件開發(fā)的一般性規(guī)律，為后期的工作做好了一定的鋪墊工作。
另外，通過工作分解結構，使得客戶在比較直觀明了的情況下對程序的功能構架有了了解，同時在反復的過程中也引起了客戶自身對軟件功能需求的重新認識和定位，為系統(tǒng)的開發(fā)定出了比較清晰的目標，減少了后期需求變動的可能性。
3、工期預計作用以及比較有說服力的成本概算
通過工作分解結構，我們比較好的定義出了軟件所要實現的具體功能，在這個意義上來說的話，我們同時也就可以從中看出各個模塊所需要的人員以及工期等相關因素。我們在前面已經提到了，這個軟件主要是從打開行業(yè)局面為主要目的，所以我們從人員工資以及相關的工期中就可以比較有說服力的計算出相關成本，然后加上一定的對水系數我們就提出了我們對于客戶的一個相對便宜而對公司來說又可以基本上持平的一個軟件研發(fā)費用。雖然事實上，最終的工期和成本都與計算的有所出入，但是出入不是很大，在25%左右，我們認為這還是一個很有價值的數據，為以后的成本計算提供了比較好的參考值。
4、強有力的質量、成本、時間控制工具
我們知道，項目的三個互相制約的因素是質量、時間和成本，三者之間的平衡是一個項目成功與否的關鍵。項目分解結構是一個項目執(zhí)行的基線，項目經理通過項目各個階段的當前情況與基線進行對比可以發(fā)現項目中出現的偏差，然后根據項目的當前情況對項目中各個環(huán)節(jié)的成本時間進行控制。
5 總結
通過上面的闡述，我們可以看出，項目分解結構這個工具在軟件項目的應用超過了項目管理中定義的范圍，我個人認為可以在需求定義的時候就開始定義。用分解結構對項目中的團隊效率控制，開發(fā)目標定義，過程控制都有非常實際的使用。
從實際工作出發(fā)，一般來說，項目分解結構定義越細致，對完成任務的時間、費用估計也就越準確。但是，任何事物都是對立統(tǒng)一的，在能夠獲得這些好處的同時，過度細分項目分解結構也會造成管理方面的工作量上升加重，因此，在項目的實際實踐過程中，對于這個度的把握就成為了項目經理必須注意的一個問題。