编辑导语：产品重构是一件特别耗费时间和人力的事情，为什么产品会出现重构呢？产品经理应该如何做好产品重构的任务？本文将从原因和重构前的准备工作两个方面展开分析，对产品重构的具体步骤进行了梳理，希望对你有帮助。

最近接到一个任务，需要重构后台某管理模块。重构，开发听了头痛，测试听了难过，产品听了流泪。但先不要戏精，先刨析需求。

一、重构是对旧产物的一次重要改革升级

（1）不是随便一个任务，都能叫重构

之所以要重构，必然是落后的产品设计已经不满足当前日益增长的产品需求，同时可能影响到当前的使用稳定。重构也是对败絮其中的一次反思，在不影响当前产品能力的情况下，对产品进行重新思考并优化设计。重构同样也可对原先设计缺陷进行完善补充，让功能体验更加完整。

（2）重构需要根据实际情况决定其程度

开发常见的重构基本是代码重构，比如优化代码性能，提高代码健壮性等，而产品的重构则等同于重做。最惨烈的无非是从产品底层由下至上开始重构，不过这种尤为罕见。一般情况下主要针对产品的信息结构层和功能模块层进行重构，可能是由于产品早期规划不够长远，随着产品不断迭代升级，导致产品使用起来信息过载或者功能混乱。

（3）重构的时机同样需要天时地利人和

对曾经走过的路再走一遍，现实中叫浪漫，研发中叫成本。很多时候需要先解决从0到1的问题，再考虑其他天长地久日久生情，用最小成本尝试，然后再根据业务发展情况进行产品周期迭代，敏捷开发精义首先就是要快。用唯快不破的速度争取机会，用日益增长的趋势换取信任，才能赢得一点点重构的时间。

二、针对产品重构任务的准备工作

所以判断任务目的，分析利害程度，评估可用时间，是拆解重构需求的基本反应。

果不其然，打开产品管理模块的信息详情页，各种信息五花八门，一头雾水。此次重构应该是因为页面的信息组织和展示出了问题，即针对产品信息结构层的优化。所以先提前给前端开发小哥哥准备好纸巾。

页面是信息的载体，目前我面临的问题如下：

1. 信息较为繁杂，不利于获取目标信息
2. 存在部分高风险配置，会直接影响线上用户
3. 存在多个易混淆的权限开关
4. 各种不明所以的参数

这可能就是古老传说的一种产品设计，叫做专为功能服务的设计。目的就是只满足功能和当事者的需求，不考虑其他使用者的感受。

追溯其历史原因，可以总结如下：

1. 汇集多个产品模块信息，当初没有做好模块划分
2. 因部分需求需要新增参数信息，直接随意插入，且没有任何提示说明
3. 敏捷开发太敏捷，没有留下产品文档

遇事不乱，先谈几段，无非破案。重构的需求不可能平白无故产生，本次案件不抓嫌疑人，不追究罪证，只找核心受害者和关键证人，细探解决案件的蛛丝马迹。

通过紧密的取证，该任务需要解决的难点如下：

1. 涉及到后端接口特别多且复杂，需要安全平移迭代。
2. 部分业务权限管理没有形成闭环，需要收集整理并且补充前端设计。
3. 高风险操作易如反掌，需要针对信息权限以及操作进行规范
4. 部分知情人士已不在，需要协调各方查验

水之呼吸，在问题与原因的空隙间，找到致胜的那条紧绷的关键线：信息所属模块？信息作用？信息展示？

逐一击破即可。

三、信息重构的解析刀法