通常意义上讲，一个产品为什么要重构？我们团队的产品为何要重构？重构的目标是什么？最终结果如何？我是如何做的？过程中遇到了哪些问题？分别是如何解决的？收获与成长最后谈一下 0-1与产品重构哪个难？哪个易？这次产品重构之旅，是我在漫漫产品路上，接触到的第一次关于“重构”的实践，收获了颇多经验，个人也因此在这4个多月中，有了飞速的成长，遂将本次产品重构经历和经验进行分享，以期帮助到有类似“重构”任务或有着“重构困惑”的产品er们。
先引用《业务中台产品搭建指南：电商业务平台全流程设计与实战》一书中，作者关于重构的原因及必要性的解读：
每个系统的诞生都源于业务需要，为了能够支撑飞速发展的业务，很多时候我们需对多个方案进行一些妥协来赢取时间。方案的妥协往往会造成架构不良，只能满足中短期需求，对于长期的延伸都有致命的伤害。还有一种情况是业务的方向发生了变化或者融合，导致原有设计的结构需要进行重新设计调整。
如果把一个系统看作是一个人，那么人身体里面的骨骼、血肉就可以看作是系统的逻辑和技术架构，它们支撑着身体的稳定运行。而产品架构的逻辑和规则，则代表着这个人的精气神和性格，一个人身体再好，精气神如果不顺畅，身体早晚也会出问题。
所以每次重构既是对这身体的血肉和骨骼进行大刀阔斧的改造外，也需要对它的精气神和性格做重新的审视和定位。
结合我本次重构的经历来看，无不印证了上述书中作者的观点和看法。
1）我新加入的产品团队，组建时间不算短不算长，一年左右，为了满足团队初期的生存和发展，会承接一些商业化项目，基本上都是定制的，因此在架构设计上，也仅最大程度上考虑了多个项目的复用性，没有考虑“产品化”。
团队前台产品（姑且叫做产品吧，实际是为几个商业化项目建的业务应用系统）运转用到的后台系统有：采集系统、数据治理与融合系统、信源管理系统（现在重构后的名字，之前的产品名字与产品功能极度不符）、工单管理系统、扫描系统等等。
其中“信源管理系统”的定位是用于运营和管理各类信源数据的，即增删改查和打各类标签用的。但是，在给各个前台应用使用数据时，却仅将采集到的数据经过【AI模型】打标后，直接给到业务去用，完全没有 采纳“信源管理系统”的“运营管理成果”，信源管理系统用的数据与客户业务系统用的数据，是两份孤立的数据岛屿。
如果不及早解决，任由这样的态势发展下去，很难想象团队会在多久的将来，会因为这些问题“over”，几个月？一年？——但可以明确预见的是：如果不解决这些问题，团队的资源将永远都不够、团队也将无法拓展更多新的业务，因为忙着修修补补每一个孤岛上“零零散散的部件”。
2）团队此前有一个标品，但是是试水的v0.1产品，只有1个在线系统，没有产品需求文档、没有产品使用手册、没有技术设计文档，也没有什么人维护了。
读完上面我举的例子，换作任何一个产品经理/技术都不能忍受吧，鉴于那么多问题，所以我们需要重构。再总结一下，我们团队的产品为何进行重构：
技术架构上有诸多问题，如后台各系统边界不清晰、数据是孤岛、无标准化前台产品等；团队此前标品没有人运营维护了，且文档资料缺失。团队核心业务发展的需要。需要整合几个核心业务系统（为项目做的）为一个“一体化平台”，重新进行产品定位、打造标品并持续迭代，并努力成为行业内标杆产品。03 重构的目标是什么？
——弃糟粕、取精华，对产品重新定位。包括产品目标行业与目标客户、产品形态、产品商业模式、产品价值主张的重新明确，产品架构和技术架构的重新调整和设计，以重塑产品的骨骼和血肉，让产品恢复精气神儿，让产品可以解决客户问题的同时为团队“挣钱”。
本次产品重构的目标，是基于当时团队的业务背景需要，分成了几个阶段，每个阶段有着不同的目标：
阶段一：重新明确产品定位，设计产品业务架构，整合三个不同的业务应用（但业务流程及业务逻辑基本相同）至一个“一体化平台”中，共用一套后台系统，通过各类权限配置为不同类型的客户及用户提供产品服务。阶段二：优化线上系统逻辑漏洞、功能优化完善，提高用户使用体验。阶段三：重新设计后台产品架构，厘清各系统职责和边界，并分版本分别重构有问题的后台系统。阶段四：随业务发展，再将各个系统中的一些功能模块剥离出去，形成单个子系统运转。比如后续可将采集系统中的采集优先级判断、采集状态的管理从“采集系统”中剥离出去，形成“采集调度模块”，而采集系统仅做采集的执行，这样整体的业务逻辑就会清晰很多。
再比如将积分规则设置、积分分配、积分管理等从用户管理中剥离出去，形成单独的“积分管理系统”，这样也会减轻用户管理的负担。
——在当时，我不能特别领悟为何要这样划分。只是按照老板的大致意思那样去做了。
甚至现在，团队研发在做后台系统重构时还在说：“XXX后台系统本就该优先重构，然后再重构前台业务系统！现在都是反的~”
现在回过头来看，我想我理解了按上述节奏和周期去划分工作的原因：
1）为了维持团队业务的生存和发展，所以需响应市场需求、响应客户需求。
有市场需求了，有客户需求了，就需要赶快出客户用户“可见的”东西（产品v1.0），后台乱成怎么样，客户和用户看不到。
2）为了占据客户及用户心智，所以要不断打磨产品，让用户看得见我们的变化。
后台不急着重构，原因是：在产品初期，占据客户及用户心智是很重要的，因此“俘获用户芳心的新功能” 与 后台优化的需求相比，仍是“俘获用户芳心”的功能更重要。
3）等业务运转起来，且用户没有其它显著的使用问题后，再花时间和精力好好优化后台系统。千万要注意，后台的优化升级，不能影响到线上正常使用。
