WBS的概念分解策略、作用、用途、分解原則、分解方法...
阿新 • • 發佈：2019-02-17
1.引言
漸進明細是專案的特點，但這並不意味著不需要計劃。沒有計劃或者是隨意的不負責任的計
劃的專案是一種無法控制的專案。在軟體高技術行業，日新月異是主要特點，因此計劃的制
定需要在一定條件的限制和假設之下采用漸近明細的方式進行不斷完善。例如對於較為大型
的軟體開發專案的工作分解結構 WBS可採用二次WBS方法，即根據總體階段劃分的總體
WBS和專門針對系統設計或編碼階段的二次 WBS。這其中部分的原因是需求的顆粒度在一
開始往往是比較粗的，因此根據功能點對於整體專案規模的估計誤差範圍也是比較大的。更
為重要的原因是，需求往往不是編碼工作分解的準確依據，因為一個需求的功能點可能對應
多個程式碼模組，而多個需求的功能點也可能只對應一個或少數程式碼模組，同時還有軟體複用
等因素要考慮，因此只有在需求分析完成以後才能準確地得到系統設計或編碼階段的二次
WBS，根據程式碼模組的合理劃分而得出的二次WBS才能在系統設計、編碼階段乃至測試階
段起到有效把握和控制進度的作用。
2.基本概念
WorkBreakdownStructure （WBS）工作分解結構：對應當由專案團隊執行以便實現專案目標，
並創造必要的可交付成果工作，按可交付成果所做的層次分解。WBS將專案的整個範圍組
織在一起並加以明確。每向下分解一個層次，就意味著專案工作的定義深入了一步。WBS
最終分解為工作細目。 WBS的層次結構以可交付成果為物件，包括內部和外部可交付成果。
（2004年版PMBOK 指南）
WorkPackage（工作細目，也翻譯為工作任務包），工作細目包括為完成該工作細目可交付
成果或專案工作組成部分而必需的計劃活動和進度里程碑。（2004 年版 PMBOK 指南） ControlAcｃｏｕｎｔ（控制賬目，CA），是綜合範圍、預算、實際費用和進度，並對績效
進行測量的管理控制點，控制賬目設定在工作分解結構（在選定水平上的具體組成部分）的
事先選定的管理點上。每一個控制賬目都可以包含一個或多個的工作細目，但是每一個工作
細目只可以在同一個控制賬目相聯絡。（2004 年版PMBOK 指南）
3.對 WBS的理解
從以上解釋，我們得出如下結論，WBS是將專案加以定義，明確專案工作任務的。由此可
見，WBS在專案管理的重要地位，所以“沒有WBS，就沒有專案管理”。
對於 WBS定義的理解，我個人認為應在以下兩方面重點加以理解：
第一方面，就是WBS的單元，即 WBS層次結構的物件，它是以“Deliverables （可交付成果） ”
為分解導向，而不是以“ScheduleActivity（計劃活動）”為分解導向。
WBS的最底層次為WorkPackage（工作細目），工作細目包括為完成該工作細目可交付成
果或專案工作組成部分而必需的計劃活動和進度里程碑。
為什麼WBS的最底層次不是 ScheduleActivity（計劃活動）而是WorkPackage（工作細目）
呢？
首先 WBS是作為專案範圍管理的工具、技術，專案範圍管理關注點是專案的組成部分，它
面向的是可交付成果，而不是過程。
其次 WBS定義的是專案及其組成部分，是 ScheduleActivity（計劃活動）定義的依據，而不
是去定義 ScheduleActivity（計劃活動）；
第三 ScheduleActivity（計劃活動）是專案進度表的單個組成部分，不是WBS 的組成部分。
對於這一點，很多人理解上可能有困難。因為，習慣說法是活動是由各項具體工作構成的，
而上面的定義我們從字面上看的習慣說法與 PMBOK的定義正好相反，但是從本質上去理
解兩者應該是相同的，只是說法不同。因為在專案管理尚未引進中國以前，我們把活動等同
於專案。
第二方面，就是WBS的結構，WBS的結構包含了科學的邏輯結構，而不是單個的、離
的、在時間順序上不連續的成果的描述結構。
WBS的結構是由邏輯推演而成的，通過層層的包含關係，非常嚴謹。結構化是WBS的
大重要特性，WBS的邏輯結構錯誤會直接導致專案實施過程發生錯誤，嚴重的會帶來
的失敗。
“做正確的事，正確地做事”是我們從事專案管理的一句格言，WBS首先解決的就是“做
的事”問題，只有明確了“做正確的事”，“正確地做事”才有基礎，所以我們說 WBS是現
目管理的重要基石。
4.WBS的主要用途
WBS是一個描述思路的規劃和設計工具。它幫助專案經理和專案團隊確定和有效地管
目的工作。 WBS是一個清晰地表示各專案工作之間的相互聯絡的結構設計工具。
WBS是一個展現專案全貌，詳細說明為完成專案所必須完成的各項工作的計劃工具。
WBS定義了里程碑事件，可以向高階管理層和客戶報告專案完成情況，作為專案狀況的報
告工具。
5.WBS的作用
防止遺漏專案的可交付成果。
幫助專案經理關注專案目標和澄清職責。
建立視覺化的專案可交付成果，以便估算工作量和分配工作。
幫助改進時間、成本和資源估計的準確度。
幫助專案團隊的建立和獲得專案人員的承諾。
為績效測量和專案控制定義一個基準。
輔助溝通清晰的工作責任。
為其他專案計劃的制定建立框架。
幫助分析專案的最初風險。
6.WBS的主要分解原則
一個單位工作任務只能在WBS中出現一次。
一個 WBS項的工作內容是其對應下級各項工作之和。
WBS中的每一項都只有一個人負責，即使這項工作要多人來做，也是如此。
WBS必須與工作任務的實際執行過程一致。
WBS應服務於專案資源，專案成員必須參與WBS的制定過程，以確保一致性和全員參與。
每項 WBS都必須歸檔，以確保準確理解專案包括和不包括的工作範圍。
在根據範圍說明書對專案的工作內容進行適當控制的同時，WBS必須具有一定的靈活性，
以適應無法避免的變更需要。
工作包的定義應考慮80小時法則(80-HourRule)或兩週法則(TwoWeekRule)，即任何工作包
的完成時間應當不超過 80小時。 WBS一般不超過 5層，如超過即外包。
7.WBS的表示方式
WBS可以由樹形的層次結構圖或者行首縮排的表格表示。
在實際應用中，表格形式的WBS應用比較普遍，特別是在專案管理軟體中。
8.WBS分解方法
類比法 類比法就是以一個類似專案的WBS為基礎，制定本專案的工作分解結構。例如，ABC飛機
製造公司，曾設計製造多種型別的大型客機，當他們計劃投入設計生產某種新型戰鬥機時，
就可以使用以往製造大型客機而設計的子系統。以從前的子系統為基礎，開始新專案的WBS
的編制。比如，該WBS的第一層中有飛機機身頂，該項又包括了飛機前身、飛機中部、飛
機後身和機翼等第二層的多個子項。這種一般性的產品導向的WBS就成為新飛機專案的範
圍定義和新型戰鬥機成本估算等工作的起點。即參考類似專案的WBS建立新專案的WBS。
自上而下法
自上而下法常常被視為構建WBS的常規方法，即從專案最大的單位開始，逐步將它們分解
成下一級的多個子項。這個過程就是要不斷增加級數，細化工作任務。這種方法對專案經理
來說，可以說是最佳方法，因為他們具備廣泛的技術知識和對專案的整體視角。
自下而上法
自下而上法，是要讓專案團隊成員從一開始就儘可能的確定專案有關的各項具體任務，然後
將各項具體任務進行整合，並歸總到一個整體活動或WBS的上一級內容當中去。仍以 ABC
飛機制造公司設計製造新型戰鬥機為例，用這種方法，則不是開始就考察WBS制定的指導
方針或是參考其他類似專案的WBS，而是儘可能詳細的列出那些專案團隊成員認為完成項
目需要做的任務。在列出詳細的任務清單後，就開始對所有工作進行分類，以便於將這些詳
細的工作歸入上一級的大項中。比如說，專案團隊某小組中的商業分析人員會知道他們必須
確定使用者對專案的要求以及該專案的內容要求；工程師們也會知道他們必須確定對系統的要
求和對發動機的要求。於是，該小組可能會將這四項任務都歸入到戰鬥機製造專案的概念設
計這個總項中去。自下而上法一般都很費時，但這種方法對於WBS的建立來說，效果特別
好。專案經理經常對那些全新系統或方法的專案採用這種方法，或者用該法來促進全員參與
或專案團隊的協作。
使用指導方針
如果存在WBS的指導方針，那就必須遵循這些方針。許多 DOD（國防部）專案都要求承
包商按照國防部提供的 WBS模板提交他們的專案建議書。這些建議書必須包括針對 WBS
中每一項任務的成本估算，既有明細估算項，也有歸總估算項。專案整體的成本估算必須是
通過歸總WBS底層各項任務成本而得到的。當國防部有關人員對成本計劃進行評審時，他
們必須將承包商的成本估算與國防部的成本估算進行對比，如果某項WBS任務成本有很大
的出入，那一般就意味著對要做的工作任務還沒搞清楚。
9.確定 WBS是否已分解到足夠詳細的一層
是否需要改善 WBS工作包的成本估算和時間進度估算的精確度？
WBS工作包的負責人是否超過一人？
WBS的工作包是否包含了多個交付成果或實施過程？
是否需要分別定義工作過程的成本或WBS內的交付成果？
是否需要更精確地瞭解 WBS內的工作過程的時間進度？
不同 WBS工作包內的交付成果是否相互依賴？ WBS內過程中的工作實施是否有明顯的時間間隔？
某一要素對資源的需求一段時間內會變化嗎？
衡量 WBS某一工作包進度的明確的目標標準存在嗎？
這些驗收標準在WBS的工作包全部完成前還適用嗎？
WBS中的一些工作包是否存在一些風險需要特別的注意？
WBS工作包中的某一部分是否可作為單獨的單元來做時間進度計劃？
專案經理，專案團隊，以及其他利害關係者包括客戶對 WBS的工作包有清晰和完全的理解
嗎？
是否有利害關係者有興趣WBS某一工作包的現狀和業績？
漸進明細是專案的特點，但這並不意味著不需要計劃。沒有計劃或者是隨意的不負責任的計
劃的專案是一種無法控制的專案。在軟體高技術行業，日新月異是主要特點，因此計劃的制
定需要在一定條件的限制和假設之下采用漸近明細的方式進行不斷完善。例如對於較為大型
的軟體開發專案的工作分解結構 WBS可採用二次WBS方法，即根據總體階段劃分的總體
WBS和專門針對系統設計或編碼階段的二次 WBS。這其中部分的原因是需求的顆粒度在一
開始往往是比較粗的，因此根據功能點對於整體專案規模的估計誤差範圍也是比較大的。更
為重要的原因是，需求往往不是編碼工作分解的準確依據，因為一個需求的功能點可能對應
多個程式碼模組，而多個需求的功能點也可能只對應一個或少數程式碼模組，同時還有軟體複用
等因素要考慮，因此只有在需求分析完成以後才能準確地得到系統設計或編碼階段的二次
WBS，根據程式碼模組的合理劃分而得出的二次WBS才能在系統設計、編碼階段乃至測試階
段起到有效把握和控制進度的作用。
2.基本概念
WorkBreakdownStructure （WBS）工作分解結構：對應當由專案團隊執行以便實現專案目標，
並創造必要的可交付成果工作，按可交付成果所做的層次分解。WBS將專案的整個範圍組
織在一起並加以明確。每向下分解一個層次，就意味著專案工作的定義深入了一步。WBS
最終分解為工作細目。 WBS的層次結構以可交付成果為物件，包括內部和外部可交付成果。
（2004年版PMBOK 指南）
WorkPackage（工作細目，也翻譯為工作任務包），工作細目包括為完成該工作細目可交付
成果或專案工作組成部分而必需的計劃活動和進度里程碑。（2004 年版 PMBOK 指南） ControlAcｃｏｕｎｔ（控制賬目，CA），是綜合範圍、預算、實際費用和進度，並對績效
進行測量的管理控制點，控制賬目設定在工作分解結構（在選定水平上的具體組成部分）的
事先選定的管理點上。每一個控制賬目都可以包含一個或多個的工作細目，但是每一個工作
細目只可以在同一個控制賬目相聯絡。（2004 年版PMBOK 指南）
3.對 WBS的理解
從以上解釋，我們得出如下結論，WBS是將專案加以定義，明確專案工作任務的。由此可
見，WBS在專案管理的重要地位，所以“沒有WBS，就沒有專案管理”。
對於 WBS定義的理解，我個人認為應在以下兩方面重點加以理解：
第一方面，就是WBS的單元，即 WBS層次結構的物件，它是以“Deliverables （可交付成果） ”
為分解導向，而不是以“ScheduleActivity（計劃活動）”為分解導向。
WBS的最底層次為WorkPackage（工作細目），工作細目包括為完成該工作細目可交付成
果或專案工作組成部分而必需的計劃活動和進度里程碑。
為什麼WBS的最底層次不是 ScheduleActivity（計劃活動）而是WorkPackage（工作細目）
呢？
首先 WBS是作為專案範圍管理的工具、技術，專案範圍管理關注點是專案的組成部分，它
面向的是可交付成果，而不是過程。
其次 WBS定義的是專案及其組成部分，是 ScheduleActivity（計劃活動）定義的依據，而不
是去定義 ScheduleActivity（計劃活動）；
第三 ScheduleActivity（計劃活動）是專案進度表的單個組成部分，不是WBS 的組成部分。
對於這一點，很多人理解上可能有困難。因為，習慣說法是活動是由各項具體工作構成的，
而上面的定義我們從字面上看的習慣說法與 PMBOK的定義正好相反，但是從本質上去理
解兩者應該是相同的，只是說法不同。因為在專案管理尚未引進中國以前，我們把活動等同
於專案。
第二方面，就是WBS的結構，WBS的結構包含了科學的邏輯結構，而不是單個的、離
的、在時間順序上不連續的成果的描述結構。
WBS的結構是由邏輯推演而成的，通過層層的包含關係，非常嚴謹。結構化是WBS的
大重要特性，WBS的邏輯結構錯誤會直接導致專案實施過程發生錯誤，嚴重的會帶來
的失敗。
“做正確的事，正確地做事”是我們從事專案管理的一句格言，WBS首先解決的就是“做
的事”問題，只有明確了“做正確的事”，“正確地做事”才有基礎，所以我們說 WBS是現
目管理的重要基石。
4.WBS的主要用途
WBS是一個描述思路的規劃和設計工具。它幫助專案經理和專案團隊確定和有效地管
目的工作。 WBS是一個清晰地表示各專案工作之間的相互聯絡的結構設計工具。
WBS是一個展現專案全貌，詳細說明為完成專案所必須完成的各項工作的計劃工具。
WBS定義了里程碑事件，可以向高階管理層和客戶報告專案完成情況，作為專案狀況的報
告工具。
5.WBS的作用
防止遺漏專案的可交付成果。
幫助專案經理關注專案目標和澄清職責。
建立視覺化的專案可交付成果，以便估算工作量和分配工作。
幫助改進時間、成本和資源估計的準確度。
幫助專案團隊的建立和獲得專案人員的承諾。
為績效測量和專案控制定義一個基準。
輔助溝通清晰的工作責任。
為其他專案計劃的制定建立框架。
幫助分析專案的最初風險。
6.WBS的主要分解原則
一個單位工作任務只能在WBS中出現一次。
一個 WBS項的工作內容是其對應下級各項工作之和。
WBS中的每一項都只有一個人負責，即使這項工作要多人來做，也是如此。
WBS必須與工作任務的實際執行過程一致。
WBS應服務於專案資源，專案成員必須參與WBS的制定過程，以確保一致性和全員參與。
每項 WBS都必須歸檔，以確保準確理解專案包括和不包括的工作範圍。
在根據範圍說明書對專案的工作內容進行適當控制的同時，WBS必須具有一定的靈活性，
以適應無法避免的變更需要。
工作包的定義應考慮80小時法則(80-HourRule)或兩週法則(TwoWeekRule)，即任何工作包
的完成時間應當不超過 80小時。 WBS一般不超過 5層，如超過即外包。
7.WBS的表示方式
WBS可以由樹形的層次結構圖或者行首縮排的表格表示。
在實際應用中，表格形式的WBS應用比較普遍，特別是在專案管理軟體中。
8.WBS分解方法
類比法 類比法就是以一個類似專案的WBS為基礎，制定本專案的工作分解結構。例如，ABC飛機
製造公司，曾設計製造多種型別的大型客機，當他們計劃投入設計生產某種新型戰鬥機時，
就可以使用以往製造大型客機而設計的子系統。以從前的子系統為基礎，開始新專案的WBS
的編制。比如，該WBS的第一層中有飛機機身頂，該項又包括了飛機前身、飛機中部、飛
機後身和機翼等第二層的多個子項。這種一般性的產品導向的WBS就成為新飛機專案的範
圍定義和新型戰鬥機成本估算等工作的起點。即參考類似專案的WBS建立新專案的WBS。
自上而下法
自上而下法常常被視為構建WBS的常規方法，即從專案最大的單位開始，逐步將它們分解
成下一級的多個子項。這個過程就是要不斷增加級數，細化工作任務。這種方法對專案經理
來說，可以說是最佳方法，因為他們具備廣泛的技術知識和對專案的整體視角。
自下而上法
自下而上法，是要讓專案團隊成員從一開始就儘可能的確定專案有關的各項具體任務，然後
將各項具體任務進行整合，並歸總到一個整體活動或WBS的上一級內容當中去。仍以 ABC
飛機制造公司設計製造新型戰鬥機為例，用這種方法，則不是開始就考察WBS制定的指導
方針或是參考其他類似專案的WBS，而是儘可能詳細的列出那些專案團隊成員認為完成項
目需要做的任務。在列出詳細的任務清單後，就開始對所有工作進行分類，以便於將這些詳
細的工作歸入上一級的大項中。比如說，專案團隊某小組中的商業分析人員會知道他們必須
確定使用者對專案的要求以及該專案的內容要求；工程師們也會知道他們必須確定對系統的要
求和對發動機的要求。於是，該小組可能會將這四項任務都歸入到戰鬥機製造專案的概念設
計這個總項中去。自下而上法一般都很費時，但這種方法對於WBS的建立來說，效果特別
好。專案經理經常對那些全新系統或方法的專案採用這種方法，或者用該法來促進全員參與
或專案團隊的協作。
使用指導方針
如果存在WBS的指導方針，那就必須遵循這些方針。許多 DOD（國防部）專案都要求承
包商按照國防部提供的 WBS模板提交他們的專案建議書。這些建議書必須包括針對 WBS
中每一項任務的成本估算，既有明細估算項，也有歸總估算項。專案整體的成本估算必須是
通過歸總WBS底層各項任務成本而得到的。當國防部有關人員對成本計劃進行評審時，他
們必須將承包商的成本估算與國防部的成本估算進行對比，如果某項WBS任務成本有很大
的出入，那一般就意味著對要做的工作任務還沒搞清楚。
9.確定 WBS是否已分解到足夠詳細的一層
是否需要改善 WBS工作包的成本估算和時間進度估算的精確度？
WBS工作包的負責人是否超過一人？
WBS的工作包是否包含了多個交付成果或實施過程？
是否需要分別定義工作過程的成本或WBS內的交付成果？
是否需要更精確地瞭解 WBS內的工作過程的時間進度？
不同 WBS工作包內的交付成果是否相互依賴？ WBS內過程中的工作實施是否有明顯的時間間隔？
某一要素對資源的需求一段時間內會變化嗎？
衡量 WBS某一工作包進度的明確的目標標準存在嗎？
這些驗收標準在WBS的工作包全部完成前還適用嗎？
WBS中的一些工作包是否存在一些風險需要特別的注意？
WBS工作包中的某一部分是否可作為單獨的單元來做時間進度計劃？
專案經理，專案團隊，以及其他利害關係者包括客戶對 WBS的工作包有清晰和完全的理解
嗎？
是否有利害關係者有興趣WBS某一工作包的現狀和業績？