我使用中的軟件開發項目的WBS

儘管在現在的項目管理領域推廣適應性的管理方法，但是傳統計劃型的項目管理方還是有其實際的意義。特別像作為乙方（供應方）的項目經理，受限於固定總價的合約和甲方用戶的被動參與，在實際運用適應性管理受到一定條件的限制。因此運用計劃導向的管理方式在這種類型的項目更能發揮實際的作用。我在基於這個前題條件下，發展出屬於自己的WBS，以協助自己管理項目各方面的運作。

為何需要WBS

只要是有參與過項目，或多或少都聽過WBS這個名詞，而且網上也有很多關於它的說明，例如：

工作分解結構 (WBS) 是項目管理中的基石，它通過系統化地分解項目工作，為項目的成功規劃、執行、監控和收尾提供了清晰、結構化的藍圖。

以上的說明指出，WBS是項目成功的基石，感覺就是沒它不行。但說到底為何項目需要WBS呢？

傳統項目管理方法的重點在於計劃，即在實際開始工作之前先把需要完成的工作思考清楚。而由一個什麼都沒有的情況來思考有在未來什麼工作需要做，而且沒有遺漏任何可能的工作，要實現起來是很困難的。因此先為項目建立一個框架，把項目應該要完成的東西都先安排好，再來才給予實施的人來思考要如何來完成它們，這樣思考工作才會更為順利。

例如如果要規劃一次外出旅遊，我可能的分解會是旅遊前、中、後，並在各階段中再加上其他內容，例如旅遊前可以包括：行、住、食、買、看等。簡單WBS的例子大概長這樣

總括來說，上面的結構主要的目的是讓我們在思考有什麼要做的時候的一個重要的框架，它能讓我們更有方向的進行思考和探索，特別當項目規模和複雜性更大的時候。

軟件開發項目的WBS

首先，WBS並沒有對錯，即使只有一層結構，也能叫做WBS，只是要完整思考有什麼任務需要完成比較困難，除非某個工作已經完成過很多次。對於我來說，合適粗細度的WBS能給予實際做事的人在思考工作時有一定的目標，能更為聚焦於某一成果。以下是我正在使用中的WBS模板：

我設計的WBS是根據Robert K. Wysocki於《Effective Software Project Management》一書中所提出的WBS框架更改而成。WBS的首層是按照現在項目標準的各主要階段設計。

於下一層就是按照每一階段中必要的產出物來作分解，例如Scope階段必要的產出有project kickoff (對應的產出是kickoff materials)、Requirement Garthing (對應的產出是RSD)如此類推。值得注意的是Design & Build階段中的內容，是通過Plan & Launch階段的「Create WBS」工作上作細化及完成的。

要完成Design & Build中的結構，則需要先把相關的需求先組織於一起，成為Requirement Set。以HR系統為例，以下的需求即可以組成一組：

• 員工可自主申請補償，並取代原有紙本方式作申請；

• 員工可以得悉其補償審核和打款情況，透明化相關資料更新，提升員工滿意度；

• 管理層要求如果申請的補償金額超過5000元，則需要部門總監審批，否則只需要部門經理作審核。以簡化細額申請的流程並對大額申請保有一定程度的控制；

• 財務部門需要每月指定期間下載同事的補償申請，以便資金的調度；

若Requirement Set決定好後，即可進一步關聯為系統的相關功能。如果功能中的邏輯較為複雜，則可以再進一步細分為若干個特性 (Features)，以減低整個工作包的複雜度。

WBS中的各個節點不直接等於工作，它指的是工作的集合，為實施工作的同事提供一個清晰的方向，好讓他們能思考需要實施的工作有那些。

後記

作為乙方項目經理，通常其項目先天會受限於訂單合同的設計及簽訂。由於人類不喜歡不確定性，因此固定總價合同幾乎是最常出現的一種合同類型。因此WBS的計劃在此類項目中發揮重要的作用，也能讓項目經理不需要作微管理，管理深度只需要至「工作包」產出物即可。