一、背景

我曾经简单地认为，产品经理必须经历从0到n的完整旅程，才能更加适应产品的设计方法。后来，经过一年多的重构一个产品，我发现我之前的理解还是幼稚的。从0到1的方法和从0到1有很大不同，难度和挑战也比0到1高很多，相信做过或者正在做产品重构的同学一定对此有深刻的理解。这篇文章结合了我自己的经历。对产品重构进行总结。

我重建的内部系统在我接手之前已经进行了大约一年的时间。之前的模式是业务方直接一句话向开发团队提到需求，然后每个开发人员根据自己的理解进行两周的工作。 ，不管能不能用，都因为公司的强制要求而不得不使用，并且在这个过程中埋下了无数的陷阱，让用户使用起来极其痛苦，体验极差，领导对这个现状也不是很满意。

经过一年多的改造和优化，我们的北极星指标——用户满意度（NPS）提升了49%，达到了我们的预期目标。今天我们就来分享一下过程中的方法和经验教训。

本文重点讲解重构步骤和方法，这里不再赘述。

2. 重建方法

重构一般有以下三种方式

推倒重来：在原系统基础上重新开发，只保留数据库等基础内容，重新开发上层代码；从头开始：保持原有系统运行，启动新项目，更换新系统，进行数据迁移；即时改造：保持现有系统持续稳定运行，同时不断改造所需模块，直至达到目标。

以下是这三种方法的比较：

方法一仅适用于原系统打算或已经废弃的情况，这种情况实际上比较少见。更多时候，我们面临的重建场景涉及在方法 2 和 3 之间进行选择。

从业务方和领导的角度来看，通常会首选方法三，因为风险较小，成本似乎也较低。但事实上，如果需要修改的模块较多，那么方法三的成本其实更高，因为兼容和填充的模块较多。陷阱和技术债务偿还；从生产和研究的角度来看，通常首选第二种方法，因为不需要考虑太多的历史包袱，处理起来比较方便，而且如果要修改的内容很多，总体成本也比较高较小。

至于最终选择哪一个，还要根据实际情况来判断。但很明显，方法三的挑战会更大，对产品经理的要求也会更高。下面的内容将根据方法三进行总结。

三、重建步骤 1、初步研究

(一)内容

商业研究

所有研究都从业务开始。在这一部分的研究中，我们需要了解两个部分：

企业所在行业的一般方法，了解行业一般如何运作，具备行业知识；公司的整体业务流程、业务特点、历史渊源。应特别注意公司与行业的差异。一旦被忽视，后续的改造中就很容易照搬行业方法，导致与实际业务需求不符。

学习和研究这两部分的内容是相辅相成的。通过观察公司的业务运营，可以更好地理解行业惯例的意义。通过行业玩法作为参考体系，可以发现公司目前的定位和优劣势。

用户研究

首先，我们需要了解哪些用户正在使用现有系统。通过细化用户差异，我们可以从多个维度对用户进行分组（稍后我们将讨论如何对B端用户进行分组）。然后我们就可以在相应的群体中找到一些典型的用户。通过一对一的采访，我们深入了解他们使用该系统的目的、路径、痛点和期望。

但一对一访谈的效率还比较低，因此需要增加问卷等方式，大量收集用户当前的需求和不足。

(2) 目的

从业务方、领导层、用户方，充分理解为什么需要重构，对现有系统情况进行全面排查，初步形成较为全面的认识。

(3) 输出

2. 梳理旧逻辑

(一)内容

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

由于具体模块的改造还没有完成，一些细节我们暂时不需要过多赘述。当转变达到那个点时，我们可以将它们整理出来。一方面，即使提前了解了一些细节，但之后也可能会忘记。一方面，可能是因为文档缺失或者更新不及时，没有人能够清楚地记得。开发需要通过代码看到原来的逻辑，所以梳理细节需要花费大量的时间和人力成本，影响早期进度。

(2) 目的

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

(3) 输出

3. 对比分析

(一)内容

通过对比实际业务需求与现有规则的差异，发现和挖掘系统中存在的一些问题，明确未来需要修改的内容。

(2) 目的

很多学生在重构现有系统时，需要改造的信息来源是调查结果或自我感受。然而，根据我的经验，这些信息还不够。主要原因有两个：

许多调查内容的用户无法告诉您该做什么。很大一部分问题是普通用户没有意识到的。由于其诸多局限性，用户反馈不够全面。同时，也无法认识到系统的根本问题。大多数只是一些交互和视觉问题；很多看似不合理的逻辑实际上符合业务特点和需求，也有其特殊的背景。只有最适合您业务需求的设计才是好的设计。

这是专门比较业务需求和现有规则之间的差异的目的。

(3) 输出

补充用户问题/需求池。通过比较发现的现有系统问题清单与之前的调查结果合并到一张表中。

4. 问题/需求梳理和分层

(一)内容

问题/需求排序

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

问题/需求分层

这些问题/需求除了按模块进行划分外，还必须进行提炼和总结，然后分层为五层：数据层——模型层——领域（业务逻辑）层——交互层——UI层

UI层：纯视觉问题，如图标语义、颜色、样式问题等；交互层：页面交互的问题，如菜单结构、操作控件等；领域层：各种业务逻辑问题； model层：底层模型设计相关，比如原来的设计不合理，不符合业务需求，扩展性差等。数据层：常见数据如混乱、不一致、来源不一致等。

(2) 目的

梳理问题/需求是大多数同学都能做到的事情，所以我不会解释太多，但是分层是很多同学没有意识到的，其实是非常重要的。接下来我们来说说为什么问题/需求要分层。 ？

当我们面对大量的问题和需求时，常常会感到困惑和不知所措。主要原因有两个：

问题太多，不知道从哪里开始。首先从哪里开始？当我们深入研究这些问题/需求时，我们会发现很多问题/需求是相互依赖的。我们现在改造现有的体制，很多功能已经形成了。当我们选择一个内容时，往往会涉及到很多其他部分。一类是横向关联，即模块之间的关联。另一种是纵向关联，表面上是交互问题，但很可能涉及到业务逻辑层，甚至是模型层的变化。

当我们改造现有系统时，由于影响评估不充分，很容易出现线上bug。因此，除了从横向功能角度对问题/需求进行梳理和分类外，我们还需要将其纵向划分层次。这样可以更好地分析相关影响领域。另外，不同层次改变问题的成本、策略、方法、时间差异很大，这也会对我们后续的优先级评估产生较大影响，所以需要纵向划分。

(3) 输出

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

5、明确重构目标和指标

(一)内容

重构不仅仅是为了改变。它需要有针对性的改变。变革的范围、最终预期达到的效果、如何衡量，都是变革前需要认真考虑的问题。

目标明确后，就需要定义相应的指标进行量化评价，包括评价最终结果的全局指标和评价各个功能的功能指标，这样才有数据支撑。

在明确指标的基础上，需要提前做好前期数据采集工作，埋点，对比优化前后的结果。

(2) 输出

数据指标定义：

6. 分析优先事项

(一)内容

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

价值增益。在看待重建的价值时，需要同时考虑短期和长期两个方面。短期的好处（比如更多交互体验的抱怨）和长期的事情（比如模型和数据层动作）需要同时做，不应该完全搁置。某一类别；依赖性。根据依赖关系，一方面可以明确顺序；另一方面，对于依赖过多的内容，尤其是底层的变化，需要花更多的时间来仔细分析和讨论；转型成本。 ROI资源支持需要根据成本进行评估。

(2) 输出

用户问题/需求反馈列表中的优先结论

7. 模块研究

(一)内容

第一步研究主要是形成一个整体的认识，尚未深入到具体模块的细节。确定了重构的内容和优先级后，我们再重点改造具体的内容。 ，竞品研究会更有收获。集中精力搞清楚一个内容，用户的痛点是什么，使用场景是什么，同时看看其他竞品是如何处理这些问题的，这也可以称为功能研究。 。

(2) 输出

8、制定并实施优化方案

下一步将按照规划重点逐步改造优化。

无论是产品还是模块的重构，这种工艺方法都是通用的

4. 启示

最后分享一些对产品设计和重构过程中的心态的更深层次的感悟。

1、产品设计

(1)尊重用户习惯

重构需要改变很多内容。当涉及到交互层，需要改变用户原有的使用习惯时，一定要三思而后行。首先要考虑的是用户的使用习惯能否保留，即使这个习惯不符合标准。这与通常的做法不同，必须首先考虑保留。事实上，很多交互方式并没有对错之分。仅当用户使用起来舒适时它们才适合。

如果确实需要改变，你应该仔细考虑如何延续系统的风格，让过渡更加顺畅，以及如何更好地通知你。

用户习惯仅仅“考量”是不够的，还确实需要带着敬畏之心去面对，否则用户就会用国粹来回应你。

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

为了节省成本，我们大多数人都希望一步到位，尽量减少后续的重复修改。然而，产品改造有时会造成一些不得不做的“浪费”。主要原因有两个：

为了让用户和数据顺利过渡，有时会增加一个过渡期。这个过渡期可能是一个临时解决方案，到时候会改变。因为改造正在进行中，有时需要兼容新旧套逻辑，从而增加额外成本

(3) 用户价值=(新体验-旧体验)-重置成本-感知阈值

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

或许于俊老师已经将【感知阈值】纳入了【更换成本】之中。我单独列出来是为了强调这一部分，因为有时候会出现感动的情况，感觉我们做了一件很棒的事情。为什么用户像狼一样不欣赏你的优化呢？原因可能是你的优化确实很好，但是用户没有意识到。

(4)可以随时回滚

没有人能保证每一次改变都会变得更好。即使没有bug，也可能没有考虑到某些场景，这可能会导致新功能产生负面影响。因此，从功能角度来说，需要保证可以随时回滚。从数据的角度来看，每次数据库发生变化时，在刷写数据之前都要进行备份。

功能回滚基于最新的代码管理功能。只要分支和需求之间的关系比较规范，数据库备份就很容易被忽视。所以服务器端同学一定要提醒，在重大改造需要数据刷新之前，需要进行数据备份。数据回滚。

(5) 小细节能带来大回报

很多产品重构对于用户使用来说太痛苦了，而改变这种痛苦并不一定需要进行重大改变才能减轻用户的痛苦。很多细节上的优化可以有很大的回报，比如增加最近使用量、操作内存等。

2、心态

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

接手前辈留下的产品，是很多学生都极其不愿意做的事情。他们觉得这是一个大坑，不知道如何下手。他们都希望自己能做出一个从0到1的产品，挖个坑让别人效仿。人家填写。

我最初的心态也是如此，但经过一年多的重构，我会发现这不是一个火坑，而是一个炼化你产品能力的熔炉。当你深入、长期的跟进时，你会对用户有更深入的了解。我对文字、场景、业务有了更深的理解。

（二）锻炼大心脏

产品重构很容易成为一件吃力不讨好的事情，你随时都会面临来自多方的压力：

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

专栏作家