产品重构之旅回顾——“一场取精华、弃糟粕的产品革命”

如果产品的架构不良，或者业务的方向发生了变化，这时就需要对产品进行重构。本文作者在一次产品重构之旅中，收获了一些经验，有了飞速成长，遂将本次产品重构经历和经验进行分享，希望能给你带来帮助。

文章导读：

• 通常意义上讲，一个产品为什么要重构？
• 我们团队的产品为何要重构？
• 重构的目标是什么？
• 最终结果如何？
• 我是如何做的？
• 过程中遇到了哪些问题？分别是如何解决的？
• 收获与成长
• 最后谈一下 0-1与产品重构哪个难？哪个易？

这次产品重构之旅，是我在漫漫产品路上，接触到的第一次关于“重构”的实践，收获了颇多经验，个人也因此在这4个多月中，有了飞速的成长，遂将本次产品重构经历和经验进行分享，以期帮助到有类似“重构”任务或有着“重构困惑”的产品er们。

01 通常意义上讲，一个产品为什么要重构？

先引用《业务中台产品搭建指南：电商业务平台全流程设计与实战》一书中，作者关于重构的原因及必要性的解读：

每个系统的诞生都源于业务需要，为了能够支撑飞速发展的业务，很多时候我们需对多个方案进行一些妥协来赢取时间。方案的妥协往往会造成架构不良，只能满足中短期需求，对于长期的延伸都有致命的伤害。

还有一种情况是业务的方向发生了变化或者融合，导致原有设计的结构需要进行重新设计调整。

如果把一个系统看作是一个人，那么人身体里面的骨骼、血肉就可以看作是系统的逻辑和技术架构，它们支撑着身体的稳定运行。而产品架构的逻辑和规则，则代表着这个人的精气神和性格，一个人身体再好，精气神如果不顺畅，身体早晚也会出问题。

所以每次重构既是对这身体的血肉和骨骼进行大刀阔斧的改造外，也需要对它的精气神和性格做重新的审视和定位。

结合我本次重构的经历来看，无不印证了上述书中作者的观点和看法。

1）我新加入的产品团队，组建时间不算短不算长，一年左右，为了满足团队初期的生存和发展，会承接一些商业化项目，基本上都是定制的，因此在架构设计上，也仅最大程度上考虑了多个项目的复用性，没有考虑“产品化”。

举个架构不良的例子（真实例子）：

团队前台产品（姑且叫做产品吧，实际是为几个商业化项目建的业务应用系统）运转用到的后台系统有：采集系统、数据治理与融合系统、信源管理系统（现在重构后的名字，之前的产品名字与产品功能极度不符）、工单管理系统、扫描系统等等。

其中“信源管理系统”的定位是用于运营和管理各类信源数据的，即增删改查和打各类标签用的。但是，在给各个前台应用使用数据时，却仅将采集到的数据经过【AI模型】打标后，直接给到业务去用，完全没有 采纳“信源管理系统”的“运营管理成果”，信源管理系统用的数据与客户业务系统用的数据，是两份孤立的数据岛屿。

很显然，这是极度不合理的业务架构设计。

如果不及早解决，任由这样的态势发展下去，很难想象团队会在多久的将来，会因为这些问题“over”，几个月？一年？——但可以明确预见的是：如果不解决这些问题，团队的资源将永远都不够、团队也将无法拓展更多新的业务，因为忙着修修补补每一个孤岛上“零零散散的部件”。

2）团队此前有一个标品，但是是试水的v0.1产品，只有1个在线系统，没有产品需求文档、没有产品使用手册、没有技术设计文档，也没有什么人维护了。

02 我们团队的产品为何进行重构？

读完上面我举的例子，换作任何一个产品经理/技术都不能忍受吧，鉴于那么多问题，所以我们需要重构。再总结一下，我们团队的产品为何进行重构：

1. 技术架构上有诸多问题，如后台各系统边界不清晰、数据是孤岛、无标准化前台产品等；
2. 团队此前标品没有人运营维护了，且文档资料缺失。
3. 团队核心业务发展的需要。需要整合几个核心业务系统（为项目做的）为一个“一体化平台”，重新进行产品定位、打造标品并持续迭代，并努力成为行业内标杆产品。

03 重构的目标是什么？

——弃糟粕、取精华，对产品重新定位。包括产品目标行业与目标客户、产品形态、产品商业模式、产品价值主张的重新明确，产品架构和技术架构的重新调整和设计，以重塑产品的骨骼和血肉，让产品恢复精气神儿，让产品可以解决客户问题的同时为团队“挣钱”。

本次产品重构的目标，是基于当时团队的业务背景需要，分成了几个阶段，每个阶段有着不同的目标：

• 阶段一：重新明确产品定位，设计产品业务架构，整合三个不同的业务应用（但业务流程及业务逻辑基本相同）至一个“一体化平台”中，共用一套后台系统，通过各类权限配置为不同类型的客户及用户提供产品服务。
• 阶段二：优化线上系统逻辑漏洞、功能优化完善，提高用户使用体验。
• 阶段三：重新设计后台产品架构，厘清各系统职责和边界，并分版本分别重构有问题的后台系统。
• 阶段四：随业务发展，再将各个系统中的一些功能模块剥离出去，形成单个子系统运转。

比如后续可将采集系统中的采集优先级判断、采集状态的管理从“采集系统”中剥离出去，形成“采集调度模块”，而采集系统仅做采集的执行，这样整体的业务逻辑就会清晰很多。

再比如将积分规则设置、积分分配、积分管理等从用户管理中剥离出去，形成单独的“积分管理系统”，这样也会减轻用户管理的负担。

为什么这样划分产品重构的阶段？

——在当时，我不能特别领悟为何要这样划分。只是按照老板的大致意思那样去做了。

甚至现在，团队研发在做后台系统重构时还在说：“XXX后台系统本就该优先重构，然后再重构前台业务系统！现在都是反的~”

但真的是研发说的这样吗？

现在回过头来看，我想我理解了按上述节奏和周期去划分工作的原因：

1）为了维持团队业务的生存和发展，所以需响应市场需求、响应客户需求。

有市场需求了，有客户需求了，就需要赶快出客户用户“可见的”东西（产品v1.0），后台乱成怎么样，客户和用户看不到。

2）为了占据客户及用户心智，所以要不断打磨产品，让用户看得见我们的变化。

后台不急着重构，原因是：在产品初期，占据客户及用户心智是很重要的，因此“俘获用户芳心的新功能” 与 后台优化的需求相比，仍是“俘获用户芳心”的功能更重要。

3）等业务运转起来，且用户没有其它显著的使用问题后，再花时间和精力好好优化后台系统。千万要注意，后台的优化升级，不能影响到线上正常使用。

如遇其它重构任务，该如何合理地安排每个阶段的产品迭代工作呢？

——可以按照如下金字塔来执行（从底到顶）：

（图引自《业务中台产品搭建指南：电商业务平台全流程设计与实战》一书，如有侵权，联系删除）

通俗一点概况就是：让业务RUN起来->让业务闭环->让业务流程完善->提高用户体验->再拓展其它新的东西。

上面的这个做事情的优先级顺序，同样也适用于生活、学习。比如学跳舞这件事：

目标是——老师教一支新的舞蹈，本节课你要学会这支舞蹈，长期目标是：你要学会自己跳舞。

可以怎么去做呢？

step1：你首先要将老师教的新舞蹈中的难的部分学会；

step2：然后将完整的片段记住，要能完整地跳下来；

step3：然后再是完扣每一块的动作，做得尽量标准；

step4：然后再是提高你跳舞的可观赏性（比如表情管理啊）考虑下台下观众；

step5：然后再是学习新的动作。

04 最终结果如何？

历时1个月，完成了阶段一的目标。最终成果是：完成了团队标品v1.0（网络情报侦察一体化SaaS平台）的构建，并重新明确了产品对外服务的模式、以及产品所服务的目标行业及目标客户群体。

又历时1个月，完成了阶段二的目标。最终成果是：1个月内完成了2个大版本的迭代，在春节复工后，正式开放给客户使用。

当前处于阶段三（第4个月），即在重构和优化后台的几个系统/模块，同时打磨客户高频使用的模块中。目前平台已经有数十个试用客户以及十多个正式签约客户了。

05 我是怎样做的？

这里分成这样两个大阶段：重构0.1阶段和重构1.x阶段，来分别介绍我具体是如何做的。

1. 关于产品重构0.1阶段

这个阶段主要是：明确重构的产品的业务目标是什么。

——即解决谁在什么场景下的什么问题？——你打算用什么路径去解决？计划什么时候可以解决？

带着这些问题，我开始行动了。

首先是与老板、与其它产品同事，沟通要一些产品资料进行学习和线上系统的亲自体验，目的是了解团队以前的业务都有哪些，以及与老板沟通当下及未来的业务重点或目标是什么。（攻哪个细分市场？当然是带着自己对行业的见解与老板谈）

接着，大致掌握了团队的业务及产品现状、团队及公司资源情况（技术人员情况等）以及产品未来的发力点（姑且认为方向正确，先入行再懂行）后，我开始着手调研目标市场、目标客户需求，目的是加深对行业、对客户的了解。

确认了目标行业、目标客户后，结合目标行业及客户的特点，制定产品对外服务的模式。像我们的产品，主要是有几种对外服务模式：一是SaaS系统，二是人工服务（如写舆情报告、人员调查报告等），三是数据服务。SaaS是产品对外服务的主要模式。

2. 关于产品重构1.0、2.0、3.0

这个阶段产品定位、产品形态已基本明确，主要任务是：具体产品的规划设计，包括业务模块的划分，产品架构设计以及每个版本功能模块的设计。

在这个阶段里，我是按照先搞前台，后优化后台的思路来进行的。

1）搞前台，是要将3个系统（一个舆情系统，一个公安核查工具，一个开源数据监测系统）进行整合，整合为一个前台应用，并通过各类权限配置为不同类客户提供服务。

主要是怎样做的？

先按照数据流向，梳理业务架构，并按不同的业务场景，划分功能模块。

接着，上手整合现有几个系统，功能合并去重、原有功能优化、缺少功能新增，最大程度复用原来的页面和接口，重点设计rabc（基于角色的访问控制）部分。

2）v1.x版本已经上线，解决了“迈进市场第一步”的问题，但仍有很多问题和漏洞需要修复。

在这个阶段，主要是修复系统的诸多逻辑不一致、逻辑漏洞、业务未闭环、功能不完善等问题。

我是怎样做的？？

逻辑漏洞第一优先级，逻辑不一致其次，业务闭环其次，最后优化不完善的功能。

注：逻辑漏洞问题应该在v1.0版本前解决掉，但因本产品推出时间紧迫，且初期仅开放给少量用户使用，所以放在了1.1版本解决。

本产品的逻辑漏洞例子：模块A和模块B用到了同样的“付费数据”查询功能，但模块A考虑了“扣除积分”，另一个模块B不扣除积分，用户完全可以“钻空子”——这是由于之前模块B的系统是私有化部署交付给客户的，所以模块B并没有积分扣除逻辑。

3）x版本已经上线，在“迈进了市场第一步”基础上，也积累了一部分用户了，这个阶段可以系统优化后台架构了，同时兼顾前台的优化。

在这个阶段，系统的稳定性、良好的架构设计、系统的数据准确性&及时性&全面性（做数据服务的厂商需要视业务重心酌情考虑），将能够帮助支撑更多用户的使用，让产品活的更久远。

4）搞后台，梳理出几个必要的核心的后台系统，明确它们的各自定位以及职责边界，以及它们之间的交互关系（还是可以参照数据的流向思路来梳理）。

06 过程中遇到了哪些问题？分别是如何解决的？

整个重构过程对我来说挑战极大。

一是我从来没做过后台，也从未参与设计过rabc模块，SaaS系统当然也没有设计过了。

二是我10月25日入职，在11月上旬就要考虑重构事情，新环境、新同事、新业务、新行业，对我来说处处是挑战。

我是如何克服并解决的？？

1）首先充分认识自己，对自己的不足与优势重新认识，对知识盲区疯狂查漏补缺。

我过往的优势是：有较丰富的AI类产品设计经验，以及可以很熟练地掌握产品规划的一些方案论，如华为的“五看三定”等，同时有着非常强的学习能力，以及调研能力。

对不足的地方，进行知识的查漏补缺。

比如rabc是什么，不清楚。

——我就去网上、去和前同事沟通交流、去看书，以此来构建这块相对完善的知识体系，然后才能上手设计我要负责的SaaS产品。

再比如，对团队的业务及产品目标不是很明确。

——我就逮住机会，和老板沟通交流（了解核心业务是什么、核心客户是谁），充分利用上班及空闲时间，亲自上手体验他们以前做的系统，并与相关同事请教，去了解每一个功能模块设计的初衷是什么、解决的是什么业务问题，并提出自己的思考

再比如，对后台的几个系统的重构和优化，从来没做过，大多系统没有界面，看不见摸不着，一头雾水。

——我就从数据流向开始梳理每个系统的作用和价值，然后搞清楚这几个系统当前是怎么互相配合（它们的交互关系）支撑业务前台运转的，然后再和每一个系统的研发沟通交流系统的主要功能以及核心逻辑，然后再基于自己的思考，发现当前逻辑的不足，并据此提出优化需求。

2）对我效率提升最大的就是：按照五看三定框架进行调研和设计。

整理文档，按照“五看三定”方法论（看趋势、看客户、看竞品、看自身、看机会；定目标、定控制点、定路径），来整理文档，每一块都由浅入深地去了解。

对于不是自己做的系统，唯一可以加深体验和了解的就是（尤其是在没有文档资料的情况下）：自己亲自上手体验，有必要可以写一下操作手册，以方便后续回顾。

07 收获与成长

1. 关于重构的实践与审视。
2. 关于SaaS的实践与审视。
3. 关于采集系统、运营管理后台系统的实践，以及系统前后台架构的整体设计。
4. 关于知识图谱的实践（还不是很深入，主要是图谱可视化工具，以及简单的本体关系）。
5. 关于抽象化思维的锻炼。

比如我们要管理10多类信源，每个页面如果都要开发的话，需要开发10遍，而将问题转化成提炼共性，去开发一个动态配置页面，将变得灵活许多也方便拓展，主要工作变为抽象提炼共性以及业务流程的设计。

08 最后谈一下 0-1与产品重构哪个难？哪个易？

谈不上幸运的是：0-1（前两年）和产品重构，我均经历过。

从个人亲身经历感受来说，我认为产品重构相对难一些，难在于你要“填坑”、你要“擦屁股”、你要“复用”，不像0-1，你有很多发挥空间。

而不论是0-1还是产品重构，都需要你对行业、客户、市场调研了解，产品重构若只是后台系统的重构，不涉及面向目标客户的重构，则不需要了解市场这些，但也要清楚业务逻辑和业务流程。

写在最后

希望本文的内容，能够对你有所帮助。

产品经理，说难也难，说易也易。不知道自己会在产品这条路上坚持多久，至少现在还算热爱，期望每天都能比昨天的自己优秀一点，加油！产品er们共勉~~ ：)

​Read More