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

产品经理一定要经历完整的从0~n才能在产品设计方法上比较游刃有余吗？这个想法还是太天真了。重构产品的方法与从0~1区别非常大，难度与挑战也远高于0~1。下面这篇文章作者就结合自己的经历，对产品重构做了梳理总结，想要了解产品重构的小伙伴赶紧来看看哦。

一、背景

曾经一度简单的认为产品经理一定要经历完整的从0~n才能在产品设计方法上比较游刃有余，后来经过一年多对一个产品重构后，发现以前的认知还是天真了，重构产品的方法与从0~1区别非常大，难度与挑战也远高于0~1，相信无论是做过还是正在做产品重构的同学，一定深有体会，这篇文章就结合自己的经历，对产品重构做个梳理总结。

我所重构的这个内部系统，在接手前已经做了一年左右，曾经的模式都是业务方一句话需求直接提到开发团队，然后各个开发根据自己的理解哼哧哼哧做两个星期，无论能不能用，好不好用，因为公司强制要求都在无奈使用，过程中也埋下无数坑，以致于用户使用起来痛苦万分，体验极差，领导对这个现状也不太满意。

经过一年多的改造和优化，我们的北极星指标–用户满意度（NPS）提升了49%，也达成了我们的预期目标，今天就把这个过程中总结出的方法、经验教训分享出来。

本文侧重讲解重构步骤方法，涉及部分细节就不在此展开过多了。

二、重构的方式

重构一般有三种方式

1. 推倒重来：在原系统基础上重新开发，仅保留数据库等基础内容，上层代码重新开发；
2. 另起炉灶：原系统保持运行，另起新项目，重新做个新系统替换，做数据迁移；
3. 运行中改造：保持现有系统持续、稳定运行，同时对所需模块持续改造，直至达成目标

这里对这三种方式做个对比：

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

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

至于最终选择哪种，就得结合实际情况来判断了。不过很明显方式三的挑战会更大，对产品经理的要求也更高，后面的内容，将基于方式三总结。

三、重构步骤

1. 前期调研

（1）内容

业务调研

所有的调研都是先从业务开始，在这部分的调研中，我们需要了解两部分：

1. 业务所在行业的通用玩法，知道行业内一般都是怎么运作的，有行业认识；
2. 公司的整体业务流程、业务特色、形成的历史渊源，其中要特别注意公司与行业的不同之处，一旦忽略就容易在后面改造中照搬行业玩法，导致与实际业务需求不符。

这两部分学习、调研的内容是相互促进的，通过观察公司业务运作可以更好的理解行业做法的含义，通过将行业玩法作为参考系可以发现公司当前所处位置及优劣。

用户调研

首先需要了解有哪些用户在使用现有系统，通过提炼用户差异性，将用户从多个维度进行分群（后面细聊如何做B端用户分群），然后就能找出对应群体中一些典型用户，通过一对一访谈深度了解他们使用系统的目的、路径、痛点、期望

不过一对一访谈效率还是比较低，所以需要增加问卷等方式，大批量收集用户目前的需求、槽点

（2）目的

1. 从业务方、领导层、用户各方充分了解为什么要进行重构
2. 对现有系统情况做一个整体的摸排，初步形成较为全面的认识

（3）输出

• 公司业务流程
• 公司业务特色总结，形成文档记录
• 各角色用例图
• 用户调研报告。包含用户体验地图
• 用户问题/需求池

2. 旧逻辑梳理

（1）内容

对系统现有主体逻辑进行梳理，包括系统主流程、产品架构、产品结构、功能模块、功能点等。

由于还没到具体模块的改造，所以有些细节暂时可以不用太深入，等到改造到那块时再梳理即可，一方面因为有些细节即使提前了解了，时间长了到后面可能也忘了，另一方面是可能由于文档缺失或更新不及时，已经没有人能记得很清楚了，需要开发通过代码看出原有逻辑，所以细节梳理需要耗费巨大的时间、人力成本，影响前期进展。

（2）目的

这一步的目的是为了对系统现有功能、逻辑有整体认知，便于后续对比业务需求，发现全局性、架构上、偏底层的一些问题。

（3）输出

• 产品主流程图
• 产品架构图
• 产品结构图（脑图）
• 通过表格整体的各模块功能逻辑清单

3. 对比分析

（1）内容

通过对比业务实际需求与现有规则的差异，发现、挖掘出系统现存的一些问题，明确后续需改造的内容。

（2）目的

很多同学在对现有系统做重构时，需改造内容的信息来源是调研结果或自我感受，但从我的经历来看，这些信息还不够，主要原因有两个：

1. 很多调研内容用户无法告知你应该怎么做，相当大比例的问题是普通用户意识不到的，用户反馈由于自身的很多局限，认识不够全面，同时也认识不到系统底层问题，更多的还只是一些交互、视觉层面的问题；
2. 很多看起来不合理的逻辑，其实是符合业务特点和要求的，也有其特殊背景，只有最适合你的业务需求的才是好的设计。

这就是专门对比业务需求与现有规则差异的目的。

（3）输出

补充用户问题/需求池。通过对比发现的系统现存问题清单，与前面调研结果进行合并在一张表里

4. 问题/需求整理与分层

（1）内容

问题/需求整理

通过前面的调研、分析，我们就有了一份用户问题/需求池，内容非常多，这就需要对这份问题/需求池进行整理。

• 按功能模块归纳
• 将重复问题/需求合并
• 将明显不合理问题/需求删除

问题/需求分层

除了将这些问题/需求按模块划分，还要对它们进行提炼总结，然后将这些问题按数据层–模型层–领域（业务逻辑）层–交互层–UI层五个层次进行分层

1. UI层：纯视觉问题，如icon语义、颜色、样式问题等；
2. 交互层：页面交互上的问题，常见的如菜单结构、操作控件；
3. 领域层：各种业务逻辑问题；
4. 模型层：底层模型设计相关，如原设计不合理，与业务需求不匹配，扩展性差
5. 数据层：常见如数据混乱，不统一、来源不一致等

（2）目的

问题/需求的整理是大多同学都会做的，就不做过多解释，但分层则是很多同学没有意识到，其实非常重要的事情，接下来就说一下为什么要对问题/需求进行分层？

当我们面对大量的问题、需求时，往往会是一脸懵逼、茫然无措的状态，主要有两个原因：

1. 问题太多，不知道从何下手，先从哪里开始；
2. 当我们深入这些问题/需求会发现，很多问题/需求都是相互依赖的，由于是对现有系统改造，很多功能已经成型，当我们选定一块内容时，往往牵扯其他很多部分，一类是横向关联，即模块与模块间的关联影响，另一种是纵向关联，即表面上是交互问题，但很可能会涉及业务逻辑层、甚至模型层的改动。

而我们在对已有系统改造时，很容易出现影响面评估不足导致线上bug的情况，所以除了将问题/需求从横向功能上整理归类，还要从纵向涉及层次划分，这样可以更好的分析出关联影响面，另外，不同层次的问题改动成本、策略、方法、时间差异很大，对我们后面优先级评估也有较大影响，所以需要有纵向划分。

（3）输出

整理分类后的用户问题/需求反馈清单

5. 明确重构目标与指标

（1）内容

重构不是为了改而改，需要有目标的改，改造的范围、最终希望达成的结果，如何衡量，都是在改之前要考虑清楚的问题。

明确了目标，就需要定义相应的指标进行量化评估，包括评估最终结果的全局指标和评估每块功能的功能指标，以便有数据支撑。

根据明确的指标，需要做好前期数据收集工作，提前做好埋点等，才能对比优化前后的结果。

（2）输出

数据指标定义：

6. 分析优先级

（1）内容

对用户问题/需求整理后，就要分析优先级，确定改造重构的先后顺序，主要从四个方面综合评估：

1. 价值收益。在看重构价值时，需要同时看短期和长期两方面，短期收益大（如交互体验上吐槽较多的问题）和长久的事情（如模型、数据层的动作）需要同时做，不要完全搁置某一类；
2. 依赖关系。根据依赖关系，一方面可以明确先后顺序，另一方面对于依赖过多的内容，尤其底层的改动，需要多花时间好好分析、好好讨论；
3. 改造成本。需要根据成本评估ROI
4. 资源支撑。

（2）输出

用户问题/需求反馈清单中的优先级结论

7. 模块调研

（1）内容

第一步的调研，主要是为了形成整体认知，还没深入到具体模块的细节中，当我们确定要重构的内容及优先级后，再对具体要改造的内容有针对性的做用户、竞品调研，就会更有收获，集中精力琢磨透一块内容，用户的痛点有哪些，使用的场景有哪些，同时看看其他竞品的针对这些问题的处理方式，也可以称为功能调研。

（2）输出

• 对应场景用户调研结论
• 对应功能竞品调研结论

8. 制定、实施优化方案

接下来就是根据规划的优先级来逐步改造优化了。

无论是一个产品还是模块的重构，这个流程方法都是通用的

四、感悟

最后从产品设计和心态分享几点在重构中体会比较深的感悟。

1. 产品设计

（1）敬畏用户习惯

重构需要改很多内容，当涉及到交互层，需要改变用户原有的使用习惯时，一定要三思而后行，首先要考虑的是能否保留用户的使用习惯，哪怕这个习惯不那么符合规范，与通用做法不太一样，也要首先考虑保留，其实很多交互方式没有对错之分，只有是否合适之分，用户用得舒服才叫合适。

如果实在需要改，就要好好考虑如何延续系统的风格，过渡更平缓，怎么更好的告知。

用户习惯不是仅仅“考虑过”就足够了，是真的需要敬畏的心态面对，否则用户会用中华国粹回敬你。

（2）不可避免的“浪费”

为了节约成本，我们大多希望一步，尽量减少后面的反复变动，不过产品重构有时候会出现一些不得不做的“浪费”，主要有两个原因：

1. 为了让用户、数据平稳过渡，有时会增加一段过渡期，这段过渡期可能是临时方案，等后面时机成熟会再变化；
2. 因为是在进行中改造，所以有时需要兼容新旧两套逻辑，从而增加额外成本

（3）用户价值=（新体验-旧体验）-替换成本-感知门槛

所有产品动作根本上都是用户价值驱动的，俞军老师的用户价值公式大家应该都很清楚了，在这个公式的基础上我在后面增加了一个【感知门槛】，即用户感知到你新体验带来价值的门槛有多高，门槛越低，带来的价值越大。

可能俞军老师已经把【感知门槛】算到【替换成本】里了，这里我单独列出来，目的是想强调这部分，因为有时候会出现自己感动自己的情况，觉得我们做了一个非常棒的优化，用户这群白眼狼怎么就不领情呢，原因可能你这个优化确实很好，但用户没感知到。

（4）随时可回滚

没有人能保证每一次改动都是向好的，哪怕不出bug，可能由于有的场景没考虑到导致新功能产生负面影响，所以从功能上要保证随时可回滚，从数据上每次数据库刷数据前有备份。

功能回滚基于现在的代码管理能力大多都具备，只要分支与需求关联比较规范，不过数据库备份是容易忽略的，所以要特别提醒服务端同学，做大改造需要刷数据前，做好数据备份以便数据回滚。

（5）小细节能有大回报

产品重构很多是用户使用太痛苦，而改变这种痛苦不一定都是要做大的变动才能让用户减轻痛苦，很多细节优化能有大的回报，例如增加最近使用、操作记忆等。

2. 心态

（1）重构是对产品能力淬火的绝佳机会，而不是火坑

接手一个前人留下的产品，是很多同学极不情愿的事情，就觉得是一个大火坑，都不知道怎么下手，都希望自己可以从0~1做一款产品，挖的坑让后面的人填。

我最开始的心态也是如此，但随着一年多的重构，会发现这其实不是火坑，而是对你产品能力二次打磨的火炉，当你深度长时间跟进后，你会对用户、场景、业务这几个词的理解更深。

（2）锻炼大心脏

产品重构确实很容易变成吃力不讨好的事情，你会随时受到多方的压力：

• 用户会喷你。因为改了用户习惯被喷，因为加了些“乱七八糟”的被喷，因为不被理解被喷，总之有各种理由；
• 前人留下的坑。你永远都不知道下个坑会在哪里，测试也回归不到，等到线上用户发现，就成了线上事故；
• 上级压力与用户适应节奏矛盾。上级希望在短时间内看到变化，但其实这比从0~1花的时间要更长，除了各种挑战外，更重要的是要给用户适应的时间，不适合在短时间做大幅度的变动，而这种矛盾难以调和；
• 不确定的风险。你也不知道这个版本的改造、优化上去能不能被用户接受，最终能否拿到你要的结果。

你需要同时面对更多的压力，所以调整好心态，锻炼大心脏才能更面对各种质疑和压力。