B端产品经理，如何操盘系统重构

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

每天早 07 : 45 按时送达

工作1-3年的产品经理，在没有任何重构经验的团队中，如何独立操盘一次业务系统的全流程重构？希望本文能提供给在系统重构启动期的你一些参考思路。

作者：Fancy刘，现某金融科技公司B端产品经理

题图来自正版图库 图虫创意，基于VRF协议

全文共 6874 字，阅读需要 14 分钟

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

重构背景

1. 系统和用户

1）系统简介

本次重构的系统，是一个风控大数据测试系统，通过线上化操作实现多种数据产品、模型的批量调用，并可为客户提供数据分析报告，同时也为我司风控人员提供建模数据的支持。

该系统的特点是小众且晦涩，与多个系统有交互。

包括上游CRM等多个业务系统有信息交互、还有下游与BI、建模平台等多个数据系统有数据交互，最重要的是底层还与数据产品API接口有核心的调用交互。

如果不了解公司核心业务逻辑，不了解公司的数据产品，将很难hold住这个系统。

我是在负责旧系统1个月后，确切得知该系统计划进行重构，虽然在这之前自己已经负责过几个有相关性的业务系统了，但是还是花了很长时间摸清了这个系统的全部逻辑。

2）用户特点

值得一提的是：这个系统是少见的有“多视角用户”的情况，有客户和分析师两种角色，两种登录账号类型，可分别从内网和外网登录，部分数据权限是两边互通的，但功能权限是隔离的。

由于客户方的存量账号庞大且用户操作高频，故系统重构必须将客户端和风控端的重构分成两部分，即在一段时间内新旧系统将会并行，而客户和分析师都是无感知的。

上面这个方案是在设计中期修改的，部门的领导也给了很多建议，这里也是本次重构计划中的难点之一。

2. 重构原因

1）内因

老系统是公司成立初期最早的一批系统，系统没有前端，只靠着一个后端python开发维护着，可想而知系统的页面有多原始。

老系统对数据测试量级有明显的天花板，效率分配不合理，资源利用率低，造成任务等待多、进度慢等问题。

领导层希望新系统能更换java语言，从而提升系统的性能。

2）外因

与多数需要被重构的系统类似，重构前的老系统往往都有以下令用户“忍无可忍”的地方：

• 账号权限体系复杂，有局限性，新用户学习成本高

• 功能设计过于保守，异常频出，用户反馈糟糕

• 页面与交互落后，操作信息不清晰，用户体验差

因此，本次重构是由内到外的重构，从核心的底层性能到用户有感知功能流程进行的整体重塑。

新系统重构内容包括：技术性能提升、权限体系重塑、功能流程改造、用户体验提升、新功能扩展等5个方面。

技术性能提升和业务流程改造因每个系统都不尽相同，这里我们暂不讨论，后面主要聊聊产品重构的思路以及各个节点需要经历什么，以便大家举一反三，在前期心中有底。

3. 团队历时

参与整个项目主要的开发测试成员有5位，均没有系统重构的相关经验。

• 产品：1人

• 后端：2人

• 前端：1人

• 测试：1人

备注：UI 属于公共资源，设计了初版系统界面。

除去技术底层的重构时间，产品参与重建新系统的时间大概是7个月，完成了内部用户使用端的重构和用户迁移。

• 前期调研：2周

• 原型设计+公开评审：2周

• 开发v1.0版本：1月

• 功能补全+新功能开发：3月

• 数据同步+新旧系统并行：1月

• 内部用户完全迁移：1月

规划与安排

对于整个重构项目，按用户使用端分了两期：一期迁移内部用户至新系统，二期迁移外部客户至新系统（二期启动时间定在一期任务全部完成并稳定运行3个月之后再开始）。

对于一期计划我们定了目标，分三步走：

1. 第一步：完成v1.0 MVP版本的上线

2. 第二步：接入更多接口和完善更多功能

3. 第三步：新旧系统数据同步和用户迁移

这个系统内部的业务源头是任务申请，有两个申请入口。一个是系统内部的申请入口，一个是从CRM发起的客户申请入口，考虑后者涉及外部系统，故不属于最小化MVP的范围。

因此第一步 v1.0 版本上线，我们的目标，就是跑通一条完整的用户使用路径：即从内部申请测试任务开始，到拿到正确的数据测试结果结束。

PS：界定MVP版本内容是十分重要的，v1.0版本无需完美无缺，做到按时上线，后续能在用户的反馈下不断完善是最好的。如一开始就憋了很多大招，不仅拉长了开发测试的周期，还可能会在后续的用户的检验中遭遇滑铁卢，对上线的内容进行修改，实在不值。

重构的全流程

1. 业务梳理

作为产品经理，如果你接到了重构系统的任务，你需要在尽可能短的时间内摸清系统的全部逻辑，除了页面能看到的逻辑，还需要去了解很多页面看不到的逻辑。

此外，还要把上下游系统的功能交互和数据交互全部理解和走通，知道数据是从哪里来，到哪去。

由于老系统年代久远，历经多个产品和研发、很多功能的逻辑没有很明确的文档留存。

如你跟你的开发都是新接手系统没多久，就收到的系统重构的任务。作为产品，你可以带着你梳理的问题和初步假设去找研发，一起查询了解问题部分的代码逻辑，从而验证自己的猜想，同时对齐你们的认知。

这个阶段，要尽可能地打通对旧系统认知的盲区，就像解剖一样，让旧系统的骨架和筋脉在脑海中有清晰的认识。

与设计新系统不同，重构系统对兼容性要求高，你需要辩证的去思考每个模块可优化的幅度和上限，在对原始功能、周边系统、用户习惯等多方兼顾的情况下，给出最优解。

因此，前期业务梳理时考虑的全面很重要，尤其是有流程改造时，我们不能只想到好的一面，也需要想到这次改变可能存在的风险和弊端是什么。

2. 用户调研

除了你自己发现的要去改造的地方，真实的用户需求是肯定要倾听的。

用户调研部分这里我采用了三种方式获取信息：

1. 日常问题收集

2. 核心用户访谈

3. 开放问卷调查

1）日常问题收集

收集日常工作中用户反馈的系统问题，将问题归纳出来，分析高频问题是不是可以通过改变产品设计来避免。

在旧系统维护期间，每天都很多用户来找我问问题，如：进行中的任务出现异常、操作哪里走不通报错了、或是不知怎么操作的咨询问题。

这些一部分是产品架构设计的问题，一部分是产品交互设计的问题。一般这种情况都是反复出现的，如：今天A反馈给你了，你去找研发解决下；明天B反馈给你，你去找研发再解决下。

高频的问题背后就是一个急需解决和重塑的核心痛点，这里虽然没有被用户明确提出来，甚至用户已经习惯了这种“理所当然”的操作。但作为产品，你是需要清晰地认识到这里就是最有价值的需求点，也是颠覆老系统产品架构的突破点。

2）核心用户访谈

针对部分核心用户和业务方领导，约时间坐在一起聊一聊。

面对核心用户，可以针对用户遇到的问题有更深层次的了解，另外这也是一个很好的机会用于方案初步的沟通，可以问问他们对于你的改造思路有什么看法建议，这对于你在设计中优先级的把控很重要，看看自己和用户最关注的重点有没有偏差。

此外，与业务方领导也是有必要坐在一起聊一聊的，毕竟系统重构不仅仅是你们自己的事，也关乎于业务方工作效率的提升。你需要让对方领导知道你的重构计划，能为他们来怎样的增益？最重要的，是当你无法判断某种方案是否可行时，对方领导可以起到拍板的作用。

简单来讲一句话：多沟通，没坏处。

3）开放问卷调查

收集问卷反馈。

经过上述的日常问题收集和核心用户访谈，你能基本了解重构中需要改造的地方。

在此情况下我收集的问卷，80%的反馈已经在我预料之中了，但是我仍然建议大家要做这一步，原因有3点：

1. 获取全量信息最快捷的方式，方便查漏补缺

2. 用户增强参与感，自己的意见也可以被采纳

3. 让用户提前知情，后期更好做用户普及的推广

问卷作为一种高效的信息收集渠道，不用就亏大了，它可以短时间获取到所有用户的对新系统的所有期望，从而可以按相同问题出现的频率建立新需求开发的优先级，如高频问题可以优先排期解决。

同时也可以让用户有一个心理预期，知道在不久的将来将使用新的系统，这样像是提前打好招呼一样，用户在后期试用新系统的也会有更多的积极性。

3. 原型设计与评审

新系统的原型需要花费较长时间来完成，建议在开始画原型之前，可以借助流程图梳理逻辑，防止跑偏，或沉迷细节耽误进度，保证你的思维的连贯性，因此效率也会更高。

此外建议第一版原型要更加认真对待，页面布局、颜色，交互路径等，能交代清楚就别一笔带过。因为大多数情况，在正式开发前，都会拉一个大型评审会，邀请两方领导和用户代表共同参加，一个拿的出手的原型图能为你在评审会上增加更多的信心。

建议在评审时，除了拿出设计方案和原型图，还要提前准备好Q&A，也就是针对听众最关注的的地方，提前写好问题和解决方法，为自己争取更多的主动性，也会让对方对你感到放心。

4. 首发版本上线前后

1）上线前

经过了专家原型评审，就可以进行后续正常的开发评审了。

在前期尽可能多跟你的研发团队沟通对业务的看法，设计初衷是什么、希望解决什么问题，让研发在开发过程中更多理解业务，减少因理解偏差出现的bug。

整个开发过程一般需要1月以上的时间，这段时间产品经理要做好项目进度管理的工作，至少做到按周统计进度，开进度会议。

如果这个项目高层领导比较关注，要定期发邮件给高层领导同步进度。

2）上线后

这里的上线可以分为两种：内测版上线、对外正式版上线。

内测版上线流程走通后，可以邀请几位种子用户来体验新系统，待用户验证核心流程跑通无误后，可以对外宣布正式版上线了。

正式上线后，是1-2个月的试用阶段，这个这段期间你需要让更多的用户试用新系统，及时暴露各种意想不到的问题，并快速进行迭代修复。

不过，用户此时还在旧系统的使用习惯中，如何让大家更多地试用新系统呢？这里我使用了三个小技巧：

1. 提供更快的触达方式（如：免权限申请）

2. 提供用户关心的试用福利（我这里是提供了一定测试量级给用户）

3. 小窗口邀请用户（我私聊了80+以上的用户，邀请体验新系统，并附上系统说明书）

当然在这段时间，你需要一边关注用户反馈，一边规划后续的任务，随时把控时间和进度。

5. 功能迭代如何抉择

可能大家都希望，新系统等把旧系统所有的功能都补齐了，再开始加用户提的新功能。

起初我也这么想，但发现想要吸引用户的关注，新功能效果最好。人都有好奇心，如果发现你有跟之前不一样的新东西，会更加想去体验和尝试。

这一点，也是我与领导沟通后被点拨到的。

最好的办法就是平衡旧功能与新功能的开发进度，前提要确定新功能的出现不会与未上线的旧功能有前后顺序的嵌套。

比如这次我在重构时，考虑到我的用户群体为各个地区的多个风控团队，大家通常以组为单位去对接客户。而老系统任务申请只能属于一个人，小组成员无法合作。

在新系统中，我就在首发版本上线的第二个月加了「小组管理」的功能，组内成员互相都可以看到彼此的任务，也可以共享自己的工单数量，不光实现了组内任务灵活流转，还实现了各团队负责人对团队内部成员工作量和工作内容的统计和把控。

这个功能本身与旧功能的没有必要的嵌套逻辑，上线用户的反馈非常好，验证了之前的预期。这种新旧功能交替开发的思路，大家可以多思考下。

6. 过程中出了问题怎么办

一般重构的系统上线后，都会收到用户较好的反馈，毕竟旧系统年久失修，新的系统会让人眼前一亮。这时候，产品经理容易沉浸在对新系统尽善尽美的幻想中，希望新系统的口碑一直保持完美，不允许有任何瑕疵。

然而，你无法避免问题的出现。

在新系统上线后的这段时间，确实是系统相对最不稳定的时期，需要不断发现问题，修改问题。

作为产品经理，要学会理解新事物发展的规律，把解决问题和如何避免后续问题的发生放在思考的第一位。

下面三点，是我在走了一些弯路之后才明白的道理：

1. 对问题有包容心（出现问题不重要，重要的是如何解决和避免问题的发生）

2. 对开发有信心（与你的开发站在同一立场上，出现线上bug先给予解决问题的信任）

3. 对用户有耐心（第一时间安抚用户，诚恳道歉并说明解决时间）

我记得一个导演说过一句话：这个的片子如果成功了，那一定是大家的功劳；如果失败了，那一定是我的责任。

产品经理并不是仅仅承担产品设计的工作，更多的还要考虑团队合作、项目管理等需要考验软实力的地方。

而问题矛盾的出现，会更加放大你在这些情况的心态和应对能力，要有大局意识，关建时候担起项目负责人的责任，你的团队成员才会更加信服你。

7. 数据同步和用户迁移

新系统基本功能都与旧系统对齐了，是不是就可以将用户全部直接切到新系统了？答案是否定的。

用户迁移到新系统，绝对不能一刀切，要采用平稳过渡的方式，逐步替换。

因为老系统的数据都是这段时间用户正在使用的，如果强制切到什么数据都没有的新系统，用户不炸毛才怪。

况且，我们这次项目分两期，一期的目标是，在外部客户无感知的情况下，内部用户已经全部过渡到了新系统。

可能你会问：外部和内部数据互通的部分该怎么办？如何保证之前在旧系统运行的流程？

答案就是——数据同步。

数据同步可以拆分为3部分：

1. 账号同步：内部账号和外部账号由旧系统同步至新系统

2. 账号关联：新系统的内部账号关联旧系统的内部账号

3. 文件同步：新旧系统产生的文件相互同步

第一步，账号信息同步

由于外部客户账号创建的源头来自上游CRM系统与旧系统的用户创建，考虑客户外部重构放在二期，故本期在此节点保持外部客户账号创建源头不变，仅将客户账号、内部账号及相关信息同步至新系统。

新系统增加「客户账号/内部账号」模块，用于替代旧系统后台的用户列表。存量数据批量刷进来，增量数据保持实时更新。

第二步，将新旧系统的内部账号进行关联

由于用户都是同一个人，在注册新系统后，他将拥有新系统和旧系统两套账号。

所以，管理员要将同一个内部用户在新旧系统的两个账号进行关联映射，保证下一步文件同步的稳步实施。

第三步，新旧系统的文件相互同步

为实现外部客户无感知的内部用户迁移，新旧系统的文件同步非常重要，也是保证无感知效果的关键。

首先确定同步范围，这里有一个最大化和最小化原则。

• 旧系统同步新系统时要遵循最大化原则。即新系统要在未来替代旧系统，将旧系统产生的全部数据完整地同步至新系统，保证用户所有在旧系统能查到的内容在新系统也能查到。

• 新系统同步旧系统要遵循最小化原则。即只同步还在旧系统的外部客户需要看到的数据足够。如果完全同步，不仅占用资源，还可能让内部用户无法脱离旧系统。

以上三步的完成，为后续的「用户迁移」奠定了基础。

最后，用户迁移

因为业务流程的原因，需要客户参与的任务，都会从CRM申请。因此用户迁移的最后一步，就是联合CRM将上游的任务从旧系统切换至新系统。因为前面已经做好关联，所以CRM来的任务，都能在新系统的已关联账号看到。

这样一来，用户自然就会主动移步至新系统操作，同时近期产生的数据也能新系统都能查到，可以算是“无缝衔接”，不会给用户造成来回切系统的困扰。

PS：在正式切换的前期要考虑更多的异常情况和应对机制。如：在正式上线前，我们采取了一段时间的手动切换，在验证没有问题后才决定上线切换。又如：当异常情况出现时，可手动将新系统的任务推回旧系统等等。

8. 小结

以上就是一期计划里所有涉及重构的关键节点，可能不同业务不同系统之间会有不同，不过核心思路是相通的，都是遵循「平稳过渡」原则，尽可能减少用户的学习成本、降低用户的操作门槛，优化业务流程，提升用户综合体验。

在用户迁移至新系统后，老系统也不用立即关掉。给内部用户一段时间的适应期，也能让内部用户将之前同步至老系统的任务做完，这样会让用户对系统更有安全感。

分享和展望

1. 印象最深的两件事

1）产品经理也可以看代码

当时准备做自动生成风控分析报告，涉及风控领域专业知识，老系统对这个功能无文档记录，我跟开发都不清楚报告中的数值、比率的生成逻辑是什么。

唯一能参考的就是老系统用python写的长达数十页的代码，由于需要结合业务知识和风控知识去理解，就算开发自己看也有困难，所以我选择自己扒代码。

我当时也是想试试，万一能看懂了呢？

后面经过认真的梳理，推导和验证，花了两天时间终于搞清楚了这里的逻辑，后面给开发讲解的时候还是很有成就感的。

2）意外收获的点赞

一次偶然发现，自己的一篇wiki被点赞了很多次，包括两个部门的VP和一些不认识的人。

这篇文档是我写的一个风控策略产品的业务逻辑简述，是别的部门在负责的平台，因为我的系统即将接入策略产品接口，需要通过对方平台做调用中转，为了让我的研发能明白风控策略的业务原理，我写了一个科普性质的文档给他们看，方便他们理解。没想到最后竟然被那么多人看过，有些受宠若惊。

2. 未来要做的事

现在一期重构的进程已接近尾声，这个项目已经完成了较为复杂的内部用户迁移部分。实现了阶段目标，即：内部使用端的重构和内部用户的迁移。

待系统稳定运行3个月后，我们计划开始二期的客户使用端重构和用户迁移。

相对内部重构，外部重构的难度会降低很多。因为外部客户的操作步骤较内部少了很多，不涉及核心流程，且新系统的框架已经搭建完成，页面无需重新设计，只需更换部分功能即可。

后续考虑的重点将是：“如何做到无感知或低感知的用户切换”这个点了。

等二期项目完成时，会再跟大家分享经验的，请大家期待。

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

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

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

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