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

B端产品经理，如何操盘系统重构一、重构背景

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个月之后再开头）。

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

第一步：完成v1.0MVP版本的上线其次步：接入更多接口和完善更多功能第三步：新旧系统数据同步和用户迁移这个系统内部的业务源头是任务申请，有两个申请入口。一个是系统内部的申请入口，一个是从CRM发起的客户申请入口，考虑后者涉及外部系统，故不属于最小化MVP的范围。

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

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

三、重构的全流程

1.业务梳理

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

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

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

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

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

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

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

2.用户调研

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

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

日常问题收集核心用户访谈开放问卷调查1）日常问题收集

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

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

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

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

2）核心用户访谈

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

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

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

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

3）开放问卷调查

收集问卷反馈。

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

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

猎取全量信息最快捷的方式，便利查漏补缺用户增加参加感，自己的看法也可以被接受让用户提前知情，后期更好做用户普及的推广问卷作为一种高效的信息收集渠道，不用就亏大了，它可以短时间猎取到全部用户的对新系统的全部期望，从而可以按相同问题消失的频率建立新需求开发的优先级，如高频问题可以优先排期解决。

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

3.原型设计与评审

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

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

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

4.首发版本上线前后

1）上线前

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

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

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

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

2）上线后

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

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

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

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

供应更快的触达方式（如：免权限申请）供应用户关怀的试用福利（我这里是供应了肯定测试量级给用户）小窗口邀请用户（我私聊了80+以上的用户，邀请体验新系统，并附上系统说明书）当然在这段时间，你需要一边关注用户反馈，一边规划后续的任务，随时把控时间和进度。

5.功能迭代如何选择

可能大家都盼望，新系统等把旧系统全部的功能都补齐了，再开头加用户提的新功能。

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

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

最好的方法就是平衡旧功能与新功能的开发进度，前提要确定新功能的消失不会与未上线的旧功能有前后挨次的嵌套。

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

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

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

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

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

然而，你无法避开问题的消失。

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

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

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

对问题有包涵心（消失问题不重要，重要的是如何解决和避开问题的发生）对开发有信念（与你的开发站在同一立场上，消失线上bug先赐予解决问题的信任）对用户有急躁（第一时间安抚用户，恳切赔礼并说明解决时间）我记得一个导演说过一句话：这个的片子假如胜利了，那肯定是大家的功劳；假如失败了，那肯定是我的责任。

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

而问题冲突的消失，会更加放大你在这些状况的心态和应对力量，要有大局意识，关建时候担起项目负责人的责任，你的团队成员才会更加信服你。

7.数据同步和用户迁移

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

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

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

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

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

答案就是——数据同步。

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

账号同步——内部账号和外部账号由旧系统同步至新系统账号关联——新系统的内部账号关联旧系统的内部账号文件同步——新旧系统产生的文件相互同步第一步，账号信息同步

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

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

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

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

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

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

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

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

旧系统同步新系统时要遵循最大化原则。即新系统要在将来替代旧系统，将旧系统产生的全部数据完整地同步至新系统，保证用户全部在旧系统能查到的内容在新系统也能查到。新系统同步旧系统要遵循最小化原则。即只同步还在旧系统的外部客户需要看到的数据足够。假如完全同步，不仅占用资源，还可能让内部用户无法脱离旧系统。以上三步的完成，为后续的「用户迁移」奠定了基础。

最终，用户迁移

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

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

PS：在正式切换的前期要考虑更多的特别状况和应对机制。如：在正式上线前，我们实行了一段时间的手动切换，在验证没有问题后才打算上线切换。又如：当特别状况消失时，可手动将新系统的任务推回旧系统等等。

8.小结

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

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

四、共享和展望

1.印