老系统重构中的隐秘角落

老系统的重构对于一个传统公司或者是已经经营了很多年的公司来说，是数字化、智能化转型的必经之路。

公司里一般老系统走到了必须要重构的地步，说明该老系统在公司业务扭转中是有很重要的作用的。但是往往老系统的重构是一件很让产品研发团队比较头疼的事情，毕竟重构所涉及的反方面面太多，尤其是一些涉及到很多业务方工作扭转的系统。

15年前的老系统界面截图如下，供大家感受一下年代感：

一、重构背景

本人是从国内知名互联网大厂跳槽去了一个国内较老的传统IT公司，负责重构的老系统是公司在2005年研发出的一个类似erp系统，是.net开发的web系统，主要负责公司内部的一些文件资产的上传发布和存档。

该老系统为什么最终决定要重构？原因其实非常明了：

1. 该老系统是公司在05年开发的系统，经过15年之久的“任职”已经在底层技术支持不能满足研发人员对其正常的维护和迭代；
2. 老系统的功能需求和交互体验上不能满足用户的使用，甚至会导致用户降低办公效率；
3. 就是很多高频使用者对该老系统的“怨气”极大，整理了60多页的痛点PPT给到我们部门领导希望优化；

所以，经过和这些“怨气”较深的用户详谈后，我们发现很多系统背后的权限划分、资产、组织与用户的关联关系无逻辑可寻，及资产的信息安全管控逻辑等很不清楚，就连高频用户也不清楚，因为他们并不知道这个15年的老系统的迭代更替的详情，在公司内部也未找到相关历史的需求资料。

二、重构复盘

在新系统上线后其实暴露出很多问题，但是最终还是被认可的，只是整个项目组都是第一次重构这种老系统，会有些经验不足。

关于整个项目确定到研发上线用时：9个月。

关于我们的研发团队成员的基本情况：

1. 产品：1.5个人力，我为owner，还有一个产品辅助；
2. 设计：1个人力，因为设计资源紧缺，所以交互和UI各占0.5个人力；
3. 后端：3个人力，有2个人全部投入，另外来个人各投入0.5个人力，其中包含框架设计及所有后端开发人力；
4. 前端：1个人力，全部投入；
5. 测试：2个人力，全部投入；
6. 翻译：0.5个人力，由国际化翻译部门支持。

关于重构目标达成情况：

1. 技术项：优化技术支持，将底层技术微服务化及去x——完成；
2. 产品项：挖掘现阶段用户的真实需求、删减冗余低频功能、整合信息及调整PAL库信息架构、根据公司安全部门规定重新定义资产密级和资产权限划分——基本完成；
3. 设计项：优化用户任务目标流程路径，让交互设计和界面信息布局与时俱进，提升PAL库用户体验——基本完成。

三、系统重构的隐秘角落

本次我先不具体系统重构的过程，想先记录下系统上线后的一些意外情况，因为，在系统重构的过程中除了人力上的紧张其他感觉没有大的问题，但是在上线后，就发现在重构系统过程中有些是我们团队没有关注到的注意事项——静静的都在隐秘的角落里！

首先，从技术角度来讲：

1）数据同步这一块，在新系统上线后经常会爆出历史数据同步发生异常，比如资产的创建日期、资产的权限范围会出错。

2）是因为老系统的数据库和现在新系统的数据库不同，没办法做实时同步，如果一定要做那就很费人力，所以这点影响到了用户在新老系统切换时没有过渡期，很多用户在使用起来很不习惯（并且现公司是个传统的IT公司，有很多老员对习惯的改变非常抵触）。

其次，从产品角度来讲：

1）在产品重构的方案前期，应该要同步给到业务方及干系方的领导，即便自己的领导没有在高层内部同步本项目的事情，自己作为项目的owner也要提醒自己的领导。

这一点其实会很好地在高层建立一些理解和口碑；因为在系统重构后，其实或多或少地都会有用户反馈一些负面信息，同时，在新系统上线初期也是bug暴露最多的时期，如提前做好对干系方领导的信息同步，他们就会更全面了解你们在研发中所遇到的一些问题，以及过程中的每一次重大产品决策，这其实能很好地帮助各方领导来理解你们重构的系统。

2）不能高估IT公司内部员工对新型互联网的敏感度，在新系统上线前，一定要通过各种有效方式给大家做新系统的使用培训，而且要尽最大努力做到培训的全面性，避免用户因使用习惯的改变而带来的负面反馈。

3）有时间和精力一定要在前期做面对面的用户访谈，比如我们在前期本来是要做用户访谈的，访谈计划、访谈用户及出差城市都已经确定了，但是被领导叫停，原因则是觉得该系统的高频使用人数不多，感觉也没必要花时间和精力去做用户访谈，于是这也成了很多用户在使用不习惯的时候拿出来说事儿的“小辫子”了。

4）要实时跟进业务方答应的TODO事项是否落到实处，就拿我们的系统来说，公司的老系统其实是功能很庞大的，有不同的业务方在系统中上传和发布资产，有公司级的资产也有部门级的资产。

但是两个不同权重的资产对权限管控级别和管理人员的细分度都不同，事先，管理公司级的资产用户是不希望部门级的资产用户再使用本系统，建议他们使用公司内部的另一个可替代的老系统（但是谁会愿意用老系统呢）。

但是这个事情主要是得这两方的使用者或相关领导去协商好的问题，但是相关干系人并没有重点关注这件事情，最终也导致了两方业务方各种撕，同时作为产品研发团队的我们夹在中间其实也是很难受的。

所以实时跟进事先安排给业务方的TODO任务，清楚他们对接的进展也是产品研发团队所要关注的事情，不然就是两狗打架粘你一身毛。

5）要将老系统所有的功能点，以及存在的问题都整理出来告知全公司的用户，不然总有一些喷子会说老系统可以什么什么（其实没有），或者说老系统权限如何合理（其实是老系统的bug漏洞），还有甚者会说老系统的交互视觉好看的~

总之就是意想不到的的事情太多，想要堵住用户的嘴是不可能的，但是可以提前准备好有力的回怼材料。

注：由于系统有水印，所以不便于给大家展示最新系统成果了，抱歉！

四、总结

B端产品的产品逻辑往往是比较复杂的，涉及的用户角色也很多，但是这些往往在产品重构的过程中，只要使用正确的产品研发方法，都不会出大问题。

但是正因为是B端产品，所以很多领导在思想上就不太重视，因为做出来用不用公司内部员工往往是没有选择的，但是作为有追求的产品人，还是要避免“强权研发”产品。

同时一个系统的重构是一个很繁琐的过程，不同的产品及公司级团队所面临的的问题是千差万别的。

但是，除了关注产品本身的需求功能、技术、体验问题外，还有一些看起来不太起眼的的各部门同步问题、涉及干系方的意见达成问题等和产品本身关系不大的细节也要注意。

最后的最后我想说，系统重构这种中事情遇到了的确令人下头，但是这种机会也不是所有产品人都能遇到的经历，所以，只要大家遇到了系统重构的机会，还是大胆上吧！

本文作者 @一只船

版权声明

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