WBS(Work Breakdown Structure)是專案規劃的重要元素，我們在進行專案規劃的時候，常常犯的一個錯誤，就是從直接選擇一個專案發展的策略(或模型)(例如，Waterfalls、Incremental、Evolutionary，或者Spiral等)，再設法套到專案裡，然後從這個模型所規劃的產出去訂里程碑。這種做法，以筆者的經驗來說是不可行的。因為，不論是多大的專案，在產品上、技術上的決策，事實上遠比決定專案發展策略來得更為複雜。因此，我們在專案規劃上若是以過程為著眼，就算是採用的是Grand Design Strategy(亦即「瀑布式」發展過程)，也將無法做完專案，因為你會陷在過程階段劃分的泥沼中，不知道專案的下一步該怎麼走。而就在這當中，耗盡了時間與預算。

　　WBS是產品導向的，透過樹狀結構的方法，將專案產品分割，直到可以管理的最小單位(但也不能太細，否則會使整合與管理的成本升高)。接著我們就可以根據這些細分出來的工作項目元素，去估算工作時間、成本、所需資源、技術、相關風險。由於這些工作產品的項目是可以管理的，因此，我們也就可以從WBS轉出產品的組態項目(CI)。另外，我們也可以經由WBS的階層關係，了解各工作產品間的相互關係、工作次序等等。由此，我們就可以訂出整個專案工作網狀圖，並以每個工作的工時，訂出專案的要徑(Critical Path)。另外，每個工作產品都是以由上而下的設計、由下而上整合與測試的瀑布式開發方式產出。由於每個產品已經明確地劃分出來，因此，可以很明確地指派出去給功能單位，或開發單位負責實作。而最重要的是，專案的成本就可以精確地計算出來。

　　產品在經過WBS劃分之後，我們就可以預判出專案的可能風險。以績效要求為例，我們要求系統的整體績效每分鐘應能處理1000筆資料，如果沒有以WBS來看，我們實在看不出來達到每分鐘處理1000筆資料的風險何在，但如果我們從WBS來看，我們會發覺，影響每分鐘1000筆資料之績效達成的風險，可能會有網路的問題、硬體的問題、資料庫的問題、系統架構的問題、程式設計的問題、甚至於使用者操作習慣的問題等等……。而種種這些項目都將會是專案管理的重要議題，相對於管理規劃、技術規劃、財務規劃、人力資源規劃、風險管理規劃等等納入專案管理計畫書的相對段落中。

----------------
引文:

秘書長你好：

一般 WBS 的架構都是以軟體生命週期展開，因軟體生命週期有其發展順序，故可用於時程的展開、工作安排、成本估算等等....。

若依您的做法，是以專案產品為導向，不曉得要怎樣進行。例如：專案產品是人事系統，將其功能架構展成 WBS 模式，因 WBS 工作項目元素，彼此並無關連，故無法安排工作順序等等。

以上問題尚祈 秘書長指點迷津。

　　從軟體發展專案來看，初步的WBS是從功能架構轉過來的(從產品的生命週期來看，是系統需求分析、系統架構設計等階段的產出)，對於獲取者(acquirer)而言，初步的WBS又會轉成SOW（工作條款），通常廠商(supplier)拿到的案子應該是已經有初步的WBS。如果獲取者無法發展初步的WBS，那麼，他們就該找另一個supplier來幫忙做這件事(找出系統的需求)。

　　當然，廠商拿到初步的WBS還是要再經過一些確認及再發展的工作，將初步的WBS再向下展開至可以管理及指派給各產品組件開發小組作業的規模。這些被細分成為一個個Work Package的組件或工作項目，在執行時，就可以用生命週期的觀點(劃分成軟體需求分析、軟體架構設計、軟體細部設計、程式編碼與測試、軟體整合......)來劃分其發展的階段。以協助進度的掌握及報告。

　　當然，有些標準文件，例如ISO 9001及ISO/IEC 12207會提醒你在發展階段的時候，要找一個適用的生命週期模型。這個工作對於發展初步或細部WBS都是有幫助的，因為有些隱含在產品發展期中的工作，可能是看不到、想不到的，例如，功能組態稽核(FCA)、物理組態稽核(PCA)；另外，就是生命週期模型也會協助定出所謂整品的整合策略、交付時程、以及交付項目。但是如果僅從軟體生命週期過程的階段來劃分WBS，則是會有風險的(這是個人先前有應用的經驗，因此不再建議用這種方式)，因為你定出的工作項目會是：系統分析、系統架構設計、軟體需求分析、軟體架構設計......，然後定出他們的duration，這樣做似乎是把系統開發的工作通通列入了，事實上並非如此，因為還有技術上的複雜度、相關的風險而產生的其他工作事項及產出，例如風險管理計畫，另外就是一些像產品組件的make-or-buy策略(哪些組件技術要自己開發、經由教育訓練獲得技術移轉，然後再發展自行發展產品組件，或者根本就是用COTS產品來代替)、以及相關的專案規劃及執行的作為，你可能就沒有辦法在先前就考慮到，而且，這些多半是因為交付的產品或服務需求特性所引起的。

　　有關於您所指WBS工作項目元素彼此沒有關連，無法安排其先後順序，其實這是兩個層次的問題，以您所提的人事系統為例，系統被展開成為五至六層的WBS及組件之後，你會獲得的東西除了工作項目之外，當然還有組態管理的整個架構，你可以從中挑選出要納入構型管理制度中嚴格控管的項目(這段是題外話，但的確就是如此)，另外，劃分時，有個原則：「有拆解出來的工作，就會有將之整合的工作」。而彼此先後的關聯，是會受到合約要求的影響，例如，甲方要求先交付系統的哪些功能，這些功能要先設計、實作、整合及交付；會受到組件設計的自然律的影響，甲功能與乙功能之間需要丙介面才能夠運作，要先發展丙介面、甲功能、還是乙功能，這也許又與您的資源及人員技能水準會有關聯；會受到測試策略的影響，例如採用的是由上而下、由下而上或是骨架式測試策略？外界環境的影響，例如，某些開發中會使用到之軟硬體組件交付的前置時間(lead time)(向其他的廠商採購，運用在專案的產品當中)....，這些都是工作間關連的來源。

　　在實務上，有了WBS之後(從功能架構轉出，以及生命週期模型的工作要求與產出)，將WBS映對至ISO/IEC 12207主要生命週期活動與工作、CMMI的工程PA、專案管理PA、支援PA中的SP;或ISO 9001品質管理制度第7章產品實現部分的要求項目，就可以彙整出整個專案全部的工作項目(tasks)。此項工作可以使用WBS與軟體生命週期工作矩陣交叉考慮而達成。相關做法個人於92年4月份有關於ISO/IEC 12207在專案中的實踐方法研討會中已經說明。　
　

----------------
引文:

工作分解結構分析 WBS ( Work Breakdown Structure )是軟體專案規劃很重要的關鍵工作 !

關於如何發展 WBS，可以參考 MIL-HDBK-881，有詳盡的說明。

有時候大家都有點誤解, 藉這個機會來討論. 我的看法是 :

Product WBS 產品的工作分解結構 - 在收到及討論需求的時候, SA 會根據產品的最終想要達成的目標, 將產品依據技術及產品發展的過程順序, 展開詳細的 Work Package (也可以翻譯成工作包). 這裡要分為兩大區分, 一邊是產品本身的分解, 另一邊是發展/開發產品的工作分解.

For example, 要做一個 ERP 系統, 這個系統的 Product WBS 應該是:
1. 以產品達成的模組設計所展開的工作包 (module, interface, unit, .....)
2. 要發展這個系統所需要的其他工作的工作包 (Planning, testing, configuration Management, ...)

有了 Product WBS 的展開, 就可以根據每一個 Work Package 來估算所需要的 : 時間, 資源, 人力, 成本. 這個時候也可以判斷是否要委外開發或是採購現成的元件或產品.

經過估算後, 就會要考慮要用哪一種 life cycle model 了, 是要用 waterfall, 還是 spiral 等等, 不同的 life cycle model, activity 的順序也會不同.

一旦決定了 life cycle model, 也就等於決定了每一個工作包, 依據實際執行工作的順序, 排列成 activity list. 而這個 activity list 就是常見的, 用 Microsoft Project 工具所排列的專案計畫工作項目清單.

這樣解釋不曉得通不通 ??

專案的主要目標是在達成可交付給滿足客戶或使用者期望的Deliverables；而非只是一堆活動的組合。

以產業標準Best Practices的角度來看，PMI PMBOK 3rd Edition(2004)在Project Scope Management 其中5.3 Create WBS – subdividing the major project deliverables and project work into smaller, more manageable components.

PMI在2001也發表了第一個Practice Standard for Work Breakdown Structures的實務標準，並且將在2005更新。這些內容可以做為實務參考的一些方向與論點。

據知中華民國軟體品質協會近期將會開設一個課程來探討這個主題：

◎專案開始時如何正確的建立Work Breakdown Structure (WBS)，這將是團隊指派、範疇控制、軌道遵循與有效控制的關鍵。
◎如何正確的使用Top Down方式建立WBS ─ 重點在於分解範疇成為可量測的結果架構，先將專案最終目標與結果的Deliverables，分解成高階層的結果，再將其做工作指派。
◎如何避免以錯誤的方式建立WBS：一般常犯的錯誤是由專案經理獨自列出專案中應做的一堆事情，然後每個關係者接著提出他們要做的事與需求，這樣會使專案增加不須要的工作，並且將使專案範疇持續擴大。
◎如何經由良好與正確的WBS建立方法，使專案經理能控制範疇並滿足使用者與客戶的需求。
◎如何讓專案的執行者可練習策略控制而不用做細微的管理。