如何解救一款难以持续的SaaS产品

原来简单提过这个话题，今天再相对深入的和大家探讨下。

中国目前绝大多数saas公司都是销售驱动，客户需求驱动，很难拒绝定制开发，很容易就做成项目了；除非有很强产品力和业务洞察力的团队来做，否则慢慢的经过几年积累，产品就会变得臃肿不堪。

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

• 维护成本越来越高；
• 用户体验越来越差；
• 积累的客户从资源变成绳索，调整的难度以及工作量越来越大。

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

现有产品上重构or另起炉灶新开发一套？

这个时候，公司就面临艰难的抉择，基本上所有研发团队都会建议另起炉灶，从研发角度这是更简单、更高效的方式；不用管原来的恶心代码，团队士气也会更高一些。

但从公司的角度，更需要考虑几个因素：

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

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

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

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

一般来说，B端产品的迁移成本极高，客户要改变使用习惯成本也极高；而且总有一些客户不愿意迁移，最终不可避免的结局就是长期维护两套系统。

没有经历过的人是很难想象这样的代价和成本的，迁移老客户，老客户劳筋动骨；不迁移老客户，老客户一定程度受忽视和伤害，影响口碑。

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

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

一、重构的思路以及原则

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

1. 做好人的准备

如同我以前一篇文章中说到的，人是事情成功与否的最关键要素。

要做好庖丁解牛的工作，有几个角色非常重要，数据库架构师、解决方案架构师、功能架构师。

不一定每个角色都需要一个人，但是一定要有人承担对应的角色；比如说数据库是B端产品的基石，一旦错误之后调整的成本非常高，数据库架构师需要是懂数据库设计技术，对业务发展、业务细节非常了解，并有前瞻性的一个人或者多个人来协作；解决方案架构师实际也是需要是懂业务，并对技术有理解的一个人或者多个人。

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

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

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

要确定产品重构的路径，需要将产品最终的大致架构，主要是功能架构、系统架构设计出来；另外确定一些核心业务设计的思路以及原则，反复打磨，才能得出比较满意的答案。

知道了终点大概是怎样的，才能很好的思考最佳的前进路径。

3. 做好重构优先级的选择

对于产品的重构来说，路径以及优先级的选择极其重要，能够找到最合理，最省力的路径是非常考验团队的。

这里很难有一个固定的答案，但是有一些原则性的内容可以去遵循：

1）优先做好地基式的核心架构调整

做重构最核心的是将数据库架构、产品功能架构、页面架构做正确；数据库也好，功能也好，页面架构也好，实际上就是找到最合理的方式，就是在用户体验以及产品的生长性之间找到平衡点。

一般来说，让用户用足够少的页面看到足够多关心的内容对于体验是最好的；但是产品是生长的，架构分类没有分好，最后功能或者页面也会非常拥挤，不能扩展，所以需要找到体验和生长性之间最佳的平衡点。

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

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

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

3）优先做好新需求量大的模块重构

产品不是静态的，我们在做产品重构的时候，一定会面临外部大量的需求还在不断的涌进来；对于新需求很多的功能模块，与其在错误的功能基础上面花大量的时间做新需求，还不如重新来做一下。

实际上所谓的重构，很多时候都是一个个模块，一个个功能进行重写，将大的风险用敏捷，庖丁解牛的方式去分解掉。

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

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

5. 尽最大努力的做减法，每一次成功的减法都是一次胜利

对于臃肿系统的重构，在重构重写过程中，一定要想尽一切办法做减法；模块的减法、功能的减法，甚至一个字段的显示、一个检索条件，减到极致，好的重构一定伴随着大量的减法。

二、建议事项

从客户角度，每次重构之后的升级对于已经熟悉历史系统的人来说，都是一次折磨，折磨的次数多了客户是容易崩溃的。

从用户的体验和口碑的角度，在迭代安排上面有如下的一些建议事项：

1. 每次迭代升级，让客户不断的有甜头可尝

每次迭代升级，重构后的新版本体验需要大大超过原来的版本，或者有能够解决客户痛点的新功能，用户才有动力升级。

在设计安排每次迭代计划的时候，要充分的考虑用户升级的动力，否则会碰到很多阻力。

2. 迁移升级过程，尽量做到客户无感知，免培训，减少客户的投入成本

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

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

每次大的重构，都需要一定时间的灰度测试周期，让一些典型客户先将重构的模块用一下，确保没有问题之后再进行全量发布，这样可以尽量少的折腾客户。

每一次折腾，都会带来不信任以及后面的不配合，产品口碑变差。

4. 新客户只开放必要的功能，减少后续迁移的成本

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

#作者#

作者：李东林（微信公众号：SaaS产品说；微信号：jianguzhuxin），菜小秘联合创始人，原ADP大中华区产品负责人，14年To B研发与产品设计，团队管理经验，主导过多款大型企业管理软件的设计、研发、上线，也有过数年移动互联网TO C的创业经验。

本文作者@东林-Tony 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！