8 个技巧 做个有原则不撕逼的运营

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

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

场景1:

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

场景2:

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

场景3:

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

场景4:

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

以上这些,是不是似曾相识的场景?

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

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

1,自己梳理先行

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

1)、这个需求的目的是什么?

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

3)、这个需求外部(包括竞争对手)的常规做法是怎么样的?

4)、这个需求是常规性需求还是偶发性需求?是长需求(升级改版)还是短需求(功能优化)?

5)、这个需求的紧急程度怎么样?

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

2,内部沟通先行

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

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

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

3)、需求是否有什么遗漏的地方?

4)、对需求的各个细节,大家是不是还有不同意见和建议?

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

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

3,信任是沟通的前提

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

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

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

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

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

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

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

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

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

5,把握原则,适当妥协

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者 奔跑的大橘子

关键字:产品运营, 运营

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部