自己回顧起來，專案生涯中最輕鬆的一段，應該是我剛畢業時參與的案子，也就是高鐵台中段的建造案。

輕鬆的原因主要是因為當時的工作非常單純。

所謂單純並非指專案好做。 工程建築案一樣有其技術上複雜之處，但好處在於工程專案的「需求」往往都很清楚且具體。 這是因為土木工程界對於專案管理這檔事情概念已經較成熟，各承包商或是業主對於本身分工很清楚，合約執行上也都很明確。 若自己不設計只是負責施工的，別人會把施工圖交給你；就算有包含設計，需求也多是一開始就談定的，照著規範與業主要求，都不致於會出現奇怪的結果。

所以大部分的事情只要秉持著「照合約」、「照圖施作」等基本原則，幾乎不會出甚麼大問題。 反正有爭議，大家就拿原始合約或是設計圖、施工圖出來對照。 原來怎麼寫、怎麼畫，事情就該怎麼作。 若有一方想改，那要怎麼改，要加多少錢，都可以此角度展開談判。 所以事情其實很有規則可以遵循。 對第一份工作的我而言，指令明確下，自已就很清楚每天要該幹嘛。

再加上當時的自己也真只是案子中的小螺絲釘。 只需要顧好我的工作即可，老闆拿不拿的到錢、或變更能否弭補過來，老實說其實也不這麼跟我相關(笑)。 反正別人提的東西要做不做很簡單，就看設計圖、施工圖上有沒有？ 不然看合約有沒有(因為可能是合約有要求但漏設計)？ 政府的法規有沒有(也可能是法規有限制，可是設計錯了)。 都沒有？ 那就抱歉，你的要求我無法做。 你有意見，請找我們的法務或是找更高層的老闆談吧！

所以回想起來，那真是輕鬆的一段日子。

可惜呢，之後無論是軟體案、是顧問案、或是一些組織內部的開發或系統導入專案，都再也沒這麼簡單過了。 尤其之後我除了當PM外，可能還得兼作Pre-sale、甚至當送貨小弟，往往案子結束還要負責去收帳，自然更沒辦法只是照章行事把手邊的事情做好就好。 因為若只是「照章行事」，要不就是搞砸案子，要不就是弄壞了客戶關係。

這也是後來我讀到PMBOK(Project Management Body of Knowledge)中關於Stakeholder Management(利害關係人管理)時，特別感覺心有戚戚焉的緣故。 因為專案是否能順利結案，其中一個關鍵就在於PM是否有把利害關係人的需求與憂慮都妥善照顧好。

像我剛開始做軟體或是顧問案時，也是沿用過去的經驗。 想說只要先跟客戶談妥需求，彼此簽了約就沒事啦。 之後有甚麼問題，大家就拿合約出來吧；反正合約跟需求都有白紙黑字的簽名畫押，一切跟原條文不符合的，大家就來談加錢或是工期展延。 如此將簡單、清楚、又明白。

但這樣幾次之後，我很快的就驚覺這類「白紙黑字」的動作其實未必是最好用的。 當然，也不完全沒用，可是比較是當成面對最壞打算才用到的手段。 如果兩方真的鬧得很不愉快、必須要上法院時，有清楚的合約定義絕對是可以自我保護。 但大部分時間，你通常不會打算跟客戶鬧上法院，那這類文件對於「專案的順利推動」，幫助就沒一開始想像的那麼大了。

因為呢，簽名畫押是一回事，但更多的往往是簽字以外的東西。

甚至經驗多了後發現，一開始要客戶在需求描述上簽名其實並沒想像這麼難。 這是因為客人會找你來，就是因為他自己不懂。 而他不懂，就會把很多事情想得很簡單、不然就是想得很美好；甚至，他想的根本是錯的。

舉例而言，很多客戶常常會誤把管理問題想成是程式問題，會覺得說，「嗯，若我們來整合這兩個系統，那我的管理問題都可以消失於無形啦。」

但我的認知可能會覺得，「喔，你只是想我們整合兩個系統，並讓資料可以交換？」這簡單嘛。 於是需求裡頭寫的都是哪些資料要能交換，我認為這是結案的關鍵，可是客戶只覺得是些技術細節沒興趣細看，於是就把需求單簽名認可了。

可是呢，一旦等東西做出來、客人真的開始有機會使用後，他才真正開始理解當初簽了甚麼鬼東西。 這時候他才會告訴你：「你做的並不是我要的啊」。 我要是拿出當初簽的白紙黑字說，『明明這些都是當時你同意的不是嗎？』 客戶通常會回說：「我當時確實是這樣講，可是我以為這是甚麼甚麼意思啊」。 客戶也通常會再加這麼一句：「我以為你們比較專業，會能自然的了解我是要甚麼啊。」 然後就因為這種認知不同，開始有著冗長的討論、爭辯、甚至吵鬧。 吵到最後，或許能收到錢，但生意也可能就做這麼一次了。

另外，那些沒有外部業主的開發專案更是如此。 公司內部的案子自然不會有合約、也不會有業主這樣的角色。 可是若沒有合約為基準，不管你今天怎麼樣的計畫、規則、執行方式、甚至專案目標都有人會有不同的看法。 更慘的是，每個人的意見其實都有些他的價值在。 今天若需求都是胡說八道那還真簡單，最慘的就是每個人的意見都有道理。 A說功能少一些好，為能早點做完上市場；B要求功能多一點也沒錯，因為便宜又大碗才能吸引消費者。 (PS這也是為何要有Charter的原因)

在這種情境下，寫一個需求框架很辛苦，要讓大家按此簽名畫押更辛苦。 甚至呢，就算所有人簽了需求後一樣不代表之後可以無後顧之憂的埋頭苦幹了。 做為PM或案子的負責人，還是得隨時空出一隻耳朵隨時聽著不同的聲音；這是因為經營情勢會變、而這可能直接的影響到那張幾個月前大家還看似理想的需求單。

比方說，一間公司可能原來說要寫一隻程式來解決對外文具採購的詢價事宜，讓供應商可以上網填寫公司資訊、甚至告知有哪些產品。 但程式開發可是曠日廢時的，有時候開發個三五個月下，原單位自己買了別的工具解決，或是原單位自己換了別的作法(比方固定只跟一間文具通路公司採購)。

這時候程式不需要了，就算最後交付出來的專案成果確有符合一開始簽字的原始需求，也不表示這東西現在還能「繼續符合使用者的需要」。 也因此使用者可能抱怨、使用單位也可能不願意接手、不願意使用，更可能影響老闆或是其他人對於專案成敗「觀感上」的定義 → 你覺得成功了，因為有符合當初白紙黑字的承諾；可是老闆甚至周圍所有人都認為這案子是失敗了，因為做出來一個完全無用的東西。

這就是這類情境下尷尬之處啦。 不能只是埋首苦幹，而是要不斷的去探測Stakeholder的心意，而且隨時考量專案是否要做某些變動、甚至提議中止。

但這也不是叫你隨波逐流，隨時調整專案範疇。 因為若你把範疇控制得太鬆，A君要加新功能你點頭、B君要調整方向你也OK、C君想改變架構你也答應，當甚麼都往裡頭丟下，又可能因為範疇潛變(Scope Creep)而把案子變成一個完全匪夷所思的架構，或是讓案子最後難以收尾。

控制得太嚴，可能你完成專案卻沒打中靶心；控制得太鬆，則很可能讓你難以收尾。 所以平衡變成是很重要的一個關鍵，一方面要談定需求、但也要保持某種彈性，避免不該進來的東西進來。 這時候，尺度的拿捏、談判的能力、以及交換的概念就得很清楚。 更重要的是，一但查覺不對勁時，自己「主動」就要先去詢問並了解到底是怎麼一回事，然後來思考是否有調整與交換的空間。

這也是專案金三角為何這麼重要。 因為惟有時時把這東西放在腦中，才知道「可否交換」以及「如何交換」。 那這部分一系列以來已經訴說多次，這裡也不再贅言。 只簡單的講說，若是有合約的發包案，因為時間大體都不能動、預算也多已鎖死，所以範疇增加幾乎都意味著要客戶承諾增加合約金額與時間。

可是一旦不是這種類型的案子，比方說前面講說為內部開發個文具採購系統。 因為是內部要用、時間可能很彈性；今年出來很好，明年出來好像也沒差。 預算常常可能也很有空間可以談。 也因此，範疇很難強硬的鎖死不動(但不表示你不用把它鎖死)。 畢竟在這種專案結構下，你必須要最終使用者真的覺得好用，才有辦法驗收。 但偏偏一開始大家常常很多細節沒想好，或是使用者根本不是軟體專業，想像一堆功能但實際根本無法用或是不會用。 所以，過程中PM就得花最多時間在幫忙收斂需求，而這是這類專案中得花最多時間專注之處(換言之，不同專案的管理重點其實往往會不同)。 再附帶一提，這其實也是變更控制(Change Control)的一環。 有些PM誤以為變更控制就只是記錄變動或是Lock住變動，但這其實是完全錯誤的認知。 讓變動在「被控制的狀態」下發生，這才是變更控制的核心概念。

就像我前幾篇提到，專案就像牧羊一樣。 開始適度放鬆，但是逐漸縮緊，確保最後真的可以被執行。 這也是為何一些複雜的開發案，前面需求確定的階段其實最花時間。 甚至會花一堆時間談跟專案執行無關的部分。

比方說，軟體系統的開發案，一開始根本不該談功能，而要先談大家平常怎麼做事，以及為何要做這些事情。 我們需要廠商提供哪些資訊，又為何要這些資訊。 這些事情是真的透過系統處理方便，還是人手處理方便；是電腦判斷容易，還是有太多例外需要人為判斷。 這些都講清楚了，Business Process都搞通了，才來訂軟體的需求與功能，才來談使用者介面這類事情。

進行中，除非有特別的狀況 Business Process可能不能再大改(明明是廠商來填資訊，不會變成送資訊給廠商)，但功能或是使用者介面搞不好還會有些微調。 當然，甚至Business Process也都有可能改，因為公司組織架構或是工作流程可能根本變了。 文具採購的工作全部外包到通路商進行了，也不需要不同廠商逐項報價，那這系統的核心功能，甚至存廢問題都該討論。

這是PM該去關注的焦點，也是定期該主動拿出來討論的問題。

但看到這裡的讀者，請也不要誤會我的意思。 我並不是說你不要去談定需求，也不是說需求不該lock-down，PM能簽下Scope Statement還是很重要的一個步驟。 只是我要強調的是，大家千萬不要「過份迷信」白紙黑字這種東西。 因為最後的成果認定，有與沒有有時候是很直觀與情緒性的(就算你能量化也是一樣)。 就算簽了名，你還是得「主動的去時時探查」到底大家意向是否還是如當初一樣；還是因為時間產生了新的需要。 除了白紙黑字的簽名外，「政治層面的觀感」一樣是PM需要關注的重點。

否則，或許最後你的老闆或是其他利害關係人會因為白紙黑字而不能找你麻煩，但是對於做出一個沒意義的東西這件事情，他也絕對不可能給予你甚麼很高的評價。 或許「官方定義上」你的案子是成功的，但長此下來，對個人職涯發展並不會有甚麼正面幫助。

所以，Stakeholder Management的第一課，就在於需求的確保其實是專案從頭到尾都要「一直持續」做的事情。 千萬不要以為取得需求的簽核就以為從此可以高枕無憂。 除非你是對外的合約，不然這真的只有在極少數的情況下才成立的。

也因此，所有專案的負責人，希望能小心注意並以此共勉之。

PS 為了讓匆匆瀏覽文章的讀者也能快速掌握文章精髓，特別在文末加上「文章的關鍵句」。 希望讓大家能更容易吸收與理解。
- Charter與合約能降低變異、提高共識，但不保證共識能永不改變。
- 白紙黑字有必要，但不表示拿到就能高枕無憂。
- 察覺情勢有變時，PM得主動探詢、了解現況，並判斷下一步該幹麻。
- 變更控制的關鍵也在於主動探詢，並讓變動在控制下發生。
- 需求確認是需要在專案過程中一直持續做的。