很多人都有类似的经历，当需要其他部门同事配合完成工作，项目需要跨团队协作时，总是会遇到重重难题。如果没有做好沟通，可能会影响后续项目进程。如何在会议上发言，让对方接受你的方案，推动跨部门合作？本篇文章分享了会议发言的技巧，供大家一起学习参考。
我先来描述下一个场景，你就是其中的主人公：
你是公司的一名数据分析师，工作非常忙碌，但总是有其他业务部门的人跑过来找你提临时需求，导致你经常无法按时完成既定工作，严重影响工作效率。于是，你想出一个对策，制定了《业务部门给数据团队提需求的流程和规范》。
这天，你约各业务部门负责人开会，要求他们以后的数据需求必须按照流程走，否则都不接受。但其业务部门往往是老大，他们业绩好、功劳大，并不重视你的要求。这时候，你在会议上要怎么陈述自己的方案，才能推动这件事走下去呢？
当然，这个案例我做了简化。在实际工作场景中，你是需要提前跟一些刺儿头一对一沟通清楚、获得他们认可的，然后你才能开大会，否则肯定会被自己坑死。
我相信，很多人都有相似的经历，当你想要其他部门同事配合你的工作时，总是会遭遇各种推脱和阻碍。你需要不断推进工作，这种”推进“其实是一种很常见的高难度沟通场景。
现在很多公司都有项目制，都需要跨部门、跨团队协作推进。但一旦涉及其他部门，往往在进度安排、角色分工和资源调配上，会出现各种各样的矛盾。而且在沟通中如果不能好好说话，很可能影响团队间关系，影响项目进度。
为什么跨团队合作和沟通总是这么难？
原因主要有2点：一是，各个部门的优先级事项不同；二是，各方的理解存在偏差。
第一点，各部门优先级不同，我想你应该能理解。像上述场景中，尽管规范数据流程对数据部门很重要，但对业务部门其实没那么重要。如果因为要走数据流程，而耽误了他们的销售业绩和时间，那才是绝对不能接受的。
第二点“理解偏差”，是指各方对合作事项的理解不一致。比如，双方对任务难度理解不同。数据团队认为提需求不就是填个系统表格嘛，多简单呀。但业务团队却认为要填写申请特别麻烦，他们有别的事要忙。再比如，双方对任务需要交付的时间理解不一致。数据团队认为的“尽快”是在当天完成，而业务团队则觉得“一周”也挺快了。
搞清楚这两个背景，我们就能够在心态上接受跨团队沟通的挑战，从而能够做得更好。
面对这种情况，怎么做？
今天这节课，我们先把这个问题简化为：在跨部门合作的沟通会议中，要如何陈述方案，才能最大程度地避免这两种偏差，顺利推动合作发生呢？
首先，你需要明确一个职场跨团队沟通的原则，那就是谁痛谁负责，谁痛谁解决。在上述案例中，如果临时数据需求已经严重影响你的工作了，那你必须以负责人的姿态，主动去推动合作，因为别人是没这个动力的。
其次，你需要在会议的一开始就明确地陈述你的想法。很多人存在误区是，以为自己讲清楚了，但其实参与会议的其他团队同事还是一头雾水。
这里我给你提供一个陈述方案的架子，你可以参考。
因为陈述方案的目的既是解决问题，又是推销自己的想法，所以这个架子其实灵活结合了前面文章提到的“解决问题结构”和“FAB结构”（属性-优势-利益）。
这个陈述方案的结构一共有4层，分别是：
为什么（Why）
做什么（What）
有什么好处（Benefit）
马上行动（Action）。
乍一看挺复杂的，但其实是环环紧扣的。我先给你解释下，每个部分分别要说点什么。
第一步是说为什么，为什么部门间需要合作推进某件事情的发生。这部分你可以讲讲事情的背景和问题的严重性。它的核心目的是唤起对方关注，让他们产生“的确是这样，我们要做点什么了”的想法。
第二步是说做什么，也就是你希望参与的各部门在项目中分别做点什么。这里是陈述主张的核心部分。需要注意的是，你给出的陈述一定要明确，以显示你的确经过了深思熟虑，否则别人很容易就反驳你。
第三步是讲讲推进这件事对各个部门有什么好处。这一步很重要，但很容易被大家忽略。说到底，还是没有站在对方的角度想问题。如果你能够为对方的行动创造一个好的理由，那这件事推动下去的可能性至少提高了30%。
第四步，也是最后一步，你要说说马上大家可以完成的行动。在销售话术中，这叫“临门一脚”，敦促大家从静止观望的状态，切换到即将行动的准备状态。我猜，很多人都有这样的感受：会上说得好好的，会议一结束，大家依然没有行动。这其实就是缺乏临门一脚，拆分出最快能够实现的部分先做，让合作先跑起来。
那么针对课程一开始的案例，你可以怎么运用这个结构来表达呢？
你可以这么说：
未来各团队数据需求必须通过规定的流程，否则我们不接受需求。我理解大家提出的每个数据需求都很重要，可能关乎到几十万的营收（认可）。
但是临时需求严重扰乱了原本数据需求的处理进度，导致交付时间一次次推迟，影响了那些按流程提需求的部门，也影响了我们部门的工作效率（Why）。
所以，我结合实际情况，制定了“业务部门给数据团队提需求的流程和规范”，希望每个部门都组织同事学习，并且严格按照流程走（What）。
这样一来，我们的工作效率会提高，也能为大家提供更多的数据支持，而且，这样能够提升各部门同事全局考虑和项目管理能力（Benefit）。
我建议，大家现在先看下这份规范，如果有问题，可以在会上直接和我确认。如果没问题，我会邮件全公司，就算是一个正式通知了（Action）。
怎么样，用了架子，是不是整体表达更有逻辑，思路也更清楚了呢？
