一旦产品变得臃肿，就会遇到很多问题:
维护成本越来越高
用户体验越来越差
积累的客户从资源变成了绳索，调整的难度和工作量越来越大。
在这种情况下，应对一些市场的新竞争是非常被动的。而且体验差了之后，客户会慢慢流失，团队无计可施，陷入两难境地，这也是国内大多数B端产品企业的现状。
改造现有产品还是开发一套新的？此时，公司面临着一个艰难的选择。基本上，所有R&D团队都会建议开始一个新的炉灶。从R&D的角度来看，这是一种更简单、更有效的方式。不会照顾到原来恶心的代码，团队士气会更高。然而，从公司的角度来看，需要考虑几个因素:
新系统的开发成本和开发周期。
一个新系统的开发，投入少量客户使用，然后成熟稳定，需要很长的打磨周期。
老客户迁移成本。
这个成本包括迁移过程中投入的BD、实施、培训、售后成本，也包括客户投入的成本。
在并行期间，涉及到一些bug或者需求，这就需要双方的开发成本。
人员需要两个团队，不同的产品线需要两个团队，比如开发、实施、培训、售后。扩大招聘和培训将变得更加困难。另外两条产品线之间的产品也是高度耦合的，沟通工作量大。
一般来说，B端产品的迁移成本极高，客户改变使用习惯的成本也极高。而且总有一些客户不愿意迁移，必然的结果就是长期维护两个系统。没有经历过的人很难想象这样的价格和成本。迁移老客户，老客户努力；不迁移老客户，老客户受到一定程度的忽视和伤害，影响口碑；
除非客户很少，或者基本可以保证所有成本相对较低的迁移，否则作者不建议重新开始，成本极高。除了所有成本乘以2，还有迁移和客户成本，每个客户的迁移和实施可能是一个复杂的项目。
所以相对于现有产品，开发一套新的成本肯定会成倍增长。很多公司选择这种方式后，陷入了对新产品不满意，老产品无法移植的困境，浪费了大量的时间和资源，作者也很少找到成功的案例。
那么如果我们需要知道如何重构一个系统，应该怎么做呢？我认为可以参考以下思路和原则:
1.为人们做好准备。
正如我在之前的一篇文章中所说，人是成功最关键的因素。为了做好工作，有几个角色很重要，比如数据库架构师、解决方案架构师、功能架构师。不是每个角色都需要一个人，但一定要有人承担相应的角色。比如数据库就是B端产品的基石。一旦出错后调整成本非常高，数据库架构师需要一个或多个懂数据库设计技术，对业务开发和业务细节有很好了解，有前瞻性合作的人。解决方案架构师实际上需要一个或多个了解业务和技术的人。
b端产品是交叉学科，懂业务、懂技术的相对容易找到。很难找到既懂业务又懂技术，能有机结合的人。这样的人目前在中国是稀缺资源。一般来说，跨学科、有技术技能的人比有业务技能的人更容易学习业务，公司要选择合适的人进行这个方向的培训。
如果短时间内很难找到合适的人，最好有外部顾问保持一定的控制力。
2.大致设计出理想的产品形态。
确定产品重构的路径，需要设计产品最终的总体结构，主要是功能结构和系统结构，确定一些核心业务设计的思路和原则，反复打磨才能得到满意的答案。知道了终点是什么，就可以思考最好的前进方式。
3.【div】[/div】做好重建优先级的选择。
对于产品重构来说，路径和优先级的选择极其重要。找到最合理省力的路径，对团队来说是一个很大的考验。这里很难有固定的答案，但有一些原则性的内容可以遵循:
优先调整基础型核心架构。
重构的核心是使数据库架构、产品功能架构、页面架构正确。数据库、功能、页面架构，其实是在用户体验和产品增长之间找到平衡的最合理的方法。一般来说，最好是用户看到足够多的关注内容，有足够多的页面，但是产品在成长，架构分类划分不好，最后功能或者页面会过于拥挤而无法扩展，需要在体验和成长之间找到最佳的平衡。
高频使用的一些核心模块，或者功能特别差的，应该先重构，对用户价值最大，客户有足够的合作动力。
优先考虑新需求大的模块重新配置。
产品不是静态的。我们在做产品重构的时候，必然会面对大量的外部需求。对于有很多新需求的功能模块，与其在错误的功能基础上花费大量时间，不如重新做一遍。其实所谓的重构，往往是对模块和功能的重写，以敏捷、巧妙的方式分解大风险。
4.
不用说，每重构一个模块，都是一次重生的机会。不能一个坑填另一个坑，至少要达到85分以上的设计分数才能开始，不要盲目追求速度。
5.
从客户的角度来说，每一次改造后的升级，对于那些已经熟悉历史体系的人来说，都是一种煎熬，客户遭受的次数越多，就越容易崩溃。从用户体验和口碑来看，迭代排列有如下几点建议:
1:
每次迭代升级，让客户不断品尝到甜头。每次迭代升级后，重构的新版本的体验需要大大超过原版本，或者有新的功能可以解决客户的痛点，从而可以激励用户升级。在设计和安排每个迭代计划的时候，要充分考虑用户升级的动机，否则会遇到很多障碍。
2.
每次重构后的升级往往伴随着数据迁移，所以这个负担不应该交给客户，实施团队应该帮助客户完成。另外，每次重构后的功能基本不需要培训，客户基本可以避免实施培训的成本。
3.【div】[/div】做好灰度测试，先确认新功能可行，再进行全量发布。
每一次重大改造都需要一定时期的灰度测试，让一些典型客户先使用改造后的模块，在保证没有问题后再进行全量发布，让客户尽可能少的被折腾。每一次折腾都会带来不信任和不配合，产品的口碑也会变差。
4:
新客户只开放必要的功能，降低后续迁移的成本。这是一个小提示。对于一些旧产品中没有做好的不必要的功能，在重新配置的过程中，不应该向不断增加的新客户开放，以免增加后期迁移的成本。
重建困难；简单难；生活艰难；但大多数人只有经历了足够的困难，才能找到内心的平静，过上平淡的生活。
