原则系列－如何解救一款难以持续的SaaS产品吕布是怎么死的

原来简单提过这个话题，今天再相对深入的和大家探讨下。中国目前绝大多数saas公司都是销售驱动，客户需求驱动，很难拒绝定制开发，很容易就做成项目了，除非有很强产品力和业务洞察力的团队来做，否则慢慢的经过几年积累，产品就会变得臃肿不堪。

产品一旦变的臃肿，就会碰到很多问题：

• 维护成本越来越高

• 用户体验越来越差

• 积累的客户从资源变成绳索，调整的难度以及工作量越来越大。

这种情况下，应对一些市场新锐的竞争就很被动。而且体验差了之后客户会慢慢流失，团队对此无能为力，从而陷入进退两难的困境，这也是中国大多数B端产品企业的现状。

现有产品上重构or另起炉灶新开发一套？这个时候，公司就面临艰难的抉择，基本上所有研发团队都会建议另起炉灶，从研发角度这是更简单，更高效的方式，不用管原来的恶心代码，团队士气也会更高一些，但从公司的角度，更需要考虑几个因素：

• 新系统的开发成本以及开发周期。

  
  

一套新的系统从开发到小部分客户上线使用，再到成熟稳定，是需要相当长的打磨周期的。

• 老客户的迁移成本。

这个成本包括在迁移过程中投入的BD、实施、培训、售后成本，也包括客户投入的成本。

• 在并行期间，涉及到一些bug或者需求，需要两边都开发的成本。

• 人员需要两套班子，应对不同产品线，开发，实施，培训，售后都需要两套，招聘培养扩展的难度都会变大。另外两条产品线之间产品还高度耦合，沟通工作量大。

一般来说，B端产品的迁移成本极高，客户要改变使用习惯成本也极高。而且总有一些客户不愿意迁移，最终不可避免的结局就是长期维护两套系统。没有经历过的人是很难想象这样的代价和成本的，迁移老客户，老客户劳筋动骨；不迁移老客户，老客户一定程度受忽视和伤害，影响口碑；

除非客户非常少，或者可以基本保证比较低成本的全部迁移，笔者很不建议另起炉灶新开发一套，成本极大，除了所有的成本乘以2，还有迁移以及客户那边的成本，每一个客户的迁移以及实施落地可能都是一个复杂的项目。

所以新开发一套相比在现有产品上重构，成本绝对是指数级的增大。很多公司这样选择后，陷入对新产品不够满意，老产品也迁移不过去的困境，浪费大量时间和资源，笔者鲜有发现成功案例。

那如果需要去庖丁解牛的重构一套系统，我们应该怎样来做呢，笔者觉得可以参考以下思路以及原则：

1: 做好人的准备。
如同我以前一篇文章中说到的，人是事情成功与否的最关键要素。要做好庖丁解牛的工作，有几个角色非常重要，数据库架构师，解决方案架构师，功能架构师。不一定每个角色都需要一个人，但是一定要有人承担对应的角色。比如说数据库是B端产品的基石，一旦错误之后调整的成本非常高，数据库架构师需要是懂数据库设计技术，对业务发展、业务细节非常了解并有前瞻性的一个人或者多个人来协作。解决方案架构师实际也是需要是懂业务，并对技术有理解的一个人或者多个人。

B端产品是一个交叉学科，单一的懂业务，懂技术的人都相对好找。既理解业务，也理解技术，并且能够有机结合的人比较难找，这种人目前在中国属于稀缺资源。一般来说，这种交叉学科，技术的人去学习业务比业务的人学习技术要容易一些，公司内部要选择合适的人往这个方向培养。

如果在短时间内很难有合适的人，也最好有一个外部的顾问来进行一定程度的把关。

2: 将理想的产品形态大致的设计出来。

要确定产品重构的路径，需要将产品最终的大致架构，主要是功能架构，系统架构设计出来，另外确定一些核心业务设计的思路以及原则，反复打磨，才能得出比较满意的答案。知道了终点大概是怎样的，才能很好的思考最佳的前进路径。

3: 做好重构优先级的选择。

对于产品的重构来说，路径以及优先级的选择极其重要，能够找到最合理，最省力的路径是非常考验团队的，这里很难有一个固定的答案，但是有一些原则性的内容可以去遵循：

• 优先做好地基式的核心架构调整。

做重构最核心的是将数据库架构，产品功能架构，页面架构做正确。数据库也好，功能也好，页面架构也好，实际上就是找到最合理的方式，就是在用户体验以及产品的生长性之间找到平衡点。一般来说，让用户用足够少的页面看到足够多关心的内容对于体验是最好的，但是产品是生长的，架构分类没有分好，最后功能或者页面也会非常拥挤，不能扩展，所以需要找到体验和生长性之间最佳的平衡点。

一些核心的数据库表，核心的功能架构需要尽量优先的去调整，在错误的数据库，错误的功能架构上做的内容都是无用功，还是要重新来过。

• 优先做好核心或者特别烂的功能的重构

一些高频使用的核心模块，或者特别烂的功能要优先去重构，这种重构对用户的价值也是最大的，客户有足够的动力来进行配合。

• 优先做好新需求量大的模块重构。

产品不是静态的，我们在做产品重构的时候，一定会面临外部大量的需求还在不断的涌进来，对于新需求很多的功能模块，与其在错误的功能基础上面花大量的时间做新需求，还不如重新来做一下。实际上所谓的重构，很多时候都是一个个模块，一个个功能进行重写，将大的风险用敏捷，庖丁解牛的方式去分解掉。

4: 追求极致，不要重蹈覆辙，每次重构的机会都是一次重生的机会。

这个不用多说，每次重构一个模块，都是一次重生的机会。我们不能用一个坑去填另外一个坑，至少要做到85分以上的设计才开始动手，不要一味的追求速度。

5: 尽最大努力的做减法，每一次成功的减法都是一次胜利。
对于臃肿系统的重构，在重构重写过程中，一定要想尽一切办法做减法。模块的减法，功能的减法，甚至一个字段的显示，一个检索条件，减到极致，好的重构一定伴随着大量的减法。

从客户角度，每次重构之后的升级对于已经熟悉历史系统的人来说，都是一次折磨，折磨的次数多了客户是容易崩溃的。从用户的体验和口碑的角度，在迭代安排上面有如下的一些建议事项：

1: 每次迭代升级，让客户不断的有甜头可尝。
每次迭代升级，重构后的新版本体验需要大大超过原来的版本，或者有能够解决客户痛点的新功能，用户才有动力升级。在设计安排每次迭代计划的时候，要充分的考虑用户升级的动力，否则会碰到很多阻力。

2: 迁移升级过程，尽量做到客户无感知，免培训，减少客户的投入成本。
每次重构之后的升级经常会伴随数据迁移，这个负担不要给到客户，实施团队帮助客户完成，另外每次重构后的功能要做到基本上不需要培训，客户也可以基本上不用投入实施培训的成本。

3: 做好灰度测试，先要确认新的功能可行再进行全量的发布。

每次大的重构，都需要一定时间的灰度测试周期，让一些典型客户先将重构的模块用一下，确保没有问题之后再进行全量发布，这样可以尽量少的折腾客户。每一次折腾，都会带来不信任以及后面的不配合，产品口碑变差。

4: 新客户只开放必要的功能，减少后续迁移的成本。
这是一个小的tips，对于老产品中一些做的不好的非必要功能，在重构的过程中，通过权限处理，就不要开放给不断增加的新客户了，免得后面还增加迁移的成本。

重构很难；简洁很难；人生很难；不过大部分人只有经历过足够多难题之后才能找到内心的从容，过好平淡的生活。

END

SaaS产品说近期精选文章:
(原则）SaaS创业公司产研团队的组建
(原则）如何保持B端产品的简洁
（原则）如何定义需求的优先级
（原则）敏捷开发适合B端产品吗
（原则）如何定义B端产品MVP(下）
（原则）如何定义B端产品MVP(上）
（原则）B端产品数据库设计的一些原则
（原则）如何让B端产品像C端一样极致易用
（原则）如何做B端产品的PMF