編輯導語：本篇文章作者系統地從多個方面講解了如何管理干系人，分別從干系人的概念、識別、分析、管理以及綜合案例展開講述，希望對你有幫助。

請你思考一下，下面這個失敗的項目，主要是誰的錯？

甲方派一個副總經理全權主持項目，乙方負責項目的開發與實施。

在項目一開始，乙方嚴格按照甲方副總經理提的需求編寫需求規格說明、制作系統原型，與客戶開了 20 多次會議。

到乙方交付第一個版本時，在驗收會上，從來沒見過的甲方總經理出現了，說“我們要的不是這個，而是XXX”。

乙方拿出會議紀要，甲方總經理又來一句：“唉，是副總沒搞清楚”。

這個項目的結果是乙方終止此項目，幸好預付款可以勉強支付第一階段的成本。

對此甲方還很不爽，還要起訴乙方。

如果你認為項目失敗的原因是甲方的錯，請你記?。?/p>

當你作為乙方沒有實力挑選甲方的時候，“甲方永遠是對的”。

作為乙方，如果不從乙方自身找原因、提升自己，下次做這種項目同樣可能導致項目失敗。

在這個項目中，乙方存在的問題是沒有管理好干系人。

甲方讓副總經理“全權”主持項目，乙方就誤以為副總經理是最大的干系人，而忽視了總經理，沒有找總經理調研需求。

在項目的關鍵節點沒有及時跟總經理溝通確認，結果項目成果最終被總經理一票否決了。

做一個B端項目往往會涉及到很多干系人，管理干系人是保證B端項目成功的重要任務。

做一個C端產品也不能忽視干系人管理，特別是合規檢查員（財務、法務、審計、行業監管部門等）。

很多做P2P的金融公司、教育培訓公司遇到危機都是因為行業政策的影響。

本文將結合華為的案例，與你分享如下幾點：

一、重新認識干系人

干系人的概念很早在項目管理領域就有了。

我們先來看一下項目干系人在PMBOK（項目管理知識體系）中的定義：能影響項目、項目集或項目組合的決策、活動或成果的個人、群體或組織，以及會受或自認為會受它們的決策、活動或成果影響的個人、群體或組織。

我從產品的視角來重新定義“產品干系人”：影響產品成敗的個人或組織。

因為我們做干系人管理的目標是促進產品成功，所以我們更關心影響產品成敗的個人或組織，而不是受影響的個人或組織。

就像《三體》說的“毀滅你，與你無關”。

我們把關注點聚焦于“影響產品成敗的個人或組織”，有助于后續識別干系人、分析干系人、管理干系人。

干系人有多種叫法：項目相關方、涉眾、利益相關者。

這些叫法都不夠直觀，干系人的英文單詞是Stakeholder，這個英文單詞的字面意思“籌碼持有人”更能體現干系人的本質。

做一個項目涉及到多方利益的博弈，Stakeholder就是項目博弈中的籌碼持有者，誰的籌碼多誰就有更大的影響力與話語權。

Stakeholder（籌碼持有人）是干系人概念的本質，抓住這個本質，有助于區分干系人的優先級。

在多方需求有矛盾沖突的時候，你就知道以誰的需求為主了。

二、干系人識別

在項目的早期階段就要識別干系人。

我們可以從“影響產品成敗的因素”來識別干系人。

有個工具“影響地圖”推薦給你。

1. 影響地圖

影響地圖是《Impac Mappping》一書中提出的，形式如下圖所示，通過“Why→Who→How→What” 四個層次的分析法。

以結構化的形式顯示，將業務目標（Why）、角色（Who）、影響（How）、產品功能（What）之間建立關聯，讓團隊清晰地看到：

• 對什么人產生什么樣的影響可以幫助實現目標；
• 提供什么樣的產品功能（或服務、運營手段）才能產生這樣的影響。

影響地圖的四個層次分別表示：

1. Why（目標）：要搞清楚業務目標、為什么研發這個產品？
2. Who（角色）：想要實現這個目標，哪些角色會影響目標的實現？
3. How（影響）：這些角色是如何對目標產生影響？是幫助還妨礙？
4. What（什么）：我們可以做什么來支持這些影響的實現？可以是產品功能、活動運營、內容交付、服務等。

我們來看兩個影響地圖的經典案例：

案例一：

案例二：

前面提到，可以從“影響產品成敗的因素”來識別干系人。

聰明的你已經看出來了，影響地圖中的“Who”就是影響項目成敗的干系人。

所以，可以用影響地圖這個工具來幫助我們識別干系人。

2. 干系人檢查清單

有些干系人很容易識別，如客戶、發起人、老板、最終用戶等，有些干系人很容易被忽視，比如：合規檢查員。

忽視重要的干系人會導致項目的失敗，我們可以通過干系人檢查清單來避免遺漏干系人。

組織內部（乙方）的干系人檢查清單：

組織外部的干系人檢查清單：

以上羅列的干系人檢查清單未必全面，不一定都適合你的項目，請根據你的項目特點進行調整、裁剪。

在干系人識別階段，可以先通過團隊頭腦風暴、訪談已知干系人、影響地圖來梳理干系人，再利用檢查清單避免遺漏。

3. 案例

下圖是乙方給某銀行做的網銀系統項目的干系人管理表（部分），把識別到的干系人填寫到表格中。

三、干系人分析

識別出干系人之后，接下來要進行調研，收集干系人的信息，包括干系人的基本信息、痛點、利益點、需求、期望、價值觀，甚至他們的隱性需求。

然后分析每個干系人對項目的影響力、對項目的關注程度。

在干系人很多的情況下，還要對干系人進行分類、排優先級，以便制定管理策略。

1. 干系人地圖

當干系人眾多的情況下（特別是B端項目），可以用干系人地圖進行分類。

干系人地圖根據權力/影響力（籌碼數量）、興趣/利益（對項目的關注度）兩個維度進行分類、排優先級。

序號代表干系人的優先級。如圖所示：

在分析干系人的權力/影響力時，華為公司做B端項目銷售的一個實踐做法可以借鑒：梳理B端項目決策鏈的關鍵環節，找出每個環節的主導者、參與者，各個擊破。

2. 挖掘隱形需求

在分析干系人的需求時，通過訪談、問卷、焦點小組等方法獲得的需求往往是顯性需求，還有一些隱形需求是干系人很關心但沒有告訴你的需求，如圖所示：

要挖掘隱性需求，要區分兩種情況：

1）干系人因能力所限，無法表達出隱性需求

• 只說方案不說目的：用Y模型、5Why分析法深入挖掘需求；
• 需求描述不全：用PSPS模型還原需求；
• 沒想到的細節需求：用場景分析法補充細節需求。

2）干系人有所顧慮，不愿說出隱形需求

• 觀察反常細節：事出反常必有妖，從反常細節挖掘真相；
• 對人性心理的深刻洞察：用同理心代入；
• 結構屬性分析：屁股決定腦袋，從干系人所處位置推測其關注點，比如：新官上任三把火，而快退休的領導往往求穩；
• 動向分析：從甲方公司戰略變化、政策調整、近期負面消息推測干系人的關注點。

3. 阻力點分析

不要小看你做的產品，你做的產品對甲方來說是一場數字化變革，現在講的數字化轉型對企業也是一場變革。

任何一場變革都會帶來利益的重新分配。有人得意，就會有人失意。

失意的人會抗拒變革，抵制你的產品，甚至把怒氣撒在你身上。

不是因為他不喜歡你，而是因為他覺得他的利益是因為你的產品而受到了損害。

這樣就會導致你的產品推進不順利、甚至失敗。

所以，我們非常有必要去分析阻力點。

凡事興一利必有一弊。一個新系統上線，有人受益，可能就有人利益受損。

比如：責任增加？權力變??？工作量增加？收入減少？

例如：很多老舊小區沒有電梯，政府推出惠民工程，給老舊小區補貼加裝電梯。

但很多小區都推進不順利，搞了幾年還沒裝上電梯。

這背后的原因不難理解，就是因為低樓層住戶的反對，因為他們的利益受影響。

所以低樓層住戶就是加裝電梯項目的阻力點。

我了解到一些成功加裝電梯的小區是這么搞定阻力點：高樓層住戶湊錢補貼低樓層住戶。

再強調一次：變革的本質，就是利益的重新分配。

發現阻力點后，在干系人管理環節要對阻力點進行管理，盡量減少阻力點對項目結果產生負面影響。

4. 案例

繼續前面網銀系統項目的干系人分析，通過調研得到干系人簡介、需求、期望等信息，填寫到干系人管理表中。如下圖：

請你思考一下，這個項目的阻力點是什么？哪些干系人可能反對這個項目？

四、干系人管理

做完干系人分析之后，要評估關鍵干系人對不同情況可能做出的反應或應對，以便策劃如何對他們施加影響，得到他們的支持，減輕他們的潛在負面影響。

也就是說：把朋友搞得多多的，把敵人搞得少少的。

1. 干系人地圖

在干系人分析時，我們用干系人地圖對干系人進行分類、排優先級，然后我們可以對干系人地圖中不同象限的干系人采用不同的策略（如圖所示）：

• 第1象限的干系人優先級最高，策略是重點管理，他們的需求優先級最高，要及時跟他們溝通匯報；
• 第2象限的干系人的需求要盡量滿足，爭取得到他們的支持，避免他們成為阻力點；
• 第3象限的干系人保持溝通，盡量拉攏，使他們在項目中受益；
• 第4象限的干系人監控動態，避免成為阻力點。

乙方在做B端項目時，經常會遇到一個困惑：

甲方大老板的權力/影響力很大，那我們做項目時是不是都要跟甲方大老板確認？

有人說項目的關鍵里程碑都要跟大老板確認。

其實這要看情況，你做一個預算很小的項目去找大老板確認，人家肯定不理你。

那什么情況下要去找甲方大老板確認？

取決于這個大老板在干系人地圖的第1象限還是第2象限，也就是說，要看他對項目的“興趣/利益”大不大。

如下三種情況，甲方大老板對項目會比較關注，應該把他放在干系人地圖的第1象限，建議你要盡早跟大老板確認，不要等項目驗收會才見到大老板。

1. 甲方大老板是項目的發起人
2. 這個項目是甲方的戰略項目
3. 這個項目的預算特別大

接下來，以華為的實踐為例，看華為是如何管理干系人。

華為很重視在客戶中發展Coach（線人，支持者），不同角色的客戶對項目有不同的促進作用：

華為針對B端項目中優先級高的干系人，有7種武器，如圖所示：

華為搞定B端客戶的7種武器，具體做法如下圖所示：

2. 甲方的類型及應對策略

做B端項目要經常跟甲方打交道，會遇到各種各樣的甲方。

可以按照“配合度”、“專業度”這兩個維度把甲方分為四種類型，如下圖所示：

1. 頭狼型：這種甲方的專業度高，不僅是業務專家，也懂信息化、數字化；配合度高，只要乙方說的有道理、有助于目標達成，他都愿意配合；
2. 貓頭鷹型：這種甲方很專業，但配合度不高，很強勢，口頭禪是“我不要你覺得，我要我覺得！”
3. 綿羊型：態度很友好，配合度高，但不專業，提需求時零零碎碎、不完整，甚至提的很多需求是偽需求；
4. 鬼見愁型：專業度低，不懂裝懂；趾高氣揚，脾氣暴躁，不把乙方當人看，經常當眾訓斥乙方。

以上四種類型的甲方不能統一對待，應該用不同的應對策略，如下圖所示。

1. 頭狼型：這種甲方是專家，忽悠不了他，如果乙方不專業的話很容易就被發現，會被換掉。乙方要提升自己的專業性。這種甲方很難得，跟他合作的項目成功率很高，也可以從他身上學到很多。跟他協作的時候要定原則、樹邊界，避免沖突；
2. 貓頭鷹型：這種甲方要統一戰線，盡量拉攏。用項目成功對他的潛在收益、項目失敗對他個人的風險來引導他合作。實在不行的話找他領導來協調：借天使之力，讓魔鬼閉嘴；
3. 綿羊型：這種甲方要小心，別被他誤導，因為他不專業，提的需求可能是偽需求。要注意挖掘需求，積極引導；
4. 鬼見愁型：這種甲方只能嘗試溝通，實在不行的話只能祝你好運了。

3. 如何管理甲方的期望值

有個小故事：

小學班上數學老師在公布考試成績，小明考了61分，數學老師大大表揚了他。小王考了81分，但是被數學老師批評了。

你應該猜到原因了：

小明是學渣，第一次考試及格，超過老師的預期，所以被老師表揚。

而小王是學霸，平時成績很好，這次成績遠遠低于老師預期，所以被老師批評。

你的項目成果能否讓甲方滿意，不僅取決于項目成果本身做得好不好，還取決于甲方的期望值。

要讓甲方滿意，除了盡力把項目做好，還要注意管理甲方的期望值。

如何管理甲方的期望值呢？接下來分享幾點建議：

1. 謹慎承諾：你的一個不經意的口頭承諾，甲方可能都記在心理，有了預期。如果沒做到的話甲方就不滿意；
2. 面面俱到，不如單點極致：資源有限，無法面面俱到、各個方面都做到極致?？梢园延邢薜馁Y源集中在甲方重視的焦點上做到極致，其他方面不拉胯、達到及格線就行了；
3. 及時通報，過程透明化：注意在項目的進展過程中跟重要干系人定期保持溝通，有問題及時通報，有風險要及時給甲方打預防針。不要憋大招想給甲方一個驚喜，最后變成驚嚇；
4. “整體規劃、分步實施、持續優化”：這是信息化項目中經常給甲方灌輸的一個理念，降低甲方想“一步到位”的預期。

企業變革績效曲線：如下圖所示。

前面提到，你做的產品對甲方來說是一場數字化變革，企業數字化轉型對企業就是一場變革。

變革不是立竿見影馬上就可以見到效果。

變革要經歷一個艱難的磨合期，這期間的績效水平反而比變革前更低，而甲方的期望往往是變革后可以立馬見到效果。

這樣就會造成很大的期望落差，甲方看到績效水平越來越差，開始質疑項目沒做好，甚至會放棄項目。

可以說，乙方在變革的磨合期壓力是巨大的，乙方如果不能管理好甲方的期望值，可能項目都撐不過黎明前的黑暗。

怎么辦？

建議你把企業變革績效曲線在項目上線前提前給甲方看，讓甲方對變革過程有個正確的認識，建立起合理的預期。

4. 案例

繼續前面網銀系統項目的案例，在干系人分析后，根據各類干系人的特點做出應對措施，如下圖所示。

五、干系人管理綜合案例

接下來通過一個干系人管理的綜合案例，來貫穿干系人管理的幾個環節。

1. 項目背景

某IT上市公司有大型產品研發團隊，主要開發游戲、應用軟件。

常有骨干被高薪挖走，造成經驗的流失。

團隊中新人較多，難以快速上手，造成研發效率低下。

CEO在EMBA班上聽說了知識管理，覺得是個機會，于是打算在公司開展知識管理，并計劃開發一個知識管理系統供內部使用。

2. 干系人識別

因為知識管理系統是在企業內部使用的，所以通過企業的組織架構圖來初步識別干系人：

并通過訪談現有的干系人，來發現新的干系人：

3. 干系人分析

對關鍵的干系人進行調研、分析，了解他們的需求、期望，并有意識地做阻力點分析。

對干系人分類調研，不同的干系人問不同的問題：

對關鍵干系人準備訪談提綱，安排一對一訪談：

對調研的結果進行整理分析，填寫到如下表格中：

用干系人地圖對干系人進行分類、排優先級：

4. 干系人管理

應用干系人地圖，對干系人采用不同的策略進行分類管理：

對干系人提的需求進行需求分析，得到功能需求：

六、小結

有效的干系人管理是項目成功的重要保證。

C端產品的干系人管理要特別注意監管機構。

B端項目的干系人相對C端產品而言更加復雜多樣，所以本文舉的例子主要是B端項目的案例。

還需要注意的是，干系人分析不是一次性任務。

因為隨著項目的進展，干系人的權力、對項目的態度、優先級可能會發生變化。

因此，干系人管理是一項持續進行的行動。

隨著在整個項目期間各種事件不斷發生，項目團隊可能需要根據新的干系人或環境的不斷變化而重新進行優先級排序、調整應對策略。

本文由 @張在旺 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議。