为什么每个产品总是被重构?

Kevin改变世界的点滴

共 1863字,需浏览 4分钟

 ·

2021-06-10 19:49





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

重构指的是对现有的产品或技术方案推翻,重新从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
浏览 59
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报