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

开个宗明个义

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

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

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

你们公司只有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，互联网从业者；《从零开始做运营》作者。聊产品聊运营，偶尔深度。分享一切有益有趣的内容。

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