如何運用WBS真正讀透一本書

胡晶晶

作為一名項目經理，工作分解結構（WBS）是我日常使用的工具。通過《項目管理評論》這一平臺，我有幸參加了由中國電力出版社舉辦的《工作分解結構實操秘訣（第2版）》新書分享活動。活動后，我開始反思平日里對于這一常見又易被忽視的工具的應用情況，并找出正在跟進的一個項目，本著閱讀指導實踐的想法，查找優化WBS的方案。

在翻開新鮮出爐的《工作分解結構實操秘訣（第2版）》之前，我結合實際工作情景，列出來以下幾個亟待解答的問題。

場景一：項目的工作分解結構和項目集的工作分解結構概念混淆。更進一步說，這種混淆可能造成項目經理和項目集經理之間工作內容出現重疊，浪費資源。①項目的工作分解結構與項目集的工作分解結構應怎樣區分？

場景二：樣本項目工作分解結構的制定過程如下：通過對業務、技術和項目管理三個方面進行需求發現會議，形成需求發現報告，并獲得客戶簽署。在客戶簽署的基礎上，項目經理開發工作分解結構。整個項目范圍被分解為項目啟動、需求發現、配置、測試、上線和項目收尾幾個階段。每一階段為第一層級的工作分解結構。第二層級是業務顧問根據項目需求訪談成果（項目范圍）抽象出的業務模塊。每一階段都根據業務模塊進行分解。技術工作經過技術顧問評估，穿拆在對應的項目階段中。針對每一階段，項目進度計劃中都羅列出了對應的可交付成果。這個過程和當中的步驟是否還可優化？即②需要了解項目范圍與工作分解結構之間存在怎樣的關聯？④樣本項目所使用的工作分解結構是否完整？⑧樣本項目的工作分解結構是否還有更優的組織方式？

場景三：樣本項目定義項目進度計劃的過程是先通過會議，由業務顧問負責人、技術顧問負責人和項目管理團隊共同定義工作分解結構。經過多次復審，形成最終版本的工作分解結構。通過對每一項活動定義時間，匯總形成項目進度計劃。在過程中，實施團隊會與客戶進行各種形式的溝通，力求溝通充分。內部形成一致意見的項目進度計劃最終經由客戶復審和批準。由于研發工作是由研發部門而非交付部門安排，在項目進度計劃中根據研發部門的輸入，描述了軟件發布時間，沒有進行進一步的分解。這個過程和當中的步驟是否還可優化？即③工作分解結構對項目進度計劃有怎樣的作用？⑨對于由研發部門負責的工作，怎樣通過優化工作分解結構來更好地控制項目進度？

場景四：工作分解結構在實際工作中依據漸進明細的原則滾動更新。需要更新的內容有可能是對某些任務進行更加細化的分解，也有可能對已經批準的范圍進行調整。而由于項目進度計劃經過嚴格的審批，甲乙雙方對于更新已有的項目計劃心有顧慮。有時在決策是否調整進度計劃的過程中，事實已經發生。項目經理再根據事實的發生被動更新項目計劃。⑤項目進度計劃是經過簽字批準的項目關鍵文件。工作分解結構作為一個關鍵輸入，對它進行更新時，有哪些注意事項？

場景五：經過上述評估，樣本項目的工作分解結構大體符合書中提出的要求。但是，如何對工作分解結構的好壞做出評價呢？即⑥當前所使用的工作分解結構好不好？可以怎樣改進？

除上述5個場景中涉及的問題外，我還總結出另外兩個日常工作中遇到的問題：⑦在面向不同的利益相關方時，怎樣更好地展示工作分解結構，使利益相關方更好地了解我想表達的內容，從而支持我的工作？⑩如何在虛擬團隊背景下優化工作分解結構的使用？

受到活動中汪小金老師的啟發，我將《工作分解結構實操秘訣》（第2版）使用分解技術，用思維導圖的方式配合理解。這張思維導圖并不是一份完整的工作分解結構，我只以目錄為脈絡，分解到第二層級。根據不同的側重點，可能您會有一張不同的思維導圖（掃描文末二維碼，查看思維導圖）。

通過拆解閱讀，在書中的相應版塊找到了自己想要解決問題的答案。書中“第1章 1.2 什么是項目集WBS和項目組合WBS”，解答了我的第一個疑惑。項目層面的WBS與項目集或項目組合層面的WBS的相同點在于基本概念相同，工具和技術相同。而所包含的內容和責任人不同。回到案例，相同之處暫且不言，就不同之處，項目集經理負責項目之間的邊界和關系界定。項目經理負責確定項目內部的工作。

書中“第9章 把WBS應用于進度和成本管理”一章提到了將WBS與進度計劃聯系起來的必要性：“確保WBS中所定義的全部工作都有對應的計劃，都將得到執行。確保只執行經過批準的工作，范圍之外的任何工作都必須不做。”樣本項目中制定項目進度計劃的過程是科學的。

解答了心中的疑惑，我開始嘗試反思實際編制的WBS是否完美，并結合項目的具體信息做出了修改。這是一個IT管理軟件的產品實施項目。項目范圍包括產品配置和研發，整個業務范圍涉及承保、理賠、賬單管理、財務結算、預估業務等多個模塊。從實施方的角度講，項目實施周期為3年。合同下包含財產險和壽險兩個獨立的項目，這兩個項目作為項目集來統一管理。兩個項目的實施周期存在一定時間上的重疊，并且實施團隊核心人員為同一批人員。實施團隊和研發中心在實施方的組織中是并行存在的兩個團隊。項目組織架構如圖1所示。

在編制樣本項目的工作分解結構之前，實施團隊與客戶團隊組織了業務、技術和項目管理三方面的訪談。根據訪談報告，項目經理組織會議。由首席業務顧問、首席技術顧問和項目管理團隊共同定義工作分解結構。經過多次復審，形成最終的工作分解結構，如表1所示。通過對每一項活動定義時間，匯總形成項目進度計劃。在過程中，實施團隊會與客戶進行各種形式的溝通。力求溝通充分。在提交客戶審批之前，工作分解結構經過公司內部的項目指導委員會審批。內部正式批準的版本，最終經由客戶評審和批準。就研發工作而言，在項目計劃中根據研發中心的輸入，描述了軟件的發布時間。而對于每一次發布的內容未在工作分解結構中進行更加細致的定義和追蹤。

但更為重要的是通過這次檢查，我識別到了樣本項目的WBS值得優化之處。研發中心隸屬于項目執行團隊之外，而研發中心每次軟件包的工作分解結構沒有集成到實施項目的WBS之內。實踐證明，這給客戶方的利益相關方造成了研發中心工作不可控的錯覺，造成了不必要的擔心。但是通過讀書后我發現，樣本案例中的研發工作遵從標準的敏捷管理思路。每一次版本發布作為一個Sprint。書中“第12章 在敏捷項目中使用WBS” 從管理項目范圍、管理產品范圍和如何創建WBS三個方面解釋了敏捷方法（產品管理）與《PMBOK？指南》（項目管理）的區別。經過思考，如果將每一次版本發布的內容根據功能模塊進行進一步的分解，并展示在項目進度計劃中，這將是對當前項目進度計劃的優化，更加有利于控制項目進度，獲得更高的客戶滿意度。這讓我對樣本項目的成功更有信心。因此，我將工作分解結構中的下述內容作了修改，如圖2所示。

這樣一來，將開發工作視同為由項目組向研發中心 （R&D） 的外包項目。整合研發中心的信息，將開發工作的WBS匯總到整個項目的WBS中，并盡可能細化具體任務，完善項目進度計劃。在工作分解結構的第四層，展示了更加具體的分解，如功能一、功能二、功能三。更新后的工作分解結構更加完整。對于客戶所關心的新功能發布一目了然。在實戰中，客戶對實施方的整體滿意度也因此而提升了。

在閱讀《工作分解結構實操秘訣》的過程中，我對如何判斷工作分解結構的好壞有了更加結構化的認識。書中“第5章 有助于掌握WBS的關鍵問題”中“5.10 什么是判斷WBS好壞的標準”是很好的總結。我發現書中的十六條標準修改后完全可以作為用來判斷和檢驗WBS是否能進一步優化的標準，甚至能夠用作檢查表。這十六條標準分別是：

（1）它以可交付成果為導向。

（2）它定義了項目范圍。

（3）它向所有利益相關方明確了項目工作。

（4）它涵蓋了100%的工作。

（5）它包含所有可交付成果，包括項目管理。

（6）每個下級分解層級都包含了上級層級的100%工作。

（7）工作包有利于識別為交付工作包所需開展的任務。

（8）它以圖形、文本或表格來呈現對項目范圍的逐層分解。

（9）WBS組建用名詞或形容詞命名。

（10）它是全部可交付成果的層級結構。

（11）每個組件都有一個WBS標識（編碼）。

（12）它至少有兩層，其中至少有一個分解層。

（13）它由工作的執行者創建。

（14）利益相關方和專家已經參與WBS的創建。

（15）它隨著項目范圍的漸進明細而更新。直到確定范圍基準。

（16）它隨著項目變更控制而更新。

“工作分解結構是項目管理中最有用又最易被忽視的工具。”通過學習，用書中的理論指導實踐，才能精益求精。我建議各位同仁在閱讀后都對自身項目的工作分解結構進行評審和優化。用思維導圖拆解圖書的內容以此指導閱讀只是閱讀方法中的一種。它適用于帶有明確目的的閱讀，能夠幫助你快速找到想要的答案。