本節書摘來異步社區《嵌入式系統開發之道——菜鳥成長日志與項目經理的私房菜》一書中的第2章，第2.4節，作者：邱毅凌，更多章節內容可以訪問云棲社區“異步社區”公眾號查看

02-04項目范圍（Scope）管理

嵌入式系統開發之道——菜鳥成長日志與項目經理的私房菜

剛剛我們已經強調了，必須盡量在項目初期排除不確定性，否則，越在項目前期犯的錯誤，對項目成敗的影響就越大。在此我們看到了一個驚人的數據—68倍！前期的分析與規劃工作做得越仔細，后期出現‘驚喜’的機會就越低。雖然所有人都了解這個道理，但往往都過份低估了項目獨特性可能帶來的影響。

有相關經驗的工程人員，常會認為同質性高的項目沒什么了不起，沒必要做太多規劃工作，做就對了！等到項目后期才發現，新項目和以前做過的項目還是有些差異，此時已完成的系統架構已經無法容納這個差異，最后只能投入更多的時間或人力，進行架構性的改變。

這就是68倍的由來。過度輕視項目的困難度、走一步算一步的工作方式，最嚴重的往往是：根本不知道項目的真正目標（通常是自以為知道，但其實對細節完全不清楚），就直接往錯誤方向硬干，做越久，偏差越大，最后想要拉回來更是難上加難！

所以PMP知識體系告訴我們，當項目啟動后，首先就是要花時間做好項目的范圍管理，唯有定義出正確的范圍（Scope），之后做的進度、成本和人力計劃才是有意義的。

所謂項目范圍除了包含該做的項目，也要弄清楚不該做的工作，兩者同樣重要。項目團隊的人力、時間與預算都是有限的，沒有理由對項目范圍不加限制，任由工程師天馬行空的按照自己的想法去做。在項目管理的思想中，這絕對是缺乏紀律的行為，稱為鍍金（Gold Plating）或范圍蔓延（Scope Creep），這都是應該要盡力防止的事情。

從幻燈片的流程圖中可以看出，需求分析也是個循序漸進、不斷修正的工作，甚至經常發生已經到了項目執行階段，客戶才要求更動規格的事。此時，項目計劃既已完成，就應該執行變更管理流程，在新計劃中適時反應項目范圍變化所帶來的影響。

范圍管理有兩項重要的工具，一項是我們現在要談的工作分解結構（Work Breakdown Structure，WBS），另一項則是變更管理。

在評估工作量時，有個人人皆知的簡單概念：事情越大越復雜，越不容易估計準確。因為這樣很容易就會忽略一些重要的細節，所以人們早就知道由繁化簡的道理，并將其應用到項目范圍管理中。簡單來說，就是將一件復雜的工作，切割成許多較容易執行的小工作，假使這些小工作還是太復雜，就繼續切割，并反復遞歸地執行這項分割工作，直到我們有把握評估每件小工作的特性為止。

舉例來說，最初的項目范圍可能只是一句話：開發一臺多媒體播放器。誰也沒辦法由此精確估計出Schedule、Cost等項目特性，所以必須繼續將開發工作切分為軟件、硬件、結構、生產，然后再為每個項目繼續分割，可能會得到：選擇MP3譯碼IC、系統架構設計、實現電源管理模塊、準備備料計劃等較可掌握的小型工作。

工作分割最終會長成一個樹狀結構，根（Root）為項目目標，樹葉（Leaf）則為許多小工作，這個樹狀結構即稱之為WBS。至于工作要切割到多細才合理呢？如果切割太細，則項目范圍分析時難免會觸碰到太多技術細節，一旦工作項目太多，會使得項目計劃過于復雜，而且容易扼殺工程人員的創意空間；如果切割太粗，則項目計劃就會有評估不準的風險。

對此PMP給出了建議：WBS最底層的工作（Leaf）要非常具體，不容模棱兩可，而且至少必須切割到約一周或40個工作小時的工作量—這是一項經驗值，這種工作量的工作，用于評估不至于產生太大的誤差，且工程人員仍保有足夠的發揮空間。

制定WBS是項目規劃階段最重要的工作，除了將項目目標切割為項目計劃中的基本單位外，更重要的是，在制定WBS的過程中，我們可以過濾出所有規格、管理與技術上的盲點，并在項目初期盡快理清所有不明確之處。

就算從沒聽過PMP或WBS，一般人在解決問題時也都會自然地將其切割為許多小問題，然后逐一尋求解決方案。WBS的思想很靠直覺，大部分項目都知道要按此思想做事，但并未真正把WBS畫出來。所謂沒圖沒真相，我們就無法對WBS的合理性做嚴謹的review，而且在擬定計劃時，很容易就會忽略某些工作項目。

記錄WBS的方法有很多種，我會建議使用Microsoft Project來做（要用Excel來記錄也無妨，但在制定項目計劃時，還是得復制到項目管理工具上）。

WBS有兩種描述方式，一個是圖表法（如幻燈片的左半部），優點是一目了然，但當項目工作較為復雜時，這樣的圖難免顯得雜亂，且較難以工具進行處理。所以通常我們會用另外一描述方法—在紙上畫出樹狀結構草稿，然后使用如幻燈片右半部的列表來做管理。

在進行任務分解時，由上至下的標準必須一致，否則，當項目較復雜時，很容易因為任務分割標準不一，導致任務重復。一般使用的任務分解方法如下。

按照子功能分割
按照系統架構
按照項目生命周期
參考以往類似性質的項目
初版WBS完成后，一定要經過相當嚴謹的檢查與公開review。再強調一次，如果WBS有問題，之后進行的Schedule、成本（Cost）、人力資源（Human Resource）等評估都會跟著出問題。

WBS其實就是項目的Scope Baseline（基線或基準），它除了描述本項目中所有必須執行的工作之外，同時也說明不在WBS中的工作，都是沒必要執行的！有時候，后者反而是容易被忽略的思想，項目主管放任工程人員執行了半天似乎與本項目有關卻不屬于項目目標范圍內的工作，這樣的行為對項目來說都是非常不利的！

項目有一個重要的特性—必須先做‘對’，行有余力才做‘好’。嵌入式系統產品開發項目更是如此，客戶要你做低價位的MP3播放器，你卻做了一個可以播MP3的智能型手機給它，你說客戶該哭還是該笑？

總之，WBS絕對是項目計劃的基礎，如果連要做什么都不知道，項目運行宛如瞎子摸象，要順利結項只能靠老天保佑了。

接下來，我們將談談項目范圍管理的第二項重點—變更管理1。

變更管理是在項目談行階段用來處理項目計劃與實際狀況有落差的情況。如幻燈片中的流程圖所示，項目在執行時，追蹤與監控工作必須同步運行，一旦發現計劃與實際狀況不符，或客戶提出規格更改要求時，就必須提出變更需求。

在變更處理流程中，相關人會評估接受此變更的影響。還記得我們前面說的項目鐵三角嗎？某一邊的更動，勢必要影響其他的兩個邊。如果這個變更真的輕微到不會對項目其他的面造成影響，那我們也沒必要為此擔心。一旦某項變更會嚴重影響進度或需要增加成本，則必須所有關系人（例如：PM、公司高層、客戶代表等）討論同意后才能接受此變更，并將所造成的影響全部照實Update到計劃書中。假使項目關系人無法接受變更帶來的負面效果，就只能放棄此變更，或請工程人員另覓他法。

無論如何，我們不能放任一個已知的問題在項目中，而不去處理！

對項目來說，變更宛如萬惡根源，是很負面的字眼，也是項目經理的夢魘。變更可能會對項目的正常進展帶來無盡的麻煩，但奇怪的是，幾乎沒有項目不會碰到變更。特別是電子產品開發項目，電子產品的生命周期短、開發復雜度高，有時真的就是計劃趕不上變化，當客戶說出‘若不改規格就不用賣了’時，身為伙伴的我們不配合也不行。

面對這種狀況，流著眼淚、帶著微笑地接受絕對不是最好的處理之道，這只是讓沖突點延遲爆發而已。最好的方法應該是如上所述，召集所有關系人，大家一起審視原先擬妥的計劃書，共同面對問題，以尋求解決的方法，讓RD加班只是方法之一，縮減規格、增加預算或時間，甚至放棄變更都可以拿出來討論。

面對變更需求絕對不能慌亂，務必使變更在受控制的前提下對項目產生影響，千萬不可任其隨意變化。項目經理一定要把持一個鐵的原則—因為變更會影響項目進行，因此，所有的變更一定要經過CCB（Change Control Board，變更管理委員會，即與此變更有關的關系人參與決策的會談）的同意，并造出新的計劃書，而工程人員只需隨時按照最新版本的計劃執行即可，嚴格禁止接受客戶私下變更規格的請托。

實際上，我們會把變更處理流程制定的越簡單越好，并鼓勵員工一旦發現任何計劃與實際狀況有落差時，馬上向主管報告，若連主管也無法處理時，則提出變更需求。項目經理會視狀況召集需要參加CCB的項目關系人，變更審查時必須謹慎，必要時，一定要深入進行技術的review。

項目團隊存在的目的只有一個，就是讓該項目順利結項，假使發現某項變更請求可能會使項目出現大問題，也應將此突發事件視為當前最高優先級的工作，項目經理必須盡力協調，務必要將其處理妥當，直到造出新計劃為止。否則，放任項目繼續執行下去并無任何意義！