产品经理说的“迭代”等于推翻重做吗？
这是Kevin的第 869 篇原创，
当一个产品经理加入一个新团队。通常会面临对老版本迭代的问题。新需求从一个按钮入口更改到一个页面的逻辑调整，随着时间推移产品需求变得越来越多和复杂。
迭代是每一个互联网产品必须经历的过程，产品经理通过迭代保证用户体验的同时、还要带来新增长。
曾经在产品经理圈传的比较火热的一张图
图片来自网络
在上图的第二个选项中，不管是滑板、还是自行车，迭代的产品都是可用的。可是一旦控制不好迭代的版本和需求颗粒度，每一次迭代可能就变成了又一次的重构。
产品的迭代，本质都是基于当下的产品做调整。产品随时都能保证用户的实际需求和业务承载。但重构则不同，因为研发周期长，并不需要考虑产品推出给线上用户。
所以产品经理被传言“老喜欢推翻重构”，实际上真的是这样吗？这里我们说下我们走过来的3个案例分享
1.业务的迭代导致产品的重构
在PMTalk产品探索期，我们需求的迭代也代表着业务方向调整。但即使不影响大的业务方向，业务的调整也会导致产品面临重构。
曾经PMTalk产品经理社区在1.0时候，我们探讨了基于LBS的社交方向。在PC端实现附近产品经理查询的需求。我们希望PMTalk能够为产品经理人群为代表的社交需求。虽然社交很难，但我们相信用户是孤独的，需要一款这类产品取解决社交需求。
基于LBS的地图人群查询
可是在LBS需求上线后，由于用户少、停留时间断，社区数据并没有太大的变化，反而因为在web端定位导致的定位不准确以及地图api的联调导致开发花了大部分时间在接口的对接与调试都耽误在这里。
我们不得不放弃了LBS方向，仅因为想调整到社交业务就导致了这次悲剧的重构和资源浪费。
2.推翻重做的迭代可能是最快的
产品经理之所以原因去推荐重构做产品，也可以算一种“自身职业需求”，当接之前的产品到自己手里。不免会受限于前期产品框架的设计，在新需求加入后迭代要注意产品之前的规则、逻辑跳转与全局操作，保持新版本与老版本一致。
既然要考虑如此多的非当前需求的业务，推翻重做可能是最简单的方式。既可以满足眼下最重要的业务需求，也可以满足在产品设计的效率上也是最快的。
同样的问题在开发同学上也非常类似。你可能听过一个开发同学在接收到上个开发同学的项目，如果去看前同事的老代码。同样也会变得疲惫不堪，这时候开发在需求评审下，会评估新需求推行一鼓作气重构开发技术框架也是常有的事。
3.梦寐以求的小步快跑迭代
几乎所有的互联网产品研发团队都希望进入小部快跑，需求不用太大。每次一个星期、或2个星期的需求迭代周期，完成后又进入到下一轮。团队的工作既可以有张有弛，产品也有明显的数据指标提升。
可是要知道这一切都建立在成熟的业务方向，和稳定的版本基础，以及有合适项目管理者前提下。我接触过许多互联网研发团队，有的是2个月、有的1个月、有的可能是3个月才会出现一个版本。这样的项目管理与迭代方式，不仅在试错成本上高，同样团队的工作激情也会被长时间的闭门造成带来消极情绪。
可是假设产品连app都没有，只是有Pc\小程序。对于团队来说，用小步快跑的方式反而会导致降低研发效率。
PMTalk是严格意义上的阿米巴团队管理，一个团队的匹配会尽可能的精益求精，比如前台、后台的人数通常是2：1。团队不会超过10个产品研发人数。所以给研发更多的时间在撸代码上，比如在一个月版本、半个月的版本计划。
小步快跑的迭代，在多经历几个版本后才可能等于一个产品重构。这样的方式显然也是最节约成本的，避免了重构的资源浪费。
由此可见，迭代的最后都会造成版本的重构。只是迭代的版本周期，所以我们才会有版本号按照下面的方式逐渐过渡。
今日Bonus：加我好友 pmkevin001，领取直播原型部件库，同时还有运营模版，带你了解快速提升产品运营进阶
每天体验1款app知识星球
我创建了一个《每天体验1款app》知识星球，有超过20个行业嘉宾在圈子里。加入后365天，每天体验一款APP。提升产品设计能力，同时有1500份体验报告帮助你找到竞品。
平均1天1块钱，扫码购买即可加入
连续体验90款应用，通过后原路退回