答应我，Saas重构前这10个坑一定要看完！

我认为重构坑太大，因此我将从十个方向告诉您重构之前需要注意的几点。

我认为重构的坑太大了，所以让我们从十个方向来谈谈，在重构之前值得注意的几点。

如果您尚未进行重建，请查看这10个坑并收集它们。 下次，您需要将它们拒之门外，然后再次仔细查看它们。 顺带一提，让您的领导一下。 如果您踩在重建坑上，也请参阅这些坑。 那些没有踩到的东西应该引起注意！ 如果不幸的是您像我一样完成了重构，那就握手吧。

首先，我们对重新配置有一个清晰的定义：我们需要从内部到外部重做以前的系统，然后我们将拥有两个独立且不相关的系统，而不是对先前系统进行部分重新配置，因为坑 部分重新配置的数量不够大。 重构是因为先前的技术框架无法支持新功能的后续迭代。

让我们谈谈这10个坑！

设计不合理，更改与否？

2年前，我加入了公司，我的任务是重建系统。 以前的产品经理不知道他已经更改了几波，也没有留下完整的文档。 要进行重建，我们必须了解旧系统，例如手背。 没有办法。 我们只能花两周的时间来整理旧系统的逻辑。 在某些业务流程中，我们发现了许多不合逻辑的地方。 例如，药房退回药品后，其状态不是退回而是返回上一步：等待药品交付； 治疗师已经开始治疗，医生可以删除医生的订购项目，记录突然消失； 待付款项目将在几天后自动关闭，并且作为严格的产品经理将无法收回这笔款项，这些不合理的事必须予以更改！ 因此，我将退药的状态更改为退回的药，诊所的药剂师也爆炸了：“我发现，只有在我将药寄出后，医生才开错了处方，所以我拿回了药，让医生进行了更换 并重新发行。现在您已经退还药物，并且已经直接退还。医生如何更换它？”

我怎么能认为医生总是开错药？ 听了之后，我很害怕。 不应因为患者不想要药物而撤药吗？ 为了保持我以前的完美逻辑，我添加了另一个功能：返回修改。 我认为其他诊所的药剂师在阅读此按钮后会有一种奇怪的感觉。 当谈到这些非理性时，

确实很纠结。 以前的产品经理也不是傻瓜。 他故意制造了逻辑缺陷，必须由客户强制实施。 但是，为了抱怨系统中功能逻辑的一致性和合理性，这是不可避免的。

如何打破用户习惯？ 上面也提到了

，我们重构的主要原因是以前的技术框架太旧，无法支持新功能的迭代。

，但是，如果领导者只是在技术水平上重新构建一套系统，而愿景和互动体验却没有改变，他们怎么能感觉到我们团队的价值呢？ 技术无法直接看到。 互动和视觉很容易被察觉。

我们经常看到的是C端产品。 一段时间后，我们将更改一组视觉样式，该样式必须易于使用，尤其是一些低频必需品，例如移动银行，但这对于领导者展示表现是一件好事。

因此，要重建SaaS，必须改变视觉和交互！ 但是，让我们尽量不要改变太多：

我们真的不能高估用户的计算机级别。 例如，如果我们更改时间控件，他们将不会使用它。

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

现在使用元素的组件，用户如何不能选择时间段？ 他认为他想双击以进行选择，然后在某个日期（即选择日）上单击了两次。

也有非常重要的一点。 在用户切换系统之前，请要求他们使用更多新系统，直到他们习惯为止。 最好熟练地使用它们。 否则，一旦工作繁忙，系统将无法正常工作，并且会有更多的投诉。

重构的内容越来越多，一般来说

saas并不是一个单一的系统。 它将具有一个操作平台，以及外部对接，例如公司内其他业务的对接以及第三方应用程序的对接。

我们只是想重建用户端的系统，而没有其他动作。 但是，当我们这样做时，我们发现必须重做操作平台，并且必须重做所有外部对接，例如聚合支付对接，出站对接检查。 工作量比预期增加了一倍以上。

因此，在评估重构的内容时，最好仔细阅读所有与重构有关的内容。 尽管这个主意非常好，但是如果您不对其进行尽可能多的更改，请不要动，但要做好重新计划的准备。 <

的功能必须> 旧的系统可以将

重构的系统和系统从0升级为1。最大的不同是：不同的商业时间，不同的升级方案。 我们都知道MVP的真相，但这在重建系统时不起作用。 我们的用户迁移到新系统上使用。 旧系统具有某些功能，而新系统则必须具有。 否则，他们的工作将无法进行。

，但是在我们发展它时，我们不可能招募数十人。 所有功能都是同步开发的，因此我们必须分批进行。 例如，我们首先执行门诊相关功能，然后执行物料库存管理功能。 如果是0到1的乘积，我们可以在门诊服务后开始小规模促销，让一些库存管理要求较低的小型诊所首先使用它，并在随后的新功能开发中一起优化旧功能。

当然，为了防止我们在更改旧功能和添加新功能时出现偏差，每个版本上线后我们都会发现一些用户体验，但毕竟与实际使用有所不同。 这个重构过程有点像一个半黑匣子，对产品经理有更高的要求。 如上所述，对于新功能，建议遵循MVP原则，而不要立即全部完成。 以

为例，我们最初计划做健康管理功能，设计是完美的，包括用户自己的家庭测量数据上传以及家庭医生的多对一服务。 但是后来，我将其删除了，但只提供了一个运行状况索引数据库。 尽管这是一个发展方向，并且许多诊所都提到了这一点，但现在只有少数人真正能够做到这一点，事实证明我们是对的。 延长

在线时间，然后延长

。 我们最初计划在4个月内对其进行重建，因此需求文档必须在1个月内完成。 当我们的产品经理每天超过10点加班时，我们就会按时交付PRD。

从3月开始，预计将在6月重建。 后来，据说重建于十月，然后更改为第二年年初，然后更改为三月。 猜猜，最近几个月？ 明年十月！ 花了一年半的时间。 我们不想看到

项目延迟，但原因并非全都是人为造成的。 我总结了以下几点：

在这段时间内对销售和客户服务造成很大压力。 之前已经积累了数百种需求，并且已经向客户承诺这样做。 尽管我们确实设计了新系统，但是客户无法使用它。 起初，当我认为它将在6月完成时，当客户敦促需求时，我告诉他们新系统已经构建并且可以使用。 但是后来，销售部门不敢让用户知道我们有两个系统，因为担心他们总是会问新系统什么时候上线。

有一个老客户超过3年。 在会议期间，他一直坚持说：“我是您的第一批用户。我提出了这两个要求，并告诉我我会这样做。让我等待。结果，我等不及了。 2年。我真的等不起。”

数据迁移是一个大漏洞

我们重建的系统是一个全新的系统，与旧系统无关。 如果用户要使用新系统，则必须将旧系统的数据迁移到新系统，否则客户信息和历史病历将丢失，这肯定不好。

数据迁移并不像您想的那么简单：开发和编写脚本，只是分批运行。 在进行数据迁移之前，产品经理应清楚地写出迁移字段的交叉引用关系。 我们已经撰写了20多页文档，超过1000个字段。 在

中有很多要注意的地方。 简而言之，让我们感受一下复杂性：将文档交给开发人员后，每个模块都负责数据迁移代码的开发，并且工作量不小。 到那时，六个或七个开发项目已经写了一个多月。 最后，客户可以申请迁移。 我们无法尽快完成迁移。 在正式迁移之前，开发人员将尝试多次迁移，并且只有在通过多次测试验证数据正常之后，才会通知客户正式迁移。 数据量少的客户可能需要2-3个小时才能迁移，而数据量大的客户则需要6-7个小时。

，但我们必须了解两个系统是不同的，并且不可能进行无缝连接而不会出现任何错误。 尽管我们会提前告知客户迁移的预防措施，并让他们通过电子邮件确认已知的风险，但我们无法避免迁移后出现的问题，甚至要求他们退回。

完成了数据迁移，这表明系统的重建已基本完成。 但是不要太早高兴。 测试后有测试。 尽管据说新系统的功能是成批完成的，并且是成批在线的，但新的上层系统仍然不稳定。 没有真正的用户，很多问题都不会爆发。 当我们完成重新配置并与外界正式开展业务时，立即启动如此大的系统的风险仍然很大。

快到了新年，诊所很忙。 结果，页面加载速度非常慢，服务器异常，并且系统无法每隔一天登录一次。 客户的意见很大，在我们的年终研究中给我们的分数很低。

在新系统中出现错误是正常的。 毕竟，测试用例的覆盖范围是有限的，并且有许多客户无法预料的操作方式。 但是，功能越多，发生错误的可能性就越大； 另一方面，不同的功能分散在不同的开发中，因此，修复错误后，由于同步不到位，将解决更大的问题。

的那段时间非常恐怖。 恐怕在早上到达公司之前，客户群激增了。 在运行了一个多月之后，新系统终于稳定下来，至少不会有大的错误。 这时候，我有点放心了。

：客户总是谈论旧系统。 如果

没有比较，就不会有伤害。 如果新客户直接使用新系统，则问题将更少。 迁移的旧客户有很多问题，因为他们可以谈论旧系统。 例如

，他自己诊所的药剂师要求我在退还药品后更改要交付的药品状态，因为旧系统是这样的； 医生说我要用病人的医疗卡