坦白来说，能够正儿八经对产品进行复盘的机会其实很难得。

熟悉我的朋友应该都知道，这两年对见字如面的更新频率总是没有以往频繁了，其实核心的原因我目前在一家 toB 行业的小程序平台里当产品负责人，平常工作里需要关注的事情太多了（又一次跳入了创业公司的深坑），精力和时间有限。前两天和一个朋友打电话，他说“你的博客最近不更新了有点可惜”，仔细想了想还是得保持正常的更新，所以咱们就继续聊聊工作中相关的感悟吧。

这次我想咱们可以聊聊，作为产品经理的角色，如何发起并且支撑产品的重构直至顺利结束。

对于大多数从事产品岗位的朋友来说，“重构”这个词其实是比较模糊又熟悉的。很多产品同行都觉得自己大大小小都参与过几次“产品重构”，但归属于自己的实际工作好像就是改改原型，设计新的交互样式搞个新的产品版本（所谓的大版本更新），作为项目经理推动一下进度开开会，除此以外更多的“重构内容”都属于研发角度对于服务或者架构角度的重构，虽然确实提升了研发的效率和架构的合理性，但是自己没啥深度的参与。

刚好我所在这家公司的产品在前期的设计确实还存在蛮多问题，所以从 2022 年的年终我们就开始讨论产品重构这件事，但由于真刀真枪的产品重构需要花费的成本实在太大，所以我们其实花了大概一年半的时间陆陆续续准备其中的工作，并在 2024 年的年中正式完成了产品重构，产品顺利发布上线（这里是我在产品博客里的 PR）。

选择合适的重构时机

不论从什么时候开始，“现在是重构的最佳时机吗？”，“重构之前需要做哪些必须的事情？”，“如何保障重构工作顺利完成？”都应该是大家都会关注的问题，有人会觉得这些都是“重构工作的道法术”，我倒是觉得咱们可以逐个拆解，一一探讨出这些问题的答案。

先从实际问题出发，不要轻易重构

“不要为了重构而重构”应该是最核心的道理，虽然确实可能是因为客户或者老板的一句吐槽与抱怨，我们就开始镀金找理由，然后把重构作为某个季度或者年度的目标来计划落地，但作为一名成熟的产品经理，我们还是要明白“任何重构都存在风险与成本”，“重构必须要带来如期的收益”这两个核心原则。

不论公司规模大小，所能够调用的产研资源都是有限的，也就是说当我们在考虑是否要重构的时候，务必要提前想清楚“有一段时间是无法上线新需求”的，如果确认要重构，那这个重构的时间必须要选在产品总体比较稳定，业务流程和用户流程都总体稳定的时候，避免因为重构中的投入成本又无法响应客户与市场的需求。

圆规正传（言归正传），我负责的 FinClip 其实是一款面向 B 端的私有化小程序生态平台（简单来说就是做了一个可以私有化的微信小程序），用户可以基于这一套产品打造自己的小程序生态，我们的产品之所以要重构，主要有三方面的原因：

第一，产品的基础架构设计混乱失序

我们的产品自从 2019 发展到现在也有三四年的时间了，但实际上产品的诞生其实是源自另一个产品的配套服务。即使上线起初计划使用 MVP 的形式不断优化，但也并没有建立起团队内部统一的思维框架与产品共识。

也许是出自快速交付客户或者向上管理的什么原因，即使是可以抽象为近似场景的功能点，在以往也都交由完全没有共识的不同同事独立交付，交付过程中又缺少统一的同步与复盘，其实都在不断的证明“做产品真的需要具备长期主义”，缺少延展性但又频繁救火的产品其实还是在不断的骗自己。

但说实话，我觉得这个问题出现在 toB 的产品里又有点合理，从根源上来说，toB 产品相比 toC 产品欠缺的就是“数据反馈感”。愿意在 toB 产品中埋点统计的人少之又少，具备数据分析意识的人也少之又少。

大多数 toB 产品同事们的习惯还是通过主观判断来决策，通过客户与自我说服中的“我认为这里应该 XXX”，“这里就是需要 YYY”来设计对应的功能，但如果缺少足够的“产品 sense”，非常有可能把产品变成一个缝合怪，乍一看该有的功能都有，但仔细看会发现产品架构越发混乱，功能散落没有联系，缺少必备的需求文档与判断依据无法复盘或者溯源设计背景。

到了一定的时间，还很容易发现产品无法自圆其说，用户的理解成本不断上涨。这也变相导致前端市场侧的同事在销售推介产品时遇到的问题变多，无法保证产品的销售转化持续增长。

第二，产品的能力无法支持用户深入使用

随着客户不断增长，我们也发现了越来越多在早期产品定义时不合理的设计，物是人非在这个时候找寻原因已经变得毫无意义，但基于用户的真实场景来回顾用户的使用流程，对不同功能与字段进行抽象，梳理出正确且合理的产品模型则变得十分重要。

缺少了抽象后的领域模型，不仅会导致在用户侧实际的交互与体验一言难尽，还会导致冗余的代码不断增长，修复的补丁无穷无尽，产品后续的拓展性与连接性几乎为零。比如希望在产品中集成跨系统的连接与认证，就必须要在产品设计早期设计好对应的账户体系，而不是等到需要用的时候再去改线上的逻辑。

0-1 阶段的产品为了快速验证商业价值，可以用 CURD 来满足尽快上线的原则，但 1-10 阶段的产品如果还是在重复 CURD，不对具有共性的需求进行抽象实现，就很容易建立出来一个“摩天大楼般的违建房”，在一个潦草设计的地基上不断缝缝补补只能治标不治本。

作为产品设计者的角色，核心的工作都应该是在仔细思考后，得出“多做一件 X，可以少做 N 件 Y 的需求”的结论，也就是我们说了很多次的“抽象”。以为通过自己或团队的效率来快速响应客户的意见，快速上线 N 个需求更像是用“战术上的勤奋掩盖战略上的懒惰”，从始至终都被客户牵着鼻子走，团队中的每个角色都不会太好受（但……这件事对于响应客户的当事人来说，又很容易收获来自客户的认可与赞扬，又便于自我镀金或者在团队内向上管理，有一点难评）。

第三，产品缺少能够匹配产品特性的设计

不管是什么行业的产品，在交互与界面上都应该是能够“自圆其说”的。不需要投入过多精力与引导，用户自己就能使用并且发现所有需要的能力。如果想在产品中证明它具有的“生态与运营”能力，就更需要通过合理的规范设计证明产品的价值。

当然，设计工作其实也得找到合适的分寸，既不能“设计不足”也不能“过度设计”。设计不足往往意味着在产品早期就缺少必要的抽象和前瞻思考，导致产品上线后存在天生的缺陷（在一些不重视产品岗位的公司时有发生），而过度设计则意味着偏离了实际的用户需求，在产品非核心的边界不断雕花（在一些过度追求 设计的公司时有发生）。

在做产品设计时，我觉得称职的产品经理都需要始终关注“成本与收益”的平衡点，我们更愿意通过设计来简化复杂的实现层面的问题，而不是为了解决复杂的实现问题，引入了一个更复杂的设计方案。

不管怎么说，合格的产品设计工作都需要通过持续的学习与经历来不断提升，并不能通过“按照大厂或市面上其他产品的样子借鉴抄袭”来走捷径。业界中始终有一种“大厂做的肯定是深思熟虑的结果，借鉴他们的准没错”，但完全不考虑不同体量的团队所需要投入的成本，也不愿意投入足够的思考与分析成本，这一点其实有些不作为了。

为了解决上述三个问题，随后我们的产品团队花费了大约 2 个季度的时间来厘清其中的逻辑（也不是一帆风顺，厘清逻辑本身其实还是在解决一些历史债，其中的挑战一度高到有部分团队同学产生“要不别重构了？又不是不能用”的想法）。在分别整理出了产品核心部分的域模型，用户流转模型，状态机，不同功能的关系图，行业现状与竞品的分析对比等各类资料。

友军说明：上述三个问题已经得到了产品和研发团队的一致共识，且得到了老板的认可和授权，由于老板的架构师角色出身，从产品底层设计的角度也向团队提出了很多挑战，不过好在最后重构工作能够顺利开展。

只有在前期做好充足的准备，才能为后续的投入带来最有性价比的准备，即不浪费投入的成本，又保证重构过程中的团队成员目标一致，也避免后续沦落到“为了重构而重构的沼泽中”去。

明确合理的交付目标节奏

随后我们需要关注的，则是确认产品重构到怎样的状态就可以推进上线与交付，并且在过程中及时控制投入的成本。不然漫无边际的“重构”迟早会耗光公司的耐心与愿意投入的资源。

从这个角度来复盘，我觉得其实这次的重构过程中，这一点做的并不是太好。尽管有外部客户定制需求打断，重构人手不足，管理层与资方中途因为投入成本开始犹豫等各种或客观或主管的原因，但随着项目重构的时间不断加长，明显会发现参与重构的同事都开始失去信心。与我而言，问题的核心还是在最开始没有建立出明确的交付目标。

说到如何管理项目与明确目标，可能大多数人都会提到“SMART 原则”，其中分别通过 Specific（具体的）、‌Measurable（可衡量的）、‌Achievable（可实现的）、‌Relevant（相关的）和‌ Time-bound（有时限的）来约束双方达成共识。在这次的重构过程中，我觉得没有做好的地方在于—— Measurable（可衡量）与Time-bound（有时限）。

虽然在重构初期我们就明确了这次的重构目标，但从事后的角度也不难看出，这三点问题（即前文提出的“产品的基础架构设计混乱失序”，“产品的能力无法支持用户深入使用”，“产品缺少能够匹配产品特性的设计”）其实难以作为重构的验收结果。到底做到什么样的结果才算是彻底解决了问题？实现哪些待办项才能够算作是“架构合理了，用户可深入使用了，设计匹配产品特性”了？更别提大家既要满足客户在线上版本中的支持与响应，又要抽时间不断推进产品重构的进度，重构的时限只有被一次又一次的延长。

仔细想来，衡量这些难以量化的目标还是应该通过具体的事件或者时间节点进行切割，在已有的敏捷迭代中通过更细致的时间安排，设计每一个迭代中的具体任务（“能做多少做多少”的思路在迭代中过于务虚无法落地），通过提前设计安排的阶段进度来约束重构进度整体可控，保证对应的功能与设计能够分阶段上线验证就显得更重要了。

重构重心的角色转变

在产品角色陆陆续续完成前期的工作之后，重构工作的重心就会从“定义梳理定义”逐步转变为“设计稿确认”，“开发测试”了。由于前期的准备工作总体比较扎实，在产品定义部分并没有什么需要反复确认的部分。但依然需要产品经理能够在这个阶段与研发同事多沟通，尽力保证研发能够充分了解业务角度的设计，避免因为业务了解不充分，而导致的问题。

但我还是建议产品经理能够参与到研发的重构过程中，研发同事的相关分析与会议之中，不说能够短时间内了解一些技术层面的方案，但至少能够对重构过程中一些比如“抽象”，“解耦”的逻辑有一定的了解。

举个简单的例子，大多数人都听说过“微服务”这个概念，但是这样做的目标到底是什么，能够带来哪些价值，拆分为服务之后如何确认每一个服务之间的依赖强弱关系，其实都是需要研发同事们仔细考量的。同理，我们在听到性能需要优化时，大家的第一反应可能都是把数据放在缓存里，虽然说效果确实立竿见影，但我个人觉得也不应该“万物都可加在内存中”，有一点算是走捷径的方法了（本段纯作为非技术人士的发言，不一定对，欢迎拍砖）。

产品发布后的持续关注

随着开发提测节奏越来越快，选择合适的时机将产品发布上线就变得重要了起来，我们不可避免的希望伴随重构后的产品上线，用户也能够自发且主动的切换到新的版本之中，但实际上这里还是不可太过武断，需要从尊重用户的角度来陆续推进新产品上线。

新老产品的数据迁移

首先，我们需要关注的就是新老产品之间数据的平滑迁移，保证能够在客户无感知的情况下将用户和数据内容全部都过渡到新的系统中，并且设计好对应的迁移策略和规范来约束迁移过程中的相关准备工作。

由于产品重构的原因，肯定会存在一些数据表映射与修改的问题，一般来说数据迁移会有一个最大化和最小化的原则，前者是指“新产品要考虑能够完全替代旧产品，保证用户所有已有的数据在新产品中都能够查到”，后者则是指“只需要迁移客户能够真实看的到的数据，避免因为完全同步占用的巨量资源和成本”。

随着用户和数据都迁移到新的产品之中，老的产品也不需要立刻下线，至少需要待机一段时间，避免因为线上问题的忽然出现而影响用户的信心。总之，在数据迁移的这个过程中，产品也需要和研发同事紧密配合，避免出错。

新产品的发布上线

在这里 toB 和 toC 的产品会有些许的区别，比如在 toC 的产品之中，一般会使用定量定性的灰度，或者人工增加过渡选择页等尽可能符合用户预期的方式，引导用户切换至新版本的产品之中。并且通过产品上线初期频繁的用户沟通了解分析来自用户的喜好评判与使用反馈，并在上线后的短期内快速优化对产品的反馈与建议问题。

但是在 toB 的产品中，可能更多会通过“站内信”，“短信通知”类似的批量消息触达机制，快速告知用户系统升级的时间，以及对于用户的潜在影响。不过不论是哪个领域，关注用户体验提供无摩擦的用户使用交互都是行业的大趋势，毕竟即使是再关注效率和质量的 toB 产品，背后的用户始终是一个个活生生的个体，行业早期的“toC 的产品经理更需要具备洞察力，toC 的产品更关注用户体验，”的想法应该是被摒弃的认知了（难道 toB 就不需要洞察力不关注用户体验吗）。

我个人觉得在这一个过程中，最需要注意的就是“兼听则明”，虽然说老系统更改到新系统总体是解决了很多问题，能够让人眼前一亮的，但在新系统刚上线的初始，也确实是系统最容易暴露问题的阶段。在这一个阶段中必须要沉着冷静，不仅能够接受产品上线过程中任何“预期之外”的问题，也需要能够引导团队耐心且冷静的修复相关的问题。

新版本上线后不论用户是表达满意还是意见其实都是好事，本质上这还是代表用户依然在使用产品，对产品有更好用的期待，作为背后的产品经理其实最担心的应该就是“用户并不在乎任何改版，从内心深处就确认了产品经理不会聆听他们的声音，对他们的想法没有好奇心”。在我从业的这些年也用过各种联系用户和他们交朋友的方法，只要愿意静下心来和用户沟通，似乎没有什么问题是不能解决的。

当然，即使产品上线一段时间后，对应的产品经理也依然需要持续关注使用情况和相关数据，在迭代中逐步安排后续的优化调优事项，逐步提升用户的使用体验，尽量保证产品使用过程中的稳定与质量始终在线。

不仅仅是与用户做朋友，也需要与研发做朋友，只要原因用真心做产品，总是在做正确的事情吧。