我觉得重构这个坑太大了，所以就从十个方向来说说，重构前到底有哪些点是值得注意的。

如果你没有做过重构，请看完这10个坑后收藏起来，下次要重构前翻出来再仔细看一遍，顺便给你的leader也看看；如果你正踩在重构的坑上，也请看完这些坑，那些还没踩的千万要注意了！如果你不幸和我一样做完了重构，来，我们握个手吧。

首先，我们明确下重构这个定义：把之前的系统从里到外地重新做一遍，做完后就是2套独立不相干的系统，不是在之前的系统上部分重构，因为部分重构的坑还不够大。重构是因为之前的技术框架不能支持后续新功能的迭代了。

下面就来说说这10大坑吧！

设计不合理，改不改？

2年前我入职，任务就是重构系统，之前的产品经理不知道换了多少波，也没有留下完整的文档。要重构，肯定要对老系统了如指掌啊，没办法，我们只能先花2个礼拜的时间，把老系统的逻辑基本完整地梳理下来。

在一些业务流程方面，就发现很多不合乎逻辑的地方。比如药房退药以后，药品的状态不是已退药，而是又回到了上一步：待发药；治疗师已经开始治疗了，医生还能把医嘱项删掉，这条记录就突然消失了；待收费的项目几天后就自动关闭了，这钱追不回来了……

作为一个严谨的产品经理，这些不合理肯定要改！于是我就把退药后的状态改成了已退药，结果自家诊所的药师就炸了：“我药发出去以后才发现医生开错了，把药拿回来让医生改了重新发，你现在退了药直接就是已退药，那医生怎么改？”

我怎么会想到医生老是会开错药呢，听完突然心里怕怕的，退药不应该是患者不想要了吗？为了保持我之前完美的逻辑，我又加了个功能：退回修改。我估计其他诊所的药师看了这个按钮会有种莫名其妙的感觉吧。

遇到这些不合理时，真的挺纠结的，之前的产品经理也不是傻子，故意弄个逻辑缺陷，肯定是被客户逼的。但为了系统内功能逻辑的一致性和合理性，我们还是改了之前不合理的地方，后面被吐槽也是在所难免的。

用户习惯怎么破？

上面也说到，我们重构的主要原因是：之前的技术框架太老，不能支持新功能的迭代。

但如果只是技术层面上去重做一套系统，视觉和交互体验上都没有改变的话，领导如何感知到我们团队的价值？技术是不能被直观看到的东西，交互和视觉才是容易被感知到的东西。

我们经常看到的是C端产品，过段时间就换一套视觉风格，并一定对用户友好，特别是一些低频的必须品，比如说手机银行，但这是能让领导秀业绩的好东西。

所以，重构Saas，视觉和交互一定要改！但我们尽量不要改太多：

1. 系统结构框架和页面上功能布局改动不要太大，方便快速找到功能；
2. 菜单和页面上的名词尽量不要改动，且各模块间保持一致；
3. 交互形式和组件要全局统一的改，不然前后操作不一致，用户使用时更懵。

我们真的不能太高估用户的电脑水平，比如说我们就改了个时间控件，他们就不会用了。

之前的时间控件是这样的，开始时间和结束时间分开选择：

现在用的Element的组件，用户说怎么不能选一段时间了？原来他以为是要双击选中，然后在一个日期上点了2次，就成了选中一天。

还有很重要的一点，在用户切换系统前，请他们多使用新系统，直到能习惯，最好能比较熟练地使用。不然工作一忙，系统又不会用，抱怨就更多了。

重构内容越做越多

Saas一般都不是一个单一的系统，他会有运营平台，还有和外部的对接，比如公司内部其他业务的对接，第三方应用的对接。

我们原本只是想重构用户端的系统，其他都不动，但做着做着就发现，运营平台要重做，所有的外部对接也要重做，比如说聚合支付对接，检验外送对接。工作量比之前预想的翻了一倍不止。

所以，在评估重构内容时，最好把所有和他相关的东西都捋一遍，虽然想法很好，尽可能不改的就不要动，但要做好都重做一遍的打算。

功能必须>老系统才可推广

重构的系统和从0到1的系统，很大的区别是：商用时间不同，推广方案不同。

我们都知道MVP的道理，但这个在重构系统时行不通。我们的用户迁移到新系统使用，老系统有的功能新系统必须有啊，不然他们的工作没法开展。

但我们开发时不可能招上几十个人，所有功能同步开发，肯定还是要分批做的。比如我们先做门诊相关的功能，物资库存管理的功能后面再做。如果是从0到1的产品，我们可以做完门诊后就开始小范围推广，让一些对库存管理要求不高的小诊所先用起来，在后续新功能开发时一起优化老功能。

当然，为了防止我们改动老功能和加入新功能时跑偏，我们每个版本上线后也会找一些用户体验，但毕竟和真实使用是有区别的。这个重构的过程有点像半黑盒子，对产品经理的要求更高，改动功能上面说过了，对于新加功能，还是建议遵循MVP的原则，不要一下子做全。

比如我们本来打算做健康管理的功能，设计的很完美，包括用户自己在家测量数据后上传，家庭医生多对1的服务。但后面做的时候删到了最简，只给了一个健康指标库。虽然这是一个发展方向，也有很多诊所提，但现在真正有能力做起来的还是凤毛麟角的，事实也证明我们是对的。

上线时间一延再延

我们原本打算用4个月的时间重构，这样需求文档必须要在1个月内完成，在我们产品经理每天加班到10点多的情况下，我们不负众望地按时把PRD交给了开发。

从3月份开始，预计到6月份完成的重构，后来说要到10月份，后来又改成了第二年年初，后面又到了3月份。你猜，最后几月份做完了？第二年10月份！整整用了1年半的时间。

项目延期是我们都不愿意看到的，但这里面的原因也不都是人为能规避的，我总结了这几点：

1. 原本只想重构1个系统的，结果越做越多；
2. 开发动手前只顾眼前版本的功能，没有仔细看完所有文档，导致开发后面功能时发现不支持了，再把之前的功能又重新做一遍；
3. 开发过程中产品经理还在不停调研用户，导致需求变更；
4. 分出部分人力继续老系统功能的迭代，如果1年多的时间老系统一点不动，客户流失率很高，还是要适当的上新；
5. 人员的变动：离职、调岗等，这方面我们还算基本稳定，不然第二年10月份都做不完。

这段时间销售、客服的压力都很大，之前就积累了几百条需求，答应了客户做。虽然我们在设计新系统时确实是做进去了，但是客户用不了啊。一开始以为6月份能做完的时候，客户催需求时，就告诉他们新系统做了，马上就能用了。但到后来，销售都不敢让用户知道我们有2套系统了，生怕一直问：新系统什么时候上线啊。

有个3年多的老客户，在大会的时候一直拉着我说：我是你们第一批用户，我就提了这2个需求，和我说会做的，让我等等，结果一等就是2年，我真的快等不起了。

数据迁移是大坑

我们重构的系统是一个完全新的系统，和老系统没有关系，那用户想要用新系统，就必须把老系统的数据都迁移到新系统，不然客户资料丢了、历史病历丢了，这个肯定是不行的。

数据迁移没有想象的那么简单：开发写个脚本，批量跑一下就行。数据迁移前，产品经理先要把迁移字段的对照关系写清楚，我们写了20几页文档，千余个字段。

里面有很多需要注意的点，简单的说几个让大家感受下其中的复杂度：

1. 字段对不上。相同字段问题不大，缺少和增加的字段就要特别注明怎么处理。如果是之前比较重要的字段，但新系统去掉了，是否要保留过来？
2. 业务类型有修改。比如老系统有方便门诊，新系统没有这个类型了，怎么处理老系统方便门诊的数据？
3. 数据迁移不过来。不是所有数据都能做迁移的，有的是因为没法迁，要重新配置，比如外部对接；有的是因为数据量太大，成本太高，比如说统计报表。
4. ……

我们把文档给到开发后，每个模块负责的开发分别写数据迁移的代码，这个工作量也不小，当时6、7个开发差不多写了1个多月。

终于，客户可以申请迁移了，我们还不能一迁就成功，开发在正式迁移之前，会先试迁几次，测试多次验证数据没有问题后，才会通知客户正式迁移。数据量小的客户可能2-3个小时就迁完了，数据量大的要6-7个小时。

但我们必须明白，2个系统就是不一样的，不可能百分百没差错的做无缝连接。虽然我们会把迁移的注意事项提前告知客户，并让他们邮件确认已知晓风险，但还是避免不了迁移后的问题，甚至还有要求要迁回去的。

做完数据迁移，标志着系统的重构基本完成了。但别高兴的太早，后面又是一场接一场的考验。

新上系统不稳定

虽然说新系统功能是分批做的，也是分批上线的，但一直不对外商用。没有真实用户的时候很多问题都不会爆发出来。当我们重构完成，正式对外商用时，一下子把这么一大个系统推出去，风险还是极大的。

那时快过年了，诊所的业务也特别忙，结果隔三差五的出现页面加载速度极慢、服务器异常、系统登录不了的情况，搞得客户意见很大，在我们年终调研时给我们的打分很低。

新上系统有bug是很正常的事情，毕竟测试用例的覆盖面有限，而且还有很多客户意想不到的操作方式。但功能越多，出现bug的概率就越大；另一方面，不同的功能分散在不同的开发身上，修复bug时常常会因为同步不到位，改出更大的问题来。

那段时间还是过的挺心惊胆战的，就怕早上还没到公司，客户群里就炸开了。差不多磨合了1个多月，新系统终于稳定下来了，至少不会出现很大的bug，这时才稍稍松了口气。

客户老拿老系统说事

没有对比，就没有伤害。新签客户直接用新系统，问题就少的多。迁移过来的老客户，问题可多了，因为他们可以拿老系统说事。

比如上面说的，自家诊所的药师要求退药后状态变为待发药，因为老系统是这样的；医生说我要把患者的就诊卡片用颜色区分出来，因为老系统的大色块看着清楚，但新系统的风格不是这样的啊；运营说为什么不能预约到科室，老系统可以，虽然我们已经给出了替代方案……

我们必须要想好怎么说服他们适应新功能，甚至指导他们规范自身业务，不要一不习惯就要求改回老系统那样，这样的话新系统的意义在哪。我们的设计也不是凭空捏造的，也经过了大量的客户调研，而之前一些不合逻辑的功能，可能就是为了1-2家特殊诊所。个性化定制本来就是Saas的大忌。

但如果真的是我们判断失误了，确实是老系统好，我们也要毫不犹豫地改回去。

蓦然回首，落后竞品一大截

重构的1年半时间里面，我们会经常去看竞品的功能，每次他们上线的变更都会仔细的看，有时候看得心里痒痒的，这个我们也计划做的啊，怎么被他们先做了去。

这段时间80%的精力都花在了系统重构上，能被客户感知到的新功能自然做不多，我们眼睁睁的看着一些刚起的新兵，在这一年多的时间里面把功能做的比较强大，开始和我们抢客户了。

经常客户提需求时，我们都说，这个功能新系统实现了。他们戏称我们在“憋大招”。虽然最后结果还不错，新系统推出了，客户满意度还挺高的，申请迁移的客户特别多。但我们在后面还是很心虚的，就怕什么都说在新系统能实现了，客户对新系统的预期过高，真正使用时有点不满意就产生很大的心理落差。所以，我们后面还做了些降预期的处理。

结局呢？你猜

都看到第10点了，朋友，辛苦你陪着我走完了这一遭，我们都希望像童话故事一样：重构圆满完成，开始新的征程。

我们满腔热血地规划未来，目标就是：同行NO.1。这个目标不高，毕竟我们的新系统目前能排前三。

上次有个客户还说：你们这类系统有其他做的好一点的吗，我知道的就你们和另外一家。

我想了想，还真想不出第三家来了，倒真不是王婆卖瓜、自卖自夸，这只是产品经理实事求是的自信。

最后，你应该猜到结局了吧，老板说：这条业务线亏损好几年了，先stop吧。所有的人都懵了，这么一年半时间的心血，有种白费了的无力感。我们一个团队二三十人，都咬着牙，天天加班在做，调休假都积了20多天没时间休，还基本没有人离职，这么苦都熬过来了，却在刚看到光明的时候被扼杀了。

其实，站在公司的层面，我能理解老板的决定。但对于产品经理来说，还是觉得不甘心。产品就像是自己的孩子，还没养大就要放手了。

总结

虽说结局令人感到遗憾，但不得不说，这2年我的能力还是提升相当多的，就是被上面的那些大坑磨的。系统重构的过程，也是我重塑的过程。

#专栏作家#

司马特小队，公众号：司马特小分队，人人都是产品经理专栏作家。8年+互联网资深产品经验，多年B端产品管理经验。具有多个从0到1的大型B端产品的孵化、重构、迭代经验；主要教授产业互联网产品相关的硬核知识点。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议。