敏捷沟通 – 如何管理干系人？ PMP里面有一金句：项目经理80%的时间都应该花费在沟通上，其他的事情只需要占据20%估计很多PM们听到这会感到愤愤不平，觉得自己被简单的打上了沟通者这个貌似谁都会做的标签 然而，事实确实如此

话虽这么说，但是在项目管理的语境里，沟通可不仅仅是交流和稀泥，它更是提高团队效率的一大利器拥有良好沟通的团队往往能事半功倍，并且在以下几点表现出很强的优势：

1. 良好的团队氛围

2. 融洽的客户关系，团队内外的充分信任

3. 高效的交付环境

4. 信息的及时分享，避免不必要的浪费和返工

5. 更多创新的基因

沟通大于文档是敏捷宣言的基本原则，在敏捷开发之中，能否在团队和干系人之间建立起合适的有效沟通渠道，是衡量项目成功的重要指标之一今天小马哥便会简单分享一下敏捷沟通中，干系人的识别建立沟通和管理过程

干系人，简单点说便是利益相关者，它指代一切会对某个事物产生影响或者被影响的个人或者组织对于一个项目而言，干系人大概可以分为四类：

直接影响者 ：他们可以是团队成员，项目负责人或者对项目有直接干预权的职能经理们

间接影响者 ：他们不会直接参与到项目中，但是却可以间接的对项目产生影响比如公司的CEO，或者人事经理

直接被影响者 ：比如产品的目标用户，项目所在地的社区等等，都是直接被影响者

间接被影响者 ：指所有会被项目的连带效应间接影响的人或者组织比如公司其他项目组的成员，竞争公司等

在敏捷沟通中，这四类干系人都是需要被妥善进行不同程度的沟通管理的然而在实际操作中，上面的分类方法虽然能囊括所有的干系人，却往往不够相互穷尽，会有一些重合，所以我们通常会从其他的角度去进行分类，并规划沟通方案

识别项目干系人是进行干系人管理的第一步，通常也是最重要的一步毕竟对于项目经理而言，只有清楚的知道自己将要打交道的人是谁，才能够量体裁衣，合理分配自己的精力去建立关系干系人的识别在项目启动阶段便已经开始，是项目经理立项之后要做的头几件事之一由于每个项目的背景甚至涉及行业各有不同，所以识别干系人必须是一个团队工作，需要尽量拉来项目发起人和团队成员，一起进行干系人的初步识别，避免遗漏 识别干系人是一个发散过程，有很多工作坊的工具都可以帮助实现，小马哥简单的推荐一些自己用过的好用的工具：

1. 头脑风暴

2. 思维导图/树状图

3. 专家意见

举个简单的例子，假如我们要在 李家村 开一个 诞哥染发店 ，那我们经过头脑风暴之后产出的干系人大概是这样：

在以上这些常规方法中，小马哥想强调一下 专家意见 的重要性特别对一些背景复杂，企业架构庞大的项目，一定要确保能请到一些对于公司或者行业熟知的专家（比如产品经理，客户代表，职能经理之类的）参与识别过程，否则很有可能无法识别出正确的干系人，败在起跑线上

另一个需要强调的点是，在干系人识别阶段要尽量的识别出所有的可能干系人，哪怕是隔壁村口烫头的王师傅，只要和项目有那么一点儿关系，都可以先识别出来 只有在发散阶段尽可能的识别出所有的干系人，我们才能更胸有成竹的进行下一个步骤： 干系人分类 

干系人分类主要有两大功能第一是对于识别出的干系人进行一个逻辑梳理，这样更能帮助项目经理进行二次验证，去发现一些遗漏的干系人 通常为了梳理逻辑进行的干系人分类会按照组织架构职能或者干系人属性来进行分类 而进行这样的分类， 亲和图 便是一个非常适合的工具比如诞哥染发店便可以通过 亲和图 进行如下简单的分类梳理：

值得注意的是，上面的分类方法虽然可以一目了然的了解干系人的类别，方便团队去查漏补缺，但是却并没有减少关键干系人的数量说白了，如果用这种分类方式，项目经理便会面临太多干系人需要去管理的问题要解决这个问题，便需要第二种分类方式： 干系人优先级排序 顾名思义，干系人优先级排序的分类方式便是为了识别出高优先级的关键干系人，并对他们进行重点管理，同时针对不同优先级的干系人采取不同的沟通策略

小马哥最常用的排序方法便是关系 影响力矩阵，它通过分析干系人对于项目的关系和影响力的强弱程度来对干系人进行一个四象限的分类为了帮助大家理解，我们直接分析诞哥理发店，然后上图：

可以看出关系 影响力矩阵其实是一个简单的四象限图，从左往右代表对于项目的关系紧密性的提高，而从下至上代表对于项目影响力的提高通过这样一个简单的矩阵，我们便很容易的将这一大堆干系人分在了四个不同的象限之内：

象限A （高影响力，高关系）可以看出，所有的理发店员工合伙人包括主要客户都处于这个象限

象限B （低影响力，高关系）在这个象限内的主要是一些潜在的受益者和被影响者，比如隔壁村的烫头王师傅

象限C （低影响力，低关系）和象限B类似，但程度更低 比如王家村村民，对于一些欢乐宅男来说，受影响的程度是非常低的

象限D （高影响力，低关系）这个象限的对象往往是一些其他项目的经理或者组织职能经理甚至公司领导层，他们不直接管理项目，也不太关心项目，但是却拥有很大的权力去影响项目成败

通过这个矩阵，我们可以一目了然的看出，处于高影响力高关系的象限A的干系人们便是咱们项目的绝对关键干系人，但是处于其他象限的干系人看起来貌似也不能忽略作为项目经理我们往往精力有限，那对于不同象限的干系人我们要采取什么样量体裁衣的沟通策略呢？小马哥的建议如下，都是干货哟：

象限A（高影响力，高关系）：高频沟通 多渠道交互式沟通

对于处于象限A的关键干系人来说，我们需要做到保持沟通的及时性和完整性，并且尽量满足如下原则：

1. 关键信息书面化，紧急信息口头化（及时化）

2. 不管再忙，定期会议必须要有，确保各方信息的一致

3. 定期点对点收集干系人反馈，了解期望变更

让干系人能够参与到团队日常工作当中

在这四点原则中，第一到第三点缺一不可，是非常关键的沟通基准然而，一个项目能否被称为一个沟通良好的5A项目，第四点显得尤为重要特别是针对敏捷开发团队来说，能否让客户参与到团队的一些日常开发过程（比如每日站会迭代计划会等），直接影响了交付的进度和质量

象限B（低影响力，高关系）：保持告知 推式沟通

对于象限B的干系人来说，一方面他们对于项目的影响力很小，但同时他们的利益又与项目息息相关对于这类干系人，我们通常采取的策略便是保持信息的传达，确保让这些干系人知道发生了什么在敏捷开发当中，以每周或者每个迭代为周期的邮件和报告通常是最好的沟通方式

象限C（低影响力，低关系）：监控 拉式沟通

这个象限的干系人便是我们常说的边缘人通常情况下，他们并不会对项目有任何的影响，也不会想要知道项目的进展但是对于这个象限的干系人，我们却不能直接不闻不问，因为说不定哪天他们的角色或者性质突然变更，便会跳到其他象限去小马哥便遇到过不小心得罪了其他部门的经理，结果他突然负责了我的部门的乌龙事件

对于这个群体，最好的沟通方式便是被动的 拉式沟通 ，如果他们主动向你询问，便在可以告知的范围内尽量告知如果他们不主动寻求沟通，便不需要有过多的操作

象限D（高影响力，低关系）：保持满意 低频交互式沟通

象限D是一个红灯区，是著名的大佬象限，很多项目经理往往都是在这个象限吃了哑巴亏为什么这么说呢，因为处于这个象限的干系人往往都具有如下特征：

1. 权力很大，往往可以左右项目的存亡，比如公司的CEO

2. 很忙，事情很多所以往往对于项目不了解，或者浮于表面

由上可见，如果足够不幸的话，便很容易遇到这样的情况：公司大领导不知道从哪道听途说了项目的负面消息，在没有和你过多沟通的情况下，草率的决定关停项目，并且还不给你辩解的机会遇到这样的情况，几乎是无解的，因为领导做这样的决定，摆明了是对于你的不信任，再说什么效果都是很小的

然而，大家不必惊慌，搞定大领导，大家只需要做到一点便够了： 让其满意 而想要让大佬满意，大家需要遵循以下一些沟通原则：

1. 适度的直接沟通 直接沟通是建立信任的基础，想要确保项目状况的正确传达，就必须保证信息是直接从你这里传出去的 然而，由于大佬们往往很忙，在什么频率上进行让双方都很舒服的沟通便是一门学问了，小马哥的经验是每月一次的汇报会议，大家仅供参考

2. 书面报告 敏捷也好，瀑布也好，书面报告是最好的向大佬们传达项目状态的方式 建议项目经理们能从范围成本进度质量风险资源等几大方面，从比较高的颗粒度去进行一个全景式的汇报 ，这样的报告通常能让领导们对于项目整体有一个八九不离十的理解，减少从其他地方得到的不实消息对项目的影响 另一个小tips便是，领导们往往都是喜欢数字和图表，适当的可视化是很有用的

3. 对于领导提出的咨询要求尽可能的满足 这是确保领导满意的重要一环，有时候领导们会突然找到项目团队询问一些问题，这个时候项目经理要确保领导们的问题得到及时满意的答复，并同时尽量让自己成为联系点，而不是让领导直接询问团队成员

最后草率的总结一下，在识别分类好干系人并根据以上策略制定好沟通管理计划后，相信你便可以更加自信的去用不同的策略去管理项目干系人啦！最后提一句， 干系人的分类是一个动态的过程，要记得定期根据实际情况进行更新哦！

最后再送大家一个工具，如果你对某些关键干系人还想进行更深一步的分析的话，小马哥推荐大家使用 Persona 进行干系人刻画，对干系人的需求期望态度影响力和支持程度等进行一个全面的分析和记录，模板如下：

如果你感兴趣的话，欢迎来小马哥的个人网站qio一qio: www.himateng.com