产品迭代什么意思(产品迭代什么意思代的步骤)

编辑导读:重构是一件特别耗费时间和人力的事情,很多公司的业务给人的感觉就是不停在重构。为什么产品会出现重构呢?本文将从原因和重构前的准备两个方面展开分析,希望对你有帮助。

重构,也就是重做。有好多公司好像总是深陷在重构的魔咒中,或者是打算重构,又或者是正在重构。而我也逃不出这个魔咒,消失了一个多月的时间,对一个刚刚起步的产品进行了从头到尾的重构。

下面就来讲讲,通过这次重构,我自己总结到的一些事情。

一、为什么频繁出现重构?

如果你是一个刚入职的产品经理,你也许会抓狂:怎么总会有各种各样要重构的理由?如果你做产品经理有一定的时间了,你也许会隐隐约约觉得,好像每次重构的原因都大同小异。下面我就和大家分析一下,为什么会频繁出现重构?

主要就在于这三个关键原因:

1. 业务发展方向判断不清晰

有些公司在刚成立,或者刚开始启动一条业务线的时候,业务和产品缺乏体系化的规划,为了尽快投入市场,追求快速、简单、高效的落地,经常在收到一个客户需求的时候只是简单判断就开始设计并开发落地。

然而细活要靠慢工出,一味追求速度,没有充足的时间分析和论证,很多决策也许一拍脑袋就做了,缺乏客观性。

诚然,快速高效地做好并交付产品,不仅是解决了当前客户需要解决的问题,也是为了顺应业务将利益放大化,较为灵活。

但是这样做也会有非常明显的坏处。一是交付的产品只能解决客户现有的需求;另外则是限制了你身为产品经理业务能力的提高,因为前期产品设计调研过程如果过于快速,你就缺乏对产品深入的思考,甚至不会考虑产品的未来将要如何发展,长此以往就会造成你在行业上的短视。

而如果为了追求速度,没有在前期做好充足的准备,导致产品缺少足够的可扩展性,当用户需求在未来升级的时候,现在的底层设计就没有办法跟上业务的发展,最终导致重构的出现。

就好比最初的时候,客户找你建一个房子,你经过简单分析,认为小平房可以满足客户现在的需求,于是你只打了一个适合小平房的浅地基。后来客户的需求增大,小平房已经不能满足使用了,要往上盖成摩天大楼,可是你的地基承载不了大楼,那你只能推倒小平房重新打地基了。

尽管我们无法确定未来的业务会有什么样的发展,无法通过解决这个问题完全避免重构,但是我们还是可以在这上面减少一些重构的可能性,而这只需要我们在前期判断业务未来发展的时候,合理增加设计的一部分可拓展性。

举个例子,一个完整的营销活动会涉及商品的选择,参加人员的选择、规则的设置、奖品的设置以及投放渠道的设置。

刚开始为了尽快将活动上线,可能会简化很多流程,采用对用户对开发来说都简单便捷的方法,比如将创建活动页直接集成以上的选择和设置,一步到位创建活动。

但在后来活动场景增加了,也许是商品的选择需要增加规格选择项,也许是投放渠道要增加,也许是参加会员要增加分类,也许是活动规则有变动……

而原本的方案并不支持这些拓展,只好推翻重构解决这些问题,这就产生了巨大的迭代成本。

2. 产品功能设计不合理

产品功能设计有问题,是重构原因中比较多出现的情况。

就比如我们开发一个购物APP的商品列表页,想让不同会员等级的客户在浏览商品列表页的时候,看到对应当前会员等级能享受到的会员价格。

然而为了实现这个功能,我们可能需要请求多个接口,但多个接口参与进来之后,程序运行的工作量就变大了,这样的后果就是页面加载变慢,很大程度上影响了用户体验,即使做了几次优化也没有明显的改善。

虽然我们满足了用户需求,但是却降低了用户体验,这样的产品功能设计是有问题的。

最终为了彻底解决这个问题,我们只能推翻了先前的设计,彻底重构这个部分。

虽然这只是一个页面,但也算一个小重构了。如果在其他更大体量的产品中,那么重构的成本也就增大了。

3. 技术架构有问题

当然了,并不是所有的重构都是产品层面的重构,有相当一部分的重构,其实发生在技术层面,也就是说,在技术架构部分出现了问题。

现有的表结构设计不能承载新的功能,为了满足新的业务场景所以重构;已有的业务代码之间相互作用影响过于紧密,后续迭代成本不断攀升;原有代码某些地方存在缺陷,比如编码不够规范等,需要对代码进行完善;原先的技术方案存在不合理的地方,业务没有进行足够透彻的分析,需要对技术方案进行优化或更换;原有的框架不流行或是出现了严重0day,有新的技术新的框架流行起来,需要将代码进行优化。

总的来说,几乎每家公司都会遇到上面的这三大类问题,而这种问题也不仅仅会出现在产品上,更多时候,它们会存在于管理上。

对于SAAS产品来说,如果在开发设计前没有做好充分的准备,对业务了解不充足,制定的策略不合理,那重构的可能性就极大,重构的代价更是难以预估。因为要做一次全站重构,是一个大体量、高难度、系统化的活。

之所以有些公司有些业务让人感觉一直在重构,很大的原因是因为每次重构完后没过多久又不能满足新的业务需求了,为了发展只能再重构。

但一个不够合理的重构,就是一次大的损失,不仅耗费人力物力,更多的是错过了市场的时间窗口,而这样的错过对公司来说是不小的打击。不合理的重构,后面还需要二次重构、三次重构……有些公司就是在这样无止境的重构中耗死了。

既然重构有这么多坑,那作为重构的掌舵人,如何尽可能的避免这些坑,将全站系统重构规划好呢?

那就要在前期的准备工作中做好充足的市场调研和业务分析了。

二、产品重构前的准备1. 对业务有透彻了解

在重构之前,你一定要先去深入的了解你所做的行业、市场,以及自己公司的业务,对大方向有一个概念。接着要了解准备做的产品,还有竞品的情况。

对这些有充足的了解之后,可以根据下面几个问题思考:

对于当前业务,公司在未来3年会有怎样的发展考量和要求?和竞品相比,产品在哪些功能上存在较大的不足甚至落后?你要给所做的产品打造什么样的未来竞争优势,产品迭代的方向在哪里?

当你得出这几个问题的答案,你也就清楚了你的产品的主要功能和主要流程在将来的一段时间内是否会发生变化,有多大的变化,会怎么变?

这个变化决定了产品的架构,也就从根本上决定了重构的策略。

2. 对客户有深度接触

和客户进行实际接触和深入沟通,并观察客户在工作中的情况,深入了解用户的需求,包括客户对所在行业的看法以及他们自身在未来有什么样的发展计划。

并找出以下问题的答案:

未来3年,什么样的产品更适合客户的自身发展?直至现在,客户遇到了哪些问题影响了产品使用,有哪些问题是现在的产品功能不能满足的?对于其他竞品,客户有没有比较欣赏的觉得非常好的功能?

3. 对底层逻辑有基本的了解对现有的产品设计逻辑有一定的了解;能大概了解技术底层设计;在产品设计方面,产品哪些功能在当前存在严重问题。

尽管我们没有办法完全避免重构的可能性,但我们可以在开发前多思考多做准备多和客户沟通,减少不必要的重构。

而当重构无法避免时,我们也要做好重构前的各项准备,让每一次的重构都是有意义有价值的。

作者:氟西汀,比二会更帅一点的男人,公众号:氟西汀终究还是没了。

本文由 @氟西汀 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议