大型项目沟通管理实践分享

随着项目制的推广，很多公司级的业务改造或技术改造都陆续采用项目形式进行推进，这些项目有着一些相似的地方：周期长、涉及业务组多、项目成员庞大、影响面广等，随之带来了很多的项目沟通问题。如何解决这些沟通问题，减少项目风险？接下来我将以多云迁移项目为例子，和大家分享一些实践经验。

项目目标，在21年年底之前需要将公司所有部署在云上的应用迁移至另一个线上云。项目为期4个月，涉及近30个业务组，共计一百多名主要对接人员。可见，这个项目涉及面非常广，因此也遇到了一些挑战：

1、项目周期短，涉及业务组多，需要各个业务方能够及时响应。但是各个业务组承接的项目较多，势必存在资源争夺的情况，响应速度也因此会打折扣；

2、技术方案复杂，一旦出现问题，影响将会很大，所以各个技术方案均需相关方认真评审，做好确认；

3、项目分为5个里程碑，每个里程碑环环相扣，但只有其中3个里程碑需要业务方参与改造和测试，业务方的参与度及关注度会打折扣；

4、项目涉及人员多，沟通信息复杂，沟通效率不高，沟通信息的透明化难度大。

大家都知道，项目经理在整个项目中的角色，更类似于一个路由器，连接着管理层、项目核心团队、干系团队、职能部门等，项目所有的信息都会汇聚到项目经理处，如何将这些信息都有效的进行筛选、分发、收集，这将是一个很繁琐且重要的过程。

项目启动时，我们会制定项目计划，项目复杂度不高的情况下，计划的重点一般都是实现项目目标的里程碑计划，任务分工及交付时间等。而干系方较多的复杂项目，让所有人参与项目的所有阶段，这是不可行也是大可不必的事情，所以此时就需要提前做好项目的沟通计划。做好沟通计划的目的，是为了高效联动所有干系方，让大家能够清晰的知晓项目的进展，更有序的围绕项目目标开展，减少风险。

在制定沟通计划时，我们需要考虑以下几个点：

沟通对象及沟通策略

沟通形式及内容

沟通的频率

在制定沟通计划之前，我们得明确我们需要和谁沟通，即明确沟通对象：

1. 识别干系人，制定干系人登记册

2. 对干系人进行分析，确定沟通策略

项目干系方一般会有管理层、项目核心团队、干系团队、职能部门等，每个角色对项目的参与程度、支持程度、参与阶段都会有所区别，我们需要深入了解项目的现状以及各方干系人对项目的期望和诉求，采取相应的策略，这时候就很有必要对干系人进行分析。我们可以使用原利益&权力矩阵将干系人分为高权利高利益、高权利低利益、低权利高利益、低权利低利益四类，根据利益&权利矩阵对这4类干系人采取不同的措施。

在和干系人沟通时，我们还需要及时记录干系人的沟通偏好，调整对和干系人的沟通策略。如有些干系人上午比较忙，下午和他沟通的响应速度会更快更顺畅，和这类干系人的沟通就比较适合放在下午进行；又比如有些干系人对项目及自己负责部分的信息了解较全面，我们在和他沟通的时候就可以直入主题；而有些干系人对项目情况了解不多，我们在和他沟通时，就有必要带上上下文了。

• 书面沟通和口头沟通

按照沟通的媒介来分，我们可以把沟通的形式分为口头沟通、书面沟通两大类。我们在项目的推进中，会发起多次的面对面沟通、周会、每日站会等，这些都属于口头沟通；而像邮件、会议纪要、各类文档等，都属于书面沟通。口头沟通和书面沟通都各自的利弊，所以也会有不同的使用场景。口头沟通一般都是面对面完成，少了物理距离的阻碍，沟通的响应速度会比较快，但是也比较容易造成信息的丢失，特别是在信息密集输出的时候，左耳进右耳出也是常有的事情；而书面沟通恰好相反，通过书面形式沟通，常常会有较长的等待时间，但是发送的每个文字都将有迹可循。所以，口头沟通比较适合用于讨论和确认，书面沟通比较适合用于信息的告知。我们比较常见的模式就是通过口头沟通确认信息，然后通过书面沟通将结论发送给相关干系人。

我曾经有遇到过某些项目成员，由于对一些问题没有达成共识，通过邮件展开了激烈的讨论，由于邮件的形式天然带着一种严肃性，导致透过文字传达的情绪越来越失控，最终问题也没有很好的解决，反而激起了双方的矛盾，如果他们没有通过邮件，而是找个地方面对面将问题讨论清楚，或许就是另一种结局了，这就是一个典型的沟通形式错用的例子。

在我们多云迁移项目推进过程中，也使用到了口头沟通和书面沟通，我们通过一对一的线下沟通，确认了各业务组的应用整改排期情况，并记录在文档中，并且日常进行一对一或群聊确认进展，并持续将沟通结果更新在文档中。我们每周会组织周会确认任务进展及问题的讨论，并通过会议纪要、周报等形式，将项目情况同步给项目成员。

• 沟通群的设计

由于处于不同的办公区域，除了需要选择合适的沟通方式来进行不同类型的沟通外，沟通群的设计也非常重要。

不知道大家有没有遇到过这样的情况，经常莫名其妙被拉进各种群，但是又不清楚这个群是干嘛的，拉我进来又是需要做什么，好不容易看完群里的历史聊天记录，突然发现另一个群也在聊同一件事情。我们每天面对几百甚至破千条未读群信息，无从下手，导致我们没有办法及时获取和处理重要信息。所以在项目启动前，我们就需要做好群的设计，我们可以考虑以下几个问题：

我们项目有哪些类型的信息需要进行传递？每一类信息需要哪些人知晓？需要哪些人参与讨论？需要那些人决策？我们项目每个里程碑的参与成员是否相同？

例子：多云迁移项目的群设计

在多云迁移项目的推进过程中，我们根据项目的里程碑、用途、参与人员等，创建了以下几个群：

由于项目部分成员：如老板、管理层、HRBP等，仅需要知晓项目阶段性信息，且项目成员不需要参与项目的所有阶段，但是需要知晓目前的进展，所以我们每周会对项目的决策、进展、风险、计划等信息进行通晒，此时需要有一个包含所有项目成员的群，即“多云迁移项目沟通群”。

   本项目一共有五个里程碑：

其中里程碑一、二、三需要业务组参与，且每个里程碑需要串行进行，所以我们根据不同的阶段创建了里程碑二需要的“仿真集群应用部署服务群”，用于应用部署相关事项的推进；创建了里程碑三需要的“多云迁移项目测试沟通群”，用户测试相关所有事项的推进；由于各个业务组参与本项目的成员内部沟通信息也非常多，如自己业务相关的排期、方案等，所以我们每个业务组还有各自的内部沟通群。由于里程碑一的环境准备、里程碑四、里程碑主要由中间件、运维等成员参与，不涉及业务方，所以我们还创建了“多云迁移项目干活群”。由于里程碑一业务方的应用整改需要有明确的排期计划，所以此阶段采用了一对一面对面沟通的形式进行确认，此阶段没有拉群。由于每个里程碑参的人员不同，且串行推进，所有成员都可以通过“多云迁移项目沟通群”了解到目前项目进行到哪个阶段了、目前有什么问题、我大概什么时候需要开始介入。

一个好的群设计，可以让我我们的信息更顺畅和全面的进行流转，减少低价值信息影响项目成员的响应速度，让需要关注项目信息的成员可以及时获取和自己相关的重要信息。

随着项目的不断推进，项目的信息会越来越庞大，作为项目经理，我们需要对信息进行归总筛选，识别哪些信息是需要干系人随时知晓、哪些信息是需要进行阶段性分析后给出结论等。根据不同的沟通内容，我们可以把沟通的频率分为随时沟通（日常讨论）、日沟通（每日展会）、周沟通（周会）、月度沟通（月度复盘）等。

很多项目经理会在Kick Off时就和大家约定好沟通的频率，比较常见的就是通过周会同步项目的各类信息，这是比较好的一种做法，但是如果想要更好的推进项目，就需要我们根据实际情况及时对频率进行调整。例如当发现项目风险很大或者做冲刺时，我们就要加快沟通的频率，将周会调整为每日站会，每天跟进项目进展，以便快速获取最新的信息，做出合适的决策，当风险解除或者冲刺结束后，我们就不需要有这么高频的沟通了，此时就可以恢复周沟通的频率了。

当一个较重要/较复杂/有较大成果等里程碑结束时，我们还可以发起阶段性的复盘，对过去这个里程碑完成情况、重要成果、做的好的地方、需要改进的地方、风险顾虑等进行总结，沉淀经验，制定好下一步行动计划，确保下一个里程碑乃至整个项目可以更加顺利的推进。

多云迁移项目刚启动的时候，我们听到了内外部很多的声音，虽然我们每个人都尽最大的努力完成项目的工作，但是大家对整个项目的信心值依旧不高，觉得这个项目就是一个“靠天吃饭”的项目。第一个里程碑结束的时候，我们就组织了一次阶段性的复盘，把我们项目的现状进行了总结，组织大家敞开心扉聊了聊自己的顾虑，并且共同制定了解决这些顾虑的措施，复盘结束后，大家的信心都提升了不少。很多时候，对未知的恐惧会让人非常挫败，当把未知转换成已知时，我们自然就有了信心。

除了做好沟通计划外，我们在沟通时还需要讲究一些沟通技巧。

人都是喜欢听好话的，也是好面子的，这是人性。当我们发现项目成员中，有做的好的地方，一定要及时进行夸奖，这是最低成本的激励方式，当我们希望项目成员能够以他为榜样的话，就比较适合当众进行夸奖，让大家知道这样做我们时喜欢的，以便激励其他成员进行效仿，而被夸奖的当事人也会感到自己的努力被看到了，从而持续保持积极性。自从在应用迁移阶段，多云迁移项目大群中有了每日夸夸的环节，我们明显能够感觉到群内乃至各个业务组内部沟通群都活跃了不少，呈现了一幅如火如荼、成果满满的景象。

相反，当我们发现项目成员有做的不当的地方，需要及时指出，且最好是私下面对面的沟通，保护好当事人的自尊。当众的批评，当事人往往会感到“丢了面子”而产生比较大的打击，自暴自弃，不愿配合的不在少数。但是，如果遇到及其不配合或者无法沟通的成员，适当使用公众的压力，也是一种比较好的方式，但是需要注意措辞，谨慎选择。

夸奖和批评本身不是目的，无论是夸奖还是批评，我们的目的都是为了能够解决问题，更顺利的推进项目，所以当我们能够顺应人性，用大家都舒服的方式沟通，我们的目的自然就能达成了。

如果大家有过购房的经验，或者关注过一些房产中介的短视频，我们会发现一个有趣的现象，销售在介绍户型时，常常会使用“这是您家的客厅”、“我们来到了您家的厨房”等表述，这样的介绍，让我们身临其境，仿佛这真的是我们自己家，无形中增加了我们的购房欲望。这就是很实用的一个技巧，我们在与他人沟通时，站在他人的角度，帮助对方分析利弊，根据他人的情况提供合适的建议，会让对方感觉到你是真的在帮助他，而不是单纯只为达到自己的目的，这会让增加对你的信任，更愿意积极配合。

一个大型的项目，前期的准备往往会花费较长的时间，在项目正式启动时，为了便于沟通，我们会给项目起一个名字。在与干系方做前期的沟通时，我们会使用这个名字。在沟通的过程中，可能会因为醒目的目标、范围、方案等的变更，在项目正式立项时，又会给项目起一个新的名字，此时如果没有对该名称进行强调，在后续项目推进中，经常会遇到两个名字混用的情况，一些不了解情况的成员听到后，可能就会一脸懵，这说的是同一个项目么？除了项目名称，一些概念或功能的定义也会出现同样的问题。如果放任不管，就会非常混乱。比如多云迁移项目，就有两个名称：“一刀切云项目”、“多云迁移项目”。比较好的做法是，当有多个名词代表同一个意思时，我们需要在项目组中进行确认，统一使用的名词，并且在后续所有的沟通过程和群名称都使用统一的名词，以免出现混乱的情况。

当我们的项目有了一个比较好的项目计划，加上沟通时使用了合适的技巧，相信我们的项目将会非常顺利的推进了。