软实力之沟通篇

无论作为程序员还是技术leader，沟通，在我们的工作中起了很大的作用。每个人都会说话，但是会沟通之道的却不是太多，不信你往下看。为了增加代入感，全文都以第一人称“我”来叙述。因为有些案例出自朋友身上。

我把他们分为三大类别：

# 一、向上沟通

# 1.1 雷区一：所有问题都自己扛！

在我还是个刚刚转岗的 PM 小菜鸟时，我负责管理一个项目，代号叫“KK”，这个项目是为公司的战略项目提供底层支撑的。在跟进这个项目的前几个月里，我跟技术负责人阿仑配合得还算默契。但是，我发现他有个特点，就是所有问题，都自己扛。

距离里程碑发布只剩一周了，但在测试时，我们还在不断地发现新的 Bug。以目前的进度和剩余 Bug 的潜在影响来看，按原计划上线，质量风险很高。这天，开站会时，我请团队中的每个人，在白板上画出自己的发布信心指数。总体来看，情况非常不乐观。

我跟阿仑一起做好当天的安排之后，特意提醒他：“现在的情况不是很好，我们最好跟方雷提前报备一下。”我说的方雷，是这个项目的发起人，也是阿仑的上级。阿仑没有应声，转而找旁边的开发，开始讨论别的问题了。我心里很着急，但也只好作罢。实际上，我的担忧并不是空穴来风。方雷曾经在很多个场合强调过，KK 是今年的重点，稳定性更是重中之重。最近几次线上出问题，我们团队没少挨骂。这次的上线风险这么高，要不要及时告诉方雷呢？ 我在方雷的办公室门前，绕了两个弯，各种纠结顾虑，再一想到方雷那严厉的神情，就打起了退堂鼓。最终，我什么都没说，就离开了。新版本最后还是如期上线了，但我却并没有因此感到轻松。且不说遗留 Bug 的潜在风险，由于时间紧张，我们连线上监控都没做到位，也没时间充分考虑应急预案和演练。

正当团队全力补漏的时候，线上还是出事了：底层依赖的第三方服务报错，导致很多线上用户请求失败。大晚上接到客户侧的紧急电话，我们才知道出了事。第二天，方雷在邮件里，劈头盖脸就责骂了我们一顿：“之前我一再强调监控，结果已经预见到的问题，你们都没有做应对，这是非常严重的人为事故！”

看到这里，你觉得我冤不冤呢？其实，我明明知道这样上线会有很大问题，也明白现阶段最好的应对方式是什么，甚至还在心中打了无数的底稿，可以说服方雷调整上线计划。可是，当我站在方雷的办公室门口时，却死活迈不出自己心里的那道坎，这个“坎”究竟是什么呢？首先是层级差在无形之中给我带来的心理压力，包括方雷平日里强硬的作风，都让我有点怵，不自觉就想躲开。

其次，都快上线了，项目还有这么多问题，作为项目经理，我也是有很大责任的。另外，因为阿仑不想去汇报，如果我汇报了，我会觉得像打小报告，不仗义。实际上，做好一次紧急问题的汇报沟通，并不是什么难事。但是，迈过自己内心的那道坎，主动大胆的发起沟通，是做好向上沟通的第一步。事实上，我们首先必须要明确，这类严重影响稳定性的问题，已经不属于可以自己扛的级别了，必须要让上级知晓的。

明确了这一点，处理方式可以有很多种。比如，跟阿仑深入探讨下项目的处境，尝试说服他一起去找方雷。即便他不去，我也可以跟他说明自己的判断和接下来的行动，因为客观暴露风险，合理应对，这本身就是项目经理的职责所在。当然，我也可以尝试用邮件的形式，发一封项目风险告警，客观描述现在的风险和影响，提醒方雷特别关注，等等。

这里的关键是，不管通过什么途径，我们必须时刻从大局出发，让这些项目关键信息，及时有效地流动，保障及时有效的决策。当真正重要、紧急的事情发生时，直接打电话或走过去敲门，确保第一时间沟通，才是更合适的做法。记住，你不需要所有问题，都自己扛。

# 1.2 雷区二：只知道吐槽，不知道争取

在 KK 项目组，连续加班是常有的事，半夜 2 点爬起来升级，也是家常便饭。即便我们的工作强度已经这么高了，线上仍然问题不断，项目组从上到下都压力很大。在如此“恶劣”的生存环境中，团队成员彼此之间就好比“难兄难弟”，私底下经常一起吃饭。当然，少不了的，就是一起“吐槽”。

某个周末，又是一次通宵上线，我们忙到凌晨 4 点多钟，结果更新之后，出现了个突发情况，按照流程果断回退了。第二天，在定位解决问题后，又重新来过。在连续了两个通宵之后，项目得以成功上线，但团队却撑不住了。在看不到尽头的艰苦境况中，吐槽似乎成了最有效的排解压力的方式。比如，我们可能经常听到这样的吐槽：“出了问题挨骂”“没出问题是应该的”…… 刚开始，我也会跟着吐槽几句，因为我也一样，拼死拼活却得不到认可。可是，除了私下吐吐苦水，又能做什么呢？你看，这就是我踩过的第二个“坑”。当团队和管理层之间关系紧张时，很多项目经理会特别容易掉进一个误区，那就是，尽自己的努力帮团队解决问题，脏活累活都自己来。这样的“老好人”，在团队中会有很好的人缘，但是，跟着大家一起吐槽，似乎并不能带给团队真正的帮助。特别是当你同时受到高层压力的驱使，被迫去快速拿结果时，就很容易演变成“夹心饼”，吃苦受累，最后反而落得两头埋怨。

那么，破局的点在哪里呢？答案就是，把“夹心饼”变成“连接器”，成为高层干系人与团队之间紧密联系的纽带。事实上，经过层层汇报，高层干系人能够得到的一线团队的信息，相当有限。很多自上而下的决策，如果不能根据一线反馈，及时调整的话，就很容易走形，偏离本意。作为项目经理，当需要高层重视和支持的事件发生时，该出手时就得出手，引发高层关注，把团队最一手的相关动态信息及时传递给他，争取高层必要的支持，而不是跟着团队一起吐槽。

所以，这一次，我立刻想到了方雷！我应该让他听到团队的声音，让他意识到，长期这样下去的严重影响。而且，他才是解开这个困境的最合适的人。事实表明，方雷的介入，大大提升了团队士气。

# 1.3 雷区三：抓不住重点，给不出方案

某次会议散会之后，我叫住了他。我说：“我们团队最近加班很严重，已经连轴工作好几天了，这样下去，恐怕会……”我的话还没说完，方雷就毫不客气地打断了我，说：“现在这些年轻人，加几天班，就叫苦叫累的，想当年，我加班可多了去了……(此处省略一万字)”

你看，在得到方雷的支持之前，我又踩了一个“坑”，也就是我想说的第 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 整合力

在一个业务团队中，除了总负责人之外，项目经理往往是唯一站在全局层面的人。毕竟，其他人都各有各的职责分工。在这样的定位之下，项目经理一定要成为一个“多面手”。因此，优秀的全局整合能力非常关键。简单来说，整合力就是把互相分离的部分连接在一起，使它们发挥出整体作用的力量。一群优秀的人结合在一起，也并不一定能成为一个优秀的团队，不一定能真的做成一个业务。作为项目经理，整合力就意味着你要去主动发现项目组中的各类风险和问题，综合运用各种能力，跨部门、跨角色地整合资源，以实现全链条的共同目标。

关于整合力，我定义了两个“凡是”：凡是能促进业务良性运作的，凡是能促进团队健康发展的，都是整合管理的范畴。举个例子，我身边有个项目曾经遭遇到了发展上的瓶颈，军心溃散，士气低落，这时，我就变身成了教练，借助教练技术，给业务负责人及核心团队“照镜子”，帮助他们看到限制他们的模式到底是什么，促发团队进行深度思考和交流，共同梳理出当前局面之下最好的思路和打法，从而帮助团队更好地走出困境。所以，你看，所谓的整合力，就是不受限于你自己的角色、从头到尾把事做成的能力。这种整合力来源于你对项目环境的观察和感知，最后要落地到全局层面的行动中去。

在“六力模型”中，执行力是从现在的“行”开始，想要影响别人，就要先做好自己，走出自己的小圈圈，去承担更大的职责，并且把你在日常执行中遇到的每一个问题，都视为一个开启新循环的机会。信息力和感知力是指你要不断拓展自己对环境的准确认知和把握，观察、观察、再观察，从复杂的系统中找到一个恰当的发力点，通过把它有效地透明出来，让集体共同看见，从而获取新的共识，也就是新知。最后，你还需要通过影响力和整合力去践行这个新知，反向影响和改造环境，最终推进新知的有效落地。