如何做好WBS（Work Breakdown Structure）？

01-21

由技術崗逐步轉到管理崗，現在主要是做項目管理，我們知道，項目管理中有一項比較重要，就是WBS，即將項目工作進行分解。在分解的過程中，需要注意層次性，一是確保全面性，即覆蓋到該項目涉及的所有方面的工作，二是便於後續細化。
後續細化：這裡的細化並非一直細化下去，而是到達一定的粒度，比如細化到80小時的工作量即可。層次化的細分很實用，比如用excel做checklist時，如果是按照層級劃分，那麼後續可以方便增加新的任務項，而不影響整體的結構，也防止任務項重複。大大減輕了checklist維護的工作量，也更清晰。
還有其他要注意的嗎？可以讓WBS做的更實用。

WBS是一個不錯的工具，適用於順序型（或者說瀑布式的）項目管理，不外乎包含項目，工作包，任務等幾個層級，指定到人，指定時間。展開來說如下。

分解原則

1、將主體目標逐步細化分解，最底層的日常活動可直接分派到個人去完成；

2、每個任務原則上要求分解到不能再細分為止；

3、日常活動要對應到人、時間和資金投入。

二、任務分解的方法　

1、採用樹狀結構進行分解；

2、以團隊為中心，自上而下與自下而上的充分溝通，一對一個別交流與討論，分解單項工作。

三、任務分解的標準　

1、分解後的活動結構清晰，從樹根到樹葉，一目了然，盡量避免盤根錯節；

2、邏輯上形成一個大的活動，集成了所有的關鍵因素包含臨時的里程碑和監控點，所有活動全部定義清楚，要細化到人、時間和資金投入。

在我們日常管理項目時，要學會分解任務，只有將任務分解得足夠細，足夠明了，才能統籌全局，安排人力和財力資源，把握項目的進度。

創建要求

創建WBS時需要滿足以下幾點基本要求：

1、某項任務應該在WBS中的一個地方且只應該在WBS中的一個地方出現。

2、WBS中某項任務的內容是其下所有WBS項的總和。

3、一個WBS項只能由一個人負責，即使許多人都可能在其上工作，也只能由一個人負責，其他人只能是參與者。

4、WBS必須與實際工作中的執行方式一致。

5、應讓項目團隊成員積极參与創建WBS，以確保WBS的一致性。

6、每個WBS項都必須文檔化，以確保準確理解已包括和未包括的工作範圍。

7、WBS必須在根據範圍說明書正常地維護項目工作內容的同時，也能適應無法避免的變更。

詳情參見：

工作分解結構_百度百科

你講的情況，必敗無疑。

WBS的實踐，最大的問題在於，過早地鎖定需求細節、架構設計方案等，從而才能夠拆分出比較細的任務安排，但如今的軟體系統越來越複雜，基本無法確保一開始的考慮和想法是準確的，必然涉及不停的修改和完善，那麼就會涉及到要更新一開始的WBS內容，但這個就變了一個耗費極高的事情。

強烈推薦你了解和學習敏捷的方法，以及我在這個答案里推薦的書籍：IT項目管理有什麼好的書籍推薦？ - 徐毅的回答

關鍵在於，你針對多大的東西（需求）進行WBS拆解。敏捷方法下，是先明確需求，但是不做詳細的任務拆解，只有等到某個Sprint（約等於迭代）要開始了，做計劃的時候，才把少量（例如100個需求做10個Sprint，那麼這個少量大概就是一個Sprint做10個需求）需求拿出來，進行拆解，而且這個拆解過程是敏捷團隊（敏捷團隊是跨職能特性團隊，意味著團隊整體而言是具備多個模塊能力和開發測試等多個職能的能力的）來完成的，而不是由某個項目經理一個人獨立完成的。

1．簡化圖帶你了解WBS結構

Work Breakdown Structure（WBS）是將整個項目一層一層細分成更小部分的過程，它便於企業明確目標、了解工作、控制進度，確保項目的勝利完成。下面我們通過一個項目工作簡化圖來講解如何做好WBS。

圖中WBS中分解後的工作部分代表了獨立的工作任務，可分配給項目團隊，外部的承包商或項目夥伴。這裡我們需求強調的重點是：WBS是將整個項目劃分為可分配的「工作包」，項目往往圍繞著WBS最底層的工作包來進行計劃、組織和控制。也就是說這些分類更細的底層工作，往往成為項目成敗的關鍵。

2.舉個例子（蓋房子）

我們以蓋房子為例，解釋一下工作包的劃分和底層工作包的重要性：

3.舉一反三學會構建自己的WBS

剛才在蓋房子例子中，我們反覆提到底層工作包的重要性，這裡總結幾點意見，幫助你建立、完成自己的底層工作包：

首先，工作包可以分配給另一位項目經理進行計劃和執行；

其次，工作包可以通過子項目的方式進一步分解為子項目的WBS；也可以工作包可以由惟一的一個部門或承包商負責，也就是我們常說的「分包」、「委託」。　　

最後，工作包的定義應考慮80小時法則(80-HourRule)或兩周法則(Two Week Rule)，即任何工作包的完成時間應當不超過80小時。在每個80小時或少於80小時結束時，只報告該工作包是否完成。通過這種定期檢查的方法，可以控制項目的變化。

希望上述三方面內容能夠由淺入深的幫你了解WBS，做好WBS。

不結合系統工程的項目管理註定會挖坑無數的。

做WBS不難，難就難在真的按上面的時間來執行～項目管理的規划過程需要不斷地更新，不過總是更新就相當於沒有計劃，還是控關鍵成果吧。

WBS作為項目計劃與控制的基礎，層次清晰、粗細合理不僅方便制定出合理的進度計劃、資源計劃、成本計劃等，更有利於責任人的落實和計劃的跟蹤。

同時，「什麼樣的WBS才是好WBS」、「到底分到多細」也是項目經理和計劃工程師編製WBS時常常困擾的問題。我來談談對WBS編製的原則和粗細的考慮因素的理解。

WBS編製的主要原則

1.100%原則

下層級所有的WBS項之和必須完整的涵蓋上層級WBS項，即不能遺漏，也不能多餘。

2.同層級同思路

同一WBS項下的分解應該是一個思路，如基於交付物、基於流程、基於專業。只要沒有遵循此原則，必然導致重複項的產生。

3.每一個下層WBS項只能從屬於一個上層的WBS項

4.WBS項之間應能區分不同的責任者和不同工作內容

各項應有較高的整體性和獨立性，各項之間的工作責任、界面應儘可能小且明確。

5.合理的粗細程度

最底層WBS項應該便於資源和費用的載入，且具有可比性、可管理、可定量檢查。需要合理的粗細程度既避免太粗造成「黑箱子」眾多，項目控制乏力；也避免太細造成管理成本太高。

6.必要的假設

WBS編製屬於計劃的一部分，根據項目的初步思考進行編製。有的項目經理、專項負責人一提到WBS就皺起眉頭，一會想這樣做一會想那樣做，一會又怕過程中出現什麼問題，WBS總是定不下來，最主要的原因就是沒有理解「WBS也是假設」。

7.WBS在項目過程中可以根據實際情況調整

WBS是可以調整的，甚至有些時候必須調整。工作內容的增加減少、工藝工法的更改等都必須調整WBS。有些項目計劃工程師如果不了解這點就只能拿著計劃愁容滿面，不知道如何檢查，如何更新調整計劃。

WBS粗細的主要考慮因素

1.使用/服務的層級

PMO（即項目管理部門）層級的WBS，可只用分解到項目大階段（里程碑）；項目經理層級的WBS需細化到項目產品交付物；各分項主管層級的WBS需細化到本分項詳細的交付物；各作業人員需細化到完成某個具體交付物的流程。項目計劃工程師可根據進度管理需要，對WBS有不同的粗細要求。

2.項目彙報/檢查周期

如項目彙報/檢查周期為每周，則最底層WBS項盡量工期小於一周，以便於每次進行彙報、檢查時能準確反饋進展情況。如果一個項目檢查周期是周，但是分解的WBS大量的是以月為最小顆粒度，那麼就會造成每次檢查的時候都是「估計進度」、無法統計具體的工作完成量，一旦相關責任人虛假瞞報又沒能提前識別，對進度將會產生嚴重影響。

3.固定工期和問題發生可能性

某項WBS項根據經驗，工期較為固定，且問題可能性小，則這項WBS可以較粗；反之，工期不固定或問題可能性很大，則需要進行較細分解，以便於進度跟蹤控制。

4.關鍵線路和非關鍵線路

某項WBS項在進度計劃中處於非關鍵路徑，且機動時間較多，則分解可以較粗；反之，處於關鍵路徑或機動時間較少，則需要較細分解，以利於過程中對這項WBS項的跟蹤控制。

5.項目工期的寬裕程度

項目工期較為寬裕，則項目底層WBS項可較粗，如項目工期緊張，則必須進行精細化管理，底層分解出較細的WBS項。

6.具體責任人的管控能力有關

某項WBS項的負責人，經驗較豐富，能較好的如期完成工作，則可以較粗。對於一些「新人」要特別注意，其負責的工作可能細化，一方面有利於其自己掌握工作內容和節奏，另一方面也防止其「亂拍胸脯瞎保證」對項目造成影響。

7.前後工作的搭接關係

雖然某個WBS項的下一層按照同一個思路分解即可，但也必須考慮和後面工作的搭接關係。如一個裝備製造項目中研發設計中只有「齒輪設計」一項，但後續的製造是分批次進行的，甚至不同的負責人進行加工，則需據此細化「齒輪設計」為齒輪A設計、齒輪B設計……