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

0 评论 2789 浏览 5 收藏 12 分钟

编辑导语:近几年很多企业开始做SaaS产品,但是一些企业的产品经过多年的需求驱动积累,就会变的比较难以推动,产品也会陷入两难的地步;这时候是选择重构还是重新开发?本文作者分享了如何解救一款难以持续的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 原创发布于人人都是产品经理,未经许可,禁止转载。

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

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!