层会议发言结构助力推动跨部门合作

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