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

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

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

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

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

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

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

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

如果你認為項目失敗的原因是甲方的錯，請你記住：

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

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

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

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

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

做一個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. 面面俱到，不如單點極緻：資源有限，無法面面俱到、各個方面都做到極緻。可以把有限的資源集中在甲方重視的焦點上做到極緻，其他方面不拉胯、達到及格線就行了；
3. 及時通報，過程透明化：注意在項目的進展過程中跟重要幹系人定期保持溝通，有問題及時通報，有風險要及時給甲方打預防針。不要憋大招想給甲方一個驚喜，最後變成驚吓；
4. “整體規劃、分步實施、持續優化”：這是信息化項目中經常給甲方灌輸的一個理念，降低甲方想“一步到位”的預期。

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

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

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

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

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

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

怎麼辦？

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

4. 案例

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

五、幹系人管理綜合案例

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

1. 項目背景

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

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

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

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

2. 幹系人識别

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

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

3. 幹系人分析

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

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

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

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

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

4. 幹系人管理

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

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

六、小結

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

C端産品的幹系人管理要特别注意監管機構。

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

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

因為随着項目的進展，幹系人的權力、對項目的态度、優先級可能會發生變化。

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

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

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

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部