当重构不可避免发生的时候，产品经理要弄清楚重构的原因并在重构之前做好准备。

市场上的saas公司有一个很奇特的现象，要么打算开始重构，要么已经走在重构的路上，似乎永远脱离不了重构的魔咒。

我当时去丁香园的时候，主要就是为了去做整个系统的重构（严格意义上来讲应该叫重做）。

一、为什么频繁出现重构？

在我看来，主要有以下3点关键原因。

1. 没有考虑清楚业务发展轨迹

很多公司在刚创立之初，或者是业务线刚启动之初，倾向粗放式发展，或者缺乏有体系的业务和产品规划。什么是粗放式发展，就是说前期收到一个客户需求，简单判断后，就开始设计并开发落地。

整个过程遵循的一个道理是快速、简单、高效的落地，并投入市场。

快就会意味着很多环节都缺乏足够的分析和论证，很多决策会伴随着大量拍脑袋式的主观决定。

这样的方式有好处、也有坏处，好处就是顺应了业务，业务需要你快速给她一个可商用的产品，可以直接解决客户目前存在的问题，你在最短的时间内做好并交付，非常灵活

坏处也很明显，首先你做的产品只能对应的解决现有的客户需求；另外过于快速的前期产品设计调研过程也会驱使产品经理弱视、甚至不去考虑产品未来会如何发展。

而随着用户需求在不久的未来不断升级，且产品并没有做好充足的可扩展性，就会发现现有的底层设计已经无法满足不断发展的业务变化了。

这就像造房子，你当初为了造个小平房，打了个适合小平房的浅地基，结果盖着盖着，你盖成了一座摩天大楼，毫无疑问这样的地基是无法承载摩天大楼的，无疑只能推倒重来。

很多时候，我们确实不知道未来业务会变成怎么样，有经验的PM能想的更深一些，判断的更准确些，但是也不可能完全预料的一模一样，因此无法因为这个原因完全避免重构，但是我们可以通过前期对于业务未来发展的方向判断，融入更多的可扩展性设计，减少因为这个原因所导致的重构的可能性。

举个例子，一个营销活动，涉及到商品选择、参加人员选择、参加规则设置、奖品的设置、投放渠道设置。

初期，考虑到尽快上线，采用创建活动页直接集成这些设置项，然后一步到位创建活动，对用户来说无疑是最便捷的，对开发来讲也无疑是最简单的。

但是随着营销活动的场景逐步增加，比如选择商品的时候需要支持按照规格进行筛选；选择参加人员的时候需要支持按照是否是会员进行筛选；投放渠道从原来1个渠道变成了3个渠道。

再比如当商品改动了某些属性，那么导致了营销活动创建中也得改；会员增加了等级种类，那么营销活动创建中也得增加；投放渠道和活动规则集成在一起，每次增加一个新渠道，就得重新写一遍活动创建。

这个时候开发就开始疯狂了，原先的方案随着业务的发展带来巨大的迭代成本，前期因为没有规划好产品，导致制定的技术方案几乎没有任何可扩展性，最终只能靠重构来彻底解决这个顽疾。

2. 产品功能设计问题

这是第二种比较高频的情况，就是产品功能设计有问题导致的重构

比如：我们原来针对诊所的预约系统，预约到科室维度，采用了科室组的概念，这是一个在线下没有的概念，是之前产品为了解决一个问题而生造出来的概念。

什么问题呢？

因为线下诊所存在这样的场景：一个医生需要在多个科室进行看诊，因此他的看诊时间被多个科室占用着。也就是说当用户A预约了科室1的上午8点，那么用户B就不能预约科室2（和科室1是同一个医生）的上午8点了。

所以为了解决这个问题，把科室1和科室2进行打包，设置成一个科室组，同时设置科室组的开放预约时间段。那么可以针对科室组进行预约。

这在当时其实是为了解决医生时间冲突的问题而专门设计的一个产品功能。

虽然大致上解决了这个问题，但是因为引入了科室组，导致客户在设置排班的时候操作更加复杂，理解难度也加大了，更不用说使用了（调研发现只有很少量客户在用）

虽然需求存在，但是因为功能的不合理设计，导致用户并没有真正用起来。也就是说这样一个刚需痛点并没有很好的解决。因此对该功能进行重构，就是当务之急了。

再举个例子：

产品经理希望用户在浏览商品列表页的时候，能够根据当前用户会员等级显示相应的会员价，导致了该页面最终需要请求多个接口，而使得页面加载异常的慢，在优化了几次后，也没有明显的改善。因此只能对该功能进行整体改造，这其实就是一次重构，只不过规模和复杂度相对较低，算是一个小重构。

3. 技术架构问题

有些重构，其实并不是产品层面的重构，更多是技术层面的重构。

1. 原先的底层表结构设计，已经无法满足并实现新的功能，业务倒逼重构
2. 原先的业务代码过于耦合，导致后续的迭代成本不断攀升
3. 还有就是原先代码有很多缺陷的地方，比如编码规范等，重构是对代码的完善
4. 原先开发人员的经验欠缺、业务分析不透彻，导致技术方案并不合理，优化或者更换技术方案
5. 还有就是新技术、新框架的流行所带来的代码进化要求

这三类问题几乎每家公司都遇到的问题，而且不只是产品问题，更多的是管理上的问题和人的问题。

对于saas产品来说，全站重构更是一个大体量、高难度、系统化的活。可以说如果考虑的不够透彻、准备不够充分、策略不够合理，就可能把一次重构变成一次灾难。

有的公司为什么给人感觉一直在重构，很大概率是之前重构完后，只用了1年，就又无法满足新的业务需求了，怎么办呢？再重构。

一次糟糕的重构既耗费了大量人力物力，也错失了市场的时间窗口，更会带来数不尽的坑，进而需要二次重构、三次重构来填坑，不夸张的说，很多公司是被重构耗死的。

那么作为一个重构掌舵者，你该如何规划好一次全站的系统重构呢？

前期的准备工作必不可少，没有做好充足的调研和分析，注定又会是一场失败之旅。

二、重构前必要的准备

1. 深度了解业务

这个我在之前分享过好几次了。

先要了解行业、其次是你们在做的市场、然后了解你们公司自己的业务、最后则是产品和竞品情况

了解这些后，有利于你回答以下几个问题：

1）公司对于本业务在未来3年的发展思路和要求

2）哪些功能相比竞品存在较大的落后和不足

3）从打造产品未来竞争优势角度，你会往什么方向进行产品迭代

这几个问题的答案就是为了搞清楚你的产品的主体功能和主流程是否在未来一段时间内会有较大的变化，以及怎么变？

因为他决定着产品架构，进而决定了重构的策略。

2. 深度接触客户

通过与客户的一线访谈，观察客户工作情况，了解用户的需求，以及他们对行业的看法和未来自身发展的计划。

你需要回答以下几个问题：

1）客户在未来3年随着自身的发展，更需要什么样的产品

2）客户目前使用产品过程中遇到的所有影响使用、功能无法满足的问题

3）客户对于其他竞品中觉得非常好的功能的推荐

3. 要知道一些底层逻辑

1）你需要了解现有的产品设计逻辑

2）需要大致了解技术的底层设计

3）目前哪些功能存在较为严重的产品设计问题

下一期会讲怎么如何评估需要重构的程度，以及怎么设计重构

#专栏作家#

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

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

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