新知一下
海量新知
6 5 2 3 1 9 7

【干货】如何重构老系统?

刀哥说 | 资深产品经理 2022/09/23 09:37

新知达人, 【干货】如何重构老系统?

目录结构:

一、啥是系统重构?

二、为什么要系统重构?

三、系统重构,要注意哪些点?

四、该如何推动系统重构这件事?

五、个人过往真实案例分享

前言:

SuperG同学的公司,最近在搞各种大翻修,但是同时里边的员工还要正常工作,于是就出现了:因为厕所要重建,所以要换楼层上厕所,因为楼梯要重修,所以只能用电梯。

导致中午去撒个尿,一趟要20多分钟,造孽啊~

一、系统重构是什么意思?

系统重构,就是结合业务现状,重新设计系统

并不是完全的从0到1,其实是从1到10的过程,既然老系统让公司业务正常运转了那么多年,肯定有其可取之处,千万不要全盘否定,而是要深挖业务,做好用户调研,保留重要的业务场景、流程,取其精华去其糟粕。

二、为什么要系统重构?

  • 老了,跑不动了,年轻人~

  • 各板块之间耦合关联性太深

  • 很多功能已无法满足飞速发展的业务现状

  • 已经在现有系统打了各种补丁,让系统变得越来越臃肿

  • 很多业务流程非常长,牵一发而动全身

  • 优化系统功能,已变得举步维艰,动哪块都感觉不自在不合理

三、系统重构,要注意哪些点?

1·结合各垂直事业部业务场景,梳理业务流程现状

先梳理业务流程现状,再结合现状提出可优化的流程点与业务协商,双方意见没冲突,那就可以往下推进。

梳理时,建议重点关注以下几点:

  • 主要流程:先把当前主要大流程搞清楚,一般比较容易整理

  • 正向流程:一件事情的正常流转

  • 逆向流程:事情是同一件事,但往往是一些非常规流程更难处理

  • 单业务流程:一个事业部,一个业务线的流程

  • 多业务流程:一个事业部,多个业务线的流程

  • 跨系统:从上游到下游,多系统之间的数据是如何流转的

  • 跨模块流程:当前系统,不同模块之间数据是如何输入输出的

2·合理拆分,系统各板块功能边界

  • 哪些属于基础主数据?

  • 哪些属于公共功能?

  • 哪些属于不同业务线功能?

  • 前后端功能该如何拆分?

  • 各模块之间如何关联?

3·逐层梳理产品架构

产品架构的本质:

理解透彻如何挑出白萝卜、红萝卜,这些萝卜又应该分别放进哪个箩筐。

新知达人, 【干货】如何重构老系统?

展示层: 系统以什么样的形式给人使用?电脑桌面、浏览器、手机、ipad等。公司内部业务系统,一般是浏览器访问。

表现层: 系统长什么样?也就是产品原型,菜单结构如何划分,页面功能解决什么问题?功能页面如何体现?业务流程该怎么走?等。

业务层: 业务功能特性,整理各事业部的特色业务功能;你必须有,别的业务不需要。

随着时间的推移,会有不少中台层的功能变成业务层的功能;反之,业务层的功能很少会变成中台层的功能。为何?

因为随着公司的发展,各事业部的业务个性化需求会越来越明显,想去优化又因为是公共功能改不了,怎么办?只能从中台层剥离变成业务层特有功能。

中台层: 共性功能,各事业部都需要的共有功能;你有我有全都有啊~

要想做好中台层的架构,首先得知道中台到底是什么?阿里官方的解释:“前台”就是贴近最终用户/商家的业务部门,包括零售电商、广告业务、云计算、物流以及其它创新业务等。

而“中台”则是强调 资源整合、能力沉淀的平台体系 ,为“前台”的业务开展 提供底层的技术、数据等资源和能力的支持 ,中台将集合整个集团的运营数据能力、产品技术能力,对各前台业务形成强力支撑;官方的解释是推出中台为了提升效率支撑前台业务的快速发展。

支撑层: 辅助功能+对接的外部系统。比如:权限管理,销售平台对接,物流服务对接,沟通工具,等。

4·定义不改什么比要改什么更难

要改什么,咨询下业务体验下系统,画画流程图跑跑业务数据,一般都能发现。但是,哪些地方又不改,直接迁移到新系统呢?迁移之后,能否与新的业务模型,产品架构耦合呢?

不改的前提有三个,重点深度思考:能满足业务现状,业务比较喜欢这块功能,迁移到新系统风险比较小。

5·历史数据如何处理?

哪些数据是可以舍弃,哪些数据是当前就应该人工维护以便后期批量导入?

如果有些重要数据是不能舍弃,那么在做表结构设计的时候,就要考虑前后数据库表字段的兼容性。

要么在新表中的字段包含旧表必填字段,要么新旧表字段之间有一对一映射关系。

系统重构,数据库中大部分表必然要调整或者重新设计,但小部分表能保留的建议保留复用。

6·业务同事的对互联网软件的接受程度如何?

为何有此一问,举个例子,如果你的用户连英文都不会,你做个中英文双语系统;再比如,你的用户连电脑都不怎么会用,你却做了个系统,他们简单的操作一件事情,要跳转五六个页面。

你我都不是真实用户,不要把用户的水平想象的太高,这不是贬低而是真的换位思考。如果是以上这两种情况,前者英文版本去掉,后者将页面尽量做简洁,流程能合并的合并,说明该给就加粗放大提示清楚,他们在乎的不是页面丑不丑,而是页面少一点,流程简单一点,解释说明明显一点。

对于这类人,多做几次产品培训,保留好培训视频。老系统重构,在此问题上,永远不是他们的问题,而是你的耐心问题。

7·投入产出比

是否一定要重构系统,能否通过更低成本的业务培训或者优化当前系统解决现有问题,但凡有一点希望,我们都不要去贸然重构系统。

如果非改不可呢?那一定要先做好投入产出比的估算,改造老系统都是吃力不讨好的事情。做好了可能并不会获得多少表扬,做砸了就会有严重的后果,被辞退或者降职降薪。

这个应该是大佬们最关注的问题,要投入多少人天,花费多少时间、金钱,建议列个功能清单,将整个项目计划列一下,让大佬心中有数。

8·灰度测试环境数据是否完善

都要动刀了,结果连个测试的地方都没有肯定不行;为了以防万一,灰度测试环境的数据应该定期维护,尽量保持跟正式环境一致,但不用做到实时,一般一周更新同步一次即可

9·多跟业务、技术沟通

千万别他喵的闭门造车不懂装懂,记住一点,人家骂你蠢好过被辞退。你这不是改造系统,你这是在造定时炸弹。

开动之前,一定要先吃透系统现有的逻辑,不懂就问。页面、规则、流程我们一般都会去问。但是,小的点也不要放过,比如一些业务专有名词是什么意思。

10·立项之前产品内部先达成一致

先在产品团队内部消化掉自己能消化的所有问题后,再走出门对外沟通推进。

11·哪个地方先开刀?

识别可以最快可以独立重构的模块,搭好全局重构的优先步骤。一般对现有业务影响比较小的闭环功能,适合先搞起来。

12·不要影响现有业务正常运转

业务不可能等着你系统做好,系统无论如何重构优化都跟不上业务的发展速度,除非公司倒闭。

那么,结合这种现实情况,我们在做系统重构的时候,个人建议新旧系统双系统并行。老系统继续打补丁,新系统分好优先级按进度开发。

13·不要忽视权限管理的重要性

系统设计之初,一定要重视这块,虽属于基础支持层功能,但一旦系统使用的人越多这里存在的价值就体现的越大。

权限配置这块无非包含:公司组织架构管理,用户管理,角色管理,权限配置。大圈套小圈,最终实现一个用户可以拥有多个角色,一个角色可以有多个权限,一个权限可以分为按钮权限,数据权限等。

四、该如何推动系统重构这件事?

  • 立项,拿着功能清单,让各方大佬签字画押

  • 招人,重构非儿戏,找有相关项目经验的产品经理,开发等

  • 宣讲,开会将完整的初步产品解决方案同步给项目组所有相关人

  • 大佬,带头的梳理产品架构,技术架构,主流业务流程图等

  • 分工,各小弟针对大佬的产品架构图,认领自己擅长或者感兴趣的模块

  • 做事,使用模块化方法,画流程图画原型,将系统各板块高内聚低耦合;如果能力足够,可以为开发梳理产品信息结构图(约等于E-R实体关系图),这个有助于他们更好的做数据库表结构设计。

  • 内部,产品团队内部,各小弟将自己画好的流程图、原型图汇总整合,跑通目前有考虑到的业务场景下的业务流程。

  • 初审,跟业务对原型和流程,查漏补缺。这里主要关注,业务场景是否齐全,逆向流程是否有遗漏。

  • 二审,跟开发团队对原型和流程,这里主要沟通原型规则,流程图

  • 终审,叫上项目组所有成员,主要是让团队所有人信息同频,业务跟开发理解的是否一致。还有,强调清楚本项目所有风险点,避免后期踩坑。

  • 概要设计/测试用例评审,也就是让技术反讲咱们的产品设计方案。背景、目的、了解清楚没,数据库表结构怎么设计,业务规则、流程有哪些等等。

  • 开发测试都能讲清楚,接下来咱们产品的主要工作就变成保姆了。动不动就关怀嘘寒问暖一下,保证项目过程中正常推进即可。

五、采用模块化设计理念,重构商品模型

什么是模块化?让系统功能高内聚、低耦合、可复用、可扩展。

比如一个积木是一个节点,十个积木搭建成一个组合。这个组合可以单独拿出去用,可以和其他的组合继续组合,变形金刚里的大力神就是6个机器人组合的,就是模块化。

结合本话题,分享下我在前公司采用模块化设计理念,做的案例:

 老电商系统,商品模型如何重构

-END-

作者:猪哥,吴日华,八妹-社交-深圳、Henry、庆慧|医药|深圳|产品、SuperG-北京-医疗 、广州-产品-小程、老虎色

 

更多“系统”相关内容

更多“系统”相关内容

新知精选

更多新知精选