无论是程序员还是技术人员leader，沟通，在我们的工作中起了很大的作用。每个人都会说话，但是会沟通之道的却不是太多，不信你往下看。为了增加代入感，全文都以第一人称“我”来叙述。因为有些案例出自朋友身上。
我把它们分为三类：
# 一、向上沟通
# 1.1 雷区一:自己扛所有问题！
我还是个刚转岗的人。 PM 小菜鸟时，我负责管理一个项目，代号叫“KK这个项目为公司的战略项目提供了基本的支持。在跟进这个项目的前几个月，我与技术总监阿仑合作。然而，我发现他有一个特点，那就是所有的问题都是他自己承担的。
距离里程碑发布只有一周了，但在测试过程中，我们仍在不断发现新的 Bug。以目前的进度和剩余 Bug 根据潜在影响，质量风险很高。今天，在车站会议上，我邀请团队中的每个人在白板上画出自己的信心指数。总的来说，情况并不乐观。
在我和阿仑一起安排了当天后，我特别提醒他：现在情况不是很好，我们最好提前向方雷报告。方雷是这个项目的发起人，也是阿仑的上级。阿仑没有回应，转而寻找旁边的开发，开始讨论其他问题。我很着急，但我不得不放弃。事实上，我的担忧并非毫无根据。方雷曾多次强调，KK 稳定性是今年的重点。最近几次网上出现问题，我们团队没少挨骂。这次上线风险这么高，要不要及时告诉方雷？ 我在方雷公室门前，我绕了两个弯，各种纠结的顾虑，再一想到方雷那严厉的表情，就打起了退堂鼓。最后，我什么也没说就离开了。新版本最终如期上线，但我并不觉得轻松。且不说遗留 Bug 由于时间紧迫，我们没有做好在线监控，也没有时间充分考虑应急预案和演练。
就在团队尽力弥补漏洞的时候，网上还是出了事故:底层依赖的第三方服务报错，导致很多网上用户请求失败。直到晚上接到客户侧的紧急电话，我们才知道发生了什么事。第二天，方磊在电子邮件中责骂我们:我之前一再强调监控。你没有处理预见的问题。这是一起非常严重的人为事故！
看到这里，你觉得我委屈吗？事实上，我清楚地知道这样上线会有很大的问题，现阶段最好的应对方式是什么。我甚至在心里做了无数的草稿，可以说服方磊调整上线计划。然而，当我站在方雷办公室门口时，我无法迈出心中的坎。这个坎是什么？首先是层次差无形中给我带来的心理压力，包括方雷平日里强硬的作风，让我有点害怕，不自觉的想逃避。
第二，都快上线了，项目还有那么多问题，作为项目经理，我也有很大的责任。此外，因为阿仑不想报告，如果我报告，我会觉得这就像一个小报告，不是正义。事实上，报告和沟通紧急问题并不难。但是，跨越内心的坎，主动大胆的发起沟通，是做好向上沟通的第一步。事实上，我们必须首先明确，这种严重影响稳定性的问题不再属于我们可以自己承担的水平，必须让上级知道。
要明确这一点，处理方法有很多种。比如和阿仑深入探讨项目情况，试图说服他一起去找方雷。即使他不去，我也可以向他解释我的判断和下一步行动，因为客观暴露风险和合理应对是项目经理的责任。当然，我也可以尝试以电子邮件的形式发送项目风险报警，客观描述当前的风险和影响，提醒方雷特别注意，等等。
这里的关键是，无论如何，我们都必须始终从整体情况出发，使这些项目的关键信息能够及时有效地流动，并确保及时有效的决策。当真正重要和紧急情况发生时，更合适的方法是直接打电话或敲门，以确保第一次沟通。记住，你不需要自己承担所有的问题。
# 1.2 雷区二:只知道吐槽，不知道争取。
在 KK 项目组，连续加班是见。 2 起床升级也很常见。即使我们的工作强度如此之高，在线问题仍然存在，项目组从上到下都面临着巨大的压力。在这样一个糟糕的生活环境中，团队成员就像兄弟，经常私下一起吃饭。当然，不可或缺的是一起嘲笑。
一个周末，又是通宵上线，我们忙到凌晨 4 时间多了，结果更新后，出现了紧急情况，按照流程果断回退。第二天，定位解决问题后，我又来了。连续两个晚上，项目成功上线，但团队撑不住。在看不到尽头的艰苦情况下，吐槽似乎是缓解压力最有效的方法。比如我们可能经常听到这样的吐槽:有问题就挨骂没问题是对的…… 一开始我也会跟着吐槽几句，因为我也一样，拼死拼活却得不到认可。但是，除了私下吐苦水，还能做什么呢？你看，这是我踩过的第二个坑。当团队和管理层之间的关系紧张时，许多项目经理特别容易陷入误解，即尽力帮助团队解决问题，自己做脏工作。这样的好人在团队中会很受欢迎，但似乎并不能给团队带来真正的帮助。特别是当你同时受到高层压力的驱使，被迫快速拿到结果时，很容易演变成三明治蛋糕，吃苦受累，最后两头抱怨。
那破局的点在哪里呢？答案是把三明治蛋糕变成连接器，成为高层干部和团队之间的紧密联系。事实上，经过层层汇报，高层干部能够获得的一线团队信息相当有限。如果很多自上而下的决策不能根据一线反馈及时调整，很容易走形，偏离初衷。作为一名项目经理，当需要高层关注和支持的事件发生时，必须采取行动，吸引高层关注，及时向他传递团队第一手的相关动态信息，争取高层必要的支持，而不是跟随团队。
所以，这一次，我立刻想到了方雷！我应该让他听到团队的声音，让他意识到长期的严重影响。此外，他是解决这一困难的最合适的人。事实表明，方雷的干预大大提高了团队士气。
# 1.3 雷区三:抓不住重点，给不出计划
会议结束后，我拦住了他。我说:我们队最近加班很严重，已经连轴工作好几天了。如果这样下去，恐怕会……在我说完之前，方雷不礼貌地打断了我，说：现在这些年轻人，加班几天，抱怨累了，想想那一年，我可以加班更多……(此处省略1万字)
你看，在得到方雷的支持之前，我又踩了一个坑，也就是我想说的第一个 3 误区:抓不住重点，给不出计划。现在团队加班很严重团队任务没有及时更新某某工作不主动，总是迟到……如果你只是这样反映问题，只是说这里不好，那里不好，但没有告诉他为什么要注意这个问题，你的意见不仅会被注意到，甚至会产生相反的效果。
高层干部的时间往往很宝贵，所以在沟通之前，要做好充分的准备。你要反映的问题是否符合高层干部的核心关注点，是否能引起他们的关注和进一步行动的关键。在向高层干系人提问题的同时，一定要给他一个明确的“点”，让他知道，为什么要关注这个问题。事实上，只有抓住对方真正的核心关注点，才能在后续的沟通中更有针对性地进行高效的管理。
虽然我很了解方雷的脾气，但我还是被刚才的姿势吓坏了。幸运的是，我提前准备好了。于是，我打开电脑，把准备好的数据放在方雷面前，说：你知道，我们的在线质量不能容忍任何错误。这是我们团队前两个月的连续加班记录。有人做过统计，连续三周加班，人的身体、心理、情绪都会跌到谷底。现在团队已经连续加班和通宵两个月了。再加上每次上线的心理压力，恐怕很容易犯错。昨天上线的时候，团队吸取了教训，最后还是很稳定的，可以算是这么长时间的利！我想知道我们是否应该简单地庆祝，帮助你减轻心理压力，鼓舞士气，或者有一个新的开始？”
我一口气完成了事先准备好的台词，方雷先有点惊讶，但他很快就认出了我的判断。的确，我们要想办法鼓励大家，而且一定要及时！灵机一动，然后说：嗯！我觉得今天是个好时机。我们正计划下午开复盘会。我会准备一些零食和饮料。如果可以的话，请到场告诉你两句话！在复盘会上，方雷显然提前认真准备。他从目对大部门的重要性，到对大家辛勤工作的感谢，再到对绩效和奖励措施的承诺。可见他不习惯公开说那么多鼓励的话，气氛有点奇怪。
# 二、跨部门沟通
事实上，人类社会的许多冲突始于边界一词。例如，部门之间有一个边界，所以有一个部门墙。虽然只部门，但沟通的复杂性会急剧上升。
为什么？不是自己人。那么，我们应该如何处理跨部门沟通的问题呢？我和你分享两种方法。
一.约法三章，先说清楚
让我们来看看第一个：三章。既然你不是你自己的人，你应该知道我应该做什么，你应该做什么。那么，如何约定三章呢？
# 2.1 第一步:建立君子协议:
在合作前，你要跟对方建立合约，明确合作目标、合作事项、双方各自的需求和责任、时间进度要求、风险及责任人。建立合约时，要由双方负责人进行邮件确认，公开做出正式的承诺。
需要注意的是，在合作开始时，建立稳定的预期是关键，必须公开确认双方的责任和进度要求。否则，如果这些问题不明白，就会给后续工作带来巨大的隐患。
# 2.2 第二步：建立机制
千万不要以为签完合同就万事大吉了。有一次，我们遇到了这样的情况:看着要去联调 Deadline 对方的任务还没有完成。在我问了对方之后，我意识到好的功能界面不能按时交付。他们给出了很多原因，比如工作比想象的更复杂，以及产假、离职等等。
在项目实施过程中，可能会出现各种情况。只有及时了解甚至提前预测风险，项目才能始终保持可控。合作建立后，需要建立传统的沟通机制，不断推进。例如，项目信息开放共享，每周定时间开会，双方相关人员交流工作进展和风险。此外，您还可以使用标准的任务管理和文档管理工具，实现项目任务和文档的统一流程管理，确保过程中的后续检查。
常规机制和工具建成后，在运行过程中，还需要经常自检，确认下一个过程中是否有疏忽。比如有没有三不管区？每个依赖任务的责任是否明确，责任是否具体到个人？如果发现模糊区域的存在，应及时明确需要共同合作的内容，由哪个部门和人负责，明确权责和合理分工，避免后期相互推诿和争吵。
# 2.3 第三步：解决问题
通过周期检查，我可以及时发现问题。但是，如果事先约定好了，并做了周期检查，对方负责的事情还是出问题了，该怎么办呢？有同学会说：“找他们领导！”在跨部门沟通中，打出领导牌，的确会起到一定的作用。但是，这张牌属于“王炸”，不到特别时刻，不要随便拿出来用。在找领导之前，建议你先自己摸清楚状况，尽快启动风险应对机制，确定问题处理方案，比如改变方案、调整时间、增加资源、减少范围等。
另外，你要把问题和相应的决议结果抄送给双方的负责人，让双方清楚问题对整体项目的影响及调整方案。同时，你还要明确的是，今后要采取哪些预防措施，以避免问题的再次发生。那么，什么时候该找领导呢？我曾经就遇到过一种情况：两边的领导已经达成了正式的约定，但是，不是每个牵涉进去的协作方都会立马配合。
原因有很多，比如，这个部门的 KPI 早就定义好了，目前上面的领导虽然认可了合作方案，但是没改 KPI，原来的目标依然有效。对于这部分新增的工作，他们要额外投人去做。因此，他们非常担心，虽然增加了工作量，但产出却不受领导的重视。类似这种会影响合作落地的根本机制问题，你就需要引入双方的领导，来一起研究解决方案。比如，在双方的绩效考核指标中，加入跨部门利益的指标，来强化这种目标和利益的捆绑，让双方真正把劲往一处使。
“约法三章”，可以说是最为常见的一种跨部门沟通的应对方式。接下来，我们再来看看第二种方法：打开边界，一起想办法。尽管不是自己人，咱还是要把对方当成自己人看待，好，就一起好；出了问题，大家就一起扛。为什么说跨部门沟通还需要打开边界呢？我给你分享一个我经历过的项目，你就明白了。
X 项目是一个非常典型的跨部门、跨职能的大型项目集，项目组人员接近两百个，涉及到的跨职能小组就有 12 个。由于技术复杂性，各模块之间的依赖和耦合很强，再加上各业务模块都有自己的目标和优先级，跨部门沟通的成本很高。在这样的背景下，每个业务模块都反馈说：“跨部门协调这个事，太难了。”一个很小的改进，可能就需要交互、前端、中间层、后端、各模块的测试都参与其中。即使只是组织一个会议，要想把人叫齐，都颇费周折。这种跨部门的协作，已经融入到每一天的工作中了。这时，“约法三章”的沟通方式，显然已经不适合我们了。那怎么办呢？
你需要结合不同业务模块的功能、相互之间的依赖关系，来为各个业务模块设计统一的交付节奏，也就是根据项目中的关键依赖，把交付时间错开排布。比如，在 X 项目中，我们在每个月固定设置了四个发布窗口，分别是 5 号、10 号、15 号和 20 号。接着，根据这 12 个模块的先后依赖关系，我们把它们安排在不同的窗口进行发布。在此之前，这些模块的发布时间都是自行定义的，现在，每月有了统一的规划和交付节奏，协同复杂度降低了很多，因为彼此之间有了稳定的交付预期和协同基准。
需要注意的是，节奏的设定没有固定模式可循，你需要在自己的情境中，尝试总结规律，并把它们固化下来。有一个指示性的指标，就是重新设定节奏之后，如果跨部门协调的问题明显变少了，那么，当前这个节奏就是更合适的。
其次，想要打开边界，你还需要主动往前一步
对于这个项目集里的 12 个子业务模块来说，每个模块既可能是底层服务的用户，同时又是上层服务的依赖方，彼此互为上下游。在这样的情况下，如果没有彼此的通力合作，那就谁也做不好。曾经，我见过两个部门的负责人来来回回地在邮件里争吵，据理力争地互怼。后来，因为实在无法直接沟通了，他们就跟我说：“给我们加个项目经理吧。”
在了解了需求之后，我发现，每个模块的日子都不好过，要么是被需求的反复弄得焦头烂额，一肚子怨气，说：“明明之前都约定好了，需求还是说变就变。我辛辛苦苦做出来了，说不用就不用，全白搭了。”要么是被频繁的依赖问题折磨得陷入“水深火热”的境地，纷纷吐槽：“底层服务又出问题，害我挨用户一顿臭骂。整天出问题，真是拿我们当小白鼠。”
不管是哪一方，每个人都盯着别人的问题，同时捂住自己的问题。像这样的情况，就算是再放 10 个项目经理，估计都很难从整体上改善局面。那么，该怎么办呢？在和项目集的高层领导一起深入地剖析了现状之后，我们都认为，“头痛医头，脚痛医脚”的方式，并不是我们想要寻求的解决方案。 我们把真正的担当解释为“上敬老，下爱小”。什么意思呢？上敬老，是说对于用户方，你要去主动深挖用户方的需求及业务背景，走在用户前面；下爱小，是指对于依赖方，你要全面监控、必要容错、并帮助它不断改进。通过这次的深入讨论，我们认识到，只有各个模块都往前走一步，才能够引发系统的改善。与其去责怪对方，不如跟他一起找到合作共赢的方式，最终让所有人获益。每次主动往前一步，最终必将体现到工作的长期效果上，从而形成持久化差异。
# 三、向下沟通
在做项目管理的前几年时间里，我经常会听到一种声音：“项目经理无权无势，不就是个打杂的吗？”老实说，刚开始从小白起步时，我也经常有这样的困惑。没有权力，却要承担很大的责任，还得让别人愿意听我的，互相配合着把事情做好，难度真的非常高。但正因为这样，我们项目管理部的项目经理们，在这些磨练中，个个都发展出了一身武艺。这其中最厉害的一项本事，叫作“非职权领导力”。在大量的实践中，我逐步总结梳理出了非职权领导力的六力模型。“六力”分别是执行力、信息力、感知力、透明力、影响力和整合力，这六力是层层递进的关系，代表了非职权领导力发展之路上的六个层次。
# 3.1 执行力
执行力是非职权领导力的根基，俗称“靠谱”，这是项目经理的立身之本。我们判断一个人是否靠谱，往往是在说这个人是否具有两个特征：主动担责和有始有终。
- 主动担责
管好自己的一亩三分地，并非就是执行力好。比如，我见过很多策划，在写好策划案之后就甩手不管了。但是，我曾遇到过这样一位策划，他不仅把自己的本职工作做得很出色，还会帮忙给所有策划制作一张总进度表，即时同步信息，汇报进展。如果中间过程出现了问题，比如开发跟测试发生了冲突，他也会主动想办法协调解决，推进项目落地。
一段时间后，他被 Leader 点名表扬，很快从几个同级中脱颖而出，得到了晋升。我问他：“你为啥做这么多事？”他笑笑说：“也没啥，我就是很想看到整个产品都做得很好，不能忍受有些环节出了问题没人管，没人上，那就我上呗。”所以，你看，执行力的第一层，并没有什么神奇的，你首先需要跳出自己的小圈圈，主动承担更大的责任，而不是眼睁睁地看着项目出现问题，放手不管。
- 有始有终
言必信，行必果。交给你的任何事情，都有始有终。当很多人都只是在完成任务时，如果你懂得闭环的重要性，势必会事半功倍！当时，我在团队中发起了一项“零 Bug”的改进活动，后来因为一些原因没有坚持做下去。她在了解了情况之后，很严厉地跟我说：“作为一个项目经理，你发起的任何一件事都要有‘Close’的动作。你既然跟团队讲过要做这件事，现在不做了，就算自认为原因再合理，都需要给大家一个交待，而不是不声不响地就停止了。”
实际上，一个有始有终的闭环，意味着你要对自己的每一个行为负责，清楚地了解为什么做，目标是什么，做完之后效果是怎样的，还有什么问题，以后要做哪些改进。如果中途有变化，也要及时跟相关方明确说明调整或取消的原因是什么。一屋不扫，何以扫天下？执行力可以说是你能够影响他人，继而具备非职权领导力的根本。
# 3.2 信息力
在大数据时代，谁掌握着数据和信息，谁就拥有更强大的力量和权力。由于自身的职责和信息渠道的便利，项目管理人员会很容易成为团队中拥有最大信息量的人。大到全局的战略、项目的初衷和发展方向、决策的起因和前后变迁，小到每个团队每天在干什么，都尽在项目管理人员的掌控之中。因此，项目经理就好比是项目信息的交换中心。
我曾遇到过一个项目经理，他就拥有这种神通广大的信息力。不只是项目组里，甚至是公司里上上下下发生的事情，他都能第一时间获悉。所以，遇到拿不定主意的事情时，我经常向他打听消息。有一次，我忍不住问他：“你到底是怎么做到的？”他说：“没什么神秘的，我这个就是好奇心强，而且比较热心。我对别人很感兴趣，就会经常跟大家多聊几句，不管聊的东西有没有用，我都记得清清楚楚。而且，我还特别喜欢帮助别人。比如，我觉得某个机会适合某某，我就会推荐他去试试看。久而久之，大家就会主动给我提供信息，让我帮忙出谋划策，所以我就成了最有信息力的人啦！”
当然，信息力可不只是掌握简单的八卦，而是要让流动的信息汇聚起来。作为初学者，你可以通过信息互通机制和平台来帮助自己做到这一点。比如，周会、站会、周报、邮件列表、通讯群，甚至是各类数据平台，都可以成为信息力的承载。除此之外，能够让非正式信息自动流向你，就属于内功的范畴了。在与人交往与合作时，好奇、关心、真诚、友善……这些特质都会帮助你构建起信任基础。连接多了，覆盖面广了，自然会形成规模效应和网络效应，这时就会产生信息力的红利了。
# 3.3 感知力
感知力建立在信息力的基础之上，不同的是，感知力是对“冰山下”隐性信息的敏锐度。这种对系统敏锐的感知判断，俗称“闻味道”。感知力是日积月累的功力，但也并不是什么深奥的功夫，你也可以做得到，重点就是平常在开会时，你要多练习、多观察。
举个例子，某业务负责人请我给他的管理层做一次共创会，请大家根据总体规划，各个角色共同定义下半年各自的工作重点。拿到这个需求之后，我先跟几个管理者开了一次沟通会。会后，我找到这位负责人，跟他同步了我对管理团队的观察，并且提出了我的共创方案：“在这次共创之前，我们必须先有个复盘环节，否则，以咱们团队现在的这种合作状态，根本没法很好地共创。咱们得提前准备，我需要你的大力配合。” 他很快就认可了我的方案，并且惊讶地问我：“你是怎么做到在这么的短时间内捕捉到这么多复杂的背景信息的？”你可能也很好奇，事实上，这就是感知力在现实场景中的运用。要想培养感知力，你需要经历三个层次。 第一层：现象层。这一层观察的焦点，是在“冰山上”的行为。比如，你观察到开发和产品在会上吵起来了，这时，你注意到的是行为，还不是真正的感知。
第二层：意图层。这一层观察的焦点，是在“冰山下”行为背后的真正意图。具体要怎么做呢？最简单的是，多问几个为什么。比如，他们为什么会吵起来，各自想要达成什么目标。仔细思考之后，你会发现，原来技术已经对于产品的频繁变更忍无可忍了，技术 Leader 有很大的压力，想要为受苦受难的开发们出头；而产品的意图也很直接，他们的想法是：“业务 KPI 在那儿摆着，咱能不能别那么磨叽？快速推进不行吗？”观察到这一层，你就很接近冲突的根源了。
第三层：感受层。你要试着从这些现象和意图中，去感受每个人的状态和需要。你会发现，开发的核心感受显然是愤怒；产品直接承担着业务指标带来的高压，老大的想法又一直在变，技术的不配合让他们受到双面夹击，早已是苦不堪言，核心感受是苦涩。
体会到这些之后，你会发现，如果不事先处理好这些强烈的感受，这些人是根本没有办法在一起很好地进行共创的。于是，在共创开始前，我安排了一个之前提到过的复盘环节，就是让每个成员画出自己从项目启动以来的状态、经历，并把其中的“高光时刻”和“至暗时刻”分享给大家。当天，这位负责人第一个发言，跟大家分享了开创新业务以来自己的坎坷经历。他的开放和坦诚让大家一下子轻松了许多。接着，轮到产品，她提到了刚上线就被苹果推荐的成就和喜悦，同时又分享了最近“两头受夹板气”的惨痛经历。开发同学则拿出自己的画，说自己自始至终都是“压力山大”，从来都没轻松过……就这样，大家开始一点点地敞开了心扉。
那些平时看不到的真实一面，被集体看见和理解之后，团队内部淤积的压力也终于得到了释放。于是，大家开始聚焦在共创下一步真正有效的解决方案。总之，要想培养感知力，就要在日常的观察之中下功夫。从关注行为，到关注行为背后的意图，再到关注意图背后个体的核心感受和深层需要，最后着眼于团队中的气场和互动品质。
# 3.4 透明力
信息力和感知力是对环境的观察、观察、再观察。你需要注意的是，这些观察的结果只有透明出来，才能发挥效用。你要想办法把你看到的问题可视化，让决策者和团队都能看到这些问题。这就是我经常说到的透明的力量。
我在一个团队中经常听到这样的声音：“搞什么需求评审、交互评审？要做什么先说好，然后就别再来烦我了。让我安静地写会儿代码，不行吗？”于是，这些评审会能不开就不开。结果，在 Deadline 之前，需求稿、设计稿和技术方案的问题不断爆发，要熬上好几个通宵，才能保证版本的正常发布.但是到了下一个版本，情况依然如此，循环往复。
经过仔细了解，我发现，如果在早期投入精力的话，这些导致发布延期的大多数问题都是可以有效避免的，发布的风险也会大大降低。实际上，定位问题并不难，但是要想解决这个问题就很难了。因为这个团队三四年来一直都是这样，他们早就已经习惯这种模式了。想要引发改变，不是仅凭一人之力就可以做得到的。要打破这个恶性循环，就一定得让大家真正地看见问题，并且从心底里达成共识。
我教你两个透明化呈现的方法：一个是“分析−思考−看见”，一个是“目睹−感受−看见”。前者走脑，是指借助数据、事实、逻辑分析等，调动头脑的智慧，创造共识；后者走心，是指运用图片、视频、故事等形象化的元素，调动情绪的力量，创造共鸣。如果你能结合起来用，效果会更好。
在一次版本总结回顾时，我给大家讲了一个“熊猫大侠”的故事。这位“熊猫大侠”是一个苦兮兮的程序员，他有着熊猫一样的黑眼圈，他的黑眼圈是怎么来的呢？我以这个问题为切入点，以故事的形式带领大家回顾了整个版本进行过程中的一幕幕场景，从上个版本结束时的“累觉不爱”，需求评审会上的睡意朦胧，讲到提测前对设计方案的争执不下，最后到上线前的“兵荒马乱”。“熊猫大侠”的故事，使团队成员深度地看到了项目的现状，并产生了共鸣。接着，我晒出了各种过程数据，包括需求变更率、需求和设计问题发生的阶段及成本、各阶段等待时间、研发负荷度等，邀请团队一起来想办法解开 Deadline 的“魔咒”。
看见这些事实和数据之后，大家才真正地意识到早期那些看似无聊的评审工作的重要性。除此之外，团队还进一步定义了各角色的协作规则，以达到更合理的节奏。最后，在团队的共同努力下，我们进一步建立了基于过程数据的效能改进机制，各角色的协同状况得到了持续的改善。所以，你看，想要改善什么，就把什么透明化！在走脑的同时又要走心，让团队的所有人都看见问题，调动起集体的关注力和改变的动力。这样的话，这种透明的力量就会自然地推动变化的发生。
# 3.5 影响力
项目经理无权无势，行走江湖，靠的是大家肯买你的账。能让他人买账的这种影响力，对个体来说，就是说服力；对群体来说，就是感染力。人们通常认为，要想提升影响力，一定要能讲，会讲。但很有意思的是，影响力的真正秘诀却在于“听”，而不是“讲”。 我曾经跟一位产品总监合作，他本人聪明又强势，属于公认的特别难搞的类型。有一次，他主动跟我说：“别人跟我讲话，我向来只听两句就忍不住想打断，但是你说的话，我几乎全都听完了。”他之所以会这样说，并不是因为我的表达能力比别人强、我的逻辑更清晰、我的话更有道理，而是因为在他讲话的时候，我做到了真正的听。跟其他人相比，我更懂他的逻辑，我明白他是出于什么样的考虑，才会那么说、那么做的。我给他提的每一条建议都是建立在我对他的理解之上的，所以才能被他听进去。
不听，是一切沟通问题的根源。要想增强你的影响力，你需要先培养“听”的能力。那么，该怎么培养这种能力呢？我给你分享一个小技巧。你可以找一位项目中的成员，请他聊一聊，在最近的工作中，他有没有什么高兴或者烦恼的事。在听他说话的时候，你一定不要打断他，也不需要特意去想自己该怎么回应。你只要简单地把注意力放在对方身上，清空你的思绪，打开你的所有感官，留心去体会对方的状态和需求就可以了。试着保持至少五分钟的专注，并在结束后记录自己的体会。
同时，我鼓励你跟对方分享一下，在刚刚的对话中，你留意到了什么。另外，你也可以跟他沟通下，有没有什么事情是你可以帮他一起做的。实际上，在真正有说服力的对话中，恰恰并不存在什么“一定要去说服”的想法，这又是一个有意思的悖论。实际上，只有当你真诚地抱着想要了解和倾听对方的愿望，放下对自己的想法的执着时，你才能留意到对方真正的需要。这样自然的交流分享，反而更容易产生碰撞，引发共振。如果你能够在你的每次工作对话中有意识地坚持运用这个小练习，半年之后，你的影响力就能够得到很大的提升。
# 3.6 整合力
在一个业务团队中，除了总负责人之外，项目经理往往是唯一站在全局层面的人。毕竟，其他人都各有各的职责分工。在这样的定位之下，项目经理一定要成为一个“多面手”。因此，优秀的全局整合能力非常关键。简单来说，整合力就是把互相分离的部分连接在一起，使它们发挥出整体作用的力量。一群优秀的人结合在一起，也并不一定能成为一个优秀的团队，不一定能真的做成一个业务。作为项目经理，整合力就意味着你要去主动发现项目组中的各类风险和问题，综合运用各种能力，跨部门、跨角色地整合资源，以实现全链条的共同目标。
关于整合力，我定义了两个“凡是”：凡是能促进业务良性运作的，凡是能促进团队健康发展的，都是整合管理的范畴。举个例子，我身边有个项目曾经遭遇到了发展上的瓶颈，军心溃散，士气低落，这时，我就变身成了教练，借助教练技术，给业务负责人及核心团队“照镜子”，帮助他们看到限制他们的模式到底是什么，促发团队进行深度思考和交流，共同梳理出当前局面之下最好的思路和打法，从而帮助团队更好地走出困境。所以，你看，所谓的整合力，就是不受限于你自己的角色、从头到尾把事做成的能力。这种整合力来源于你对项目环境的观察和感知，最后要落地到全局层面的行动中去。
在“六力模型”中，执行力是从现在的“行”开始，想要影响别人，就要先做好自己，走出自己的小圈圈，去承担更大的职责，并且把你在日常执行中遇到的每一个问题，都视为一个开启新循环的机会。信息力和感知力是指你要不断拓展自己对环境的准确认知和把握，观察、观察、再观察，从复杂的系统中找到一个恰当的发力点，通过把它有效地透明出来，让集体共同看见，从而获取新的共识，也就是新知。最后，你还需要通过影响力和整合力去践行这个新知，反向影响和改造环境，最终推进新知的有效落地。