编辑导语：本篇文章作者系统地从多个方面讲解了如何管理干系人，分别从干系人的概念、识别、分析、管理以及综合案例展开讲述，希望对你有帮助。

请你思考一下，下面这个失败的项目，主要是谁的错？

甲方派一个副总经理全权主持项目，乙方负责项目的开发与实施。

在项目一开始，乙方严格按照甲方副总经理提的需求编写需求规格说明、制作系统原型，与客户开了 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 协议。