为什么每个产品总是被重构？-技术圈

做过产品研发的同学应该接触一个关键词：重构

重构指的是对现有的产品或技术方案推翻，重新从0到1做。

重构主要分为两类，第一个是技术重构、第二个是产品重构；

技术重构对于用户的影响几乎为0 ，由于没有界面的变化，但却大大减少了开发成本；

产品重构则有点像从0到1新做一个产品，用户的感足非常强；今天要谈的重构主要以技术重构为主。

重构也是产品从1到10的必经之路；但在什么时候发生重构、以及重构理由那每个团队都不同。

主要集中在提升开发效能、减少资源浪费、增强用户体验3个纬度上

发生重构前产品仍然是可以用户的，只是随着代码堆积、历史原因导致了新需求产生了技术瓶颈；也有是因为产品被收购了，需要和母公司进行数据流通，同样会要求投入大换血进行改造。

一个互联网产品重构的过程中同样也会伴随着一些新需求，但都是基于已有的功能做优化；比如文案的调整、或按钮逻辑调整；页面路径设计；

▲ 虎扑的商品分类重构

但整体的主要产品功能架构是不会变的。

PMTalk的2次重构

第一次重构：从开源系统选择自研过渡

主要是去解决开源系统带来的维护成本问题；市面上有很多开源的社区系统，为了满足快速上线，很多创业团队会和我们一样在早期选择开源系统；抛开商业授权等问题，但开源系统是难以做迭代和升级的，同时维护成本极高；

而我们当时的重构有2个方案：

方案1:重启一个项目全部把现有的功能和内容重新写；

方案2:为了不影响社区下线，选择部分重要功能进行重构，不重要的等有时间再做。

在有限的人力和时间下，为了保持用户体验尽可能保持一致，只能选择了方案2。

第二次重构：更换前端框架，从JS到react

在第一次重构上，我们为了兼容开源系统。在自研新写的页面选择的框架是和开源系统一样的；但这前端框架上是非常老的；老的前端框架在渲染、加载能力都不够；同时也会带来未来诸多的维护和功能升级问题。

这次的重构，希望选择前沿的框架，降低未来的开发成本，同时增加用户体验。由于已经上线的页面较多，同时业务和新需求不断，我们也只能和第一次重构一样，选择伴随着新功能上线覆盖老页面,一步一步切换。

什么时候才重构？

1.稳定的业务形成

重构的启动一定要选择在没有新功能的场景，产品已经处于稳定生命周期。最好业务没有变、也没用新功能，此时的重构效益才最大。

前面技术重构主要是解决产品的代码维护成本。因为随开发时间的累积、不同开发的同学编写的习惯是不一样的。未来每次的新功能、新页面撰写，所维护成本也越来越大。

2.维护成本太高

同样因为在早期都会想着怎么快怎么来，对于技术方案的设计实际上就没有花时间。落下了开发技术、开发环境在前期没有思考好，后期随着版本的发布，加载速度越来越慢，用户的体验也越来越差。

所以满足以上2个条件，就可以思考重构了。

重构对产品经理要做什么

在重构阶段，不管是产品架构重构、还是技术重构，产品经理还是有很多工作可以做的。最基础的就是在功能不变的情况下更改前端的交互、路径、甚至是某些逻辑。

我们叫做功能优化。

尤其是在重构阶段，产品经理应该聚焦在功能优化上，而不是功能的新增；比如搜索功能对结果新增类型；和重新做一个搜索功能就是2个层面的事情。

前者的开发成本更低、同时实现简单、但能够达到更好的体验效果。

理解重构后的未来

前面我提到，要重构首先要基于稳定的产品结构、业务性质上。重构的时间随着开发成本和时间，如果只有app、小程序、web在没有复杂的功能设计下，4-6个月的时间是重构的基础。

也就是说在未来半年下，业务到底会如何变化、产品需不需要开发新功能、以及当前有没有重要支持的业务，都是产品经理要考虑甚至是花时间调研。

有资源的团队会投入部分资源在重构、还有一部分投入在维护现有系统上。但绝大多数的开发团队还是全部投入在新产品的重构上。

所以如果你的产品没有跑出一个固定盈利模式、或持续增长的版块，一定不要重构。

哪怕开发起来多么痛苦，但也比重构快，快速验证不断加速跑步。什么技术架构、微服务都不需要考虑，你需要做的就是如何做到产品最好

今天的分享就在这。

今日Bonus：加我好友 pmkevin001，领取直播原型部件库，同时还有运营模版，带你了解快速提升产品运营进阶

👇点击阅读原文，加入打卡训练营，每天体验1款APP