• 2017年7月2日,氧16网正式改版,增加会员登录注册功能,感谢群里小伙伴的支持!
  • 氧16网设计交流1群:331622745,设计交流2群:536159510,欢迎志同道合的朋友加入!
  •    1年前 (2016-06-08)  文章 |   抢沙发  4 
    文章评分 0 次,平均分 0.0

    产品和运营,来打一架吧!

    本文原作者韩叙,从业10年的运营工作者,一直在互联网产品运营的路上,曾任百度高级产品运营师,目前担任猫眼电影产品运营专家。作为一个从业7年的设计工作者,1年的运营工作者,不免有些自己的想法,所以文章会被主观的删减增加,还请各位看客海涵。

    一个互联网产品团队,核心角色是产品、运营、研发、UI/交互。这四者之间的关系大致是需求提出方和满足方的关系

    比如运营向产品提需求,产品向研发和设计提需求。产品和运营就是需求提出方,研发和设计就是满足方。

    四者是相互依赖和配合的关系,却分为两大阵营:产品和运营。这两个角色想要做好自己的工作,就必须与对方持续、紧密的配合,缺了谁也不行。

    但是在产品和运营协同工作的过程中,会出现很多复杂又难以解决的问题,所以无论哪个公司都避免不了产品和运营的战争,分别举例如下:

    一、运营认为,产品不重视运营,但运营却要为产品背负责任:

    为什么 PM 做功能从来不和我们讨论,他们懂用户需求吗,懂行业吗?功能上线后用户骂声一片,就让运营出来安抚一下、解释一下,其实就是擦屁股。好容易有几个版本的效果好,PM 就在群里邮件里开心的写着效果评估。其实那是因为运营的核心用户在挺我们啊,是我们为新版策划了活动啊!

    为什么运营提的需求总是优先级最低的?提一个需求还按必须给什么效果预估,没上线怎么预估,这不是形式主义忽悠人吗?什么需求都要运营想透彻会影响哪些代码问题,那开发能不能在开发时候想想看怎么方便运营推广呢?

    二、产品认为,运营总是没起到应有的作用:

    运营什么时候才能不盯着 KPI 做活动,数据倒是上去了,怎么不看看留存呢?运营形式总是模仿别人的,不断的试错,一点延续性都没有,功能改来改去,把产品搞的乱七八糟乌烟瘴气,什么需求就马上要,产品不稳定了还怪我们。

    为什么运营就不能具备一些基本的产品思维,别再提那些不着边际的需求了,这和用户直接反馈有什么区别,害得我们还要花时间去解释为什么不做。我们需要的是爆点,不是小打小闹。运营你说你懂行业朋友多,那就多请一些大腕来活跃啊,帮着传播推广啊。

    以上描述看似极端,但很真实很有代表性,相信很多公司的产品和运营同学都有过类似感受。因此,让这两个角色配合默契、有序运转、形成合力,并不容易。

    下面就聊聊产品和运营这亦敌亦友的关系。

    1.原因是什么

    产品和运营配合出现问题的根本原因是:两者目标不一致,导致从出发点到具体执行都是两条平行线,不能拧成一股绳,就无法形成合力。由此可见,将产品和运营的目标统一,是解决这个问题的核心点。

    为什么会存在目标不一致的现象呢,因为屁股决定脑袋。从组织架构的角度说,很多公司的产品和运营分属两个团队,由两位不同的老大负责。既然团队和老大都是两个,那么目标肯定也是两个,否则就无法衡量这两个老大和两个团队的价值。比如,两个人炒一盘菜,一人负责切,一人负责炒,那色香味俱全是谁的功劳,味如嚼蜡谁又是幕后黑手,就很难分辨了。如果两个人互相推脱责任,就进入到扯皮阶段了,很难根治。

    一般在团队分工时,都会避免工作内容和目标有重合,保证团队或个人的独立性。这样做的目的是保证员工的个人发展空间,也便于清晰的衡量工作产出,暴露所存在的问题。

    综上可知,因为团队分工的问题,导致了产品和运营的目标不统一。除此之外,两个团队的架构,还会带来其他负面效应。比如两个老大为了争夺话语权,出现对峙的情况。这种状态势必会影响到决策的合理性,最终影响产品的进展。

    还要补充一点就是各方看待问题的角度和态度不同,就算是同属产品的设计和开发、产品和设计、产品和开发也会存在太多争执。在不同的产品团队也会导致不同的阵营:比如产品狗和设计狮一丘之貉,程序猿被动挨打;产品狗和程序猿狼狈为奸,设计狮忍气吞声;程序猿和设计狮暗度陈仓,产品狗无奈唏嘘。无论哪种,对于产品的良性发展都不利!只是影响多少的区别罢了。而在我认识的设计里都或多或少会操着产品的心,然后面对开发和产品的互博,一场争执在所难免!就如我之前所说《需求的一句话:设计的一小步,开发的一大步》

    2.如何解决

    说到这里,想起自己(韩叙)在百度的经历。第一年时,产品和运营是分开的两个独立团队。虽然整体上还算正常,但也会出现各自为战的情况,运营做活动、核心用户和内容策划;PM 为了不断提升转化等数据,做着各种产品优化。单独看任何一方的工作都是正常合理的,但两边同时来看就能发现交集和协作很少。

    第二年时,为了孵化独立的新项目,优化了团队架构,每个新项目都成立独立团队,每个团队都有一位 PM 作为负责人。虽然每个团队都不到十个人,但所需角色都有,比如产品、运营、研发、设计,麻雀虽小五脏俱全。在这个小团队里,虽然每位成员分工不同,但关注的目标是一样的,只是大家通过完成自己的任务去达成这个目标。比如,运营在运营种子用户、建立对外合作、准备预热活动等;PM 在优化操作流程、提升流量转化率;研发保证按照需求和时间点完成开发任务,并且尽量少出 BUG;UI 设计师力求页面效果不仅满足 PM 的功能需求,也符合运营的预期调性。不仅如此,在每天的晨会(站会,10 分钟)和每周的例会(1 个小时)里,大家会抛开自己的分工,一起加入产品的讨论。虽然经常会有不靠谱的建议,但这才像一个团队。

    但这个模式也有缺点,就是只适合 5-20 人的小团队。如果人数增加到 30 人,就肯定行不通了。原因是:

    首先,一个老大直线管理这么多人的成本和难度很高,沟通和信息互通也不会那么通畅。如果老大和员工之间再增设一个层级,变成金字塔式架构,就更复杂了。

    其次,如果是 30 人的团队,那么产品和运营的人数也会增多,比如各 5 个,这就意味着产品和运营分别成立了二级团队。独立的小团队变成大团队,又会出现上文中所说的目标不统一,各自为战的情况。

    所以,如果可以拆分成小团队,或者本是小团队的公司,可以尝试上述的方案。一旦团队规模变大,就不再适用了,这也是业内都很羡慕团队「小而美」的原因吧。

    当然,大团队也不是无解,可以通过扁平化的团队架构,来缓解产品和运营配合不好的问题。比如一个总监同时管理产品和运营团队,这两个团队分别有 1 个经理级中层,再各带一个小团队。这样的三层团队设置,从层级上来讲是可以接受的,承担 30 人的团队也是没问题的。

    可是为什么很多小团队也无法做到目标一致呢?那我们就要反思团队中出现的问题和每个人的想法有没有渠道可以真实表达,团队领导是否服众,能不能解决一个团队中出现的问题,帮助成员解决实际产品困难。最糟糕的情况就是人际关系上的事情了,人心散乱,不战而败!

    3.谁更有话语权

    说起产品和运营的关系,就不得不说话语权的问题。这两者一定会存在强势和弱势的关系,不可能有一碗水端平的状态,只是强弱差或大或小而已。当然,谁都希望能主导项目,但是有时候并非是自己能左右的。

    决定一个团队是产品驱动还是运营驱动,有两个因素:

    团队基因。团队基因主要是创始人团队带来的,所以基本等同于创始人基因。从一个公司,到一个小团队,这个规律都适用。所以,要看一个团队是什么角色来驱动,主要看老大。如果老大是 PM 出身,公司很有可能是产品驱动;如果是开发出身,那么运营的角色一定是很弱势;相反如果是运营出身,势必产品在弱势,说改就改,其他的改完再谈。如果非互联网出身的老大,产品和运营的两个阵营势均力敌,厮杀的会更为激烈。

    产品属性。就是看是什么产品了,不同类型的产品就是适合不同的团队架构,也决定了角色之间的话语权。一个工具型产品,肯定是产品驱动的,比如天气、笔记、拍照类 app,即使渠道的作用很大,但也不会成为驱动方;一个 O2O 产品,肯定是运营驱动,比如团购、到家类 app。

    所以,如果要看一个团队里哪个角色更有话语权,哪个角色是主导地位,就从上面两个因素中就可以看出。

    4.该怎么配合

    那么产品和运营应该怎么配合,才是合理的,是可以发挥双方合力的。我认为,分为产品上线前和上线后两个阶段。当然,可能没有这样纯粹的阶段,但有这样的状态。

    上线前:

    第一步:产品的功能规划以及发展方向,都是老板的决策。在决策完成之后,应该告知团队全员,项目的背景、方向和规划,让大家充分了解信息,对于后续执行的过程是有帮助的。

    第二步:之后执行环节的规划,就是产品和运营协同工作的开始。比如,受众人群、功能特点、版本节奏、运营规划等,应该双方一起参与讨论,得出一个大概的框架和计划。

    第三步:按照框架计划,大家开始分头行动。产品去画原型,定功能细节;运营做准备内容、流量渠道和核心用户,以及策划上线后的爆点。在这个阶段,产品和运营可以暂时分离开,不必有频繁的协作。但由于有了前两步的铺垫,在分头行动的过程中,双方也了解对方的计划和进展,所以信息是互通的。

    第四步:上线前的准备阶段,之前分头行动的产品和运营的双方,就要再次回到一起,交出之前的作业。也就是大家为产品上线所做的准备,进展、遇到问题和后续计划是什么,拿出来互通和讨论。问题都解决后,就可以上线了。

    上线后:

    进入到产品正式运转阶段,产品和运营再次结合在一起协同工作。在这个阶段需要高频次的沟通,以及互相推动彼此的工作。

    运营,主要关注用户反馈。在做好内容、用户、活动、渠道等运营工作的同时,向产品及时和详尽的通报用户反馈,让团队了解用户对产品的反应。关注用户需求,转化为产品需求,推进 PM 上线。提出可以大幅提升运营效率的工具需求,推进 PM 用产品的方式解决。

    产品,协助运营的规划和执行工作,除了修复 BUG 和完成产品需求之外,要关注运营的反馈,因为这是产品投入到用户群体之后的反应,是印证之前决策的过程。要关注运营遇到的问题,是否可以通过产品的方式解决。主动与运营同学沟通,给出解决方案并推动研发完成。还需要关注运营措施是否合理,是否对产品的目标有推进作用。如果发现偏离目标,或者唯 KPI 的行为,要及时沟通并推动改进。

    当然,在产品上线前后可不只是做这些事,上面只是提到需要产品和运营配合的节点。由于每个项目的情况都很复杂,所以上述事项肯定也不全,只能是作为一个思路,举例说明。

    5.为什么不少运营想转 PM

    其实产品和运营的关系,描述起来非常简单。产品负责功能设计,也是研发和设计师等支持满足方的接口;运营负责维护、拉动和推广,机器不能解决的问题,都需要运营来解决。

    在我看来,产品和运营是两类不同但平等的职位,所需人才的类型也是不同的。但为什么现在很多新人更愿意从事产品工作,甚至已经做运营的同学也希望转做产品,主要是因为「产品经理被神话」而带来的供求不平衡造成的。

    主要原因是李开复、周鸿祎等明星Boss或者互联网创业公司创始人,都公开宣称自己是产品经理,把这个职位的工作内容描述的过于理想化,这样就吸引了更多优秀的年轻人投身到这个领域。另外,公司深受影响,更重视产品经理这样的岗位,愿意花更高的薪水去请这样的人才。

    在这样的供求关系带动下,优秀的年轻人愿意加入,感觉职位高大上且薪水高;公司也愿意高价请人,认为产品经理重要,且只有高价才能请来。这就是有些运营人员希望转做产品的原因。

    当然也有不少开发和设计想转岗产品经理,毕竟被压迫久了想尝尝指挥的滋味也可以理解的。

    其实,产品经理当然也要从基层做起,甚至从打杂做起。有很多 PM 已经从业一两年了,还在团队里打杂救火,或者做一些边缘化的事,这都是很正常的情况。

    文章写到最后,还是套用那句老话:理解万岁!产品的成功也许不是每个人的原因,但产品的失败必是每个人的问题,齐心做好产品和推广,毕竟身在一个团队,谁也不想把自己的产品做黄了!

     

    除特别注明外,本站所有文章均为氧16网原创,转载请注明出处来自http://yang16.com/10306.html

    关于
    氧16是专注于分享设计、摄影的原创独立博客,立志打造成为中国优质的设计摄影分享平台。文章涉及平面设计、交互设计、设计教程、创意广告、美图插画和优秀摄影作品

    发表评论

    表情 格式

    暂无评论

    切换注册

    登录

    忘记密码 ?

    您也可以使用第三方帐号快捷登录

    切换登录

    注册

    扫一扫二维码分享