做不好工作分解結構，你的專案已經失敗了一半

工分製為什麼會失敗

工作分解結構（WBS）是保證專案成功的關鍵，是為專案團隊和客戶提供綜合的視野的一個主要工具，也是跟蹤系統的基礎。

團隊一起開發WBS可以提升團隊對專案可交付成果的使命感。同時也有助於提供團隊成員需要的雙重視角——不僅可以瞭解每個成員必須做什麼才能要完成自己的專案任務，也可以瞭解到每個人的角色是如何與整個專案融為一體的。

有兩種格式的WBS：提綱格式或層級格式。層級格式看起來非常類似組織結構圖；提綱格式如圖下所示。

提綱格式

有趣的是當今許多軟體包中，WBS是以提綱格式展示的，然而大多數人都認為建立的WBS應該是層級格式的，在我們看來層級格式也是在團隊環境中建立WBS時最好的格式。

描述層級最高級別的術語為“專案可交付成果”，層級的最低級別稱作工作包。

為了說明這個概念，讓我們來看看WBS是如何應用到專案上的。

如果你願意，那麼就想象這是你家鄉一個美好的週日下午。你決定帶你的愛人和小孩子出去兜風享受美好的一天。你開車沿著道路行駛，小孩子心滿意足地坐在汽車座位上，望著窗外。

所有的一切都很順利，直到你突然看到正前方有個很熟悉的頗受大眾歡迎的快餐店的標識時，後座的小孩興奮地喊道：“我想吃寶貝套餐，就現在！”作為車裡的兩個關鍵干係人，你和你的愛人很願意承擔這個小專案，我們將這個專案稱作“購買和消費兒童快餐食品”或者“寶貝套餐”。

你停下車，牽著小孩子走進了那家餐館。你告訴櫃檯後面的那個新幹系人：“請給我來份寶貝套餐！”

這是車上所有干係人都清楚的事。

但新的干係人沒有完全明白，所以問：“您需要哪種寶貝套餐？”

此時，你就可以說出你的專案目標是這個寶貝套餐，而且隨著專案的進行專案可交付成果的進一步說明就會變得易於接受和正常。如果此時你的小孩想要改主意：“我想要一個極樂漢堡”，這樣專案的可交付成果就發生了變化，你將有了一個新的專案。

在這個例子中，小孩子想要一個芝士漢堡，因此所有干係人現在應該明白孩子（客戶）想要什麼。

然而櫃檯服務生這位新幹系人再次拋回來另一個問題：“您需要哪種飲料？”

而這進一步的澄清是合理和正常的。一旦你答覆：“我想要一個乾酪漢堡和一杯可樂。”

接下來可能會有更多問題，一旦這些問題被解決，你就可以付錢並且得到你的專案可交付成果：那份寶貝套餐。

你想要確保自己的客戶滿意，因為客戶滿意度決定了一個專案是否成功，所以你要核查所有已交付物。

這其中有缺陷嗎？如果沒有，小孩將會品嚐寶貝套餐，然後你們將會離開這家餐廳，同時你的專案也就結束了。

如果用層級格式來構建WBS，你可以把下述主要的可交付成果當作最高級別：

·進入。

·購買寶貝套餐。

·驗證與確認。

消費。

離開。

接下來您可以對每個主要可交付成果做進一步的分解。

給大家留個題，看看剩下3步如何分解

每個可交付成果的要素都還沒被進一步分解成工作包，主要可交付成果“進入”下層的“進入餐廳”還沒有被分解。

如果你正式決定你並不想將法式炸薯條進一步分解成工作包，那麼法式炸薯條本身就變成一個工作包，所有的子元素便被刪除了。

工作包也會隨著專案的進展而變化（更詳細的工作分解會出現），這是WBS被認為是一個動態檔案的原因之一。

當你進行確認時，你應確保如果完成了所有工作，你將完成專案目標—“購買和消費一個芝士漢堡”。

值得注意的是，有時當你仔細檢查WBS時，你會發現工作的一些關鍵部分被省略了。

現在你需要找回那些遺漏項，從而減少專案後期的變更需求（以及隨之而來的工期延誤和成本超支）。

團隊參與建立WBS有利於增加責任感和溝通，減少遺漏任何所需要工作的機率。WBS需要詳細描述其中每個工作元件對於裝置、人工和材料所需的費用。因為每個元件都是一個可測量的工作單位，對比成本和進度計劃的基準線，WBS可以成為監測專案進展的基礎。

記住WBS被認為是有助於管理專案的，因此我們應該考慮專案將如何收集資訊和報告狀態。

構建WBS有助於開展這項活動，既要周密又不能拘泥於分析。

如果團隊習慣於識別短到8～10個小時的工作包，他們就需要相應地增加管理時間來跟蹤這些工作包。也就是說，工作劃分越細緻，管理成本就越高。所以限制WBS的詳細程度有助於管理專案。

編號系統可以轉化為一種有效的成本跟蹤系統。一個編號系統的例子就是把專案級別設為0。0，之下的三個主要交付成果設為10、2。0、3。0。在1。0之下，可以設1。1、1。2等。資源、成本和時間的分配已經詳細到了工作包的層級上。