编辑导读：在工作的时候，我们习惯会依赖平台化的流程，这样出错概率小，数据和操作路径可回溯。是不是所有的需求都可以抽象出来做平台化运转？本文作者对此发表了自己的看法，与你分享。
在产品经理每天的工作中，总会面临很多流程化的东西，最常见的就是标注数据的需求，每当这时候我总是在想，前人为什么不将这些需求抽象出来平台化运转，这得节省多少精力，多清晰明了。
平台的优势很显然，流程清晰、不容易出错，数据和操作路径可回溯，有段时间，我甚至萌生了一种“万物皆可平台的想法”。但事实，真是如此吗？我们迷恋平台化，究竟是迷恋什么呢？
项飙老师在《跨越边界的社区》中提到一个观点：
秩序，是指从老百姓的日常生活经验出发的一种可预测性。中国人的公共信任度是很低的，因为我们非常不信任具体的陌生人，但是我们却信任一个抽象的系统，比如网上支付手段，这种正规化和秩序化正是中国新民族主义崛起的基础。
机制与系统的秩序，相比于人治，是更容易被信任的，映射到流程上，平台化的底层逻辑就是减少人在流程中的参与比例，将更多的工作交于系统和后台，这就是我个人乃至崇尚流程平台化的深层想法。
之所以这么说，是平台将流程通过系统的方式，可视化的呈现出来，相较于操作文档等更容易理解，也看上去更简单，只要平台设计的符合人操作习惯，他看上去总会比一些长长的操作文档或者口头的流程更好上手。一个简单的例子，常规的数据标注的流程如下：
整套流程被分成了七个步骤，涉及到三方：rd、pm、外包评估同学，其中绝大部分是重复的工作，非常适合将其流程平台化。在rd数据抽取方式和评估方式相对固定的情况下，这套流程平台化之后可以简化为如下六步：
如果单从步骤上来说，从七步简化到六步，但整体效率提升更体现在后四步的各步流程都有了后台的参与，很多工作被自动化地做完了，更别说后台操作相较于excel文件的方式，更直观更方便。
在提流程平台化的需求时，尤其作为业务方，要面对的rd最大质疑，来源于需求收益怎么定，这个问题也在持续困扰我。为什么后台需求收益难预估，最大的原因是效率的概念比较虚无，且rd的okr指标难以归到这个方面。
比如刚才所说的数据评估需求后台化，我们的最主要目的是提高这个数据评估流程的效率，但后台化能提升多少效率？这个很难预估，且数据评估效率作为策略实验上线的一个衍生，rd只关注策略是否上线，根本不会将其作为okr指标，就更难推动他们去开发了。
笔者目前的思路是这样：
简单解释下1和3，1的话比较好用的方法是将流程列流程图，细化每一步骤的时间和经手人，从平台化后时间减少比例以及经手人次数上来预估效率提升情况。3则是在实在打动不了rd，推动不了的时候，pm判断确实流程有平台化的必要，那么可以通过同步产品团队的职级较高的人，通过刷高p的脸，来推动需求落地（不可常用）。
秩序化，表面简易，这让我相当一段时间，特别喜欢提流程后台化的需求，将一些业务中的流程化需求搬上平台，这种看着业务逐渐规整起来的感觉让我产生了虚幻的掌控感。直到我发现自己搭建的绝大多数后台在业务中发挥的价值并不显著，很多后面甚至弃用了，这才让自己开始逐渐反思，我们真的需要将所有流程平台化吗？
实际上并非如此，适合平台化的流程需要满足三个特点：
下面我来一个个解释。
最容易理解的是第一点，定义的方式是“有xx人每xx天使用xx次”。显而易见，如果有个流程3个人每年经历1次，那么尽管非平台化效率不够高，那么也是不需要将其平台化的，因为利用频次太低了，浪费机器资源，典型的业务场景是一个非常规的数据评估需求，比如我们这是评估多样性，这只针对特定的策略需要评估，且并非业务重点，因此使用频次可能是1年1次，两人参与，这种就非常不适合平台化。
第二点则是最容易被忽略的，像上节举的例子，数据标注，因为本身excel在多人间传送，且有多个版本，是非常容易混淆的，在excel上标注也不如在后台直观清晰，所以非常适合平台化。但有些流程，还是拿刚才举的多样性评估例子来看，如果线下的话，抽取用户cuid的推荐数据，整体来看多样性情况，通过excel抽取并汇总每个用户的推荐内容分类来看即可，这种excel的效率甚至比平台更高，主要不是看内容而是分类，只需要整体看一下推荐所属分类是否内容一致即可，可视化的需求并不高，因此不适合平台化。
第三点是流程稳定性，很多流程确实使用人数和使用频次高，也本身不做平台化的话效率低，但这个流程稳定性差，经常变动，那么它也不适合搬上平台。比如抽取平台优质内容，这个流程在于抽取评估数据的方式经常发生变动，并不能固定，有些阶段可能需要看互动量（值不一定，随产品使用人数变动，互动意愿都会发生变化），且需要防止作弊流量的影响，如果做成平台，可能很容易一段时间后变成垃圾内容的挖掘器，失去本身的初衷。
刚才我们论述了什么样的流程适合平台化，其实还有一点没讲，那就是成本考量。
是的，工作和学校的创意比赛的不同是要深刻理解到一点：“做任何事情都是有成本的”，这个成本包括研发成本、人力成本、维护成本、机器成本等，在确定一个流程是否要上平台之前，这些都是应该被考虑到的。最好的当然是研发成本低、机器成本低、维护成本低、人力成本低的流程平台化需求，但这并非是强制性的，只要真的对业务有价值，能提升效率，是可以接受适当的冗余。
考虑到各种成本，以及后续流程是否高废弃可能性，再来提需求，才是一个成熟的pm的思维路径，而不是一切思维归于惰性，将所有流程平台化，追求第一直觉的简单。
随心将夜，微信公众号 : 互联网菜鸟产品进阶之路，人人都是产品经理专栏作家。关注社交赛道和社区发展，擅长分析行业趋势。
本文由原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。