重构 10 年历史的 B 端产品，我的一些经验体会

关注并将「人人都是产品经理」设为星标

每天早 07 : 45 按时送达

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

作者：炸草少女

微信公众号：炸草少女

题图来自Unsplash，基于CC0协议

全文共 4450 字，阅读需要 9 分钟

——————/ BEGIN /——————

我目前在一家传统医疗企业，为实现信息化转型，领导期望将使用多年的旧系统进行升级。因系统扩展性不高，只能推翻重做。我司和德勤有战略合作，所以请他们团队来协助重构系统。

在重构的过程中，我在德勤的需求分析师身上学到了很多做事方法，受益匪浅。因此，把这个关于重构系统的实例分享出来，希望对大家有启发。

重构老系统

我们碰到的三大问题

1. 信息架构混乱且重复，业务流程复杂且不合理

早期的系统没有专门的产品经理规划，一味图快，有需求就加功能，留下了非常多问题。比如：

流程复杂：旧系统存在非常多的不必要流程，导致使用者为了达成业务目标，经常要在系统里操作多次，这严重影响实际工作效率。

展示复杂：现在的系统包含 900 多个页面，页面之间的重复度高。本可将信息整合为一个页面，实际却用多个页面展示。有的页面有 50-60 个按钮，且每个按钮都会触发不一样的场景。

培训难度大：使用者很容易忘记功能的作用和操作顺序，导致学习成本巨大。经调研，刚入职的同事要熟练使用系统，一般要 2-3 个月。

2. 缺少需求、设计文档

旧系统没有完整的需求说明文档，概要设计，更不用说详细设计了。文档更新不连贯，最新的文档还是几年以前的，这几年新增的业务功能则完全没有记录。且文档内容都非常简单，无法呈现完整的业务流程和核心细节，很多地方都是简单带过。

3. 没有人了解系统全部功能

文档不全，我们还寄希望于有“活文档”，但是这个希望也落空了。老系统的使用角色有近 20 个，因为功能复杂，每种角色只会操作跟自己业务相关的几个页面，但也只了解主流程，对于细节部分还是模棱两可。

系统运行了 10 多年，一直有开发工程师在维护。但因为公司人员不断有变动，文档、交接程序都不完善和规范，经过几手传递，公司内没有一个人了解系统全部功能。

面对挑战

必须要有整体且细致的规划

情况就是这么个情况，挑战非常巨大。

经验尚浅的产品经理面对这种场景，可能会急于动手，在还没有思考清楚工作流程的时候，就直接研究系统功能，看旧系统如何设计，然后在这基础上做部分优化。

但是这种工作方式并没有大局观，只知道要做但不知道要做哪些，且需求梳理完的截止时间也不确定，无疑不利于整个项目的落地。

有一阵子，工作进入了停滞期，一时找不到入手点，不知该如何处理工作。后来，在德勤的协助下，我们并没有着急开始动手，而是先思考再做！

在动手前会认真讨论和思考怎么做更有效率，并且能达到一个最好的效果。毕竟我们不可能花几年时间才把需求全部整理出来，到时候竞争公司早走在前面了。

以下是我们后来的规划方案：

1. 确定工作的目标、范围、截止时间

首先就是确定工作的目标、范围、截止时间。

目标已经很明确，就是需要把需求全都整理一遍，然后重新进行产品设计。而工作的范围即梳理全量需求：系统里的功能都需要我们全部梳理。截止时间我们是倒推的，因为新系统计划年底上线，所以需求梳理的时间要早于上线几个月。开始动工前，梳理这三个事项非常重要。梳理完还要和领导做同步和确认，这样才能明确工作方向和重心。

2. 量化需求梳理工作

确定第一步的内容后，第二步是对接下来的工作进行量化。

安排几个同事把系统的所有菜单都用 Excel 整理出来，包括一级菜单，二级菜单，三级菜单等，最后统计下来有 900+ 页面。

为什么只按页面统计，不按功能统计呢？因为涉及页面太多，有的页面功能甚至高达 100+ 个，如果按功能整理就需要花费大量时间，但我们得严格控制需求梳理的进度。且我们对功能不了解，也不了解实际的业务含义，所以前期整理的颗粒度就仅仅按照页面划分。

Excel-V0.1

有的伙伴可能会有疑问：为什么需要列一个这样的Excel表格去整理页面菜单呢？对于后台产品，前期不应该直接进行业务调研吗?

因为这是个重构系统的项目，上层领导只知道要重构，却并不知道重构的难度有多少。前期制定的系统梳理至上线时间为 6 个月。但梳理完以后，我们对工作量和工作难度有了新的认知，6 个月是绝对完成不了的。

有了这样的梳理和量化的结果，我们和领导汇报工作难度并且调整重构时间为 12 个月。

3. 确定页面梳理优先级

完成第2步的量化工作，我们是不是就开始着手梳理这 900+ 页面了？不，这还不够，还得深挖！

梳理那些没人用的页面，根本就是浪费时间。我们要搞清楚用户到底常用哪些页面，压根不用的页面就不梳理。于是，我们继续梳理页面优先级。将之前整理的页面菜单Excel的列后，再加上目前主要使用系统的各大用户组。

用户组是由业务负责人提供，大概有近20个用户组，每个用户组都有对应组长。所以，我们前期就和各大业务组组长进行沟通，逐个询问当前所有页面的使用情况，是否使用以及使用的频率。

Excel-V0.2

统计下来：高频使用的页面有200+，中频使用有100+，低频使用100+，几乎不用页面 500+。

不过，业务发生频率和需求优先级还有一定区分，经常使用的页面肯定是需要优先梳理的，但业务不经常使用的页面不一定优先级低。因为低频使用的页面，可能也会涉及到一些核心流程的流转。不过不要紧，深入调研的时候去了解详情即可，初期阶段就优先梳理把高频使用的页面的需求。

4. 进行需求梳理

需求梳理我们大概分为三步：需求调研、需求梳理、需求分析。

4.1 如何进行需求调研

前期业务负责人给我们提供了15个用户组的组长资源，于是我们就以用户组作为突破口，采取线下逐个调研用户组的方式来了解需求。

因为不同用户组在系统中都承担着各自的职能，所以我们只要满足各个用户组的核心需求，那么整个系统就相当于是调研成功了。

调研前：我们会在旧系统看该用户组的主要使用页面，根据页面大概了解用户组的特征；与此同时也会准备自己不明白的问题。

调研时：整个系统的功能特别复杂，在调研时对调研人员也进行了一定的责任安排。每场用户调研下，都有一位同事负责了解主流程，一位负责了解异常流程，一位负责做笔记/录音，一位负责技术评估等。

那调研为什么要以主要流程和异常流程来进行划分呢？主要流程是支撑用户组的正常职能操作，调研必不可少；但异常流程也十分重要。我们做需求梳理的时候肯定也是要把这些异常场景考虑上，需要给用户提供一些撤销的功能来结束整个流程。

调研的方式为在用户的工作区域进行现场访谈。因为涉及流程性的环节我们需要结合线下用户的实际操作才会理解更深，避免出现大的偏差。

调研后：前期对调研人员有了具体安排，那调研后也就需要有对应输出。

在此阶段我们主要输出的文档为：主要流程图，异常流程图，用户访谈记录。

 流程图例

4.2 如何进行需求梳理

因用户组老师工作繁忙，不可能把每个需求以及旧系统对应的功能一一描述给产品经理。所以，我们采取的工作方式是，根据上述产出的某用户组主要流程图和异常流程图，再把该用户组使用频率高的页面和流程图中的节点一一匹配。

这样就可以知道目前该用户组为实现自己的主要目标的过程中，在系统上有哪些操作。

还需要明确一点，需求调研是一个反复的过程，不可能每个用户组只调研一次即可。我们调研的整体思路还是采用先整体后细节的逻辑。

先整体：第一次调研了解用户组的主体流程和异常流程，再与旧系统页面做对应；后细节：后几次调研才开始了解页面上的其他场景和细节。

4.3 如何进行需求分析

对于使用了旧系统近10年的用户而言，他们对自己想要什么、不想要什么已经非常明确，而我们产品经理只需要能理解用户的核心需求并作出优化设计就可以了。

但即使是这样，我们还是会把用户的需求用”用户故事”的逻辑来理解。即，用户故事=用户+故事=人+事+故：谁要使用这个（角色），要完成什么活动（活动），为什么要这么做，这样做带来的价值是什么（价值）。

我们不是需求的搬运工，我们在刻意了解需求意义，进行需求分析之后，才开始进行产品设计。

5. 分配需求梳理工作

组里的产品经理有 7 位，完全前几步，接下来就是分配具体的任务了。

我们决定以用户组的维度来进行分配任务，但这也并不是随意去分配，在分配的时候还要考虑各方因素。

前期在对用户组调研的时候，已经大概了解了对应的难易程度。于是再根据现有产品经理工作年限以及兴趣的情况，进行分配任务。

比如一个产品经理，可以分配2个困难模块，3个较简单模块；比如刚来且工作经验不足的产品经理可以先分配些简单的模块去熟悉，然后逐步开始进入深层次的协作；还有对于难度较大的模块，可以让多人共同协作。

如此一来，整体团队的工作任务就已经分配得当，大家就领好自己的任务专注执行即可。

6. 整体监控

当产品模块都分配下去后，还需要计划需求梳理时间，即每个模块梳理的时间截点；

还要定期询问各位产品经理的工作情况，是否按时进行，是否遇到问题，是否需要协助等。

经常跟进进度，监控整体进度，也让整个团队的目标都在按照计划的日期如期开展。

我们只有先有条理的规划，然后一步一步执行，这样才能顺利完成任务。

我的感悟

跨进互联网做产品经理的那一刻，我便暗暗下定决心，要成为一名优秀的产品经理。

转眼 3 年多了过去了，我在这期间看了不少产品经理的书籍，也系统地学了不少产品知识。

如果问我产品经理最重要的能力是什么？我会毫不犹豫的说，解决问题的能力。

1. 解决问题，需要系统思考

在我看来，任何一个职业都是在不断发现问题和解决问题，产品经理亦是如此。

但即使是同样一个问题，换作不同的人处理，事情的完成效果也会不一样。总有些人更快些，效率高些，处理的更恰当些。

那这种能力如何去培养呢？

其实最关键的一点就是需要平时积极思考，不断的去总结和复盘。

对于一些复杂的工作，经过总结下来，其实可以形成一套SOP流程（标准作业程序）。

比如：先量化工作，再做任务拆分，排出任务的优先级，然后任务分配到人，设置任务截止时间，最后整体监控。

2. 在错误中成长，多复盘，多交流

在工作中会处理很多事情，但并不见得你每次处理事情的方式就是绝对完美的。而当我们复盘时，就好像把整件事情的经过像电影一样重新放映。

在重温的过程中，不断思考，这样的事情是否还会有一种更好的方式去解决？如果有，那又是什么。那当下次你再遇到这样的事情时，你就会用一种更好的方式去处理。

如果想不明白也可以请教自己的领导，看看领导给的建议；或者继续问产品社区的同僚们，看看他们是不是也遇到过类似问题，又是怎么解决。

产品经理需要的能力其实还有很多。“人人都是产品经理”，但不代表着“人人都是好的产品经理”。一个好产品的背后，总有一些优秀的产品经理在默默付出努力。

—————— / END / ——————

产品经理培训｜产品运营培训｜企业内训服务

请在公众号后台回复「培训」了解更多

▼ 喜欢请分享&收藏，满意点个赞，最后点「在看」 ▼