起点学院课程

答应我,Saas重构前这10个坑一定要看完!

4 评论 3374 浏览 30 收藏 19 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

我觉得重构这个坑太大了,所以就从十个方向来说说,重构前到底有哪些点是值得注意的。

如果你没有做过重构,请看完这10个坑后收藏起来,下次要重构前翻出来再仔细看一遍,顺便给你的leader也看看;如果你正踩在重构的坑上,也请看完这些坑,那些还没踩的千万要注意了!如果你不幸和我一样做完了重构,来,我们握个手吧。

首先,我们明确下重构这个定义:把之前的系统从里到外地重新做一遍,做完后就是2套独立不相干的系统,不是在之前的系统上部分重构,因为部分重构的坑还不够大。重构是因为之前的技术框架不能支持后续新功能的迭代了。

下面就来说说这10大坑吧!

设计不合理,改不改?

2年前我入职,任务就是重构系统,之前的产品经理不知道换了多少波,也没有留下完整的文档。要重构,肯定要对老系统了如指掌啊,没办法,我们只能先花2个礼拜的时间,把老系统的逻辑基本完整地梳理下来。

在一些业务流程方面,就发现很多不合乎逻辑的地方。比如药房退药以后,药品的状态不是已退药,而是又回到了上一步:待发药;治疗师已经开始治疗了,医生还能把医嘱项删掉,这条记录就突然消失了;待收费的项目几天后就自动关闭了,这钱追不回来了……

作为一个严谨的产品经理,这些不合理肯定要改!于是我就把退药后的状态改成了已退药,结果自家诊所的药师就炸了:“我药发出去以后才发现医生开错了,把药拿回来让医生改了重新发,你现在退了药直接就是已退药,那医生怎么改?”

我怎么会想到医生老是会开错药呢,听完突然心里怕怕的,退药不应该是患者不想要了吗?为了保持我之前完美的逻辑,我又加了个功能:退回修改。我估计其他诊所的药师看了这个按钮会有种莫名其妙的感觉吧。

遇到这些不合理时,真的挺纠结的,之前的产品经理也不是傻子,故意弄个逻辑缺陷,肯定是被客户逼的。但为了系统内功能逻辑的一致性和合理性,我们还是改了之前不合理的地方,后面被吐槽也是在所难免的。

用户习惯怎么破?

上面也说到,我们重构的主要原因是:之前的技术框架太老,不能支持新功能的迭代。

但如果只是技术层面上去重做一套系统,视觉和交互体验上都没有改变的话,领导如何感知到我们团队的价值?技术是不能被直观看到的东西,交互和视觉才是容易被感知到的东西。

我们经常看到的是C端产品,过段时间就换一套视觉风格,并一定对用户友好,特别是一些低频的必须品,比如说手机银行,但这是能让领导秀业绩的好东西。

所以,重构Saas,视觉和交互一定要改!但我们尽量不要改太多:

  1. 系统结构框架和页面上功能布局改动不要太大,方便快速找到功能;
  2. 菜单和页面上的名词尽量不要改动,且各模块间保持一致;
  3. 交互形式和组件要全局统一的改,不然前后操作不一致,用户使用时更懵。

我们真的不能太高估用户的电脑水平,比如说我们就改了个时间控件,他们就不会用了。

之前的时间控件是这样的,开始时间和结束时间分开选择:

答应我,Saas重构前这10个坑一定要看完!

现在用的Element的组件,用户说怎么不能选一段时间了?原来他以为是要双击选中,然后在一个日期上点了2次,就成了选中一天。

答应我,Saas重构前这10个坑一定要看完!

还有很重要的一点,在用户切换系统前,请他们多使用新系统,直到能习惯,最好能比较熟练地使用。不然工作一忙,系统又不会用,抱怨就更多了。

重构内容越做越多

Saas一般都不是一个单一的系统,他会有运营平台,还有和外部的对接,比如公司内部其他业务的对接,第三方应用的对接。

我们原本只是想重构用户端的系统,其他都不动,但做着做着就发现,运营平台要重做,所有的外部对接也要重做,比如说聚合支付对接,检验外送对接。工作量比之前预想的翻了一倍不止。

所以,在评估重构内容时,最好把所有和他相关的东西都捋一遍,虽然想法很好,尽可能不改的就不要动,但要做好都重做一遍的打算。

功能必须>老系统才可推广

重构的系统和从0到1的系统,很大的区别是:商用时间不同,推广方案不同

我们都知道MVP的道理,但这个在重构系统时行不通。我们的用户迁移到新系统使用,老系统有的功能新系统必须有啊,不然他们的工作没法开展。

但我们开发时不可能招上几十个人,所有功能同步开发,肯定还是要分批做的。比如我们先做门诊相关的功能,物资库存管理的功能后面再做。如果是从0到1的产品,我们可以做完门诊后就开始小范围推广,让一些对库存管理要求不高的小诊所先用起来,在后续新功能开发时一起优化老功能。

当然,为了防止我们改动老功能和加入新功能时跑偏,我们每个版本上线后也会找一些用户体验,但毕竟和真实使用是有区别的。这个重构的过程有点像半黑盒子,对产品经理的要求更高,改动功能上面说过了,对于新加功能,还是建议遵循MVP的原则,不要一下子做全。

比如我们本来打算做健康管理的功能,设计的很完美,包括用户自己在家测量数据后上传,家庭医生多对1的服务。但后面做的时候删到了最简,只给了一个健康指标库。虽然这是一个发展方向,也有很多诊所提,但现在真正有能力做起来的还是凤毛麟角的,事实也证明我们是对的。

上线时间一延再延

我们原本打算用4个月的时间重构,这样需求文档必须要在1个月内完成,在我们产品经理每天加班到10点多的情况下,我们不负众望地按时把PRD交给了开发。

从3月份开始,预计到6月份完成的重构,后来说要到10月份,后来又改成了第二年年初,后面又到了3月份。你猜,最后几月份做完了?第二年10月份!整整用了1年半的时间

项目延期是我们都不愿意看到的,但这里面的原因也不都是人为能规避的,我总结了这几点:

  1. 原本只想重构1个系统的,结果越做越多;
  2. 开发动手前只顾眼前版本的功能,没有仔细看完所有文档,导致开发后面功能时发现不支持了,再把之前的功能又重新做一遍;
  3. 开发过程中产品经理还在不停调研用户,导致需求变更;
  4. 分出部分人力继续老系统功能的迭代,如果1年多的时间老系统一点不动,客户流失率很高,还是要适当的上新;
  5. 人员的变动:离职、调岗等,这方面我们还算基本稳定,不然第二年10月份都做不完。

这段时间销售、客服的压力都很大,之前就积累了几百条需求,答应了客户做。虽然我们在设计新系统时确实是做进去了,但是客户用不了啊。一开始以为6月份能做完的时候,客户催需求时,就告诉他们新系统做了,马上就能用了。但到后来,销售都不敢让用户知道我们有2套系统了,生怕一直问:新系统什么时候上线啊。

有个3年多的老客户,在大会的时候一直拉着我说:我是你们第一批用户,我就提了这2个需求,和我说会做的,让我等等,结果一等就是2年,我真的快等不起了。

数据迁移是大坑

我们重构的系统是一个完全新的系统,和老系统没有关系,那用户想要用新系统,就必须把老系统的数据都迁移到新系统,不然客户资料丢了、历史病历丢了,这个肯定是不行的。

数据迁移没有想象的那么简单:开发写个脚本,批量跑一下就行。数据迁移前,产品经理先要把迁移字段的对照关系写清楚,我们写了20几页文档,千余个字段。

里面有很多需要注意的点,简单的说几个让大家感受下其中的复杂度:

  1. 字段对不上。相同字段问题不大,缺少和增加的字段就要特别注明怎么处理。如果是之前比较重要的字段,但新系统去掉了,是否要保留过来?
  2. 业务类型有修改。比如老系统有方便门诊,新系统没有这个类型了,怎么处理老系统方便门诊的数据?
  3. 数据迁移不过来。不是所有数据都能做迁移的,有的是因为没法迁,要重新配置,比如外部对接;有的是因为数据量太大,成本太高,比如说统计报表。
  4. ……

我们把文档给到开发后,每个模块负责的开发分别写数据迁移的代码,这个工作量也不小,当时6、7个开发差不多写了1个多月。

终于,客户可以申请迁移了,我们还不能一迁就成功,开发在正式迁移之前,会先试迁几次,测试多次验证数据没有问题后,才会通知客户正式迁移。数据量小的客户可能2-3个小时就迁完了,数据量大的要6-7个小时。

但我们必须明白,2个系统就是不一样的,不可能百分百没差错的做无缝连接。虽然我们会把迁移的注意事项提前告知客户,并让他们邮件确认已知晓风险,但还是避免不了迁移后的问题,甚至还有要求要迁回去的。

做完数据迁移,标志着系统的重构基本完成了。但别高兴的太早,后面又是一场接一场的考验。

新上系统不稳定

虽然说新系统功能是分批做的,也是分批上线的,但一直不对外商用。没有真实用户的时候很多问题都不会爆发出来。当我们重构完成,正式对外商用时,一下子把这么一大个系统推出去,风险还是极大的。

那时快过年了,诊所的业务也特别忙,结果隔三差五的出现页面加载速度极慢、服务器异常、系统登录不了的情况,搞得客户意见很大,在我们年终调研时给我们的打分很低。

新上系统有bug是很正常的事情,毕竟测试用例的覆盖面有限,而且还有很多客户意想不到的操作方式。但功能越多,出现bug的概率就越大;另一方面,不同的功能分散在不同的开发身上,修复bug时常常会因为同步不到位,改出更大的问题来。

那段时间还是过的挺心惊胆战的,就怕早上还没到公司,客户群里就炸开了。差不多磨合了1个多月,新系统终于稳定下来了,至少不会出现很大的bug,这时才稍稍松了口气。

客户老拿老系统说事

没有对比,就没有伤害。新签客户直接用新系统,问题就少的多。迁移过来的老客户,问题可多了,因为他们可以拿老系统说事。

比如上面说的,自家诊所的药师要求退药后状态变为待发药,因为老系统是这样的;医生说我要把患者的就诊卡片用颜色区分出来,因为老系统的大色块看着清楚,但新系统的风格不是这样的啊;运营说为什么不能预约到科室,老系统可以,虽然我们已经给出了替代方案……

我们必须要想好怎么说服他们适应新功能,甚至指导他们规范自身业务,不要一不习惯就要求改回老系统那样,这样的话新系统的意义在哪。我们的设计也不是凭空捏造的,也经过了大量的客户调研,而之前一些不合逻辑的功能,可能就是为了1-2家特殊诊所。个性化定制本来就是Saas的大忌。

但如果真的是我们判断失误了,确实是老系统好,我们也要毫不犹豫地改回去。

蓦然回首,落后竞品一大截

重构的1年半时间里面,我们会经常去看竞品的功能,每次他们上线的变更都会仔细的看,有时候看得心里痒痒的,这个我们也计划做的啊,怎么被他们先做了去。

这段时间80%的精力都花在了系统重构上,能被客户感知到的新功能自然做不多,我们眼睁睁的看着一些刚起的新兵,在这一年多的时间里面把功能做的比较强大,开始和我们抢客户了

经常客户提需求时,我们都说,这个功能新系统实现了。他们戏称我们在“憋大招”。虽然最后结果还不错,新系统推出了,客户满意度还挺高的,申请迁移的客户特别多。但我们在后面还是很心虚的,就怕什么都说在新系统能实现了,客户对新系统的预期过高,真正使用时有点不满意就产生很大的心理落差。所以,我们后面还做了些降预期的处理。

结局呢?你猜

都看到第10点了,朋友,辛苦你陪着我走完了这一遭,我们都希望像童话故事一样:重构圆满完成,开始新的征程。

我们满腔热血地规划未来,目标就是:同行NO.1。这个目标不高,毕竟我们的新系统目前能排前三。

上次有个客户还说:你们这类系统有其他做的好一点的吗,我知道的就你们和另外一家。

我想了想,还真想不出第三家来了,倒真不是王婆卖瓜、自卖自夸,这只是产品经理实事求是的自信。

最后,你应该猜到结局了吧,老板说:这条业务线亏损好几年了,先stop吧。所有的人都懵了,这么一年半时间的心血,有种白费了的无力感。我们一个团队二三十人,都咬着牙,天天加班在做,调休假都积了20多天没时间休,还基本没有人离职,这么苦都熬过来了,却在刚看到光明的时候被扼杀了。

其实,站在公司的层面,我能理解老板的决定。但对于产品经理来说,还是觉得不甘心。产品就像是自己的孩子,还没养大就要放手了。

总结

虽说结局令人感到遗憾,但不得不说,这2年我的能力还是提升相当多的,就是被上面的那些大坑磨的。系统重构的过程,也是我重塑的过程。

#专栏作家#

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

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

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 用户皆NC,ZZ、

    回复
  2. 事有不协,推倒重构……

    回复
  3. 深有体会,即便没有进行重构,日常的开发过程中也会遇到很多类似的需求重做的情况,这一路的艰辛只有自己知道。

    回复
  4. 深有体会

    回复