当产品基础框架开发完成，进入成熟期后，产品的周期化迭代就变得非常重要。所谓产品迭代，就是在一定时间内，对该产品一定量的新需求加以评估、筛选、开发、测试以及上线的一系列行为的总称。而产品迭代的周期化，即是指固定产品迭代的流程，一般为一到两周。
那么，为什么要进行周期化的产品迭代呢？这是因为，固定的周期有助于为项目团队形成规范，从而提高开发效率。如果迭代被周期所限制，那么团队就会被引导去选择一个能与这个周期长度相适应的开发量，而不是盲目增加需求或放不开手脚。
而在固定周期内，当确定开发量时，我们经常需要对一定量的需求进行筛选，固定不变的周期可以帮助我们逐渐找到适合自己的节奏，也可以帮助我们对需求进行优先级排序。此外，固定的迭代周期还有助于在整个迭代过程中，加强项目团队的时间观念，从而形成规范，比如周一主要由谁来做什么工作，周二由谁来做什么工作，以此类推。
在产品迭代的流程中，产品经理其实更多地扮演了项目经理的角色，需要跟进整个迭代的进度，也需要及时协调各方资源，保证迭代成功进行。我个人认为，产品经理作为产品的“爹”，作为对产品直接负责的角色，跟进产品的开发和测试本来就无可厚非。具备必要的项目管理能力，不应该是产品经理的加分项，而应该是对其最低限度的要求。
1.需求初定
先由产品经理从需求池当中取出部分需求，作为本周期内需要开发的内容，并进行优先级排序，一般P0、P1、P2三级即可。优先级分类太多，很容易导致在不同需求的优先级排序上造成不必要的时间浪费。排序完成后，产品经理还可以先预估一下开发成本，如果感觉开发负担太重，那么就有必要砍掉一些优先级或投入产出比低的需求。
2.需求评估
召集设计同学、技术同学和测试同学，进行本周期的需求评估，以确定最终的开发内容，以及各部门工作的排期。这部分流程最好能通过一次稍微正式些的会议来进行。在会议这种正式场合上，大家表达意见一般都是经过认真思考的，给出排期时也会较为谨慎，而且有利于形成规范。会议结束后，可以发一封邮件给整个项目团队，说明会议内容与排期确定情况，越详细越好。这样将项目流程初步落实到纸面上，一定程度上可以防止迭代规划流于空谈。
3.需求落地（设计与开发）
这是一个至关重要的环节，直接决定着本周期内的需求迭代能否成功。在上一个流程即需求评估阶段，我们已经确定了最终的开发内容，但这并不代表迭代进入这个阶段后我们就没事可做了。作为产品经理，我们在产品生命周期的每一个阶段，都需要保持活跃。而这个阶段我们需要做的，就是跟进产品的设计、开发进度，以保证产品能够在拟定的期限内开发完成，达到可测试水平。
不过，“跟进”并不等于“监督”，我们是产品经理而不是包工头。不需要整天跟在设计和技术同学后头问“XX需求做得怎么样了”，一方面无益于项目的实际进度，另一方面也会让别人觉得你自身能力不够，却只会一味要求别人，从而影响到你们在项目当中的合作。
4.需求测试
在这个环节，我们要将本周期内开发完成的需求全部提交测试。需求测试分为两部分，第一部分是产品经理自测整体逻辑，也就是说不需要关注细节与极限问题，只要逻辑总体上没有问题，此部分测试便可通过。第二部分是提交QA测试，简称“提测”。与需求落地环节一样，这个阶段中的产品经理看似无事可做，实则不可或缺。我们需要跟进测试进度，在测试同学对提测内容和逻辑有疑问时，需要及时解答。
5.产品上线
到需求测试为止的工作全部完成，即意味着本周期内需要开发的需求已经全部实现，且没有任何问题，产品可以上线。不过上线后，产品经理还需要进行一次线上回测，最大限度地确保产品不存在任何问题。如果不幸测试出了在测试环节未能及时发现的BUG，一定要第一时间提给技术同学去修复，未能修复的也需要告知运营同学，并协助运营同学做好对用户的解释与安抚工作。产品上线标志着一个迭代周期的结束，同时也意味着产品经理需要开始梳理下一个周期的迭代内容。
我们可以看到，一个产品的迭代实际上是循环往复不间断的。要在连续更替的迭代周期当中做好每一个阶段的工作也不是一件容易的事情。那么我们来梳理一些需要注意的事项，希望能在产品迭代过程当中对大家有些帮助。
1.科学设置迭代周期长度
产品迭代一般是以周为单位，每个周期为一到两周。这样的时间设置最为接地气，也最为科学，短于一周，分配给各个环节的时间都太紧，会导致各项工作都草草了事。长于两周，各个环节的工作在时间上难以把控，很容易造成迭代不能如期完成，难以形成稳定有效的规范。
2.将信息传达落实到位
任何工作能落实到纸面上，尽量落实，并让大家周知。例如，每次需求评审都使用原型与文档辅助讲解；会议记录整理后用邮件发出；BUG通过jira等项目管理应用统一提出等等，一方面避免了口头沟通易忘的风险，可以帮助各部门同学记住重要信息，另一方面也可以借此规范迭代流程，明确各自责任，防止出现问题时互相推诿的现象发生。
而且，落实到纸面上的信息，比如已经确定的产品策略、开发排期等等，如非极其特殊的情况，尽量不要更改。即使只更改过一次，也会让其他部门同学觉得“这个产品经理不靠谱，已经敲定的事还变来变去”，从而让纸面上的规定失去效力。严重者甚至会引发团队间的信任危机，对以后的周期化迭代绝对是有弊无利的。
3.优雅地跟进项目进度
前面我们说到了，对其他部门工作的跟进，不等于监督他们的工作，即没必要整天追着设计和技术同学问“XX需求怎么样了”。那么我们该如何做，既不让他们感到厌烦，还能随时把握项目的最新进度呢？有几点可供借鉴：
·将本周期内的需求逐条整理，归纳成一份列表，每晚用邮件分享当天的迭代进度，标注出当天该列表中需求的完成情况（当然要明确各项需求的责任人）。
·绑定需求的开发环境，随时跟进最新的开发进度。这样如果开发上有漏洞，就可以第一时间获知到并与技术同学沟通。
·其实，大部分的设计和技术同学还是很负责任的，有没搞懂的逻辑问题都会主动来问你（不然工作没法继续进行）。所以最基本的是，一开始就把所有需求点和其他部门同学都沟通清楚，从根本上免去不必要沟通的麻烦。
4.建立应急机制
迭代周期化需要有一套应急策略，比如开发或测试工作没有如期完成，影响了下一阶段的工作，此时应该如何做，是砍掉部分相对不重要的需求，还是牺牲上线时间，视具体情况而定。
5.适当地贡献出你的碎片时间
在两轮迭代周期之间，通常会有周末之类的空缺，这个时候产品经理还是有很多事可做的，比如收集用户反馈，整理下期需求等等。这一条看似有些苛刻，不过细细一想也可以接受。毕竟就算在工作时间，我们也会偷偷刷微博，而工作时间之外我们也同样不可能完全放开自己的工作。
6.关于正确的心态与做法
我个人认为，一个迭代周期当中，产品经理应该本着一种“打杂心态”来协调和推进整个项目。下面我来解释一下何谓“打杂心态”。
举个例子，设计同学在工作时，他会觉得除了按要求设计产品，其他事情都不属于自己的工作范围，也就是他的“杂事”。技术同学在编码时，也会觉得除了编码这一本职工作之外，其他事情都属于“杂事”。“杂事”的分类有很多，其他部门的工作可以算作“杂事”，因需求的模糊而去找产品经理沟通也可以算作“杂事”。
