用户|老系统重构中的隐秘角落电动车车主|支付宝|集五福|五

编辑导语：对于想要实现数字化转型、提升业务处理效率、改变冗杂环节的传统公司来说，系统重构也许是重要一环。不过老系统重构的过程中，总会遇到形形色色的问题。本篇文章里，作者结合实际案例，对老系统重构过程中存在的隐秘问题做了梳理，一起来看一下。

文章插图
老系统的重构对于一个传统公司或者是已经经营了很多年的公司来说，是数字化、智能化转型的必经之路。
公司里一般老系统走到了必须要重构的地步，说明该老系统在公司业务扭转中是有很重要的作用的。但是往往老系统的重构是一件很让产品研发团队比较头疼的事情，毕竟重构所涉及的反方面面太多，尤其是一些涉及到很多业务方工作扭转的系统。
15年前的老系统界面截图如下，供大家感受一下年代感：

文章插图
一、重构背景【 用户|老系统重构中的隐秘角落】本人是从国内知名互联网大厂跳槽去了一个国内较老的传统IT公司，负责重构的老系统是公司在2005年研发出的一个类似erp系统，是.net开发的web系统，主要负责公司内部的一些文件资产的上传发布和存档。
该老系统为什么最终决定要重构？原因其实非常明了：

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

所以，经过和这些“怨气”较深的用户详谈后，我们发现很多系统背后的权限划分、资产、组织与用户的关联关系无逻辑可寻，及资产的信息安全管控逻辑等很不清楚，就连高频用户也不清楚，因为他们并不知道这个15年的老系统的迭代更替的详情，在公司内部也未找到相关历史的需求资料。
二、重构复盘在新系统上线后其实暴露出很多问题，但是最终还是被认可的，只是整个项目组都是第一次重构这种老系统，会有些经验不足。
关于整个项目确定到研发上线用时：9个月。
关于我们的研发团队成员的基本情况：

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

关于重构目标达成情况：

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

三、系统重构的隐秘角落本次我先不具体系统重构的过程，想先记录下系统上线后的一些意外情况，因为，在系统重构的过程中除了人力上的紧张其他感觉没有大的问题，但是在上线后，就发现在重构系统过程中有些是我们团队没有关注到的注意事项——静静的都在隐秘的角落里！
首先，从技术角度来讲：
1）数据同步这一块，在新系统上线后经常会爆出历史数据同步发生异常，比如资产的创建日期、资产的权限范围会出错。
2）是因为老系统的数据库和现在新系统的数据库不同，没办法做实时同步，如果一定要做那就很费人力，所以这点影响到了用户在新老系统切换时没有过渡期，很多用户在使用起来很不习惯（并且现公司是个传统的IT公司，有很多老员对习惯的改变非常抵触）。
其次，从产品角度来讲：
1）在产品重构的方案前期，应该要同步给到业务方及干系方的领导，即便自己的领导没有在高层内部同步本项目的事情，自己作为项目的owner也要提醒自己的领导。
这一点其实会很好地在高层建立一些理解和口碑；因为在系统重构后，其实或多或少地都会有用户反馈一些负面信息，同时，在新系统上线初期也是bug暴露最多的时期，如提前做好对干系方领导的信息同步，他们就会更全面了解你们在研发中所遇到的一些问题，以及过程中的每一次重大产品决策，这其实能很好地帮助各方领导来理解你们重构的系统。