经理|「评论功能组件化」实践分享

面对评论功能组件化，一位中台产品经理会怎么做？本文作者作为业务向转型中台产品经理的亲历者，将自己的实操经验与大家一同分享。其中涵盖：确定核心问题，如何抽象产品组件，串联概念设计转变为流程设计等关键步骤，是一篇不可多得的组件化方法论。推荐小伙伴们交流学习～

文章插图
很长时间以来，我的工作都是一名偏向业务的产品经理。我的职责是帮助对接的业务实现更好的业务增长，这里的增长不仅包括收入的增长，也包括成本的降低。
但我很少有机会去做一名中台产品经理，以更抽象的视角去规划各个业务都会用到的核心功能。
虽然我一直都明白中台产品经理的职责是什么，但没有什么机会去实践。而我相信，一件事情做过还是没有做过，认识是完全不一样的。
所以去年年底的时候，老板说让我去负责「评论组件化」这个项目，我意识到这是一次实现自我突破的好机会。因为这对我来说是一次巨大的挑战，我之前从未负责过类似的产品。
现在，三周过去了，我也从最初毫无逻辑，到完成了整个方案的评审，一路走来感慨颇多。即骄傲于自己在三周内完成了方案的输出和评审，也谦卑于对于未知的世界，站在里面和站在外面，看到的东西有多么的不一样。
于是决定将这三周的实操经验分享出来，供更多从业务走向中台的产品经理参考。
一、确认动机对我来说，当我知道一件事情将要花去我很多的精力时，我一定要搞清楚两件事：
在解释为什么要做「评论组件化」这件事之前，我首先想跟大家解释一下这个项目是什么。
大家如果玩过积木就知道，当我们想要一个成型的具体的玩具时，我们可以用积木去拼出来。对于积木来说，它的生产过程就只有每一个碎片，当它出厂之后，就不再有生产成本了。购买的人想要什么东西，就自己拼就好。
对于一个功能也是这样，它是像积木一样由已有的模块拼起来的，还是说是在工厂里从0到1生产出来的，背后的成本是完全不一样的。
因为一些历史原因，很长时间以来，我们公司的各个业务都是并行发展的，即便是一些相同的功能，也因为各个业务诉求不一样，最终是由各业务的产品经理独立设计。
评论功能就是这样。
虽然我们的app主要是一个听书产品，但我们还是有多个独立的业务，并且在当前阶段都有独立的产品模块。评论功能就是这些业务都具备的一个功能，但长期以来都是独立开发的。
于是这就导致几个很严重的问题：
1. 开发资源的重复投入一个业务的评论功能，并不能立刻在另一个业务上复用，每做一个新业务，都需要从头开发。有产品经理可能会问，这有什么难的，你照着其他业务的代码再写一份不就可以了么？
但你要知道，再简单的评论功能也包括底层数据、客户端样式和管理后台，即使有代码可以抄，那开发和测试的边际成本也是非常高的，更不用说各个业务是否能100%复制还不一定。
2. 用户体验不一致因为是独立开发，每个产品经理都有自己的想法，且一条业务的产品经理很多时候还是流动的，因此最终呈现出来的功能有很多细节处的细小差异。
但用户访问的是同一个app，有时候这些细节上的差异，会带来体验不一致性，而这个，有时候会导致非常糟糕的用户体验。
3. 信息差导致好的方案不能共享实际情况下，很少有业务方会去研究其他业务方现在用的比较好的功能有哪些，甚至一个业务方觉得很稀松平常的功能，在另一个业务方眼里就是特别好的功能。
因此这样普遍存在的信息差，会导致即使局部最优无法实现整体最优，功能本身积累的势能无法最大程度的释放出来。
那为什么要现在做呢？
「功能组件化」这件事是有时间窗口的，做早了或者做晚了，都不合适。
从乐高的比喻比喻中你可以想象，如果我要的是一个「超人」，你给我一堆碎片，让我自己拼。那么这一定是浪费效率的，可能不如给我一个「超人」来得快。
所以如果「功能组件化」这件事做早了，那么对业务来说就是「杀鸡用了牛刀」，性价比划不来。
但另一方面，如果这件事做晚了会如何？
从系统角度来说，就会严重增加后续组件化的成本。因为每一个业务都在自己的系统里将同一个功能做了不同方向的演化，所以后续要统一管理时，改造难度很大。
就好像城市改造，如果当初都是各个小区各自规划，后续要拆迁翻新，统一治理时，成本是非常大的。