專案管理中有一個很厲害的東西，叫做工作分解結構。
它就像是廚師的菜刀，可以把食材切的一段一段的！
只是，當我拿起小刀，就會瑟瑟發抖。
######
好奇問問大家，當負責新的一個專案項目時，都是怎麼展開工作項目的呢？
年輕時候的我，剛拿到需求就會把需求直接填到工作列表中，然後就會遇到一個問題，這個工作需求好像需要工程師和設計的配合，那怎麼辦？
| 編號 | 工作項目 | 負責人 | 所需時間 | 開始時間 | 結束時間 |
| 1. | 註冊 | 產品企劃？工程師？設計師？ | |||
| 2. | 登入 | 產品企劃？工程師？設計師？ |
後來想想，似乎應該要把工程師和設計師的工作也都要切開來，於是變成下面的表格：
| 編號 | 工作項目 | 負責人 | 所需時間 | 開始時間 | 結束時間 |
| 1. | 註冊 | ||||
| 1.1 | 註冊規則 | 產品企劃 | |||
| 1.2 | 註冊頁面 | 設計師 | |||
| 1.3 | 註冊功能 | 工程師 | |||
| 2. | 登入 | ||||
| 2.1 | 登入規則 | 產品企劃 | |||
| 2.2 | 登入頁面 | 設計師 | |||
| 2.3 | 登入功能 | 工程師 |
可是工程師和設計師的工作細節，身為一個菜鳥的我，似乎無法掌握，這個時候主管就說「那就把設計師和工程師的工作追蹤，交由他們各自的主管管理」，於是就這樣變成三分工作的進度追蹤表。
| 編號 | 工作項目 | 負責人 | 所需時間 | 開始時間 | 結束時間 |
| 1. | 註冊 | ||||
| 1.1 | 註冊規則 | 產品企劃 | |||
| 2. | 登入 | ||||
| 2.1 | 登入規則 | 產品企劃 |
| 編號 | 工作項目 | 負責人 | 所需時間 | 開始時間 | 結束時間 |
| 1. | 註冊 | ||||
| 1.2 | 註冊頁面 | 設計師 | |||
| 2. | 登入 | ||||
| 2.2 | 登入頁面 | 設計師 |
| 編號 | 工作項目 | 負責人 | 所需時間 | 開始時間 | 結束時間 |
| 1. | 註冊 | ||||
| 1.3 | 註冊功能 | 工程師 | |||
| 2. | 登入 | ||||
| 2.3 | 登入功能 | 工程師 |
接下來又遇到一種狀況，產品企劃、設計師、工程師之間，突然都不知道對方做的狀況，於是又變回一張表。
光是這樣要維護這個工作進度的表單，就耗盡了我全部的精力，當然，只要中間的需求有些變動，就又要重新確認一次。
| 編號 | 工作項目 | 負責人 | 所需時間 | 開始時間 | 結束時間 |
| 1. | 註冊 | ||||
| 1.1 | 註冊規則 | 產品企劃 | |||
| 1.2 | 註冊頁面 | 設計師 | |||
| 1.3 | 註冊功能 | 工程師 | |||
| 2. | 登入 | ||||
| 2.1 | 登入規則 | 產品企劃 | |||
| 2.2 | 登入頁面 | 設計師 | |||
| 2.3 | 登入功能 | 工程師 |
然後，這樣痛苦的日子大概過了半年，心想，肯定有更好的方式。當時用來管理專案的工具是「Microsoft Project」，「Microsoft Project」是一個很好用的工具，是我的工作項目管理的觀念，趨近於零，無法駕馭。
於是開始花時間去研究，這時候發現一盞明燈，那就是「工作分解結構(Work Breakdown Structure，簡稱WBS)」。WBS的概念，就用一個相對有結構和層次的方式，針對「需求進行拆解」。
以先前的文章《搞懂系統架構》中提到的例子
這款遊戲的WBS就會類似下表的結構。
這邊有一個地方需要注意，WBS代表的是「開發過程中的可交付成果」，所以必須為「名詞」，且一個拆分的項目的執行時間在80小時以內，約2周，10工作日，目的在於將「可交付成果分解成適當的工作大小」，避免發生開發一個項目要3個月的狀況。
接著，就會持續往下展開，如下圖，而持續拆解下去的項目，就會稱之為「工作包」。以「郵件管理」為例：
那還能持續往下拆解嗎？答案是可以的，只是要不要這麼做而已。假設設計師在設計介面時，有被要求要三種不同樣式或風格的設計圖，那或許就會變成這樣，如下圖(A)。往往在拆解工作包的時候，會遇到一個問題，就是要拆到怎樣的程度才可以，其實，這個問題沒有絕對的答案。以圖(A)來說，細分下去的樣式(1)、樣式(2)、樣式(3)就會變成「工作包」，到時候還需要再將這三個工作包向下列出「活動」，也有人稱為「任務」。但是，以圖(B)來說，直接將樣式(1)、樣式(2)、樣式(3)就列為「活動」。
差異在於，
圖(A)：樣式(1)、樣式(2)、樣式(3)三個工作包各別列出，可以針對三個工作包進行各別檢核。
圖(B)：繪製完樣式(1)、樣式(2)、樣式(3)後，才算是完成一個工作包，然後一次進行檢核。
在實際進行專案的時候，如果樣式(1)、樣式(2)、樣式(3)是必須同時確認的，畢竟會想看看哪種樣式適合，那就適合圖(B)的概念。
但是需注意的是「活動並不屬於WBS的一部份」，因此整個WBS就會像下圖一樣。
(下圖只是範例，並無把所有部分展開)
當「活動」產生後，就可安排執行的負責人，也因此就可以開始針對每一個活動進行「時間及預算的估算」。
到這邊，如果還對工作分解結構(WBS)、工作包、活動不是很清楚的話，簡單用一個例子，你就明白了。
假設今天的專案目標是「完成鋼彈模型的組裝」，如下圖：
那我們的「WBS」是什麼呢？其實就是把整個鋼彈拆分成幾個主要的區塊，如下圖。
那「工作包」是什麼呢？就是將各區塊再細分到各部位。到這邊就是一個WBS圖的概念。
而「活動」，指的就是將這個「部位」完成所必要的「動作」，以組模型來說「組裝、貼貼紙、塗裝」，就會是一個基本的動作，當然有些人不會去進行塗裝，於是就只會有「組裝和貼貼紙」。所以「活動」的列舉，也會是依據實際狀況去調整。
希望用「組模型」這個例子，可以讓大家更簡單的理解什麼是「WBS、工作包、活動」，回到一開始的例子。
| 編號 | 工作項目 | 負責人 | 所需時間 | 開始時間 | 結束時間 |
| 1. | 註冊 | 產品企劃？工程師？設計師？ | |||
| 2. | 登入 | 產品企劃？工程師？設計師？ |
就會變成下列這張表。
| 編號 | 工作項目 | 負責人 | 所需時間 | 開始時間 | 結束時間 |
| 1.0 | 會員管理系統 | ||||
| 1.1 | 會員註冊 | ||||
| 1.1.1 | 會員註冊_規格文件 | ||||
| 1.1.1.1 | 繪製wireframe | 產品企劃 | 1d | ||
| 1.1.1.2 | 撰寫註冊規則 | 產品企劃 | 1d | ||
| 1.1.1.3 | 繪製註冊流程圖 | 產品企劃 | 1d | ||
| 1.1.1.4 | 設計會員的DB Table需求 | 產品企劃 | 1d | ||
| 1.1.2 | 會員註冊_介面設計圖 | ||||
| 1.1.2.1 | 繪製介面概念圖 | 設計師 | 1d | ||
| 1.1.2.2 | 製作介面元件_按鈕 | 設計師 | 0.5d | ||
| 1.1.2.3 | 製作介面元件_背景 | 設計師 | 0.5d | ||
| 1.1.2.4 | 製作介面元件_ICON小圖示 | 設計師 | 0.5d | ||
| 1.1.3 | 會員註冊_前端網頁 | ||||
| 1.1.3.1 | 製作會員註冊_前端網頁 | 前端工程師 | 0.5d | ||
| 1.1.3.2 | 串接會員註冊API | 前端工程師 | 2d | ||
| 1.1.4 | 會員註冊_註冊API | ||||
| 1.1.4.1 | 撰寫註冊API程式碼 | 後端工程師 | 1d | ||
| 1.1.4.2 | 撰寫註冊API文件 | 後端工程師 | 0.5d | ||
| 1.1.5 | 會員註冊_註冊驗證機制 | ||||
| 1.1.5.1 | 設計註冊驗證流程 | 後端工程師 | 2d | ||
| 1.1.5.2 | 撰寫註冊驗證程式碼 | 後端工程師 | 2d | ||
| 1.1.6 | 會員註冊_會員DB Table | ||||
| 1.1.6.1 | 設計會員DB Table | DBA工程師 | 0.5d | ||
| 1.1.6.2 | 建立會員DB Table | DBA工程師 | 0.5d | ||
| 1.1.7 | 會員註冊_測試驗證報告 | ||||
| 1.1.7.1 | 撰寫測試計畫 | 品質工程師 | 0.5d | ||
| 1.1.7.2 | 撰寫測試案例 | 品質工程師 | 0.5d | ||
| 1.1.7.3 | 執行會員註冊驗證 | 品質工程師 | 1d | ||
| 1.1.7.4 | 撰寫測試報告 | 品質工程師 | 0.5d |
這樣是不是就更有概念了呢？
搞懂WBS和工作包，幫你拆解專案的需求項目，更有效管理工作項目。
《如果覺得這邊文章有幫到你，歡迎請我喝杯咖啡》
——–
大家好，我是 數位產品開發教練 – 陳俊聖/廣三/HeroMi
17年數位產品開發經驗。經手至少80個大小專案。
擅長解決與工程師的溝通問題，幫你建構工程思維。
如果有任何想法，歡迎留言或發信給我，希望可以幫到你
我的信箱：info@hero-mi.com
歡迎加入粉絲團：數位產品開發教練 – 陳俊聖/廣三/HeroMi
*本站所有文章未經授權，請勿任意利用、引用、轉載，但是歡迎按讚、訂閱、分享。
留言