流程与规范只是一个保障的工具,而不是一种方法论

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

规范和流程,通常是建立在已经出现过问题或影响的情况下。

yunyign

开个宗明个义

世上本没有路,走的人多了,也就成了路。

鲁迅先生写下的这段文字,其实对于所谓的运营规范和运营流程,是很有意义的。

前两天在朋友圈看到一个动态,笑死我了。

你们公司只有6个人,也在疯传张小龙《警惕KPI和流程》文章,要认真学习和反省,话说首要任务,是不是把人数做到1000人以上?

我非常开心地点了赞。

为什么呢?

其一,很多话,别人说出来是傻逼,但张小龙说出来就成了真理。

其二,一旦一些话成了真理,信众就会不分青红皂白全盘接受。

譬如,如果有一天,笔者有张小龙一半的牛逼,我估计很多人和人争论的时候就会甩出我的文章:

你看!大神也是这样说的!

但很可能,这篇文章的结论已经被我自己甚至其他人推翻过了的,也是可能的——只是你并不知道而已。

要聊运营的流程和规范,首先必须明确:

  1. 这个话题下没有绝对真理;
  2. 流程和规范都是应运而生,而不是任何时候都必须有;
  3. 没有掉过坑里,不存在规范;没有出过问题,不存在流程。

然后,需要大家思考:

  1. 对于运营来说,流程和规范是必需的吗?
  2. 流程和规范建立的过程究竟该是什么样?
  3. 怎样让流程和规范不要成为约束,而成为推手?

接下来,我就开始瞎扯淡了。

无坑不规范,无责无流程

规范,是为了防止不规范;流程,是为了防止责任不清。

如果不明白这两个前提,那么,一切讨论都是没意义的。

我们用活动策划案的规范来举例子好了。

如果你读过《从零开始做运营》,你应该记得我提供了活动策划案的标准结构:

  1. 活动主题:活动文案的一部分,让用户看的懂,明白你的活动是什么主题,是否对他有吸引力。
  2. 活动对象:明确你的活动针对的群体,让用户看的懂,让自己抓得住,让领导认可。
  3. 活动时间:活动的开始时间、结束时间,奖励的发放时间、领取时间。
  4. 活动描述:活动文案的一部分,让用户看得懂,决定要不要参与,怎么参与。
  5. 规则详情:活动文案的一部分,让用户看得懂,让开发看的懂,一部分内容是在前端展示的,另一部分内容让开发知道活动如何实现。
  6. 投放渠道:让市场看的懂或者你自己看的懂,要有投放时间、投放渠道的选择、预算。
  7. 风险控制:让开发看得懂你的风险环节是什么,有无对应的措施来解决。
  8. 监测指标:涵盖大多数相关指标,包括投放渠道的监控、用户参与情况的监控、奖励发放的监控,等等。可以帮助你在查看数据的时候找到问题点,并且启发你去解决这些问题。
  9. 成本预估:一个活动要多少钱,单人成本多少。不一定非常准确,但是必须要有这个意识,活动有不花钱的,但是如果要花钱,你要明白一个活动的容量有多大,对指标的帮助在哪里,为了这些利益,你需要公司拿出多少钱来支持。
  10. 效果评估:有成本就有收益,你的活动的目的对网站/产品的那些指标是有帮助的,如何体现,你要考虑,让领导认可。
  11. FAQ:可以另外准备一个文档,提供给客服或者相关人员,帮助解决用户在参与活动中产生的困惑。FAQ要详细、标准。如果活动规模大,光FAQ还不够的时候,你要提前准备客服的培训文件,并积极进行沟通。

事实上,这个结构本身就是各种坑趟完了之后的结果。

活动主题、活动对象、活动时间、活动描述、活动规则(其实还有奖品设置,但策划案中丢到成本里去考查),这些内容主要是针对用户的,部分是针对开发的。如果在这些部分里有遗漏或者残缺,那要么开发看不懂,要么用户看不懂,但肯定一定会出问题。

投放渠道,这是要求运营人员在做活动策划时充分结合活动对象以及相关预算,去做对应的投放,如果遗漏或者残缺,要么你是大平台,自己有搞得定的资源,要么宣传十有八九要出问题。

风险控制、监测指标,这是给开发和运维人员看的,同时你自己要心中有数,知道哪个监测指标出现异常时其背后的原因是什么,因为一旦设置了这两项,一个比较完整的流程中,就会对应有报警机制,出现警报,你总要知道问题可能在哪儿,以及找谁处理。

成本预估和效果预期,这是给领导看的,你们家领导不是张小龙,所以钱一定不会白花,在达不到张小龙或者马化腾的心态和level的情况下,领导追求ROI是必然的,而你追求ROI就是必须的,如果你没有成本管控的意识,成本预估你一定是一脸懵的,而如果这里懵了,估计十有八九,风险你也不知道会出现在什么地方,那么监测指标你一定设计不出来,或者胡乱设计。

FAQ,这是给运维、客服、你自己,或者加班的同事看的,碰到问题,当别人找你咨询的时候,你总要有个答复对不对?不做FAQ的运营,一定不是一个资深的运营,因为他搞不懂活动与客服之间的关系,所以,做这行一定不够久,否则客服一定把他抽死。

你会发现,规范的确立,大多伴随着错误、事故、负面影响。

如果没有这些不好,那么规范是没有必要建的,毕竟张小龙说了10人小团队效率高啊,一个bug从提出到修改完成到测试上线,用不着24小时。

是的,那也是因为那产品当时没高层care,才能任由小团队这么干,否则,真出了发布事故,责任谁负?

喔,抱歉,我谈到了流程了。

那就谈流程吧。

流程的核心在于「可追溯」、「可定责」。

你说,开发难道不能自己开发完了之后打包更新到服务器么?

可以的,但是,测试谁来?覆盖不到常见的异常流程出了岔子怎么办?运维谁来?一共有100台服务器,开发每台服务器自己传?传错版本包怎么办?

所以,如果专业的人来做专业的事儿,至少出了问题,打板子打在相关节点身上,而不是打在所有人身上。

譬如这样一个场景:

甲要修改某件商品的价格,结果少打了一个0,系统里没有设计自动检测价格异常的功能,只是需要甲的领导M审批。

M觉得甲一直很靠谱,正好赶着开会,甲又催上架,心说没事儿,审批通过了。

结果商品库存都给刷爆了。

老板追究下来,甲死定了,M也逃不掉。

因为M审批了流程。

但如果没有流程,完了,死无对证。

所以,流程是为了分清责任在谁那儿。

效率与公平

规范和流程,通常是建立在已经出现过问题或影响的情况下。

所以,规范和流程,都是为了规避同类问题的再次发生而产生的的,其目的是为了尽可能的确保效率与公平。

但实际上,基于风险控制而设计的规范与流程,不可避免的对效率会产生影响,而且不论多牛逼的公司,结果一定是降低了效率。

这很正常。

张小龙也知道吐槽,10个人的团队,有个什么问题,随便走两步就能拉到负责的人,白板一些,嘴上一聊,齐活儿开搞,结果100来号人的团队就开始需要预约开会解决问题了,这效率当然比不上小团队。

不说别的,一个team里,一个产品一个运营一个开发一个设计,好歹出了啥问题都知道找谁聊。

你变成4个产品4个运营4个开发4个设计试试?搞不好你一天下来,都没机会看到16个人同时在座位上。

但是否没有解决方法呢?

其实有的。

做法也很简单:

把规范和流程真的只是作为一个保障的工具,而不要把它变成方法论去操作。

说不好听的,我上面写的活动策划案必须是这个结构么?

未必啊,你只要能够覆盖到我说的可能的坑,你怎么写都行。

如果你被规范束缚住了,你就是真傻。

说不好听的,一定要等流程通过才做事儿么?

未必啊,有些流程你就应该把它当作是一个事后备案来操作。

譬如,你是一个负责短信通道的运营人员,整天接别人的发布需求,标准流程,你要接到需求单才能做事情。

可是,谁规定了需求方不能事先先和你沟通清楚文案,然后再和领导走流程签字确认呢?

喔,当然了,如果你们已经是超过几千人的大企业,你当然可以这么干,因为前期沟通的成本太大了。

但是,凡事其实都可以考虑的更加高效和简单一些。

这是我的看法。

#专栏作家#

张亮,微信公众号:zhangleo1983,人人都是产品经理专栏作家。知乎大V,互联网从业者;《从零开始做运营》作者。聊产品聊运营,偶尔深度。分享一切有益有趣的内容。

本文原创发布于人人都是产品经理,未经许可,不得转载。

您的赞赏,是对我创作的最大鼓励。
2人打赏

评论( 1

登录后参与评论
  1. 小公司不讲流程是对的,但公司一旦到达某种规模(500人左右吧),跨部门配合就需要流程做支撑,不然就协调扯皮会把人累死的。不能指望所有人都以老板的心态在工作,从公司层面考虑问题;每个人和团队基本上都是从自身的角度和利益出发,局部最优不等于全局最优,这也是流程存在的价值。

    回复
加载中