|
|
| 首頁 | 討論區 | 最新話題 | 搜尋 | XML | 登入 |
 博客來購書 |
《主管這樣帶人就對了！》
貝殼鯨魚兒童程式啟蒙（點我去報名）
|
 |
Blueimp » 列出所有討論區 » 討論區: 專案管理 |
|
|
| 此話題中所有文章數: 3 [ 話題狀態: 一般 ] | |
|
WBSWBS - work breakdown structure---------------------------------------- 支持小惡魔 BTC : 19tn3RnCuwZVukXAwyhDWZD4uBgUZoGJPx LTC : LTFa17pSvvoe3aU5jbmfcmEpo1xuGa9XeA 知識跟八卦一樣，越多人知道越有價值；知識最好的備份方法，散播！ 藍色小惡魔(林永傑)： 臉書 |
||||
|
麥肯錫MECE原則與專案管理WBS技巧在文【麥肯錫的MECE與代數正交基底】中，我們討論了麥肯錫人面對問題的基本思維架構-MECE（Mutually Exclusive, Collectively Exhaustive），並且點出MECE與數學上的正交基底關連性。問題一旦進行拆解或解構（Decomposition），思考途徑與解決方法便由此產生。 在專案管理中（Project Management, PM），MECE原則也廣泛運用，其中最常聽到的專案管理原則與技巧為WBS。所謂的WBS即是Work Breakdown Structure（工作分解結構）的縮寫，根據Wikipedia[1]說明，WBS為專案管理基本技巧之一，WBS使用階層樹狀結構（Hierarchical Tree Structure）與100%原則（100% Rule）來定義與組織專案範圍（Project Scope）。此外，一個優良的專案WBS技巧，是針對產出（Outcomes）所進行的拆解，而非工作項目（Actions）拆解。 在上述WBS說明中有三個重點，其一為樹狀結構分解方法，其二為100%原則，其三為分解標的。在分解標的上，WBS或PM採用針對目標結果產出的分解（果，輸出），而非針對行動之分解（因，輸入），一來結果產出較易定義，一切作為行動均以結果論，其二結果量化程度較易，量化評估指標得以導入。 結合樹狀結構分解方法與100%原則即是麥肯錫的MECE原則。樹狀結構（Tree Structure）與我們在專利分析工作中，拆解技術與功效所用的魚骨圖（Fishbone Diagram）或是品質管理的因果圖（Cause and Effect Diagram）相似，均是一種拆解工作與方法。不同點在於，WBS要求的拆解除了區別出不同元件要能互相獨立外，元件的總和要能完整，也就是所謂的100%原則。換句話說，一個有效的拆解，除了個別元素要能互斥外，整合後的元件亦具備完整性，即是麥肯錫的MECE原則。 圖一為Wikipedia所介紹的一拆解範例。不論是WBS Level 1、WBS Level 2或是WBS Level 3，所有元件的總和均為100%（100%在此範例中代表腳踏車），當然所有元件或是子元件均為腳踏車獨立與不可或缺部分。需要說明，系統拆解方法端視分析者與使用者有所差異（與定義有關），並且也是需要花時間與精力討論部分（需要全域思考與整合能力）。然而，一旦此部分工作可以克服，往後分析工作均能在此架構上展開，如同麥肯錫問題解決技巧一樣，見【麥肯錫問題解決模型的啟示】。 此外，雖然WBS先強調針對產出（Outcomes）的分解，但是其他面向分解，例如OBS（Organization Breakdown Structure）為功能組織分解，BOM（Bill of Material）為材料組成分解，RBS（Risk Breakdown Structure）為風險分解與RBS（Resources Breakdown Structure）為資源分解均可在此架構下進行[2]。換言之，針對產出分解、針對組織、針對產品材料、針對風險與針對資源等均可以相同MECE原則展開，建立分解架構、利用100%原則，盡可能在相同架構下分解展開。 最後，由麥肯錫MECE原則與專案管理WBS技巧可得啟示，物理科學與自然科學的基本工即是建立架構、拆解、分析、最後整合不同元件，進而處理特定問題。當然，其中每一動作除了要有專業知識外，處理邏輯掌握亦是一重要因素。往後我們再根據此邏輯與原則，進一步以專利分析或產業分析案例進行說明。(1125字 ; 圖1 ) 關鍵字 : 專案管理、麥肯錫MECE原則、工作分解結構 (WBS : Work Breakdown Structure) 、MECE（Mutually Exclusive, Collectively Exhaustive） (科技產業資訊室-- Amber 編撰) 參考資料： http://en.wikipedia.org/wiki/Work_breakdown_structure Project Management Institute, A Guide to the Project Management Body of Knowledge, Third Edition (PMBOK Guides), 2004. http://cdnet.stpi.org.tw/techroom/analysis/pat_A089.htm ---------------------------------------- 支持小惡魔 BTC : 19tn3RnCuwZVukXAwyhDWZD4uBgUZoGJPx LTC : LTFa17pSvvoe3aU5jbmfcmEpo1xuGa9XeA 知識跟八卦一樣，越多人知道越有價值；知識最好的備份方法，散播！ 藍色小惡魔(林永傑)： 臉書 ---------------------------------------- [編輯文章 2 次, 最後修改： jieh 於 2010/10/13 上午 09:31:55] |
||||
|
WBS與專案規劃WBS(work breakdown structure)是專案規劃的重要元素，我們在進行專案規劃的時候，常常犯的一個錯誤，就是從直接選擇一個專案發展的策略(或模型)(例如，Waterfalls、Incremental、Evolutionary，或者Spiral等)，再設法套到專案裡，然後從這個模型所規劃的產出去訂里程碑。這種做法，以筆者的經驗來說是不可行的。因為，不論是多大的專案，在產品上、技術上的決策，事實上遠比決定專案發展策略來得更為複雜。因此，我們在專案規劃上若是以過程為著眼，就算是採用的是Grand Design Strategy(亦即「瀑布式」發展過程)，也將無法做完專案，因為你會陷在過程階段劃分的泥沼中，不知道專案的下一步該怎麼走。而就在這當中，耗盡了時間與預算。WBS是產品導向的，透過樹狀結構的方法，將專案產品分割，直到可以管理的最小單位(但也不能太細，否則會使整合與管理的成本升高)。接著我們就可以根據這些細分出來的工作項目元素，去估算工作時間、成本、所需資源、技術、相關風險。由於這些工作產品的項目是可以管理的，因此，我們也就可以從WBS轉出產品的組態項目(CI)。另外，我們也可以經由WBS的階層關係，了解各工作產品間的相互關係、工作次序等等。由此，我們就可以訂出整個專案工作網狀圖，並以每個工作的工時，訂出專案的要徑(Critical Path)。另外，每個工作產品都是以由上而下的設計、由下而上整合與測試的瀑布式開發方式產出。由於每個產品已經明確地劃分出來，因此，可以很明確地指派出去給功能單位，或開發單位負責實作。而最重要的是，專案的成本就可以精確地計算出來。 產品在經過WBS劃分之後，我們就可以預判出專案的可能風險。以績效要求為例，我們要求系統的整體績效每分鐘應能處理1000筆資料，如果沒有以WBS來看，我們實在看不出來達到每分鐘處理1000筆資料的風險何在，但如果我們從WBS來看，我們會發覺，影響每分鐘1000筆資料之績效達成的風險，可能會有網路的問題、硬體的問題、資料庫的問題、系統架構的問題、程式設計的問題、甚至於使用者操作習慣的問題等等……。而種種這些項目都將會是專案管理的重要議題，相對於管理規劃、技術規劃、財務規劃、人力資源規劃、風險管理規劃等等納入專案管理計畫書的相對段落中。 http://www.csqa.org.tw/datacenter/Newsletters/datacenter/0002-02.htm ---------------------------------------- 支持小惡魔 BTC : 19tn3RnCuwZVukXAwyhDWZD4uBgUZoGJPx LTC : LTFa17pSvvoe3aU5jbmfcmEpo1xuGa9XeA 知識跟八卦一樣，越多人知道越有價值；知識最好的備份方法，散播！ 藍色小惡魔(林永傑)： 臉書 ---------------------------------------- [編輯文章 1 次, 最後修改： jieh 於 2010/10/13 上午 09:31:23] |
||||
|
