都说产品是亲妈，运营是奶妈/养母，一个生一个养，但都把孩子当作自己的，自然免不了常有撕逼发生。

在公司经常会出现这样的场景：

场景1：

运营对着产品说，为什么别人能做我们不能做，我们就是要做。产品说，和你解释不清，不能做就是不能做。运营哭着说，这届产品和开发不给力。

场景2：

运营对产品说，这个需求领导说要改成这样。产品说，怎么又要改？运营说，领导就是这么要求的。产品蔑视说，这届运营真傻逼，一点都不专业，需求变来变去。

场景3：

运营对产品说，我刚写了个运营需求给你，你今天和开发说明天活动要用这个功能，让他们赶紧开发。产品说，时间不够不可能。运营说，都说好明天上线了，加班加点完成吧。产品和开发边加班边说，这孙子是想折腾死我们。

场景4：

运营说，你怎么这么开发的，我需求里明明是那样写的。产品说，你的表述有分歧，没有沟通清楚，现在到这个时间了你看怎么办吧。运营吐出一口老血。

以上这些，是不是似曾相识的场景？

当然，这都还是比较和谐的场景，背后投诉后面骂人，性子火爆点的都是直接开骂直接开撕，最后视同水火，产品给运营设小门槛，运营给产品使小心机，扯皮推诿，活儿推进越来越难。

如果确实是对方人品问题，开撕自然得撕。但事实却是：很多都是因为不了解不信任沟通不畅造成的不必要的撕逼。就和家庭教育，家长最好要保持教育观念一致一样，其实对于产品来说，也只有产品运营亲如一家，孩子的教育才能够做得更好，孩子也才能够健康成长。今天就说说运营怎么避免和产品撕逼的小技巧：

1，自己梳理先行

运营在提需求前，建议一定要先做梳理：

1）、这个需求的目的是什么？

2）、这个需求涉及到哪些功能？是否与已有功能相关？

3）、这个需求外部（包括竞争对手）的常规做法是怎么样的？

4）、这个需求是常规性需求还是偶发性需求？是长需求（升级改版）还是短需求（功能优化）？

5）、这个需求的紧急程度怎么样？

等等，不止是做到对将要提的整个需求心中有数，而且最好进行记录，用条理清新的文字、流程、框架将需求一一理顺。

2，内部沟通先行

需求准备好了，然后就可以和产品沟通了？当然不。因为运营是一个整体的团队，建议在需求对外前，一定要组织运营内部外议，对已经梳理清楚的流程进行内部沟通。沟通的点包括：

1）、需求是否能够满足接下来的运营要求？

2）、对紧急度、常规/偶发、长/短的判定是否存在不同意见？

3）、需求是否有什么遗漏的地方？

4）、对需求的各个细节，大家是不是还有不同意见和建议？

5）、需求对外时可能遇到什么问题，如果遇到，我们的应对性方案是什么？最高标准是什么，最低准则又是怎样？

内部先就整个需求达成一致性意见，将避免对外的时候需求一旦出现不同想法和差错，要对需求进行频繁变更。而且，内部沟通可以让运营的需求目的性更明确，需求更完善。

3，信任是沟通的前提

当内部达成一致之后，运营就要与产品进行初步沟通了。

常常有这样的运营，在沟通开始之前就预设了立场，觉得公司的开发人员能力不行，公司的产品逻辑不好，诸如此类。正是因为预设立场，一旦沟通一开始没有得到认同和满足，就觉得对方是在为难和刁难。

正因为预设了立场，在正式沟通的时候，一旦遇到了挫折，比如需求会驳回或需求时间被延长等时，就会觉得是对方的问题。

但事实上，我经常遇到的情况是，几乎没有一个产品和开发是不希望自己的“孩子”更好的，需求被驳回背后通常有他的客观情况，继续沟通通常都会有对应的解决方案，有时候从产品方给出的解决方案会比原本的更加完满。而需求时间被延长更是常态，但最终的结果却是没有一个需求会要到截止时间才交付，deadline只是产品希望给自己和开发都留下更多的余地。

总之多一点信任，沟通就会顺畅很多，结局也可能会好很多。

4，运营产品是协作关系，不是上下级关系

因为运营在面对产品、设计、数据分析等其他部门的时候，都是提需求的一方，所以经常会让有些运营产生一种整个公司都是在围着自己转的错觉，于是在提需求时会不自觉使用一些命令式的语气，比如“你应该”“必须”“一定”“就是”“你别管”之类的，觉得产品都应该服从运营的需求。

但运营和产品从来就不是从属关系，而是相辅相成的协作关系。运营更多的接触用户，了解需求，而产品则比用户和运营都更加了解产品，一起碰撞，才能带来更多火花。

职场上有些人天生就喜欢用命令式的语气，但这种人要有足够的气场、能力、资历和知识储备来支撑，否则就是外强中干徒增笑柄。所以，如果不是实力超群，还是低调点，先学会合作再说。而且，大多数越是实力超群的人都越是没脾气，越是愿意和人平等交流与沟通。

5，把握原则，适当妥协

不能轻易和产品撕逼，要尽量达成意见统一的合作，是否就意味着运营要一味相让，产品怎么说就怎么听呢？当然不。

这就是我之前在说第二点时，为什么建议运营内部在需求对外前，一定要沟通确认需求的基本原则和基本底限。

运营需求基本原则最核心的是要以目标为导向，当产品否认运营提出的需求时，需要产品提出的替代方案，而替代方案能够在指定时间内达到运营要求的指定目标。

在此基础上，一些无关大局的小问题可以适当妥协，比如功能的后台操作位置是放在哪里，原本的功能要求是以天为单位而产品要求以次为单位等等，目标是一致的，面对产品从开发的逻辑和产品的专业性角度提出的建议，不要一味坚持己见。

6，主动承担，主动寻找替代方案

当然，并不是每一个需求，产品都能够根据运营的目标要求找到替代方案，更多的时候是，产品有自己的一层判断，比如觉得运营的需求因某个关键接口没有开放权限完全没有可行性，又或者开发后运营起来可能会带来其他具大风险，又或者评估的结果是开发周期、投入成本与实际需求的产出不成正比。

面对这些情况下，运营需要做出分析，主动承担起一些对外沟通，风险运维管理等的活，甚至一些产品流程梳理的活，运营不妨多多承担，既是自己学习的一个过程，也能够让产品看到你的诚意，进而再重新评估，与主动帮忙考虑替代方案。

当然，实在是不靠谱的需求，就不要一味死撑，大家一起重新来寻找一个新的替代方案，或者比死嗑在原来的想法上更为有效。

7，反复沟通，多点耐心，细节是王道

一般产品根据运营的需求，准备好开发需求文档、功能原型图、逻辑流程图等后，都会再次和运营进行确认是否与运营需求一致。

这时候就不要再做好好先生，而一定要做个“找茬王”，仔细的关注这里面的每一个细节，从专业的角度 、用户的角度、后台操作的角度等等方方面面来确定规划与需求是否一致，在这个环节里面，多点细心、多点耐心是运营必须要有的态度。

产品接需求了，同时产品也给予了反馈，接下来要做的就是圆满的完成整个需求项目。所以，不明确的地方，一定要仔细询问；不清晰的地方，一定要理顺；有不妥当的地方，一定要沟通更好的解决方案，尽量将细节做到极致。

说到细节，我想说一些题外话，产品经理的素养可能让他们也会从用户的角度去设计功能按钮，但是最了解用户的毕竟是运营，所以请一定要和产品一样培养一颗以用户为中心的素养，有时候，从用户角度考虑一些页面停留时间、返回页面、按钮设计、跳转设计等等，都能够增加用户对平台的好感度，有效的提升转化率。

8，跟踪常态化，随时了解进度

需求确认，产品将需求提至技术开发以后，是不是就万事大吉，只要坐等在需求截止时间产品的反馈了？我的个人建议是千万不要这样。

需求进入开发阶段，产品会定期跟踪，而运营也最好实现跟踪的常态化，清楚在开发过程中遇到的问题，清楚开发的进度，清楚各个技术难点等等。

这样的好处，一是可以在内部沟通时有相应的反馈；二是如果运营项目有其他新的需求时，能够保证心中可以对紧急度、可执行性等有更好的评估；三是经常跟踪需求的完成情况后，运营会越来越熟悉各类型的功能开发大致的开发时间、测试时间等等，有助于以后提需求时，给产品和开发预留更加精准的完成时间。

以上8点，总结起来就是多从自身找原因，多为目标想方法，多学多做多思考。希望我们都能够做一个有原则但绝不轻易撕逼的运营。