如何做产品迭代的节奏大师

“迭代怎么又延期了？”

“需求池的需求越来越多，什么时候能处理完啊？”

“开发一个小需求能出这么多问题，也是醉了！”

“每次开发过程中，总会有各种各样的需求插入，这怎么可能不延期？”

……

上述问题是否你也在年少时抱怨过，或者身边有人这样抱怨过？

产品迭代始于产品计划，但多数情况下变化要比计划快，造成延期，甚至多数产品人都遇到过这种场景。那么怎样让我们的迭代保持长期健康、稳定呢？

这就需要我们培养一项专业能力：培养自己产品迭代的节奏感。感知变化、迎接变化、将变化作为我们新的计划，做产品迭代的节奏大师。

一、正常迭代节奏特征

产品迭代的“节奏大师”，往往会让迭代有如下特征：

1）长期健康、稳定、时间可控

2）是对相关渠道来的反馈的解决

3）每次迭代的结果都要比上一次要更好、更接近目标

了解完成必备特征后，接下来重点讲一下如何控制迭代节奏，减少迭代错乱、延期问题的产生。

二、严格控制输入节奏

下图是2个小孩子在玩游戏机，我们可以看到要想完成一个游戏，需要有手柄（输入）、处理器（处理过程）、显示器（输出），三者缺一不可。类比产品迭代，迭代完成一个版本就相当于是输出，而开发的过程就相当于处理器，而迭代的周期制定和需求的管理是我们的输入。输入间接决定输出的质量，所以严格控制产品迭代的输入，把好第一道关卡。

版本迭代的输入目前主要来源于三个方面：迭代周期的确定、需求池需求的控制、插入需求的处理。

2.1 迭代周期的确定

依据笔者的经验来看，做到以下三条最好：

1）迭代版本选择合适的固定周期

迭代版本一般需要固定周期，固定周期能够养成合理的迭代习惯，开发工作量稳定，不会存在过度饱和与工作量不饱和的情况。

2）迭代版本周期不宜过长（3周及以上）

笔者公司有的产品线一个月评审一次需求，每次接近20个较大需求，评审时间1天半；这就造成了开发过程中重要点的遗漏，以及逻辑的重新梳理，浪费很多时间，使得不得已而延期。

3）版本周期不宜过短（1周及以下，MVP产品例外）

一周以下的迭代版本最怕遇到产品经理本周紧急事项处理，耽误了下版本需求的整理，从而使得下版本需求不饱和，造成开发工作量的降低。

最好周期是2周，使产品经理能够合理调节时间，既可以处理需求，同时也可更详细了解需求背景，过程中也可以解决较紧急事务。

2.2 需求池需求的控制

需求池的控制主要体现在以下几个方面：

1）产品经理要做“需求池”，而不是“叠加池”

不要将用户、业务部门、管理者以及数据分析得来的需求直接放入需求池中，要根据公司情况经过某些层次的筛选才可进入需求池，比如：与产品模式相违背的一定需要抛离出去。

2）需求池量化评分确定优先级

需求少可以直接四象限进行分类确定；需求较多时需要进行量化评分，建立量化模型（可参考系列第一篇文章《如何创建需求池》），将优先级从高到低纳入版本。

3）“化整为零” && “化零为整”

学会重大版本的需求拆解与小需求的版本组合（用于优先级评分较低，但是和本次优先级较高需求关联性比较大的时候，可以通过组合一起迭代）。

2.3 插入需求的处理

笔者这边的插入需求一般来源于老板、业务部门、业务系统产品、使用用户；对于业务部门、业务系统产品、使用用户的需求可以直接通过需求池中需求评分量化的方式判断是否插入，插入的话是否需要延期或者将版本中某个需求滞后。

但对于老板的插入需求可以这样处理，一般创业公司和中大型公司的产品都可以看下：

对老板的需求要勇于说“不”、切忌盲目说“不”；老板给的需求一定要了解清楚，信息了解全面，确定目标，同时保证跟老板的信息要同步。别着急否定老板，回去仔细思考。

1）若与老板想法一致，直接出解决方案；

2）若不一致，需要做模型；让老板知道哪个地方可能存在问题，造成的影响是什么，同时给老板一个备选的你认为的正确方案；

3）若老板看完直接否掉，那一般只能按照他的方案走，毕竟老板作为CEO，站的角度可能不一样。

三、把握开发版本节奏

接下来就是最重要的“处理器”，这是直接影响我们输出的部分，所以我们会根据：产品需求处理、设计与开发、测试与验收以及复盘4大部分全链路讲解。

3.1 产品需求处理

这是进入到开发设计环节的第一步，也是最重要的一步，主要在于考察产品经理的业务能力、需求分析、需求把控能力。首先通过第一部分，我们已经对于需求池中的需求过滤且评分量化了，省掉了很多的麻烦。

下面就是我们需求细处理的过程，我们首先要把用户原始需求转换为我们的产品需求（不做细讲，功底需要慢慢锻炼），再将产品需求转换为功能需求（这就是开发需要看的点）；最后输出我们的需求文档（脑图、流程图、原型图、需求等）。

这一部分对于迭代节奏的把握主要是合理规划版本需求量和减少需求的变更，表现在对技术边界的理解、版本内需求预估处理数量、思维逻辑的正确梳理、业务场景的穷举、抽象转化的能力、合理的目标拆分能力、文档的全面易读性。

产品经理在中途真的发现当时想需求可能遗漏了知识点，先评估影响范围大小，别盲目让开发直接更改：小的纳入下版本（减少产品频繁变更需求的印象），大的及早整改（一步错，步步错）。

3.2 设计与开发

这是进入到把握迭代节奏核心环节，主要是UED设计和前后端开发（数据平台需要前端开发和大数据开发）的过程，掌握迭代节奏的掌握主要分如下6点：

1. 目标同步，保持大家的口径思想一致；在评审时不仅要讲解功能，更要在可能存在疑问的点上，讲解业务，立足场景，讲解目的，加深大家的理解；
2. 进度同步，保证相关联的岗位（UE和前端，前端和后端等）互悉、促进进度；昨日计划完成、昨日实际完成、今日计划完成；
3. 风险同步，减少和避免延期风险，根据实际情况看是否调整迭代计划；
4. 培养习惯，培养迭代不延期、先紧后松的理念贯彻；
5. Bug控制，提高开发自测能力，减少后续测试工作量，建bug指标监控系统，通过数据看到每次的进步；
6. 工作饱和度，为保证开发工作量饱和程度，版本间重叠2天，即负责上版本的问题和新版本的开发。

对于开发过程中最重要的一个内容是早会制度（站立会），这是把握开发节奏最重要的一步，建议规模10-25人使用，主要讲述昨日工作内容（建议共享文档写日报，同步所有人）、今日计划内容、对接事项以及本次是否存在延期可能，轮流讲述，所有人参与。

亲测早会制度的好处：

1. 判断迭代节奏是否正常，减少需求延期风险；
2. 增加团队沟通，心往一处想，及时纠正理解偏差；
3. 开发任务细分解，更有助于评估开发工作量（细分看本质）；
4. 早会的作用往往比一杯“星巴克”还提神。

3.3 测试及验收

产品测试及产品验收最重要的在于本次上线核心内容的把控，需要分清你的产品属于哪个阶段，属于哪种类型，属于什么版本，分清当前迭代的主次。

比如：我们做偏业务较强B端产品的迭代，产品验收一般在能用（V 1.0.0）、好用（满足业务需求）、易用（学习成本低）层次筛选，对于我们上线这个功能的第一版本，主要是逻辑走通、功能完善就好，相比之下能用占比更强。所以我们测试和验收的逻辑均保持在能用，有基础的体验即可；不过分追求好用和易用，后者是慢慢优化的内容，千万不要把时间浪费在了易用测试上，这样往往得不偿失。

3.4 及时复盘

希望大家能够记住一句话：避免问题比解决问题更重要、更易于节奏提升！

为了避免问题，保持正常的产品迭代进度，我们需要及时复盘，不仅是对项目的复盘，更是对人员的复盘，对自己的复盘。这个时候不是查找问题是谁产生的，主要是寻找问题发生的原因，以及后续怎么有效避免此类问题。

多问几个为什么，为什么会发生这种问题，为什么没有及时发现，为什么没有解决，未来怎么去避免，未来怎么尽早发现问题。

同时整个项目组（包含自己）也需要考虑下，是因为某个人做的不够好，环节上有疏漏，信息不全面，知识不完备，没有责任心，还是说真的能力不够…从各个方面去复盘这些问题，往往会有很大的成长，无论是项目、是产品还是个人。

优秀的产品是迭代出来的，优秀的人同样也是迭代出来的！

四、注意团队心理节奏

最近经常听到初级产品发牢骚：

“怎么做的这么慢啊？”

“怎么做成这样了”“这不是我要的那样啊？”

在思考别人问题的同时要考虑自己的问题，也要考虑大家的情绪，本身进入到一段开发中，大家的精神都是紧绷的，这样就更需要一个情绪调节者，最低也是感同身受者。

无论哪种产品都应该注重用户体验，哪怕B端也是（注重不是着重），而是一种换位思考；用户不仅仅是使用你产品的人，同样，开发也是你的用户。团队心理节奏搭建起来，那么你的迭代节奏也会是一种升华。

你应该懂得，笔者也在第二部分说到过，处理器是很重要的一部分，同样开发产品中开发可以类比处理器，如果处理器过热，会导致输出卡顿、延迟各种现象，同样，开发亦然。

不仅开发，我们需要注重整个团队的情绪；同时不仅要做产品的主人翁也要做团队的情绪主心骨。我们要懂得对方想什么，换位思考，这是产品的一项软能力，通过了解对方的想法，去合理应对每一个人。对人要以尊重为基础，必要时可以“哄”，千万不能产生对立感觉（不是说弱势），否则只会让你越加寸步难行（除非你是老板）。

经过几个月磨合，我们的团队整体就会很融洽，虽然评审争论是避免不了的，这是常态，但那不是情绪的争论，而是工作的争论，让产品做的更好的争论！这种争论往往有助于迭代节奏的提升。

【话题】当开发给你一本《，不错过任何一篇让我们互相成长的新文章。