——这是我的第70篇原创文章——
之前我们星球的小伙伴提了这样一个问题：
我觉得重构这个坑太大了，星球的小身板承载不了我这2年的感悟，故写了5000字来好好说道说道。如果你没有做过重构，请看完这10个坑后收藏起来，下次要重构前翻出来再仔细看一遍，顺便给你的leader也看看；如果你正踩在重构的坑上，也请看完这些坑，那些还没踩的千万要注意了！如果你不幸和我一样做完了重构，来，我们握个手吧。首先，我们明确下重构这个定义：把之前的系统从里到外地重新做一遍，做完后就是2套独立不相干的系统，不是在之前的系统上部分重构，因为部分重构的坑还不够大。重构是因为之前的技术框架不能支持后续新功能的迭代了。下面就来说说这10大坑吧！设计不合理，改不改？
NO.1
用户习惯怎么破？
NO.2
上面也说到，我们重构的主要原因是：之前的技术框架太老，不能支持新功能的迭代。但如果只是技术层面上去重做一套系统，视觉和交互体验上都没有改变的话，领导如何感知到我们团队的价值？技术是不能被直观看到的东西，交互和视觉才是容易被感知到的东西。我们经常看到的是C端产品，过段时间就换一套视觉风格，并一定对用户友好，特别是一些低频的必须品，比如说手机银行，但这是能让领导秀业绩的好东西。所以，重构Saas，视觉和交互一定要改！但我们尽量不要改太多：1、系统结构框架和页面上功能布局改动不要太大，方便快速找到功能；
2、菜单和页面上的名词尽量不要改动，且各模块间保持一致；
3、交互形式和组件要全局统一的改，不然前后操作不一致，用户使用时更懵；我们真的不能太高估用户的电脑水平，比如说我们就改了个时间控件，他们就不会用了。之前的时间控件是这样的，开始时间和结束时间分开选择：
现在用的Element的组件，用户说怎么不能选一段时间了？原来他以为是要双击选中，然后在一个日期上点了2次，就成了选中一天。还有很重要的一点，在用户切换系统前，请他们多使用新系统，直到能习惯，最好能比较熟练地使用。不然工作一忙，系统又不会用，抱怨就更多了。重构内容越做越多
NO.3
Saas一般都不是一个单一的系统，他会有运营平台，还有和外部的对接，比如公司内部其他业务的对接，第三方应用的对接。我们原本只是想重构用户端的系统，其他都不动，但做着做着就发现，运营平台要重做，所有的外部对接也要重做，比如说聚合支付对接，检验外送对接。工作量比之前预想的翻了一倍不止。所以，在评估重构内容时，最好把所有和他相关的东西都捋一遍，虽然想法很好，尽可能不改的就不要动，但要做好都重做一遍的打算。
功能必须>老系统才可推广
NO.4
重构的系统和从0到1的系统，很大的区别是：商用时间不同，推广方案不同。我们都知道MVP的道理，但这个在重构系统时行不通。我们的用户迁移到新系统使用，老系统有的功能新系统必须有啊，不然他们的工作没法开展。但我们开发时不可能招上几十个人，所有功能同步开发，肯定还是要分批做的。比如我们先做门诊相关的功能，物资库存管理的功能后面再做。如果是从0到1的产品，我们可以做完门诊后就开始小范围推广，让一些对库存管理要求不高的小诊所先用起来，在后续新功能开发时一起优化老功能。当然，为了防止我们改动老功能和加入新功能时跑偏，我们每个版本上线后也会找一些用户体验，但毕竟和真实使用是有区别的。这个重构的过程有点像半黑盒子，对产品经理的要求更高，改动功能上面说过了，对于新加功能，还是建议遵循MVP的原则，不要一下子做全。比如我们本来打算做健康管理的功能，设计的很完美，包括用户自己在家测量数据后上传，家庭医生多对1的服务。但后面做的时候删到了最简，只给了一个健康指标库。虽然这是一个发展方向，也有很多诊所提，但现在真正有能力做起来的还是凤毛麟角的，事实也证明我们是对的。
上线时间一延再延
NO.5
我们原本打算用4个月的时间重构，这样需求文档必须要在1个月内完成，在我们产品经理每天加班到10点多的情况下，我们不负众望地按时把PRD交给了开发。从3月份开始，预计到6月份完成的重构，后来说要到10月份，后来又改成了第二年年初，后面又到了3月份。你猜，最后几月份做完了？第二年10月份！整整用了1年半的时间。项目延期是我们都不愿意看到的，但这里面的原因也不都是人为能规避的，我总结了这几点：1、原本只想重构1个系统的，结果越做越多；2、开发动手前只顾眼前版本的功能，没有仔细看完所有文档，导致开发后面功能时发现不支持了，再把之前的功能又重新做一遍；3、开发过程中产品经理还在不停调研用户，导致需求变更；4、分出部分人力继续老系统功能的迭代，如果1年多的时间老系统一点不动，客户流失率很高，还是要适当的上新；5、人员的变动：离职、调岗等，这方面我们还算基本稳定，不然第二年10月份都做不完。这段时间销售、客服的压力都很大，之前就积累了几百条需求，答应了客户做。虽然我们在设计新系统时确实是做进去了，但是客户用不了啊。一开始以为6月份能做完的时候，客户催需求时，就告诉他们新系统做了，马上就能用了。但到后来，销售都不敢让用户知道我们有2套系统了，生怕一直问：新系统什么时候上线啊。有个3年多的老客户，在大会的时候一直拉着我说：我是你们第一批用户，我就提了这2个需求，和我说会做的，让我等等，结果一等就是2年，我真的快等不起了。
数据迁移是大坑
NO.6
我们重构的系统是一个完全新的系统，和老系统没有关系，那用户想要用新系统，就必须把老系统的数据都迁移到新系统，不然**丢了、历史病历丢了，这个肯定是不行的。数据迁移没有想象的那么简单：开发写个脚本，批量跑一下就行。数据迁移前，产品经理先要把迁移字段的对照关系写清楚，我们写了20几页文档，千余个字段。里面有很多需要注意的点，简单的说几个让大家感受下其中的复杂度：1、字段对不上。相同字段问题不大，缺少和增加的字段就要特别注明怎么处理。如果是之前比较重要的字段，但新系统去掉了，是否要保留过来？2、业务类型有修改。比如老系统有方便门诊，新系统没有这个类型了，怎么处理老系统方便门诊的数据？3、数据迁移不过来。不是所有数据都能做迁移的，有的是因为没法迁，要重新配置，比如外部对接；有的是因为数据量太大，成本太高，比如说统计报表。......我们把文档给到开发后，每个模块负责的开发分别写数据迁移的代码，这个工作量也不小，当时6、7个开发差不多写了1个多月。终于，客户可以申请迁移了，我们还不能一迁就成功，开发在正式迁移之前，会先试迁几次，测试多次验证数据没有问题后，才会通知客户正式迁移。数据量小的客户可能2-3个小时就迁完了，数据量大的要6-7个小时。但我们必须明白，2个系统就是不一样的，不可能百分百没差错的做无缝连接。虽然我们会把迁移的注意事项提前告知客户，并让他们邮件确认已知晓风险，但还是避免不了迁移后的问题，甚至还有要求要迁回去的。做完数据迁移，标志着系统的重构基本完成了。但别高兴的太早，后面又是一场接一场的考验。
新上系统不稳定
NO.7
虽然说新系统功能是分批做的，也是分批上线的，但一直不对外商用。没有真实用户的时候很多问题都不会爆发出来。当我们重构完成，正式对外商用时，一下子把这么一大个系统推出去，风险还是极大的。那时快过年了，诊所的业务也特别忙，结果隔三差五的出现页面加载速度极慢、服务器异常、系统登录不了的情况，搞得客户意见很大，在我们年终调研时给我们的打分很低。新上系统有bug是很正常的事情，毕竟测试用例的覆盖面有限，而且还有很多客户意想不到的操作方式。但功能越多，出现bug的概率就越大；另一方面，不同的功能分散在不同的开发身上，修复bug时常常会因为同步不到位，改出更大的问题来。那段时间还是过的挺心惊胆战的，就怕早上还没到公司，客户群里就炸开了。差不多磨合了1个多月，新系统终于稳定下来了，至少不会出现很大的bug，这时才稍稍松了口气。
客户老拿老系统说事
NO.8
没有对比，就没有伤害。新签客户直接用新系统，问题就少的多。迁移过来的老客户，问题可多了，因为他们可以拿老系统说事。比如上面说的，自家诊所的药师要求退药后状态变为待发药，因为老系统是这样的；医生说我要把患者的就诊卡片用颜**分出来，因为老系统的大色块看着清楚，但新系统的风格不是这样的啊；运营说为什么不能预约到科室，老系统可以，虽然我们已经给出了替代方案......我们必须要想好怎么说服他们适应新功能，甚至指导他们规范自身业务，不要一不习惯就要求改回老系统那样，这样的话新系统的意义在哪。我们的设计也不是凭空捏造的，也经过了大量的客户调研，而之前一些不合逻辑的功能，可能就是为了1-2家特殊诊所。个性化定制本来就是Saas的大忌。但如果真的是我们判断失误了，确实是老系统好，我们也要毫不犹豫地改回去。
蓦然回首，落后竞品一大截
NO.9
重构的1年半时间里面，我们会经常去看竞品的功能，每次他们上线的变更都会仔细的看，有时候看得心里痒痒的，这个我们也计划做的啊，怎么被他们先做了去。这段时间80%的精力都花在了系统重构上，能被客户感知到的新功能自然做不多，我们眼睁睁的看着一些刚起的新兵，在这一年多的时间里面把功能做的比较强大，开始和我们抢客户了。经常客户提需求时，我们都说，这个功能新系统实现了。他们戏称我们在“憋大招”。虽然最后结果还不错，新系统推出了，客户满意度还挺高的，申请迁移的客户特别多。但我们在后面还是很心虚的，就怕什么都说在新系统能实现了，客户对新系统的预期过高，真正使用时有点不满意就产生很大的心理落差。所以，我们后面还做了些降预期的处理。
结局呢？你猜
NO.10
都看到第10点了，朋友，辛苦你陪着我走完了这一遭，我们都希望像童话故事一样：重构圆满完成，开始新的征程。我们满腔热血地规划未来，目标就是：同行NO.1。这个目标不高，毕竟我们的新系统目前能排前三。上次有个客户还说：你们这类系统有其他做的好一点的吗，我知道的就你们和另外一家。我想了想，还真想不出第三家来了，倒真不是王婆卖瓜、自卖自夸，这只是产品经理实事求是的自信。最后，你应该猜到结局了吧，老板说：这条业务线亏损好几年了，先stop吧。所有的人都懵了，这么一年半时间的心血，有种白费了的无力感。我们一个团队二三十人，都咬着牙，天天加班在做，调休假都积了20多天没时间休，还基本没有人离职，这么苦都熬过来了，却在刚看到光明的时候被扼杀了。其实，站在公司的层面，我能理解老板的决定。但对于产品经理来说，还是觉得不甘心。产品就像是自己的孩子，还没养大就要放手了。
总结
THE END
上周简历很火，改简历的朋友也特别多，再讲下福利哦！
关注公众号，回复“offer”，免费领取
高邀约率简历模板+50条高频面试问题及答题技巧！
最后介绍下我们的社群服务
总价值¥2438的星球福利包，现在只要¥158即可加入
最后附上星球大额优惠券