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

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

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