项目管理学习笔记(六)沟通的技巧

概述

 在项目管理中，沟通是非常重要的技能，而且沟通的好坏就很大程度决定项目管理中的效率和人员管理等。如果沟通不好还会带来很多的麻烦，本文随笔主要介绍项目管理中如何沟通的。

向上沟通：你必须要注意的三个误区

 我会结合自己的亲身经历和我踩过的“坑”，来聊一聊向上沟通的三个误区。

误区一：所有问题，都自己扛！

不得不说，这一条，在技术人员中相当普遍。在我还是个刚刚转岗的 PM 小菜鸟时，我负责管理一个项目，代号叫“KK”，这个项目是为公司的战略项目提供底层支撑的。在跟进这个项目的前几个月里，我跟技术负责人阿仑配合得还算默契。但是，我发现他有个特点，就是所有问题，都自己扛。距离里程碑发布只剩一周了，但在测试时，我们还在不断地发现新的 Bug。以目前的进度和剩余 Bug 的潜在影响来看，按原计划上线，质量风险很高。这天，开站会时，我请团队中的每个人，在白板上画出自己的发布信心指数。总体来看，情况非常不乐观。

迈过自己内心的那道坎，主动大胆地发起沟通，是做好向上沟通的第一步。事实上，我们首先必须要明确，这类严重影响稳定性的问题，已经不属于可以自己扛的级别了，必须要让上级知晓。这里的关键是，不管通过什么途径，我们必须时刻从大局出发，让这些项目关键信息，及时有效地流动，保障及时有效的决策。当真正重要、紧急的事情发生时，直接打电话或走过去敲门，确保第一时间沟通，才是更合适的做法。记住，你不需要所有问题，都自己扛。

误区二：只知道吐槽，不知道争取

当团队和管理层之间关系紧张时，很多项目经理会特别容易掉进一个误区，那就是，尽自己的努力帮团队解决问题，脏活累活都自己来。这样的“老好人”，在团队中会有很好的人缘，但是，跟着大家一起吐槽，似乎并不能带给团队真正的帮助。特别是当你同时受到高层压力的驱使，被迫去快速拿结果时，就很容易演变成“夹心饼”，吃苦受累，最后反而落得两头埋怨。那么，破局的点在哪里呢？答案就是，把“夹心饼”变成“连接器”，成为高层干系人与团队之间紧密联系的纽带。

事实上，经过层层汇报，高层干系人能够得到的一线团队的信息，相当有限。很多自上而下的决策，如果不能根据一线反馈，及时调整的话，就很容易走形，偏离本意。作为项目经理，当需要高层重视和支持的事件发生时，该出手时就得出手，引发高层关注，把团队最一手的相关动态信息及时传递给他，争取高层必要的支持，而不是跟着团队一起吐槽。

误区三：抓不住重点，给不出方案

“团队现在加班很严重”“团队任务不及时更新”“某某工作不主动、总是迟到”……如果你只是这样反映问题，只是说这里不好、那里不好，却没有告诉他，为什么要关注这个问题的话，你的意见不仅不会得到重视，甚至还会产生反效果。高层干系人的时间往往很宝贵，所以，在沟通之前，做好充分的准备，是必不可少的。你要反映的问题，与高层干系人的核心关注点是否相匹配，这是能否引起其关注并进一步行动的关键所在。在向高层干系人提问题的同时，一定要给他一个明确的“点”，让他知道，为什么要关注这个问题。

最后，对于自己提出的问题，我还适时地给出了一个小小的“行动点”，也就是近在眼前的解决方案：下午的复盘会，邀请方雷来为大家打气。针对提出的问题，列举可能的解决方案，这一点非常重要。需要注意的是，你并不需要一下子给出完整的解决方案，因为这些问题通常已经超出你个人的能力范围。但即便如此，我依然强烈建议你，不要只是把锅甩给领导，而是在提出问题的同时，给出前进一小步的解决方案，给领导，也给自己，一个小小的行动暗示。总之，想要抓住重点，高效沟通，你要记住三点：找到“核心关注点”；用数据和事实来作“论点”；给出一个小小的“行动点”。

跨部门沟通：怎么让不归你管的人积极配合你？

曾经，有位程序员跟我说：“我们自己内部的进度都很好管，可是，一旦涉及到跨部门合作，管起来就很困难。人家又不归我们管，不可控因素太多了。如果在合作的过程中，出现了什么问题，拿他们也没办法。针对这种情况，你说怎么办呢？”其实，人类社会的很多冲突，都始于“边界”二字。比如，部门与部门之间存在边界，所以就有了“部门墙”。别看只是跨了个部门，各项沟通的复杂度就会直线上升。为啥呢？不是“自己人”了啊。那么，我们该如何应对跨部门沟通的问题呢？我跟你分享两种方法。约法三章，先说清楚。打开边界，一起想办法。

约法三章，先说清楚

我们先来看看第一种：约法三章。既然不是自己人，那就要分清楚哪些事情该我干，哪些该你干。那么，该如何约法三章呢？

第一步：建立君子协定。在合作前，你要跟对方建立合约，明确合作目标、合作事项、双方各自的需求和责任、时间进度要求、风险及责任人。建立合约时，要由双方负责人进行邮件确认，公开做出正式的承诺。需要注意的是，在刚开始合作时，建立稳定的预期是关键，双方责任及进度要求，必须要得到公开确认。否则，这些问题如果不明不白的话，就会给后续工作带来极大的隐患。必要的时候，可以筹备、召开一个跨部门的项目启动会，邀请双方的领导层参与，通过这种正式的仪式，让合作项目成为大家共同的目标。为什么很多公司级的战略合作都会举办一个签字仪式呢？其实，这就是因为承诺越公开，越正式，日后对双方的约束效力就越大。

第二步：建立机制。万万不要以为，签完合约就万事大吉了。曾经，我们就遇到这样的情况：眼看着要到联调的 Deadline 了，对方的任务还没完成。我问了对方之后，才知道，说好的功能接口不能准时交付了。他们给出了很多原因，比如，工作比想象得复杂，还有人员休产假、离职等等。在项目进行中，各种情况都有可能发生，只有及时获知、甚至是提前预知风险，才能让项目始终保持可控。合作建立之后，需要建立常规的沟通机制来持续推动。比如，项目信息开放共享，每周在固定的时间开碰头会，双方相关人员交流工作进展及风险情况。更进一步的话，你还可以借助标准的任务管理和文档管理工具，对项目任务和文档做到统一的流程化管理，在过程中确保及时地跟进检查。常规机制及工具搭建好之后，在运行过程中，你还需要经常自检，确认下流程上是否有疏忽的地方。比如，是否存在“三不管”地带？每个依赖任务的职责是否明确，责任是否具体到个人？如果你发现了模糊地带的存在，要及时明确需要共同协作的内容是什么，该由哪个部门、哪个人负责，做到权责分明和分工合理，避免后期出现相互推诿、扯皮的情况。

第三步：解决问题。通过周期检查，我们可以及时发现问题。但是，如果事先约定好了，并做了周期检查，对方负责的事情还是出问题了，该怎么办呢？有同学会说：“找他们领导！”在跨部门沟通中，打出领导牌的确会起到一定的作用，但是，这张牌属于“王炸”，不到特别时刻，不要随便拿出来用。在找领导之前，建议你先自己摸清楚状况，尽快启动风险应对机制，确定问题处理方案，比如改变方案、调整时间、增加资源、减少范围等。另外，你要把问题和相应的决议结果抄送给双方的负责人，让双方清楚问题对整体项目的影响及调整方案。同时，你还要明确的是，今后要采取哪些预防措施，以避免问题的再次发生。那么，什么时候该找领导呢？我曾经就遇到过一种情况：两边的领导已经达成了正式的约定，但是，不是每个牵涉进去的协作方都会立马配合。原因有很多，比如，这个部门的 KPI 早就定义好了，目前上面的领导虽然认可了合作方案，但是没改 KPI，原来的目标依然有效。对于这部分新增的工作，他们要额外投人去做。因此，他们非常担心，虽然增加了工作量，但产出却不受领导的重视。类似这种会影响合作落地的根本机制问题，你就需要引入双方的领导，来一起研究解决方案。比如，在双方的绩效考核指标中，加入跨部门利益的指标，来强化这种目标和利益的捆绑，让双方真正把劲往一处使。

我们总结一下“约法三章式”跨部门沟通的要点。首先，在项目合作开始时，要努力争取合作部门上级领导的支持，达成明确公开的“君子协议”，建立稳定的合作预期。然后，你要建立周期检查机制和标准化的流程，而不是想起来才问一句。最后，对于执行过程中的问题，及时跟进解决，对于涉及合作机制类的问题，要及时请双方领导介入进来。

打开边界，一起想办法

“约法三章”，可以说是最为常见的一种跨部门沟通的应对方式。接下来，我们再来看看第二种方法：打开边界，一起想办法。尽管不是自己人，咱还是要把对方当成自己人看待，好，就一起好；出了问题，大家就一起扛。为什么说跨部门沟通还需要打开边界呢？我给你分享一个我经历过的项目，你就明白了。X 项目是一个非常典型的跨部门、跨职能的大型项目集，项目组人员接近两百个，涉及到的跨职能小组就有 12 个。由于技术复杂性，各模块之间的依赖和耦合很强，再加上各业务模块都有自己的目标和优先级，跨部门沟通的成本很高。在这样的背景下，每个业务模块都反馈说：“跨部门协调这个事，太难了。”一个很小的改进，可能就需要交互、前端、中间层、后端、各模块的测试都参与其中。即使只是组织一个会议，要想把人叫齐，都颇费周折。这种跨部门的协作，已经融入到每一天的工作中了。这时，“约法三章”的沟通方式，显然已经不适合我们了。那怎么办呢？

首先，要建立统一、清晰的节奏感。你需要结合不同业务模块的功能、相互之间的依赖关系，来为各个业务模块设计统一的交付节奏，也就是根据项目中的关键依赖，把交付时间错开排布。比如，在 X 项目中，我们在每个月固定设置了四个发布窗口，分别是 5 号、10 号、15 号和 20 号。接着，根据这 12 个模块的先后依赖关系，我们把它们安排在不同的窗口进行发布。在此之前，这些模块的发布时间都是自行定义的，现在，每月有了统一的规划和交付节奏，协同复杂度降低了很多，因为彼此之间有了稳定的交付预期和协同基准。需要注意的是，节奏的设定没有固定模式可循，你需要在自己的情境中，尝试总结规律，并把它们固化下来。有一个指示性的指标，就是重新设定节奏之后，如果跨部门协调的问题明显变少了，那么，当前这个节奏就是更合适的。

其次，想要打开边界，你还需要主动往前一步。对于这个项目集里的 12 个子业务模块来说，每个模块既可能是底层服务的用户，同时又是上层服务的依赖方，彼此互为上下游。在这样的情况下，如果没有彼此的通力合作，那就谁也做不好。曾经，我见过两个部门的负责人来来回回地在邮件里争吵，据理力争地互怼。后来，因为实在无法直接沟通了，他们就跟我说：“给我们加个项目经理吧。”在了解了需求之后，我发现，每个模块的日子都不好过，要么是被需求的反复弄得焦头烂额，一肚子怨气，说：“明明之前都约定好了，需求还是说变就变。我辛辛苦苦做出来了，说不用就不用，全白搭了。”要么是被频繁的依赖问题折磨得陷入“水深火热”的境地，纷纷吐槽：“底层服务又出问题，害我挨用户一顿臭骂。整天出问题，真是拿我们当小白鼠。”不管是哪一方，每个人都盯着别人的问题，同时捂住自己的问题。像这样的情况，就算是再放 10 个项目经理，估计都很难从整体上改善局面。那么，该怎么办呢？在和项目集的高层领导一起深入地剖析了现状之后，我们都认为，“头痛医头，脚痛医脚”的方式，并不是我们想要寻求的解决方案。于是，我们在 Leader 层发起了一次跨部门的交流讨论，取名为“上有老，下有小”，意思是，在这个项目集生态里，各个模块是层层嵌套在一起的，每个模块都在持续建设中，还远未成熟。上面，有人要调用我的服务；下面，我要依赖另外一个服务提供底层能力。每个模块都是“上有老，下有小”，如果我们想要获得整体改善，该怎么做？我们收集了大家的改进建议，并进行了统一整理，形成了我们所定义的“担当力模型”（如下图所示）。这个模型总共分为四层，它们分别描述了我们在遇到跨部门沟通的问题时的四种不同心态和行为。

第一层：放弃。这背后的心态是：“见怪不怪，反正我已经绝望了。”抱着这种心态，于是，你就什么都没做。

第二层；责怪。这背后的心理是：“你怎么搞的，每次都这样？”这样想着，你依然是，什么都没做。

第三层：完成任务。这背后的心态是：“真是不省心，下次我得特意盯着你点！”抱着这种完成任务的心态，你会针对问题做全面的排查，增强对应的监控。

第四层：担当。这一层的表现是：“出问题不可怕，但我们绝对不能再犯同一个错误。”你会把错误当作完善的机会，帮助用户方和依赖方共同成长。

我们把真正的担当解释为“上敬老，下爱小”。什么意思呢？上敬老，是说对于用户方，你要去主动深挖用户方的需求及业务背景，走在用户前面；下爱小，是指对于依赖方，你要全面监控、必要容错、并帮助它不断改进。通过这次的深入讨论，我们认识到，只有各个模块都往前走一步，才能够引发系统的改善。与其去责怪对方，不如跟他一起找到合作共赢的方式，最终让所有人获益。这四层担当力模型，本质上是心态上的差异，而每次主动往前一步，最终必将体现到工作的长期效果上，从而形成持久化差异。

向下沟通

在做项目管理的前几年时间里，我经常会听到一种声音：“项目经理无权无势，不就是个打杂的吗？”老实说，刚开始从小白起步时，我也经常有这样的困惑。没有权力，却要承担很大的责任，还得让别人愿意听我的，互相配合着把事情做好，难度真的非常高。但正因为这样，我们项目管理部的项目经理们，在这些磨练中，个个都发展出了一身武艺。这其中最厉害的一项本事，叫作“非职权领导力”。今天我们就来聊一聊，如何在团队中让自己拥有更大的 Power。在大量的实践中，我逐步总结梳理出了非职权领导力的六力模型。“六力”分别是执行力、信息力、感知力、透明力、影响力和整合力，这六力是层层递进的关系，代表了非职权领导力发展之路上的六个层次。

执行力

执行力是非职权领导力的根基，俗称“靠谱”，这是项目经理的立身之本。我们判断一个人是否靠谱，往往是在说这个人是否具有两个特征：主动担责和有始有终。

1.主动担责。管好自己的一亩三分地，并非就是执行力好。比如，我见过很多策划，在写好策划案之后就甩手不管了。但是，我曾遇到过这样一位策划，他不仅把自己的本职工作做得很出色，还会帮忙给所有策划制作一张总进度表，即时同步信息，汇报进展。如果中间过程出现了问题，比如开发跟测试发生了冲突，他也会主动想办法协调解决，推进项目落地。一段时间后，他被 Leader 点名表扬，很快从几个同级中脱颖而出，得到了晋升。我问他：“你为啥做这么多事？”他笑笑说：“也没啥，我就是很想看到整个产品都做得很好，不能忍受有些环节出了问题没人管，没人上，那就我上呗。”所以，你看，执行力的第一层，并没有什么神奇的，你首先需要跳出自己的小圈圈，主动承担更大的责任，而不是眼睁睁地看着项目出现问题，放手不管。

2.有始有终.言必信，行必果。交给你的任何事情，都有始有终。当很多人都只是在完成任务时，如果你懂得闭环的重要性，势必会事半功倍！关于这一点，我想跟你分享一下我的第一位项目管理导师给我上的宝贵一课。当时，我在团队中发起了一项“零 Bug”的改进活动，后来因为一些原因没有坚持做下去。她在了解了情况之后，很严厉地跟我说：“作为一个项目经理，你发起的任何一件事都要有‘Close’的动作。你既然跟团队讲过要做这件事，现在不做了，就算自认为原因再合理，都需要给大家一个交待，而不是不声不响地就停止了。”实际上，一个有始有终的闭环，意味着你要对自己的每一个行为负责，清楚地了解为什么做，目标是什么，做完之后效果是怎样的，还有什么问题，以后要做哪些改进。如果中途有变化，也要及时跟相关方明确说明调整或取消的原因是什么。总结一下，想要做一个“靠谱”的人，我给了你两条建议：第一，跨出自己的边界，主动担责；第二，言必信，行必果，做事情有始有终。

信息力

在大数据时代，谁掌握着数据和信息，谁就拥有更强大的力量和权力。由于自身的职责和信息渠道的便利，项目管理人员会很容易成为团队中拥有最大信息量的人。大到全局的战略、项目的初衷和发展方向、决策的起因和前后变迁，小到每个团队每天在干什么，都尽在项目管理人员的掌控之中。因此，项目经理就好比是项目信息的交换中心。我曾遇到过一个项目经理，他就拥有这种神通广大的信息力。不只是项目组里，甚至是公司里上上下下发生的事情，他都能第一时间获悉。所以，遇到拿不定主意的事情时，我经常向他打听消息。

有一次，我忍不住问他：“你到底是怎么做到的？”他说：“没什么神秘的，我这个就是好奇心强，而且比较热心。我对别人很感兴趣，就会经常跟大家多聊几句，不管聊的东西有没有用，我都记得清清楚楚。而且，我还特别喜欢帮助别人。比如，我觉得某个机会适合某某，我就会推荐他去试试看。久而久之，大家就会主动给我提供信息，让我帮忙出谋划策，所以我就成了最有信息力的人啦！”当然，信息力可不只是掌握简单的八卦，而是要让流动的信息汇聚起来。作为初学者，你可以通过信息互通机制和平台来帮助自己做到这一点。比如，周会、站会、周报、邮件列表、通讯群，甚至是各类数据平台，都可以成为信息力的承载。除此之外，能够让非正式信息自动流向你，就属于内功的范畴了。在与人交往与合作时，好奇、关心、真诚、友善……这些特质都会帮助你构建起信任基础。连接多了，覆盖面广了，自然会形成规模效应和网络效应，这时就会产生信息力的红利了。

感知力

感知力建立在信息力的基础之上，不同的是，感知力是对“冰山下”隐性信息的敏锐度。这种对系统敏锐的感知判断，俗称“闻味道”。据说，马云就是个“闻味道”的高手。如果他出差一个月不在公司，那么，他回公司之后做的第一件事，就是把十层楼的办公区都跑一遍，然后找副总们开会，精准地说出公司存在的问题，观察之细密往往让人佩服至极。感知力是日积月累的功力，但也并不是什么深奥的功夫，你也可以做得到，重点就是平常在开会时，你要多练习、多观察。举个例子，某业务负责人请我给他的管理层做一次共创会，请大家根据总体规划，各个角色共同定义下半年各自的工作重点。拿到这个需求之后，我先跟几个管理者开了一次沟通会。会后，我找到这位负责人，跟他同步了我对管理团队的观察，并且提出了我的共创方案：“在这次共创之前，我们必须先有个复盘环节，否则，以咱们团队现在的这种合作状态，根本没法很好地共创。咱们得提前准备，我需要你的大力配合。”他很快就认可了我的方案，并且惊讶地问我：“你是怎么做到在这么的短时间内捕捉到这么多复杂的背景信息的？”你可能也很好奇，事实上，这就是感知力在现实场景中的运用。要想培养感知力，你需要经历三个层次。

第一层：现象层。这一层观察的焦点，是在“冰山上”的行为。比如，你观察到开发和产品在会上吵起来了，这时，你注意到的是行为，还不是真正的感知。

第二层：意图层。这一层观察的焦点，是在“冰山下”行为背后的真正意图。具体要怎么做呢？最简单的是，多问几个为什么。比如，他们为什么会吵起来，各自想要达成什么目标。仔细思考之后，你会发现，原来技术已经对于产品的频繁变更忍无可忍了，技术 Leader 有很大的压力，想要为受苦受难的开发们出头；而产品的意图也很直接，他们的想法是：“业务 KPI 在那儿摆着，咱能不能别那么磨叽？快速推进不行吗？”观察到这一层，你就很接近冲突的根源了。

第三层：感受层。你要试着从这些现象和意图中，去感受每个人的状态和需要。你会发现，开发的核心感受显然是愤怒；产品直接承担着业务指标带来的高压，老大的想法又一直在变，技术的不配合让他们受到双面夹击，早已是苦不堪言，核心感受是苦涩。体会到这些之后，你会发现，如果不事先处理好这些强烈的感受，这些人是根本没有办法在一起很好地进行共创的。于是，在共创开始前，我安排了一个之前提到过的复盘环节，就是让每个成员画出自己从项目启动以来的状态、经历，并把其中的“高光时刻”和“至暗时刻”分享给大家。当天，这位负责人第一个发言，跟大家分享了开创新业务以来自己的坎坷经历。他的开放和坦诚让大家一下子轻松了许多。接着，轮到产品，她提到了刚上线就被苹果推荐的成就和喜悦，同时又分享了最近“两头受夹板气”的惨痛经历。开发同学则拿出自己的画，说自己自始至终都是“压力山大”，从来都没轻松过……就这样，大家开始一点点地敞开了心扉。那些平时看不到的真实一面，被集体看见和理解之后，团队内部淤积的压力也终于得到了释放。于是，大家开始聚焦在共创下一步真正有效的解决方案。

总之，要想培养感知力，就要在日常的观察之中下功夫。从关注行为，到关注行为背后的意图，再到关注意图背后个体的核心感受和深层需要，最后着眼于团队中的气场和互动品质。这样一来，你就能找到“四两拨千斤”的杠杆点，从“救火式”的应对问题，变成“治未病”的先知先觉，从而在团队中积累起自己的独特影响力。

透明力

信息力和感知力是对环境的观察、观察、再观察。你需要注意的是，这些观察的结果只有透明出来，才能发挥效用。你要想办法把你看到的问题可视化，让决策者和团队都能看到这些问题。这就是我经常说到的透明的力量。那么，怎么运用透明的力量呢？我给你讲个例子，你就明白了。

我在一个团队中经常听到这样的声音：“搞什么需求评审、交互评审？要做什么先说好，然后就别再来烦我了。让我安静地写会儿代码，不行吗？”于是，这些评审会能不开就不开。结果，在 Deadline 之前，需求稿、设计稿和技术方案的问题不断爆发，要熬上好几个通宵，才能保证版本的正常发布。但是到了下一个版本，情况依然如此，循环往复。经过仔细了解，我发现，如果在早期投入精力的话，这些导致发布延期的大多数问题都是可以有效避免的，发布的风险也会大大降低。实际上，定位问题并不难，但是要想解决这个问题就很难了。因为这个团队三四年来一直都是这样，他们早就已经习惯这种模式了。想要引发改变，不是仅凭一人之力就可以做得到的。要打破这个恶性循环，就一定得让大家真正地看见问题，并且从心底里达成共识。我教你两个透明化呈现的方法：一个是“分析−思考−看见”，一个是“目睹−感受−看见”。前者走脑，是指借助数据、事实、逻辑分析等，调动头脑的智慧，创造共识；后者走心，是指运用图片、视频、故事等形象化的元素，调动情绪的力量，创造共鸣。如果你能结合起来用，效果会更好。

连夜加班成为熊猫，并且成为了“熊猫大侠”的故事。这位“熊猫大侠”是一个苦兮兮的程序员，他有着熊猫一样的黑眼圈，他的黑眼圈是怎么来的呢？我以这个问题为切入点，以故事的形式带领大家回顾了整个版本进行过程中的一幕幕场景，从上个版本结束时的“累觉不爱”，需求评审会上的睡意朦胧，讲到提测前对设计方案的争执不下，最后到上线前的“兵荒马乱”。“熊猫大侠”的故事，使团队成员深度地看到了项目的现状，并产生了共鸣。接着，我晒出了各种过程数据，包括需求变更率、需求和设计问题发生的阶段及成本、各阶段等待时间、研发负荷度等，邀请团队一起来想办法解开 Deadline 的“魔咒”。看见这些事实和数据之后，大家才真正地意识到早期那些看似无聊的评审工作的重要性。除此之外，团队还进一步定义了各角色的协作规则，以达到更合理的节奏。最后，在团队的共同努力下，我们进一步建立了基于过程数据的效能改进机制，各角色的协同状况得到了持续的改善。所以，你看，想要改善什么，就把什么透明化！在走脑的同时又要走心，让团队的所有人都看见问题，调动起集体的关注力和改变的动力。这样的话，这种透明的力量就会自然地推动变化的发生。

影响力

项目经理无权无势，行走江湖，靠的是大家肯买你的账。能让他人买账的这种影响力，对个体来说，就是说服力；对群体来说，就是感染力。人们通常认为，要想提升影响力，一定要能讲，会讲。但很有意思的是，影响力的真正秘诀却在于“听”，而不是“讲”。

举个例子，我们在听马丁·路德·金的演讲时，往往会觉得非常震撼。这是因为，真正能够征服人心的演讲都具有强大的说服力和感染力，而这些都是建立在对听众的深度理解的基础之上的。因为理解，所以才能创造共鸣。如果演讲者自己激情澎湃，但听众并不受用，那根本就无法产生真正的影响力。我曾经跟一位产品总监合作，他本人聪明又强势，属于公认的特别难搞的类型。有一次，他主动跟我说：“别人跟我讲话，我向来只听两句就忍不住想打断，但是你说的话，我几乎全都听完了。”

他之所以会这样说，并不是因为我的表达能力比别人强、我的逻辑更清晰、我的话更有道理，而是因为在他讲话的时候，我做到了真正的听。跟其他人相比，我更懂他的逻辑，我明白他是出于什么样的考虑，才会那么说、那么做的。我给他提的每一条建议都是建立在我对他的理解之上的，所以才能被他听进去。不听，是一切沟通问题的根源。要想增强你的影响力，你需要先培养“听”的能力。那么，该怎么培养这种能力呢？

我给你分享一个小技巧。你可以找一位项目中的成员，请他聊一聊，在最近的工作中，他有没有什么高兴或者烦恼的事。在听他说话的时候，你一定不要打断他，也不需要特意去想自己该怎么回应。你只要简单地把注意力放在对方身上，清空你的思绪，打开你的所有感官，留心去体会对方的状态和需求就可以了。试着保持至少五分钟的专注，并在结束后记录自己的体会。同时，我鼓励你跟对方分享一下，在刚刚的对话中，你留意到了什么。另外，你也可以跟他沟通下，有没有什么事情是你可以帮他一起做的。实际上，在真正有说服力的对话中，恰恰并不存在什么“一定要去说服”的想法，这又是一个有意思的悖论。实际上，只有当你真诚地抱着想要了解和倾听对方的愿望，放下对自己的想法的执着时，你才能留意到对方真正的需要。这样自然的交流分享，反而更容易产生碰撞，引发共振。如果你能够在你的每次工作对话中有意识地坚持运用这个小练习，半年之后，你的影响力就能够得到很大的提升。

整合力

在一个业务团队中，除了总负责人之外，项目经理往往是唯一站在全局层面的人。毕竟，其他人都各有各的职责分工。在这样的定位之下，项目经理一定要成为一个“多面手”。因此，优秀的全局整合能力非常关键。简单来说，整合力就是把互相分离的部分连接在一起，使它们发挥出整体作用的力量。一群优秀的人结合在一起，也并不一定能成为一个优秀的团队，不一定能真的做成一个业务。作为项目经理，整合力就意味着你要去主动发现项目组中的各类风险和问题，综合运用各种能力，跨部门、跨角色地整合资源，以实现全链条的共同目标。关于整合力，我定义了两个“凡是”：凡是能促进业务良性运作的，凡是能促进团队健康发展的，都是整合管理的范畴。举个例子，我身边有个项目曾经遭遇到了发展上的瓶颈，军心溃散，士气低落，这时，我就变身成了教练，借助教练技术，给业务负责人及核心团队“照镜子”，帮助他们看到限制他们的模式到底是什么，促发团队进行深度思考和交流，共同梳理出当前局面之下最好的思路和打法，从而帮助团队更好地走出困境。所以，你看，所谓的整合力，就是不受限于你自己的角色、从头到尾把事做成的能力。这种整合力来源于你对项目环境的观察和感知，最后要落地到全局层面的行动中去。

实践中的“六力模型”

有一位项目经理，她发现产品的问题不是在于研发环节，而是在于销售和研发环节的脱节，可是她很难改变这个现状，她担心直接指出问题的话会得罪别人。在把研发过程梳理清楚之后，她开始着手收集相关的数据，并且做了大量的调研和分析

摸清问题对整体的影响（信息力），然后去感知项目中各个角色的声音和诉求，这让她找到了最迫切想要改变的力量（感知力）。接着，她想办法把问题透明给销售主管及各部门的负责人，引发了更大的关注（透明力）。除此之外，她还主动找各方讨论可能的应对方案，促成变化的发生（影响力）。最终，她推动这件事被列为部门下个阶段的重点改进目标之一（整合力）。

总结

以后关于数据中台系列的总结大部分来自Geek Time的课件，大家可以自行关键字搜索。