B端产品，如何进行系统重构？

来源：人人都是产品经理　2023-06-16 21:08:23

本次会员新课我们邀请到了前钉钉高级产品经理@周翔老师，作为7年B端产品人，具有丰富的从0~N、产品重构的成功经验，对B端产品有着深刻的理解和丰富的实战经验，沉淀出系统的B端产品方法论。本文由课程内容整理，内容有删改。

(资料图)

大家好，我是周翔，曾在钉钉任过高级产品经理，现在某知名独角兽公司做资深B端产品经理，有着丰富的B端产品从0到N及重构经验。

本次分享主要分为四部分：第一部分是为什么要讲B端产品的重构；第二部分是系统重构的三种类型；第三部分是本次分享的核心内容，即B端产品重构的九大步骤；第四部分是分享在重构过程中应注意哪些点，以及在重构过程中的个人思考和主要感悟。

一、为什么要讲系统重构？

本次分享重构的原因主要有三个：

第一、重构在B端产品中十分常见，因为有很多软件系统已在公司运行很长时间，尤其在成立时间比较长的公司，通常都会有运营时间比较长的产品，但随着业务的发展，很多原本的设计或逻辑已不能满足现在新业务的诉求，这时就会产生重构的诉求。

第二、对产品经理来讲，重构比从0到1更具有挑战性，因为重构可能需要从-1甚至-N来变成1。

第三、重构是产品能力的进阶，当掌握好重构方法后，再去应对从0-1时，就会更加游刃有余，属于降维操作。

二、系统重构的三种类型

第一种类型是保留原来的系统地基，然后重建上层建筑，即在原系统基础上重新开发，保留或加固系统原有的底层架构、数据库，仅对上层代码包括业务逻辑、页面交互等部分重新开发。

第二种类型是另起炉灶，即原系统继续保持运行，另起新的项目，重新做个新系统替换，然后再做数据的迁移；该类型模式在重构中很常见，也是B端产品重构方法中重点提及的一种方式。

第三种类型是在运行中改造，即保持现有的系统持续、稳定运行的情况下，同时对所需要的模块进行持续性的重构，直至达到系统重构的最终目标。

3种重构方式的对比：

第一、从形式上看，第一种方式是保留地基，重建上层建筑；第二种方式是另起炉灶；第三种是在运行中改造。

第二、适用场景，第一种方式适用于原系统已决定被废弃或即将废弃，不需要再继续维护，但还需保留部分数据；第二种方式适用于原系统的业务仍需要持续运行，且对新系统有较充足的等待时间；第三种方式适用于原系统业务需要持续运行，只需要优化部分模块，不需要对整个系统进行彻底的重构。

第三、优势和不足，第一种方式的历史包袱较小，重构速度也相对更快，但是场景会比较局限；第二种方式相比于方式三，历史包袱较小，重构时间也更快、成本更低，但是不足之处在于一方面用户迁移幅度大，没有过渡期适应，当用户从老系统迁移到新系统时会产生非常大的不适感，特别对SaaS或商业化产品会有较大风险，用户会逐步用脚投票从而弃用原来的产品。

另一方面是风险高，因为缺少中间验证的过程，直接让用户使用新系统，对最终结果比较难控制；第三种方式的优势在于用户可以逐步接受改造，有较平缓的过渡期，还可以通过小步快跑或迭代的方式逐步验证和优化，风险较小。不足之处一是历史包袱沉重，因为在原有的旧系统基础上改造需要考虑更多，而且在用户侧还保留着之前的使用习惯。

二是依赖、关联的影响更多，因为改变的只是其中的某个模块，需要牵扯到现有、已实现的部分功能；三是部分场景需要同时兼容新、旧两套逻辑，从而增加很多额外、非必要的成本；四是部分功能会存在过渡期，但实际上会有重复的工作量，增加额外成本。

第四、综合成本的高低总体是方式1<方式2<方式3。

综上，方式一是在原系统打算或已经废弃的时候才适用，而这种情况其实比较少，更多时候所面临的重构场景是在方式二、三中选择。

从业务方和领导们的角度出发，通常都会倾向于方式三，因为风险更小，感觉上成本也更低，但实际上如果需要改造的模块较多，方式三的成本其实会更高，因为会有很多兼容、填坑、还技术债的事情；而从产研的角度，通常倾向方式二，因为不用考虑过多的历史包袱，处理起来更方便，如果需要改造的内容较多，综合成本也会更小。

但无论采用哪种方式，都需要结合现状以及公司对于产品的要求综合决定。

三、系统重构的九大步骤

系统的重构可以分为九大步骤：

第一步是需要做大量的前期调研；第二步是需要对现有的旧逻辑做系统性梳理；第三步是需要把需求和旧逻辑做对比分析；第四步是需要对前期收到的问题或需求进行整理和分层；第五步是需要基于前面的信息明确最终的重构目标，以及衡量最终重构目标的指标；第六步是需要分析优先级，分析完后会有对应的模块优先顺序；第七步是需要基于具体的模块做更加详尽和针对性的调研；第八步是需要基于调研结果制定和实施优化策略；第九步是需要在上述步骤完成后，处理大量的历史数据。

当完成以上步骤后，就可以形成整个系统重构步骤的闭环，然后不断地在下一步的行为中推进。

第一步：前期调研

前期调研主要分成业务调研和用户调研。

其中业务调研需要了解两部分内容：

一是业务所在行业的通用玩法，知道行业内一般都是怎么运作的，需要有行业认识，这部分也作为指导整个系统运行的核心业务知识和体系。

二是需要了解公司的整体业务流程、业务特色和形成的历史渊源，其中需注意的是行业通用性和公司的不同之处，一旦忽略就容易在后面改造中照搬行业玩法，导致与实际业务需求不符，因此无论行业在做相关业务时的操作如何，都需要注意公司是否有限制或条件要求。

而用户调研则主要分为三大类用户：

第一类是干系人，主要侧重于在系统中对产品有决定性作用的人，比如业务领导或对系统相关有决策权的领导层，这类人群可能对具体的功能不是太关心，甚至都不是最终用户，却对产品有着关键性的决策作用，所以对这类人群需要优先做调研，了解其对最终的重构结果有怎样的预期，需要结合这些预期做后面的行为。

第二类是典型用户，是指有具体产品操作的用户，对该类人群需要做用户分群，因为在B端产品中，不同的用户群体诉求完全不相同，甚至于完全冲突，所以需要基于不同的用户群体区分的维度做划分。比如在B端产品中，不同的管理层级的诉求差异较大，基层员工对工具的诉求和管理层对工具的诉求完全不同，这时就可以基于管理层级做划分。

再比如按照部门或业务线、产品线的维度做划分，因为不同产品线、业务线的诉求也不相同，所以可以在找到几个核心的维度后，再对用户群体做多维切割，切割完后就可以得到不同群体，得到群体后，再从中挑选不同群体的典型用户做1V1的深度访谈。

第三类是普通用户，即除了典型用户外，还需要对普通用户做调研，这时可以通过问卷方式做大批量的问题收集和需求收集，了解普通用户通用或较高频的痛点。

在完成上述两大类调研后，就需要输出对应内容，主要包括公司业务流程、业务特色总结形成的文档记录、各角色用例图、用户调研报告、用户体验地图和用户问题/需求池。

第二步：旧逻辑梳理

梳理内容主要包括系统现有主流程的产品架构和产品结构，此处需注意，架构和结构属于两种类型的东西，很多人容易混淆；当梳理好产品架构和结构后，就需要梳理具体的功能模块；再往下是细节的功能点具体的逻辑，基于此，通过由上到下逐级细化的过程，逐步梳理清楚旧逻辑。

当梳理完后，在结果上就会有四个呈现：一是产品的主流程图，二是产品架构图，三是产品结构图（脑图），四是通过表格整理的各模块功能逻辑清单。尤其对复杂系统而言，清单是必不可少的工作量，因为在前期时B端会有很多的复杂逻辑，如果没有清单记录，到了后期时就容易出现遗漏的情况，从而影响到开发节奏。

第三步：对比分析

当了解清楚业务和用户痛点、需求、业务现状和系统现有规则后，就可以对这两部分进行对比，通过对比即可发现业务实际需求和现有规则的缺口在哪里，比如业务有需求A，但实际系统规则实现的却是需求B，基于对比可以发现很多新问题和新功能缺口，而这些都是在前期调研时，用户出于遗忘或没有意识到等原因而没有反馈，但通过对比分析可以得出。

另外需要结合业务规则来判断旧系统规则的合理性，很多同学会直接基于原有经验或竞品的处理方式，强硬判断老系统规则是否合理，但实际上这种判断方式有很严重的问题，因为原有系统的设计逻辑之所以如此，很大概率都是为了迎合当时的业务诉求或有很多业务限制条件在里面。

所以在第三步时就需要把这部分规则梳理出来，避免在后续改造时把不应该改的地方给改了，这也是第三步对比分析中重要目的之一。在对比完成后就可以输出最终的系统现存问题清单，在输出清单后，就可以和第一步中的用户问题需求池相结合，从而得到最终系统或老系统现有问题的大池子，即需要一一去解决的内容。

第四步：问题/需求整理与分层

如果每个问题都需要解决，大部分同学在看到大池子的问题时都会头皮发麻，比如之前在进入某家公司做产品重构时，一进去已有100多条需求的文档在等着，再加上后期调研时的需求不断累加，最终形成了三四百条需求的文档，这无疑工作量很大，所以需要对问题和需求进行整理。

整理可以从三个方面入手：

一是按照功能模块进行归纳。

二是需要把重复问题或需求进行合并，因为有时同个问题会有不同人基于不同角度去反馈，在合并问题或需求的过程中，需要对反馈同个问题或需求的人数做记录，因为反馈人数可以代表痛点的普遍性，对于后续分析优先级时非常有帮助。

三是需要把明显不合理的问题或需求删掉，因为有很多用户的反馈比较局限，因其并不清楚业务的要求或管理上的要求就是这样，所以对于这种明显不合理的问题，可以直接做删除处理。

问题或需求需要按照以下5个层次划分：

第一、最底层是数据层，比较常见的比如数据混乱、不统一、来源不一致等问题。第二、模型层，是指与产品设计的底层模型相关的问题，而作为B端产品经理，都需要掌握关于底层模型设计的知识。第三、领域层，又称为业务逻辑层，即常见的各类业务逻辑问题。第四、交互层，主要是指页面的交互问题，比如菜单结构、页面/操作流程、控件等，这是很多介绍产品重构方法时比较集中的地方，但实际上的问题或需要重构的地方远不止这一层的内容。第五、UI层，属于纯视觉问题，比如icon语义、样式、页面布局等。

在重构时，除了需要清楚重构的目标，更重要的点是还需要知道在重构时可能会产生的关联影响，这也是对所有问题进行分层的原因。因为在原有系统上做重构时会有很多已有逻辑，不能出现改了一个问题却引发剩下的10个问题或10个BUG的情况，这在重构中需要极力避免。

分析关联性最为常见的方式是通过模块之间的横向关联和纵向关联去分析，比如分析出A模块和B模块之间的横向关联有哪些，纵向关联是指在页面上看到的某个问题，比如数据显示不对，这不仅是纯交互层的问题，还会往下涉及到数据层或其他层级，可能业务逻辑出现问题所以导致页面上展示的数据不对，需要一层层去分析。

故问题分层实际上是需要做纵向关联的分析，因为表面看到的问题会涉及到不同层级，而不同层级需要解决的问题或成本时间完全不一样。

分层的价值主要有两个：一是通过横向、纵向的关联，更容易分析出影响面；二是不同层级的改造成本都不相同，通常都是由上到下的成本逐渐增加，策略则是从左到右。

比如之前需要调整对象的状态机，最开始以为是操作逻辑即领域层的问题，但在往下分析时才发现，真正的原因在于原有的底层模型设计不合理，从而导致上层业务逻辑的不合理，这时就会涉及到改动模型层，就会牵扯到原有数据的调整，这是非常典型的表象问题。

第五步：明确重构目标和指标第六步：分析优先级第七步：模块调研第八步：设计、实施优化方案第九步：历史数据处理