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

只要你觉得，这个业务后续需要有一套独立的管理权限和配套设施（也就是我们的配置能力），那它就可以独立成为一个业务。
业务是提前定义好的，这就要求产品经理在设计时做好沟通，知道现在以及将来，已经有并可能有哪些业务会用到你的系统。
应用：一个业务使用某个组件，我叫做一个应用。
比如当我接入一个新业务时，我就默认给这个业务创建了6个组件应用，每个组件应用可以单独配置，他们组合起来，就是这个业务最终在评论功能上所有的功能特性了。
内容：对评论组件来说，最终的管理颗粒度是要细化到每条评论，包括：增、改（改不是改内容，而是改属性，比如打标）、删、查、审、导出等。
只有精细到每一条评论的管理粒度，才能最大程度上满足业务的诉求。
做完业务管理，基本所有结构层面的方案设计，就全部结束了。接下来就是更细化的展示和体验，这个就靠跟UI的沟通和配合了。
五、总结总体来说，虽然「评论组件化」对我来说是一个完全陌生的项目，而且面临着时间紧、任务重的巨大挑战，但我还是觉得有一些方法和新的可以分享给大家，无论是之后做组件化，还是突然面临一个复杂的系统任务，我觉得都可以参考：
1）了解why和why now。复杂的事情，如果需要消耗你巨大的精力，一定要去理解，为什么要做，为什么要现在做，驱动力的问题，怎么想都不过分。
2）通过大量的观察和体验，找到复杂多元的外表下，那些核心的不变的要素。跟着那些要素再回过头去看产品，如果你可以建立一个模型，当你做任意输入时，都能预料到输出，代表你就彻底掌握了。比如删除评论，回复还在不在。在没有研究这个问题时，我很少会注意到这个规律。
3）找到最原始的概念。我们可能会用到很多抽象的概念，以及基于这些概念衍生出来的二级概念，如果我们一开始理解的不是最原始的意思，很可能就容易走歪。其实我一开始并没有很好的理解功能组件和业务组件，直到技术leader跟我讲了一晚上，我才逐渐理解。特别感谢他。
4）确定管理颗粒度。系统一定是有管控单位的，比如课程管控的是节目，讲书管控的是书籍，公司管控的是员工，学校管控的是学生。找到你的系统的管理粒度，会让你在系统设计上，跟核心要素产生更好的连接。
#专栏作家#大力哥呀，微信公众号：大力哥，人人都是产品经理专栏作家。一个90后产品经理，已经写了6年的公众号，通过输出获得了许多意料外的成长。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议