工欲善其事，必先利其器。SOP、MVP是跨部门沟通的神器，达成共识就是这么简单！
Daisy是某互联网早教公司的员工，最近老板把她提升为项目负责人，这本来是件高兴的事，但是在项目推进的过程中，痛苦的事来了。第一次和兄弟部门沟通的时候，Daisy提了项目的需求，兄弟部门的同事表示理解了，也约定了项目进度表。可到了交付的时候，Daisy却傻眼了，交付物和预想的差距很大。再次开沟通会的时候，Daisy提出了改进的要求，兄弟部门的同事表示自己是加班加点才按进度表完成了交付，要大规模进行调整，需要给出明确的方向，而且部门的人员配置可能也难以达到Daisy的要求。不改，项目质量难以保证，改，又不知道具体该怎么该。
Daisy的困境是很多职场人工作的一个缩影，跨部门沟通，做好了皆大欢喜，做不好，自己可能就成了“背锅侠”，其实，只要用好SOP（标准作业程序）和MVP（最小化可行产品）两个工具，达成共识就是这么简单。
SOP——避免“鸡同鸭讲”
SOP是英文Standard Operation Procedure的缩写，翻译成中文是标准作业程序，就是将某一事件的标准操作步骤和要求以统一的格式描述出来，SOP的精髓，就是将关键控制点进行量化。
举个例子，在Daisy供职的互联网早教的公司中，内容部门和场景搭建部门是两个需要频繁沟通的部门，内容部门根据教育部等国家部委或者专业机构的要求，编写相关的内容。场景搭建部门根据内容部门提供的内容进行场景搭建。两个部门的人在开沟通会的时候可能会出现以下场景。场景搭建部门的人的说：“给我们一个幼儿园安全教育的脚本，我们根据脚本开发场景。”内容部门的人说：“好的，今天给你一个脚本，明天我们要看到实际的场景。”第二天，内容部门的人看到场景后，说：“这个幼儿园场景中教室的设计更像小学的教室，需要改；游戏园地中注意事项的部分文字太多，需要转换成动画；测试设计中，指引的标识不明显，孩子不好找……”一堆要求提完后，双方都很崩溃。
其实，在这个例子中，需求是以“脚本”的形式呈现的，但是，双方对“脚本”的理解可能是不一样。内容部门的人理解的“脚本”可能是我们要将权威机构对幼儿园阶段需要掌握的安全知识以知识点的形式提供，场景部门只要将知识点的文字视觉化就好。场景搭建部门的人理解的“脚本”可能是：提供明确的场景描述，比如幼儿园的场景可以划分为教室、游乐场，教室中有桌椅床等设施，在教室中，磕伤是以图片+语音形式展现，空调着火后的逃生是以动画片形式展现。在不界定“脚本”细则的前提下，虽然双方在沟通的时候，表面上看起来是达成了共识，其实是“鸡同鸭讲”。
用SOP来规范内容部门和场景搭建部门的沟通，对“脚本”进行细化和量化，以下几点可以参考：
1、标准：内容的编写是参照***颁布的幼儿园公共安全教育指导纲要
2、要求：教室里发生火灾后，幼儿园孩子可以在老师的指导下有序逃出教室
3、成效：学习完这套课程后，幼儿园孩子可以在老师的指导下有序逃出教室
4、场景：幼儿园的教室
5、展现形式：空调着火是图片+火苗的特效方式呈现；老师组织幼儿排队逃生以动画片的形式呈现，动画片需要呈现*****等几个步骤；逃生后的安全测试，是以情景再现的图片形式呈现，指引幼儿点击图片选择。
6、语音特点：要充分考虑幼儿的理解力，可以参考央视早教栏目《小小智慧树》节目的语言风格。
MVP——降低试错成本
MVP是英文Minimum Viable Product的缩写，翻译成中文是最小化可行产品。以MVP进行小样调研，通过反馈不断进行迭代，可以大大减少了试错成本。
还以Daisy的案例分析，作为项目负责人，她不仅要和内容部、场景搭建部门沟通，还需要和市场部、销售部门等部门进行沟通。比较高效的方法是在做SOP（标准作业程序）的时候就邀请各部门的人参与沟通，就SOP达成共识。在以SOP开发出MVP（最小化可行产品）后，邀请各部门的人通过各自的渠道去收集反馈。比如，开发出了幼儿园教室着火逃生的场景后，内容部的人拿着MVP找教育专家请教这样的表现形式是不是符合3-6岁幼儿的认知特点；场景搭建部的人拿着MVP会找玩家测试玩起来是不是顺畅；市场部的人会拿着MVP根据场景特点，制作几个版本的宣传文案，进行小范围测试；销售部会拿着MVP去收集客户的反馈意见，等到各个部门将反馈意见汇总后，将MVP根据反馈进行迭代，然后再沟通制定新的SOP去大规模进行产品开发，这样可以避免“闭门造车”，最大限度降低沟通成本。
对于做项目和做产品的人来说，跨部门沟通，最怕的是“鸡同鸭讲”，各自都以为自己明白了，其实都是站在自己的维度中去思考问题，这时候可以通过共同制定SOP的形式达成共识，在此基础上，生成MVP，再通过各自的渠道去收集反馈，对MVP进行迭代。跨部门沟通的这两个工具你学会了吗？
下期预告：达成共识，除了用SOP，还有一个好用的工具是乔哈里视窗，下次咱们就唠唠它的用法。
