主要总结重构项目的前期准备，前期准备工作是产品经理应该投入时间最多的阶段，包括了需求调研、数据分析、老系统/老版本逻辑梳理、重构版本逻辑定义等等。甚至前期准备工作决定了重构项目的质量以及重构后的用户满意度，本文将各种场景下重构项目必不可少的准备工作抽象出来，以实例进行拆解。
文章较长，其实浓缩出来也就一张图，下面所有内容都是对这张图的注释：
一、评估重构价值
关于重构项目，本人有一个核心观念：重构项目一定是在填历史遗留的坑。当老板发现系统不足以支撑业务发展，或者严重阻碍业务发展时，“重构”的需求就开始从中高层酝酿起来。
比如之前规划后台时没有一个好的架构师，没有预想到后面的业务发展和业务形态变化，十几个运营后台堆起来，运营操作一个流程需要频繁切换多个后台才能完成，这时候运营的老大会喷设计这些乱七八糟后台的人，同时也会提出“统一运营后台”的需求，具体需求为：“所有运营操作集成到一个后台，流程能简化的全部简化。”
需求就这么一句话，拆解起来就得看具体有多少后台了（产品背锅原因之一：业务侧需求不明确，一句话需求）。如果说只有三五个分别控制不同模块的后台，并且不太复杂，建议不要重构，而是应该在做第六个后台时候考虑到后面的业务发展场景，做一个高扩展性的后台，然后再陆续将前五个容纳到这个后台来。如果有十几个后台，并且其中耦合了大量的交叉逻辑，那么只有重构一条路可走。
“重构”需求大多是自上而下的需求，管理层出于对各种原因的考虑，提出重构的需求。作为基层产品经理，需要有自己的判断，到底是“重构”更好还是“优化”更佳。
评估重构价值需要先明确重构的原因，一般而言重构只有以下四类原因：
用户变了：之前产品的用户画像与现在的用户画像发生了较大的变化，用户属性也发生了改变，新用户不断涌入，老用户流失严重。这种场景下领导层可能会放弃部分老用户，专耕新用户，针对新用户属性进行重构/大改版的产品设计。
需求变了：一般内部系统的重构都归结于此原因，之前需求都实现了，只是扩展性不够，考虑的场景不够多，现在用起来非常不方便，阻碍了业务发展，因此需求从原来的“可用”升级到“便捷地用”。
目标变了：不同产品在不同阶段有不同目标，产品生命周期更迭中自然伴随着目标的变化，可能前期主要提升用户体验，做大流量，中期又以变现为目标，后期开始做留存和老用户召回，或者做品牌升级。往往在产品生命周期后期容易出现重构的需求，试图用重构版本赋予产品新的生命周期。
环境变了：这个环境包括技术环境和市场环境。技术革新带来新的想象空间，迫切期望使用新技术打造新产品来冲击市场。市场之前青睐的某种产品形态，现在已经落伍了，需要重新定位产品来跟上时代的步伐。这两种场景下的重构需求往往需要谨慎，到底是“重构”还是“新做”一个产品？
还有一种常见的原因：年久失修。不管用户还在不在，领导层决心再捡起来做的话，老代码老逻辑的维护成本远高于重构一番。此时请一定好好善待那些不离不弃的老用户，他们很可能因为重构没有契合他们的习惯就走掉了，临走前还要喷你一顿：“改的什么玩意儿！”。
根据重构原因，评估重构能够带来的价值，同时评估正常迭代能带来的价值，当“重构价值>迭代价值”时，“重构”需求才能接手，否则可能就是“瞎重构”，或者重构完了也没人愿意用。
那么如何评估重构价值？
这是一个需要量化的多维度指标，可能是节省了运营多少人天的工时，可能是提升了用户留存，可能是提高了某个核心指标等等。在这些重构带来好处的维度指标中，选择最为核心的一点或者亮点，作为重构的核心目标。
例如统一运营后台，核心目标就是节省运营工时；统一中台化服务，就是节省前台开发工时；C端产品重构，就是为了拉升某个核心指标。
二、重构前期准备
作为产品经理，在做“重构”项目时，其实最重要的就两个词：梳理和定义，梳理旧的逻辑，定义新的逻辑。无论是后台、中台还是前台相关的重构，基本上大同小异，都可以按照下面的方法去操作。
其中，后台和中台大多数还是给公司内部人使用，重构得不是很好还有机会继续迭代优化，而前台ToC的产品重构，做得不好可能就得承担用户血喷甚至流失的压力，同时前台的重构一定会涉及到后台或中台的调整。因此，本文以重构压力和产品发挥空间最大的ToC前台为例进行说明。
产品确定要进行重构之后，立即新建两个文档，一个调研文档，用来辅助产品设计，一个需求文档，逐渐更新为最终输出的PRD。同时，需要督促开发也新建技术文档，对核心重构内容进行技术调研，对于初步明确的大方向提前做好技术准备，减少开发说“这个实现不了”的概率。
调研文档必须包含的六个版块：旧版拆解、数据分析、用户画像、竞品分析、需求池、重构目标。六块少了任何一部分，我认为都会对产品方案的制定产生影响，也会对最终的重构效果产生影响。
1. 旧版拆解
无论旧版是不是你做的，只要是重构，一定要详细拆解旧版，拆得越细越好。一般重构项目，可参考的历史文档都非常有限，即使有文档也最好自己亲自细细体验。拆解旧版最终要产出的四个东西：页面结构图、前台与中后台交互的流程图、交互说明文档（关系到后面的继承性产品设计）和特殊处理说明。
页面结构图并不难，属于产品基本功，列出结构才能明确重构范围具体到哪些页面和哪些细小的点，颗粒度越细越好。
信息交互的流程图是拆解的核心，产品的功力体现在这一步。理想的产出流程图需覆盖用户操作行为的每一步请求与中后台的信息交互，这需要产品知道目前老版页面所调的所有接口、调用顺序、接口限制条件（能有接口文档最佳）等等。这里最好找个后端开发协助一起，理清了所有的接口才能确定哪些接口复用，哪些需要改造，后续产品方案需要新增哪些接口，后端开发也能更加清晰评估自己的开发量和开发难度。
交互说明文档：常听到的“反人类的设计”基本都是骂交互，重构项目的旧版拆解中，需要记录旧版核心流程上的所有交互操作，比如提交按钮、翻页器、提示框、无限加载、手势动作、隐藏和露出等。在之后的数据分析中来决断哪些交互行为一定要保留或者只能微调，因为这些强用户习惯的操作一时间很难改变，只能在后续的迭代中陆续微调。比如：习惯了手指左滑翻页，或者翻页器翻页，改版成上滑无限加载，绝对找喷。
特殊处理说明：旧版的特殊处理不一定完全能拆解出来，因为有的特殊处理很难看出来。这些特殊处理都是代码写死的逻辑，最好能分析出为什么做特殊处理，不是懒就是有特殊的限制原因，提醒你这里有坑需谨慎，重构版本就尽量减少特殊处理的逻辑。
2. 数据分析
曾经一位开发对我提的老版本加上埋点的需求不以为然，认为都要重构的东西了，没必要在老版本上面加埋点。我列了三条理由说服了开发加埋点：
改版效果需要用数据说话，新版本会加埋点，会有数据，但是老版本没有，那么核心的数据指标无法对比，也就无法衡量改版是否成功；
我对ABC功能点存在一些想法，想直接砍掉其中某些功能，或者对一些功能做一个较为大的改动，想要了解老版本这个功能点目前的用户使用情况，如果很少人用，直接砍掉，新版你们开发也省事儿（说话的时候也要站在开发的角度思考）；
我们的用户长什么样我们现在都不清楚，不加埋点来看的话，改版就是“瞎撞”。我需要知道较为清晰的用户画像，至少知道谁在用我们产品，才好制定合理的产品方案，才不会给你们开发提傻X需求，每个需求点都有理有据。
用实例进一步解释这三条理由，假如知乎文章发布页重构，首先确定一个核心数据指标，假定为发布成功率。那么需要知道老版本的这个数据是多少，重构版本与此对比来看改版效果（这里还需要限制约束条件：在发帖页平均UV波动不超过5%的前提下）。
其次，分析功能点，假如数据分析发现用户在上传视频的时候有5%的概率的失败，失败后又重新传，那么新版断点续传的功能优先级很高，同时进一步分析失败原因，新版要大幅降低这个值。
3. 用户画像
用户画像简单说就是给用户打标签，用户是男是女，喜欢什么东西，什么时候活跃，活跃时候都看了些什么。无论是在做什么项目，了解用户画像都很有必要。可能在重构项目期间，产品经理不清楚用户画像也能很好地完成重构项目，但是了解用户画像的产品经理思考的深度和视野的广度都远甚于前者，换句话说：了解用户画像能让产品经理逼格上升一个档次。
曾经有一位前辈看过我写的需求文档之后，给我提出了一些指导建议，其中有一条是：“可以在需求文档或者其他地方专门写一个部分——帮助运营做得更好”。
前辈的意思是产品在进行方案设计时候，也应该站在运营的角度去思考，如何能够帮助运营更好地开展工作或者提高效率。随着经验的积累和阅历的增长，发现不仅是站在运营的角度，还需要站在更多人的角度以及更高层次的视野去看待产品设计。
这里的提升就不得不清晰地了解用户画像，因为用户画像主要功能有四个：精准营销、广告投放、个性化推荐、辅助产品设计。在做产品设计的时候，如果能将前面三者都思考在内，虽然做出来的东西可能差别不大，但是境界和视野的差距可见一斑。
将用户画像运用得最好的一个产品我认为是虎扑，用户画像非常清晰：20-35岁的男性，以大学生和上班族为主，喜欢篮球，热爱运动，喜欢以实力论英雄。这样的用户被定义为“直男”。围绕“直男”做球鞋球衣广告投放、做吴亦凡/蔡徐坤相关内容营销、推荐评分投票帖等。虎扑的产品体验并不算好，但是围绕“直男”的运营做得在国内确实无出其右。
4. 竞品分析
这也是产品经理的基本功，在此不做详细描述，但是提醒两点：
避免没有结论的功能点罗列：这是最常见的竞品分析误区，一定要有自己的分析结论，竞品在做什么——他们为什么这么做——我在做什么——我应该怎么做。
不要只关注页面结构和前端交互，多注意一些细节和隐藏功能。比如知乎的文章发布页，上传图片可以选择本地，还可以直接复制图片到编辑器中，而复制进去的图片是直接上传云端的，展示出来的就是知乎域下的图片，而虎扑的发帖页编辑器中复制图片是直接base64解析的原图地址，并未执行上传云端操作。
5. 需求池
在体验老版本的时候经常会发现一些问题，记录下来，可能是一些功能bug，可能是一些细节的纰漏，甚至可能是一些提示文案等。但是仅自己体验后记录的需求远远不够，一定会存在很多遗漏的点，以下有三条经验可供参考：
公司内部发起调研，经常使用老版本的公司内部人员会给出很多优化建议；
对用户发起调研，邀请一批高活跃用户拉群或者面聊（沙龙形式），或者用广撒网的形式发调研问卷；
需求方的想法和建议，需求方可能是领导或者高层，沟通前做好功课，这一步很有必要，避免出现重构产出与需求方预期相差太远的问题。
需求池建立后开始做筛选工作，第一步先筛出来接受的需求，有些不合理的需求直接pass。在接受的需求池中，标注好每一条的优先级，以及解决方案，按照优先级制定重构版本需求范围和重构后迭代版本的迭代规划，而解决方案则落实到需求文档中。
下图为一个较大重构项目的原始需求池，未经筛选和标注优先级，小圆圈内的数字代表需求条数。
6. 重构目标
重构目标不是将产品做出来，而是数据层面达到怎样的水平。重构目标需要具体可量化，而不是模糊的“提升用户体验”。
【反面示例】
改版目标：通过改版内容详情页，提升用户体验，给用户更好的阅读体验。
目标解读：首先不够具体，“提升用户体验”范围太大，其次没有量化，“更好的阅读体验”如何用数据衡量？
【正面示例】
改版目标：通过改版内容详情页，在详情页访问UV波动不超过5%的前提下，将PV/UV提升10%
目标解读：明确了改版后重点看的数据指标PV/UV，反应单个用户对于内容的沉浸程度。有约束条件：新版总体UV相较老版波动不超过5%。因此，针对这个目标设计内容详情页，可以考虑增加详情页里面的关联内容推荐、优化互动模式和通知提醒等，以达到新版让用户更多地访问到内容详情页。
总之，在一些目标导向的公司，有一个清晰的重构目标，有利于产品的设计，也容易出成果。如果能再增加一些行业数据或者竞品数据进行对标，那么在写绩效总结的时候绝对是一大亮点。
完成了以上调研文档的六个步骤，再来看需求文档其实就已经很清晰了。按照各自业务场景和调研文档的结论进行设计，在前面调研文档很清晰的情况下，需求文档的撰写应该是相对水到渠成的事情。可以在调研文档进行的同时将已经明确的改版方案细节列在需求文档中，不断扩充和积累之后，需求文档也相对趋于完善。
唯一要注意的一点：继承性产品设计，千万不能一次性大幅改变用户的操作习惯，否则后果自负。
三、中期策略
“重构”项目产品经理的工作70%的精力在前期的梳理与定义，需求评审完成后就陆续跟进视觉稿、开发和测试，有不明确的地方相关方会再来找你确认，如果你文档够细，评审够清晰，这种不明确的询问就会相对较少。
在项目开发中，其实产品经理很多时候还会兼任项目经理的职责，一般而言总会出现一些临时需求和紧急需求需要占用开发资源，如果影响项目进展的话，这时候产品经理需要做出权衡，哪些是一定要在DDL前完成，哪些可以先灰度后再迭代加上，合理把控好整体的项目节奏。
在开发提测之后，我认为项目才开始进入到中期，中期主要讲究策略，如何让用户更自然和更乐意地接受新版的策略。
我个人总结的策略分为三部分：灰度策略、选择页策略、沟通策略。总体思路为灰度放量进到选择页，选择页筛出愿意体验新版的用户，对反馈强烈的用户拉群沟通。
1. 灰度策略
灰度的目的是为了降低产品BUG风险，试验新版本和新交互的用户反馈，在数据层面上对新版功能、性能、稳定性、兼容性等指标进行评价，在灰度期间不断迭代优化新版，以达到较为完善的用户体验后全量上线。
灰度上线策略可以很简单，但是一般发布会比较复杂，产品经理可以在定义合适的灰度策略之后与开发沟通是否可行，若不可行可调整为怎样的策略。
最常见的两个灰度策略大类就是定量和定时间，定量为筛选一部分属性的用户进入新版本或者直接设置前x万的访问进到新版（注意爬虫的量），定时间则是简单粗暴地开放某个时间段访问全部进到新版。在新版的设计中需要增加“返回原版”的入口，支持用户手动回到旧版。
示例：
灰度策略示例：每天新增前3万用户访问到新的首页（爬虫会爬去2万，实际每天灰度1万用户），先持续7天看效果，灰度期间迭代节奏为一周一个版本，将用户集中反馈的问题迅速解决掉。
灰度实现示例：后端下发cookie判断是否切换到新版本，cookie字段为A，下发cookie后重定向当前页面。前端确保新版和老版的JS和CSS路径没有问题。运维通过cookie进行新老版本机器切换，如果cookie有A字段，且A字段为1时（1代表新版，0代表旧版），转发到新版的服务上。
2. 选择页策略
多数用户相对比较排斥改版/重构，会影响他们本身的使用习惯。选择页策略则是在灰度策略之后，给命中灰度策略的用户展示中间页，在中间页给用户说明改版的原因和改版功能点，让用户自主选择体验新版还是回到原版。
3. 沟通策略
沟通是产品经理的强项技能之一，不仅对内对接开发设计测试等，对外对接用户也应该展现很强的沟通能力。
重构/改版一定会遇到用户侧的阻力，改版不当很可能用户就再也不见了。灰度上线后一定要做好用户反馈搜集，可以考虑在新版悬浮一个新版反馈的入口。灰度期间就是不断迭代的过程，将用户反馈的点列表记录，制定解决方案，排定优先级。
重构/改版后有人喷是好事儿，说明还有用户在用，对产品还有期待。真正可怕的是改版后用户一声不吭地直接走了。对于愿意反馈的用户可以考虑联系用户，拉群沟通，没有什么问题是沟通无法解决的，只要把用户真心放在第一位，尊重用户的反馈，改版阻力会大大减少。甚至可以考虑对一些忠实用户做认证标签，比如”热心XX“，这对于忠实用户是一个非常有效的激励。
四、后期跟进
中期灰度发布，逐步迭代完善后趋近于最终的产品形态，接着就可以全量替换上线了。其实到这里产品经理针对这个项目的核心工作基本上已经结束了，但是好产品永远是打磨出来的。
以全量上线的版本为x.0版本，持续关注数据和可优化的点，积攒一段时间后再进行迭代优化。这个时候的产品相对比较稳定，可以使用A/B测试、MVT测试等方法打磨产品。前端对于加载性能优化，后端对于响应速度升级等，都是在迭代过程中可以重点去提升的方面。
大多数情况随着项目结束，产品趋于稳定，同时又有新的项目接手，根本无暇顾及已经全量上线的新版本。
这无关痛痒，但是有心的产品会把自己做的每一个项目做到尽善尽美，将每一个可以优化的点记录下来，在后面当开发有空闲时间时安插需求，当开发看到一个用心做产品的伙伴，不会拒绝的。
