其實我還蠻高興喲哪桑對於我在〈內行人看門道，外行人看熱鬧〉的意見有正面的回應，距離神通高鐵開發團隊，我可能比喲哪桑近了一些，雖然我也沒坐過高鐵，也不屬於高鐵專案成員，但是網路上的言論卻讓我發現，很多人都在不了解狀況下來做評論，這是很危險的。當然，如果立場互換，我的反應可能也會一樣。然而，我觀察到這一點，為文除了自我警愓外，也想藉此做個提醒，有時候我們的觀感可能只是誤解，因為我們沒有看到事情的全貎。
總之，藉由這次事次能認識一個學養豐富又心胸廣闊的朋友，也算是好事一件。喲哪桑說我所引用的參考文獻他也有，真巧！我猜可能是因為我愛看的書和喲哪桑很接近吧，他寫的其它文章一看就知道，呵呵～也是溫伯格書籍的讀者。
看了喲哪桑對我的觀點的感想，我也有一些看法想要表達，於是提出來供大家參考。
喲哪桑所說的 Stakeholder Management 是 PMBOK 第三版新增加的流程－Manage Stakeholder，在 PMBOK 2000 版並沒有這個專案流程。前一版本雖然沒有規範出管理 Stakeholder 的流程，但它卻有提到「專案管理團隊必須識別出 Stakeholder，發掘出他們的需要與期望，然後管理及影響他們的需要與期望以確保專案能夠成功。」，所以管理 Stakeholder 的工作其實是分散在各 Knowledge Areas 的流程中的。而由 PMBOK 第三版把管理 Stakeholder 明顯地寫出來，就知道它的重要性是與日俱增的。
PMBOK 認為識別出 Stakeholder 是格外困難的，到底專案 Stakeholder 是什麼呢？只要是主動參與專案或他們感興趣的事情會對專案的產出或成功有正面或負面的影響的個人或組織。範圍相當廣，不過，當 Stakeholder 的意見衝突時，要以專案的客戶為主，也就是說為了要滿足客戶，其他人的需要及期望都可以被放棄。要在那麼多的不同中找出最接近的解決方案，是專案經理的主要挑戰之一。
以上是管理 Stakeholder 的原理及原則，而實務呢？據我所知，神通大型專案都會管理 Stakeholder，在專案會議中會與客戶討論重大議題並維護 Issue Log，並且會回報給 PMO 以利後續管控。在會議中，專案團隊會與所有 Stakeholder（包括客戶、使用單位及顧問）就議題討論、溝通、協商與談判，如果遇到難題（例如某些 Stakeholder 不肯退讓或專案團隊不該妥協時）會先跟 Stakeholder 保持和諧關係，會議結束後再由專案團隊討論對策後才回覆 Stakeholder，必要時請 PMO 或 Sponsor 出面協調。所以神通在專案管理方面是很重視 Stakeholder Management 的。
其實與 Stakeholder 溝通最怕碰到利益或目標衝突，當大家對專案的看法不一致時，其實很難討論出共識的。如果又碰到客戶自作主張，揣測使用單位的需求，結果開發出來的軟體卻不能滿足他們的需要，需求與設計經歷不斷地翻修，使得開發人員相當痛苦。當然，基於專案的需要應該要求直接和使用單位溝通，然而事實上就是不能如您所願，有時候基於客戶的不信任，他希望從開發團隊口中知道專案團隊的做法，有的客戶是不想讓專案團隊被框限住，有些情況是使用單位很忙，開會都沒時間。不管原因是什麼，就是團隊的「專業」要想辦法解決問題，對這些問題除了提供解決方案外，還必須應付客戶的價值觀與情感因素，因此很多事情並不如表面上看起來那麼簡單。誠如獨孤木的命題：〈stakeholder是誰？〉，答案是很複雜的。
以管理學的角度來看，這就是所謂的代理問題。開發團隊委託客戶取得使用者需求，但客戶所想的是不一樣的東西，結果可能遺漏了一些東西，然後多增加了一些使用者不需要的東西，過程中又出現了資訊不對稱－專案團隊並不知道那些需求才是使用者真正的要的，那問題就大了。代理問題解決之道是要讓委託者與代理者的利益發生相關性，問題才能真正解決，當神通與高鐵變成生命共同體時，代理問題就會被解決，雖然成本很高，但找到路就不怕路途遙。
自動引用通知: 同人的生活派對 » 當下即是威力點
自動引用通知: 同人的生活派對 » 學長對 Stakeholder management 的補充