一、背景
以前一直以为产品经理经历的产品 从0~n ，产品设计方法上应该有一套方法论。但经过一年对一个产品重构，发现以前的认知还是愚昧了。
重构产品的方法与从0-1区别很大，难度和挑战也高于0-1。
我所重构的这个内部系统，在接手前重构已经做了一年左右。（说明系统包含的范围、功能的体量是巨大的）
旧内部系统，曾经的模式都是业务方一句话需求直接提到开发团队，然后各个开发根据自己的理解直接做两个星期，无论能不能用，好不好用，因为公司强制要求都在无奈使用，过程中也埋下无数坑，重点是公司持续发展，原来的系统是否还可以支撑更完整的电商业务链条？旧系统的情况，显而易见，是不能。
经过一年的改造和优化，目前已经完成，推动上线，这个过程中遇到的问题和解决方案、总结经验教训。
二、重构方式
重构一般有三种方式
- 推倒重来：在原系统基础上重新开发，仅保留数据库等基础内容，上层代码重新开发；
- 另起炉灶：原系统保持运行，另起新项目，重新做个新系统替换，做数据迁移；
- 运行中改造：保持现有系统持续、稳定运行，同时对所需模块持续改造，直至达成目标
这里对这三种方式做个对比：
方式一，要求原系统即将废弃，但情况不多。大多数公司都会选择方式二或三。
从产研的角度，通常倾向方式二，因为不用考虑过多的历史包袱，处理起来更方便，如果需改造内容多，综合成本也更小。
从业务方和领导们的角度，通常倾向方式三，因为风险更小，感觉上成本更低，但实际上如果需要改造的模块较多，方式三的成本其实更高，因为有很多兼容、填坑、还技术债的事情。
而我接手的产品，当时团队决定是方式二。但虽然是另起炉灶，但是需要场景新做，或者场景新旧逻辑均需要兼容。
三、重构过程与方法论沉淀
1. 前期调研
（1）内容
业务调研
所有的调研都是先从业务开始，在这部分的调研中，我们需要了解两部分：
- 业务所在行业的通用玩法，知道行业内一般都是怎么运作的，有行业认识；
- 公司的整体业务流程、业务特色、形成的历史渊源，其中要特别注意公司与行业的不同之处，一旦忽略就容易在后面改造中照搬行业玩法，导致与实际业务需求不符。
这两部分学习、调研的内容是相互促进的，通过观察公司业务运作可以更好的理解行业做法的含义，通过将行业玩法作为参考系可以发现公司当前所处位置及优劣。
用户调研
首先需要了解有哪些用户在使用现有系统，通过提炼用户差异性，将用户从多个维度进行分群（后面细聊如何做B端用户分群），然后就能找出对应群体中一些典型用户，通过一对一访谈深度了解他们使用系统的目的、路径、痛点、期望
不过一对一访谈效率还是比较低，所以需要增加问卷等方式，大批量收集用户目前的需求、槽点
（2）目的
- 从业务方、领导层、用户各方充分了解为什么要进行重构
- 对现有系统情况做一个整体的摸排，初步形成较为全面的认识
（3）输出
- 公司业务流程
- 公司业务特色总结，形成文档记录
- 各角色用例图
- 用户调研报告。包含用户体验地图
- 用户问题/需求池
2. 旧逻辑梳理
（1）内容
对系统现有主体逻辑进行梳理，包括系统主流程、产品架构、产品结构、功能模块、功能点等。
由于还没到具体模块的改造，所以有些细节暂时可以不用太深入，等到改造到那块时再梳理即可，一方面因为有些细节即使提前了解了，时间长了到后面可能也忘了，另一方面是可能由于文档缺失或更新不及时，已经没有人能记得很清楚了，需要开发通过代码看出原有逻辑，所以细节梳理需要耗费巨大的时间、人力成本，影响前期进展。
（2）目的
这一步的目的是为了对系统现有功能、逻辑有整体认知，便于后续对比业务需求，发现全局性、架构上、偏底层的一些问题。
（3）输出
- 产品主流程图
- 产品架构图
- 产品结构图（脑图）
- 通过表格整体的各模块功能逻辑清单
3. 对比分析
（1）内容
通过对比业务实际需求与现有规则的差异，发现、挖掘出系统现存的一些问题，明确后续需改造的内容。
（2）目的
很多同学在对现有系统做重构时，需改造内容的信息来源是调研结果或自我感受，但从我的经历来看，这些信息还不够，主要原因有两个：
- 很多调研内容用户无法告知你应该怎么做，相当大比例的问题是普通用户意识不到的，用户反馈由于自身的很多局限，认识不够全面，同时也认识不到系统底层问题，更多的还只是一些交互、视觉层面的问题；
- 很多看起来不合理的逻辑，其实是符合业务特点和要求的，也有其特殊背景，只有最适合你的业务需求的才是好的设计。
这就是专门对比业务需求与现有规则差异的目的。
（3）输出
补充用户问题/需求池。通过对比发现的系统现存问题清单，与前面调研结果进行合并在一张表里
4. 问题/需求整理与分层
（1）内容
问题/需求整理
通过前面的调研、分析，我们就有了一份用户问题/需求池，内容非常多，这就需要对这份问题/需求池进行整理。
- 按功能模块归纳
- 将重复问题/需求合并
- 将明显不合理问题/需求删除
问题/需求分层
除了将这些问题/需求按模块划分，还要对它们进行提炼总结，然后将这些问题按数据层–模型层–领域（业务逻辑）层–交互层–UI层五个层次进行分层
- UI层：纯视觉问题，如icon语义、颜色、样式问题等；
- 交互层：页面交互上的问题，常见的如菜单结构、操作控件；
- 领域层：各种业务逻辑问题；
- 模型层：底层模型设计相关，如原设计不合理，与业务需求不匹配，扩展性差
- 数据层：常见如数据混乱，不统一、来源不一致等
（2）目的
问题/需求的整理是大多同学都会做的，就不做过多解释，但分层则是很多同学没有意识到，其实非常重要的事情，接下来就说一下为什么要对问题/需求进行分层？
当我们面对大量的问题、需求时，往往会是一脸懵逼、茫然无措的状态，主要有两个原因：
- 问题太多，不知道从何下手，先从哪里开始；
- 当我们深入这些问题/需求会发现，很多问题/需求都是相互依赖的，由于是对现有系统改造，很多功能已经成型，当我们选定一块内容时，往往牵扯其他很多部分，一类是横向关联，即模块与模块间的关联影响，另一种是纵向关联，即表面上是交互问题，但很可能会涉及业务逻辑层、甚至模型层的改动。
而我们在对已有系统改造时，很容易出现影响面评估不足导致线上bug的情况，所以除了将问题/需求从横向功能上整理归类，还要从纵向涉及层次划分，这样可以更好的分析出关联影响面，另外，不同层次的问题改动成本、策略、方法、时间差异很大，对我们后面优先级评估也有较大影响，所以需要有纵向划分。
（3）输出
整理分类后的用户问题/需求反馈清单
5. 明确重构目标与指标
（1）内容
重构不是为了改而改，需要有目标的改，改造的范围、最终希望达成的结果，如何衡量，都是在改之前要考虑清楚的问题。
明确了目标，就需要定义相应的指标进行量化评估，包括评估最终结果的全局指标和评估每块功能的功能指标，以便有数据支撑。
根据明确的指标，需要做好前期数据收集工作，提前做好埋点等，才能对比优化前后的结果。
（2）输出
数据指标定义：
6. 分析优先级
（1）内容
对用户问题/需求整理后，就要分析优先级，确定改造重构的先后顺序，主要从四个方面综合评估：
- 价值收益。在看重构价值时，需要同时看短期和长期两方面，短期收益大（如交互体验上吐槽较多的问题）和长久的事情（如模型、数据层的动作）需要同时做，不要完全搁置某一类；
- 依赖关系。根据依赖关系，一方面可以明确先后顺序，另一方面对于依赖过多的内容，尤其底层的改动，需要多花时间好好分析、好好讨论；
- 改造成本。需要根据成本评估ROI
- 资源支撑。
（2）输出
用户问题/需求反馈清单中的优先级结论
7. 模块调研
（1）内容
第一步的调研，主要是为了形成整体认知，还没深入到具体模块的细节中，当我们确定要重构的内容及优先级后，再对具体要改造的内容有针对性的做用户、竞品调研，就会更有收获，集中精力琢磨透一块内容，用户的痛点有哪些，使用的场景有哪些，同时看看其他竞品的针对这些问题的处理方式，也可以称为功能调研。
（2）输出
- 对应场景用户调研结论
- 对应功能竞品调研结论
8. 制定、实施优化方案
接下来就是根据规划的优先级来逐步改造优化了。
无论是一个产品还是模块的重构，这个流程方法都是通用的
四、感悟
1. 产品设计
（1）敬畏用户习惯
重构需要改很多内容，当涉及到交互层，需要改变用户原有的使用习惯时，一定要三思而后行，首先要考虑的是能否保留用户的使用习惯，哪怕这个习惯不那么符合规范，与通用做法不太一样，也要首先考虑保留，其实很多交互方式没有对错之分，只有是否合适之分，用户用得舒服才叫合适。
如果实在需要改，就要好好考虑如何比前任做得更好。
用户习惯不是仅仅“考虑过”就足够了，是真的需要敬畏的心态面对，否则用户会用中华国粹回敬你。
（2）用户价值=（新体验-旧体验）-替换成本-感知门槛
所有产品动作根本上都是用户价值驱动的，俞军老师的用户价值公式大家应该都很清楚了，在这个公式的基础上我在后面增加了一个【感知门槛】，即用户感知到你新体验带来价值的门槛有多高，门槛越低，带来的价值越大。
可能俞军老师已经把【感知门槛】算到【替换成本】里了，这里我单独列出来，目的是想强调这部分，因为有时候会出现自己感动自己的情况，觉得我们做了一个非常棒的优化，用户这群白眼狼怎么就不领情呢，原因可能你这个优化确实很好，但用户没感知到。
（3）小细节能有大回报
产品重构很多是用户使用太痛苦，而改变这种痛苦不一定都是要做大的变动才能让用户减轻痛苦，很多细节优化能有大的回报，例如增加最近使用、操作记忆等。
（4）产品设计尽可能穷尽场景，扩充思考广度与深度
基于重构的方式二，容错率是很低的，风险极高。因此在产品设计上需要想明白。流程正向场景，逆向场景，分别罗列清楚。再细致整理和产出方案。
而且重构方式二，缺少验证环节，实际上是无法很好的控制重构结果的。
（5）识别和评估方案的风险，并且要制定风险应对方案
没有人能保证每一次改动都是向好的，哪怕不出bug，可能由于有的场景没考虑到导致新功能产生负面影响，所以功能上的实现需要遵照小步快跑，增加验证环节。
2. 心态
（1）重构是对产品能力淬火的绝佳机会，而不是火坑
接手一个前人留下的产品，是很多同学极不情愿的事情，就觉得是一个大火坑，都不知道怎么下手，都希望自己可以从0~1做一款产品，挖的坑让后面的人填。
我最开始的心态也是如此，但随着一年多的重构，会发现这其实不是火坑，而是对你产品能力二次打磨的火炉，当你深度长时间跟进后，你会对用户、场景、业务这几个词的理解更深。
（2）锻炼大心脏
产品重构确实很容易变成吃力不讨好的事情，你会随时受到多方的压力：
- 用户会喷你。因为改了用户习惯被喷，因为加了些“乱七八糟”的被喷，因为不被理解被喷，总之有各种理由；
- 前人留下的坑。你永远都不知道下个坑会在哪里，测试也回归不到，等到线上用户发现，就成了线上事故；
- 上级压力与用户适应节奏矛盾。上级希望在短时间内看到变化，但其实这比从0~1花的时间要更长，除了各种挑战外，更重要的是要给用户适应的时间，不适合在短时间做大幅度的变动，而这种矛盾难以调和；
- 不确定的风险。你也不知道这个版本的改造、优化上去能不能被用户接受，最终能否拿到你要的结果。
你需要同时面对更多的压力，所以调整好心态，锻炼大心脏才能更面对各种质疑和压力。