系统|重构 10 年历史的 B 端产品，我的一些经验体会淘汰类|国家发展改革委|发改委

编辑导语：不管是刚刚入职的小伙伴还是已经入职工作很久的小伙伴，在重构系统的时候都应该会有一些问题，在本文中，作者总结了他的工作经验，分析了如何在旧系统上进行升级的方法，一起来看看。

文章插图
我目前在一家传统医疗企业，为实现信息化转型，领导期望将使用多年的旧系统进行升级。因系统扩展性不高，只能推翻重做。我司和德勤有战略合作，所以请他们团队来协助重构系统。
在重构的过程中，我在德勤的需求分析师身上学到了很多做事方法，受益匪浅。因此，把这个关于重构系统的实例分享出来，希望对大家有启发。
一、重构老系统我们碰到的三大问题1. 信息架构混乱且重复，业务流程复杂且不合理早期的系统没有专门的产品经理规划，一味图快，有需求就加功能，留下了非常多问题。比如：
流程复杂：旧系统存在非常多的不必要流程，导致使用者为了达成业务目标，经常要在系统里操作多次，这严重影响实际工作效率。
展示复杂：现在的系统包含 900 多个页面，页面之间的重复度高。本可将信息整合为一个页面，实际却用多个页面展示。有的页面有 50-60 个按钮，且每个按钮都会触发不一样的场景。
培训难度大：使用者很容易忘记功能的作用和操作顺序，导致学习成本巨大。经调研，刚入职的同事要熟练使用系统，一般要 2-3 个月。
2. 缺少需求、设计文档旧系统没有完整的需求说明文档，概要设计，更不用说详细设计了。文档更新不连贯，最新的文档还是几年以前的，这几年新增的业务功能则完全没有记录。且文档内容都非常简单，无法呈现完整的业务流程和核心细节，很多地方都是简单带过。
3. 没有人了解系统全部功能文档不全，我们还寄希望于有“活文档”，但是这个希望也落空了。老系统的使用角色有近 20 个，因为功能复杂，每种角色只会操作跟自己业务相关的几个页面，但也只了解主流程，对于细节部分还是模棱两可。
系统运行了 10 多年，一直有开发工程师在维护。但因为公司人员不断有变动，文档、交接程序都不完善和规范，经过几手传递，公司内没有一个人了解系统全部功能。
二、面对挑战必须要有整体且细致的规划情况就是这么个情况，挑战非常巨大。
经验尚浅的产品经理面对这种场景，可能会急于动手，在还没有思考清楚工作流程的时候，就直接研究系统功能，看旧系统如何设计，然后在这基础上做部分优化。但是这种工作方式并没有大局观，只知道要做但不知道要做哪些，且需求梳理完的截止时间也不确定，无疑不利于整个项目的落地。
有一阵子，工作进入了停滞期，一时找不到入手点，不知该如何处理工作。后来，在德勤的协助下，我们并没有着急开始动手，而是先思考再做！
在动手前会认真讨论和思考怎么做更有效率，并且能达到一个最好的效果。毕竟我们不可能花几年时间才把需求全部整理出来，到时候竞争公司早走在前面了。
以下是我们后来的规划方案：
1. 确定工作的目标，范围，截止时间首先就是确定工作的目标，范围，截止时间。
目标已经很明确，就是需要把需求全都整理一遍，然后重新进行产品设计。而工作的范围即梳理全量需求：系统里的功能都需要我们全部梳理。截止时间我们是倒推的，因为新系统计划年底上线，所以需求梳理的时间要早于上线几个月。开始动工前，梳理这三个事项非常重要。梳理完还要和领导做同步和确认，这样才能明确工作方向和重心。