【大人學】201a 搞定利害關係人所需的職場政治力上課心得
這次是跳級挑戰這門 201a專案管理個案實戰 - 利害關係人與需求管理。 一個專案裡，最重要的是專案的計畫階段，這門課就是講述在專案準備期間，如何把所有利害關係人的需求找出來，並分析它們和放到 WBS 裡的學習。以下是我的上課心得和筆記。
這是我對這門課的塗鴉筆記（Sketch Note）。
Case Study
其實我沒有想過這課和和談判課一樣會有這種燒腦的討論活動，但這次比以往的都學得多。
這次的討論是大家分別飾演公司部門裡的某中一個主管，就著某個議題和其他部門的主管（就是其他同學）討論。大家有各自有的資訊和該角色的價值觀，所以要理解對方的想法是關鍵，而這個和當中要使出甚麼的策略就是我最弱的部份。
以前在上談判課時，雖然由於自己的國語不好，但至少談判時也是三人面對三人的談判，有甚麼事也可以袖手旁觀（心虛）
但是，這次真的就只有一個人在作戰（雖然在準備環節中相同角色的人也會一起討論，但很多都聽不懂）
在討論期間，沒有重點，沒有找自己的支持者是自己做得很差的地方。
討論之後，這次和他們分享大家的策略和心得，這時真的學會比較多的東西。例如要考量對方想的是甚麼、尋找自己的支持者、談判課 中學過的拋出多個議題作交換 / wish want walk、職場大人學 中學過的 TOC衝突圖、甚至 戀愛大人學 中學過的 贏和輸破拖 等等都好像其實能用。
這令我想到以前上課的時候沒有真正把自己學過的東西應用出來，應該說平常沒有機會使用。
另外，由於大家在這類討論中不會完全地支持 / 反對你這個人，但是他們會支持 / 反對你討論的某些議題（多數都是因為和他的利益有關），所以了解到所有要討論的議題是十分重要的一件事。
關於訪問別人的需求
男朋友：今晚要吃什麼？
女朋友：冇所謂啊。
男朋友：那麼吃泰國菜？
女朋友：泰國菜太辣了，不吃。
男朋友：那麼吃日本菜？
女朋友：日本菜太生冷，不吃。
男朋友：那麼你想吃什麼？
女朋友：吃什麼都無所謂啊。
男朋友：（幹！）
這個問題很頭痛是嗎？作為男朋友很想對方能說出心裡的想法，不用在不斷猜對方的需求。
其實，在專案的計畫階段，要獲得各利害關係人的需求也是類似的情況。
有時候對方其實也不知道他要的是甚麼、又或是有些面向是對方真是沒有想到的。所以，我們要問他們的時候，其實要準備將會花很多時間去找出他們冰山下的需求。
其中一個方法就是像以上的例子般，不斷去問一些方案去確認、去驗證、以及激刺對方說出他內裡的需求，這些方案有時甚至可以是一些比較極端的方案來激刺對方說他不要的東西。在這個例子裡，至少我們能知道女朋友這次不吃辣和不生冷的東西。
關於分析別人的需求
在得到不同的利害關係人的對於這個專案的需求後，我們要如何把它們變成專案裡的交付物和限制呢？
我們可以先製造一個表格，這個表格寫下不同人的資料、以及他們份別對這個專案的關切度、它們對這個專案的影響力、以及他們對這個專案的關切議題。
例如如果是一個軟體開發的專案，那麼管理層會關注的是這個軟體能夠如期交付、品質部的高層會關注測試案例的覆蓋面是否充足、而架構師會關注這個軟體的架構是否穩固、是否有足夠彈性去應付人日後的需求等等。
在寫下他們的需求時，我們還要替他們想他們深層的需求是甚麼。例如我們可以以在 職場大人學 裡學過的同理心地圖來分析這個利害關係人想獲得甚麼、以及他害怕失去甚麼。
針對他們的關切議題，我們還要寫下可採取的行動，例如給管理層定期的進度報告等等。
最後，我們要把他們的需求變成專案的限制（例如是時間、範圍和成本）、以及各種的交付和讓各利害關係人安心的報告。
關於界定專案的範圍
我們必須在專案開始前，界定專案的範圍並讓所有利害關係人確認。其中一種做法，就是 專案授權書（Project Charter）。
在專案授權書裡，除了基本資料外（例如時程、資源等），我們特別要寫下核心產出物、專案回報架構、以及專案的三重限制（範圍、時間、成本）那些是相對可動、那些是相對不可動。
另外，在專案開始後，如果因應現實情況令專案的範圍有所改變，我們也要重新給各利害關係人確認。
關於 WBS
就像是設計一份投影片時會先以卡紙畫一個原型給各人確認才去真正以電腦製作投影片一樣，在專案開始前我們要把整個專案的交付物以 樹狀結構 寫下來給各利害關係人確認。而這個交付物的樹狀拆解結構，就是 Work Breakdown Structure（WBS）。
這樣做的好處有幾個：
第一，就是作為一個專案經理，很多時我們並不會懂得整個專案的內容，所以我們可以要求專案裡對某內容比較熟悉的人來寫下這個部份的交付物的內容，並在專案進行的過程中把這個交付物的樹狀內容清單作為驗收標準。
第二，就是我們知道有甚麼交付物後，我們才能進行排程。
第三，這次建立了交付物的拆解樹狀結構後，可能這個拆解的結構能在下次某個專案中作為參考。
第四，有了交付物清單後，我們可以把交付物的進度放在看版裡（例如 Trello），以便視覺化看到進度。
由於 Work Breakdown Structure 的主角是交付物而不是行動，所以它們必須是一個名詞，一個能交付的名詞（例如旅行專案中，其中一個交付物是「酒度住宿券」，而不是「訂購酒店」）
個人也開始嘗試把這個方法放在自己的 TiddlyWiki 裡，有機會可以寫成文章分享。
關於需求變動
課上也提到了需求變動這個很常見的情況可以怎麼辦。
第一個就是使用 敏捷，當然敏捷這帖藥不是任何人都能吃，光是要令管理層明白這是甚麼，並得到他們支持並推動這個制度已經是一大難關了。
第二個就是視覺化協商。例如我們能在專案排程軟體（例如 Microsoft Project）等看到問題，我們可以以軟體上的視覺資料和各利害關係人協商，到底要令專案繼續順利進行，到底要如何在範圍、時間 和 資源裡調整呢？
內心 OS: 個人大推這門課。
大人學筆記系列：
如果你覺得這個內容有用，不妨分享給你的朋友。
這是我的 Facebook、Twitter、Instagram 和 Threads，有興趣的話歡迎 Follow。
如果你認為我的文章有幫助，歡迎 請我喝一杯咖啡。