wbs
是交付成果導向的專案工作分解結構。那我們首先要尋找什麼是我們的交付成果。
這個問題使我想起了物件導向技術中的乙個問題，那就是如何尋找類和物件。尋找類和物件的前提是，我們對系統進行了需求分析。根據需求分析的結果，
1．遍歷需求有關文件
2．尋找所有的名詞，形成候選的類與物件清單。
3．清理掉那些重複與無意義的候選者
4．確定剩下的類和物件之間的相互關係
5．將他們按照主題組織起來
重複上面的過程，你就可以找到系統的物件結構，你就可以進行進一步的動態結構建模。
物件導向系統的關鍵問題，物件原來是這樣找出來的。那麼專案管理的關鍵問題，可交付成果其實也是這樣來的。
你首先要搞清楚什麼是你尋找的起點。然後根據起點，執行乙個尋找過程，你就可以基本上找到你的可交付成果了。
什麼是你的起點呢？
首先你應該將你的目光聚焦在你的客戶上，因為你所做的所有事情，他是買單的人。他說的話、他發給你的郵件、正式給你的文件、他要求做的報告、他要求你交付的東西就是你的起點。
你應該將與客戶有關所有的東西組織起來。
從這些材料中，你應該：
1.遍歷所有這些材料
2.尋找到有關的名詞，建立你的候選交付成果清單
3.清理掉那些重複的、無意義的候選者
4.分析剩下的哪些是你要交付的客戶的
5.分析客戶是否讓你將某些東西打成包一起交給他，這樣你可以對這些交付成果進行歸類
6.按照主題進行收集這些交付成果，以便方便你進行組織
你如果執行上面這個過程，你就可以大致建立乙個初始的
wbs。你要知道，
wbs是你和客戶之間對要提交什麼東西給他的約定，所以你應該與他達成一致。
上面這個過程，最好是你與你的團隊一起去做，這樣可以保證所有人對專案的可交付成果都有乙個清楚而且共同的認識。
這是wbs的最基本也是最核心的部分，我們來舉幾個例子：
例子一：
客戶要求開發乙個車隊跟蹤系統，對車隊的每一台車跟蹤其狀態、路線。開發周期
2010-4-5
日至2023年9
月15日。
客戶要求交付需求分析文件、設計書、程式、手冊，並負責安裝與培訓，以及為其
2各月的維護工作。
那我們大致可以知道
wbs的構成如下：
車隊跟蹤系統
需求分析文件
設計書 程式
手冊安裝
培訓維護
專案管理
其中安裝、培訓、維護是客戶要求交付的，也是可交付成果。
例子二：
客戶要求完成乙個大型
cobol
系統的遷移工作，該系統原來在主機平台上，現在要遷移到
as400
為基礎的小型機平台，功能原封不動的使用
rpg再實現。
該系統一共有
20000
個畫面，分成
14個子系統，客戶將這
14個子系統分成
4個部分進行遷移。
客戶要求提供遷移計畫，計畫獲得批准後，要交付
rpg系統的整體設計、每個部分的概要設計，以及每個畫面的詳細設計，以及最終的軟體、測試計畫與測試結果。但不負責有關安裝、培訓等工作。
按照上面的要求，我們可以大致得到
wbs如下：
**系統遷移
遷移計畫
整體設計
部分1
概要設計
子系統1
子系統2
子系統3
子系統**
詳細設計
子系統1
子系統2
子系統3
子系統**
程式 子系統1
程式1
程式2
程式3
子系統2
子系統3
子系統**
測試
測試計畫
測試結果
程式1
程式2
程式3
部分2 部分
3 部分
4
從上述兩個思路，我們能夠比較快的建立專案的
wbs核心，在此基礎上，我們就可以比較簡單的將專案給管理起來。
關於好的WBS
wbs 是專案管理的核心元素，代表了專案要完成的工作。我們可以這麼簡單的看待有關專案的層次關係 1.專案的目的。2.專案要達到的目標。3.為了達到目的與目標，我們應該做些什麼。工作 4.我們應該什麼時候做，要達到什麼樣的標準 做到什麼程度 要花多少錢。5.由誰去做？6.我們應該如何去做？7.會有什麼...
「制訂」與「制定」的區別
在對比 資訊系統專案管理師教程 第2版 與 pmbok 第3版 時發現，兩者在使用 制訂 與 制定 時有不同。前者使用制訂，例如第83頁的 制訂專案章程 後者使用制定，例如第4章，制定專案章程。到底誰的用法正確呢？根據這裡 的說法，資訊系統專案管理師教程 第2版 的用法正確。引用 制訂 跟 制定 在...
專案基準的基準 WBS
隨著專案管理技術的不斷推廣和廣泛接受，wbs也漸漸走進專案經理人的視野，專案管理日常工作的核心工具之一，它充分體現了pmbok的 分解 這一核心理念，能夠幫助專案團隊對全域性進行把控，不至於因為考慮不周或者經驗不足而導致專案偏離軌道，甚至於掉入失敗的深淵。在這裡，我把自己對於wbs在專案管理過程中的...