职业生涯 产品 查看内容

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

老高 | 发布于 2020-12-02 09:30| 浏览()| 评论() | 收藏() | 点赞() | 打印

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

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

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

  • 维护成本越来越高

  • 用户体验越来越差

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

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

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

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

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

老客户的迁移成本。

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

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

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

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

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

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

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

1: 做好人的准备。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5: 尽最大努力的做减法,每一次成功的减法都是一次胜利。

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

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

1: 每次迭代升级,让客户不断的有甜头可尝。

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

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

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

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

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

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

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

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

发表评论(对文章涉及的知识点还有疑问,可以在这里留言,老高看到后会及时回复的。)

表情