北京中医治白癜风医院 https://jbk.familydoctor.com.cn/bjbdfyy_ks4606近半年多以来一直在做重构的项目，从运营后台重构，到中台passport重构，最后换了家公司继续做纯C端的前台页面重构。踩过很多很多坑，积攒了挺多经验，总结出来准备产出一篇文章。
主要总结重构项目的前期准备，前期准备工作是产品经理应该投入时间最多的阶段，包括了需求调研、数据分析、老系统/老版本逻辑梳理、重构版本逻辑定义等等。甚至前期准备工作决定了重构项目的质量以及重构后的用户满意度，本文将各种场景下重构项目必不可少的准备工作抽象出来，以实例进行拆解。
文章较长，其实浓缩出来也就一张图，下面所有内容都是对这张图的注释：
一、评估重构价值
关于重构项目，本人有一个核心观念：重构项目一定是在填历史遗留的坑。当老板发现系统不足以支撑业务发展，或者严重阻碍业务发展时，“重构”的需求就开始从中高层酝酿起来。
比如之前规划后台时没有一个好的架构师，没有预想到后面的业务发展和业务形态变化，十几个运营后台堆起来，运营操作一个流程需要频繁切换多个后台才能完成，这时候运营的老大会喷设计这些乱七八糟后台的人，同时也会提出“统一运营后台”的需求，具体需求为：“所有运营操作集成到一个后台，流程能简化的全部简化。”
需求就这么一句话，拆解起来就得看具体有多少后台了（产品背锅原因之一：业务侧需求不明确，一句话需求）。如果说只有三五个分别控制不同模块的后台，并且不太复杂，建议不要重构，而是应该在做第六个后台时候考虑到后面的业务发展场景，做一个高扩展性的后台，然后再陆续将前五个容纳到这个后台来。如果有十几个后台，并且其中耦合了大量的交叉逻辑，那么只有重构一条路可走。
（产品也不易，背锅且珍惜）
“重构”需求大多是自上而下的需求，管理层出于对各种原因的考虑，提出重构的需求。作为基层产品经理，需要有自己的判断，到底是“重构”更好还是“优化”更佳。
评估重构价值需要先明确重构的原因，一般而言重构只有以下四类原因：
用户变了：之前产品的用户画像与现在的用户画像发生了较大的变化，用户属性也发生了改变，新用户不断涌入，老用户流失严重。这种场景下领导层可能会放弃部分老用户，专耕新用户，针对新用户属性进行重构/大改版的产品设计。需求变了：一般内部系统的重构都归结于此原因，之前需求都实现了，只是扩展性不够，考虑的场景不够多，现在用起来非常不方便，阻碍了业务发展，因此需求从原来的“可用”升级到“便捷地用”。目标变了：不同产品在不同阶段有不同目标，产品生命周期更迭中自然伴随着目标的变化，可能前期主要提升用户体验，做大流量，中期又以变现为目标，后期开始做留存和老用户召回，或者做品牌升级。往往在产品生命周期后期容易出现重构的需求，试图用重构版本赋予产品新的生命周期。环境变了：这个环境包括技术环境和市场环境。技术革新带来新的想象空间，迫切期望使用新技术打造新产品来冲击市场。市场之前青睐的某种产品形态，现在已经落伍了，需要重新定位产品来跟上时代的步伐。这两种场景下的重构需求往往需要谨慎，到底是“重构”还是“新做”一个产品？还有一种常见的原因：年久失修。不管用户还在不在，领导层决心再捡起来做的话，老代码老逻辑的维护成本远高于重构一番。此时请一定好好善待那些不离不弃的老用户，他们很可能因为重构没有契合他们的习惯就走掉了，临走前还要喷你一顿：“改的什么玩意儿！”。
(改版后的B站-UI布局整体调整)
根据重构原因，评估重构能够带来的价值，同时评估正常迭代能带来的价值，当“重构价值迭代价值”时，“重构”需求才能接手，否则可能就是“瞎重构”，或者重构完了也没人愿意用。
那么如何评估重构价值？
这是一个需要量化的多维度指标，可能是节省了运营多少人天的工时，可能是提升了用户留存，可能是提高了某个核心指标等等。在这些重构带来好处的维度指标中，选择最为核心的一点或者亮点，作为重构的核心目标。
例如统一运营后台，核心目标就是节省运营工时；统一中台化服务，就是节省前台开发工时；C端产品重构，就是为了拉升某个核心指标。
二、重构前期准备
作为产品经理，在做“重构”项目时，其实最重要的就两个词：梳理和定义，梳理旧的逻辑，定义新的逻辑。无论是后台、中台还是前台相关的重构，基本上大同小异，都可以按照下面的方法去操作。
其中，后台和中台大多数还是给公司内部人使用，重构得不是很好还有机会继续迭代优化，而前台ToC的产品重构，做得不好可能就得承担用户血喷甚至流失的压力，同时前台的重构一定会涉及到后台或中台的调整。因此，本文以重构压力和产品发挥空间最大的ToC前台为例进行说明。
产品确定要进行重构之后，立即新建两个文档，一个调研文档，用来辅助产品设计，一个需求文档，逐渐更新为最终输出的PRD。同时，需要督促开发也新建技术文档，对核心重构内容进行技术调研，对于初步明确的大方向提前做好技术准备，减少开发说“这个实现不了”的概率。
调研文档必须包含的六个版块：旧版拆解、数据分析、用户画像、竞品分析、需求池、重构目标。六块少了任何一部分，我认为都会对产品方案的制定产生影响，也会对最终的重构效果产生影响。
1.旧版拆解
无论旧版是不是你做的，只要是重构，一定要详细拆解旧版，拆得越细越好。一般重构项目，可参考的历史文档都非常有限，即使有文档也最好自己亲自细细体验。拆解旧版最终要产出的四个东西：页面结构图、前台与中后台交互的流程图、交互说明文档（关系到后面的继承性产品设计）和特殊处理说明。
页面结构图并不难，属于产品基本功，列出结构才能明确重构范围具体到哪些页面和哪些细小的点，颗粒度越细越好。信息交互的流程图是拆解的核心，产品的功力体现在这一步。理想的产出流程图需覆盖用户操作行为的每一步请求与中后台的信息交互，这需要产品知道目前老版页面所调的所有接口、调用顺序、接口限制条件（能有接口文档最佳）等等。这里最好找个后端开发协助一起，理清了所有的接口才能确定哪些接口复用，哪些需要改造，后续产品方案需要新增哪些接口，后端开发也能更加清晰评估自己的开发量和开发难度。交互说明文档：常听到的“反人类的设计”基本都是骂交互，重构项目的旧版拆解中，需要记录旧版核心流程上的所有交互操作，比如提交按钮、翻页器、提示框、无限加载、手势动作、隐藏和露出等。在之后的数据分析中来决断哪些交互行为一定要保留或者只能微调，因为这些强用户习惯的操作一时间很难改变，只能在后续的迭代中陆续微调。比如：习惯了手指左滑翻页，或者翻页器翻页，改版成上滑无限加载，绝对找喷。特殊处理说明：旧版的特殊处理不一定完全能拆解出来，因为有的特殊处理很难看出来。这些特殊处理都是代码写死的逻辑，最好能分析出为什么做特殊处理，不是懒就是有特殊的限制原因，提醒你这里有坑需谨慎，重构版本就尽量减少特殊处理的逻辑。
（虎扑M站改版前后对比）
2.数据分析
曾经一位开发对我提的老版本加上埋点的需求不以为然，认为都要重构的东西了，没必要在老版本上面加埋点。我列了三条理由说服了开发加埋点：
改版效果需要用数据说话，新版本会加埋点，会有数据，但是老版本没有，那么核心的数据指标无法对比，也就无法衡量改版是否成功；我对ABC功能点存在一些想法，想直接砍掉其中某些功能，或者对一些功能做一个较为大的改动，想要了解老版本这个功能点目前的用户使用情况，如果很少人用，直接砍掉，新版你们开发也省事儿（说话的时候也要站在开发的角度思考）；我们的用户长什么样我们现在都不清楚，不加埋点来看的话，改版就是“瞎撞”。我需要知道较为清晰的用户画像，至少知道谁在用我们产品，才好制定合理的产品方案，才不会给你们开发提傻X需求，每个需求点都有理有据。用实例进一步解释这三条理由，假如知乎文章发布页重构，首先确定一个核心数据指标，假定为发布成功率。那么需要知道老版本的这个数据是多少，重构版本与此对比来看改版效果（这里还需要限制约束条件：在发帖页平均UV波动不超过5%的前提下）。
其次，分析功能点，假如数据分析发现用户在上传视频的时候有5%的概率的失败，失败后又重新传，那么新版断点续传的功能优先级很高，同时进一步分析失败原因，新版要大幅降低这个值。
3.用户画像
用户画像简单说就是给用户打标签，用户是男是女，喜欢什么东西，什么时候活跃，活跃时候都看了些什么。无论是在做什么项目，了解用户画像都很有必要。可能在重构项目期间，产品经理不清楚用户画像也能很好地完成重构项目，但是了解用户画像的产品经理思考的深度和视野的广度都远甚于前者，换句话说：了解用户画像能让产品经理逼格上升一个档次。
曾经有一位前辈看过我写的需求文档之后，给我提出了一些指导建议，其中有一条是：“可以在需求文档或者其他地方专门写一个部分——帮助运营做得更好”。
前辈的意思是产品在进行方案设计时候，也应该站在运营的角度去思考，如何能够帮助运营更好地开展工作或者提高效率。随着经验的积累和阅历的增长，发现不仅是站在运营的角度，还需要站在更多人的角度以及更高层次的视野去看待产品设计。
这里的提升就不得不清晰地了解用户画像，因为用户画像主要功能有四个：精准营销、广告投放、个性化推荐、辅助产品设计。在做产品设计的时候，如果能将前面三者都思考在内，虽然做出来的东西可能差别不大，但是境界和视野的差距可见一斑。
将用户画像运用得最好的一个产品我认为是虎扑，用户画像非常清晰：20-35岁的男性，以大学生和上班族为主，喜欢篮球，热爱运动，喜欢以实力论英雄。这样的用户被定义为“直男”。围绕“直男”做球鞋球衣广告投放、做吴亦凡/蔡徐坤相关内容营销、推荐评分投票帖等。虎扑的产品体验并不算好，但是围绕“直男”的运营做得在国内确实无出其右。
（知乎的用户画像-来自：
