产品周期化迭代的流程和注意事项

1、产品周期化迭代的流程和注意事项当产品基础框架开发完成，进入成熟期后，产品的周期化迭代就变得非 常重要。所谓产品迭代，就是在一定时间内，对该产品一定量的新需求加以 评估、筛选、开发、测试以及上线的一系列行为的总称。而产品迭代的周期 化，即是指固定产品迭代的流程，一般为一到两周。那么，为什么要进行周期化的产品迭代呢？这是因为，固定的周期有助 于为项目团队形成规范，从而提高开发效率。如果迭代被周期所限制，那么 团队就会被引导去选择一个能与这个周期长度相适应的开发量，而不是盲目增加需求或放不开手脚。而在固定周期内，当确定开发量时，我们经常需要对一定量的需求进行筛选，固定不变的周期可以帮助我们逐渐找到适

2、合自己的节奏，也可以帮助我们对需求进行优先级排序。此外，固定的迭代周期还有助于在整个迭代过 程中，加强项目团队的时间观念，从而形成规范，比如周一主要由谁来做什 么工作，周二由谁来做什么工作，以此类推。在产品迭代的流程中，产品经理其实更多地扮演了项目经理的角色，需 要跟进整个迭代的进度，也需要及时协调各方资源，保证迭代成功进行。我 个人认为，产品经理作为产品的“爹”，作为对产品直接负责的角色，跟进 产品的开发和测试本来就无可厚非。 具备必要的项目管理能力，不应该是产 品经理的加分项，而应该是对其最低限度的要求。F F 面我们简单梳理下一个固定周期中，产品进行迭代的流程。1.1. 需求初定先由产品

3、经理从需求池当中取出部分需求，作为本周期内需要开发的内 容，并进行优先级排序，一般 POPO、P1P1、P2P2 三级即可。优先级分类太多，很 容易导致在不同需求的优先级排序上造成不必要的时间浪费。排序完成后， 产品经理还可以先预估一下开发成本， 如果感觉开发负担太重，那么就有必 要砍掉一些优先级或投入产出比低的需求。2.2. 需求评估召集设计同学、技术同学和测试同学，进行本周期的需求评估，以确定 最终的开发内容，以及各部门工作的排期。这部分流程最好能通过一次稍微 正式些的会议来进行。在会议这种正式场合上，大家表达意见一般都是经过 认真思考的，给出排期时也会较为谨慎，而且有利于形成规范。会议结

4、束后， 可以发一封邮件给整个项目团队，说明会议内容与排期确定情况，越详细越 好。这样将项目流程初步落实到纸面上， 一定程度上可以防止迭代规划流于 空谈。3.3. 需求落地（设计与开发）这是一个至关重要的环节，直接决定着本周期内的需求迭代能否成功。在上一个流程即需求评估阶段， 我们已经确定了最终的开发内容， 但这并不 代表迭代进入这个阶段后我们就没事可做了。作为产品经理，我们在产品生命周期的每一个阶段，都需要保持活跃。而这个阶段我们需要做的，就是跟 进产品的设计、开发进度，以保证产品能够在拟定的期限内开发完成，达到 可测试水平。不过，“跟进”并不等于“监督”，我们是产品经理而不是包工头。不需要整

5、天跟在设计和技术同学后头问“ XXXX 需求做得怎么样了”，一方面无 益于项目的实际进度，另一方面也会让别人觉得你自身能力不够， 却只会一 味要求别人，从而影响到你们在项目当中的合作。4.4. 需求测试在这个环节，我们要将本周期内开发完成的需求全部提交测试。需求测试分为两部分，第一部分是产品经理自测整体逻辑， 也就是说不需要关注细 节与极限问题，只要逻辑总体上没有问题，此部分测试便可通过。第二部分 是提交 QAQA 测试，简称“提测”。与需求落地环节一样，这个阶段中的产品 经理看似无事可做，实则不可或缺。我们需要跟进测试进度，在测试同学对 提测内容和逻辑有疑问时，需要及时解答。5.5. 产品上

6、线到需求测试为止的工作全部完成，即意味着本周期内需要开发的需求已经全部实现，且没有任何问题，产品可以上线。不过上线后，产品经理还需 要进行一次线上回测，最大限度地确保产品不存在任何问题。 如果不幸测试 出了在测试环节未能及时发现的 BUGBUG, 定要第一时间提给技术同学去修 复，未能修复的也需要告知运营同学， 并协助运营同学做好对用户的解释与 安抚工作。产品上线标志着一个迭代周期的结束， 同时也意味着产品经理需 要开始梳理下一个周期的迭代内容。我们可以看到，一个产品的迭代实际上是循环往复不间断的。要在连续更替的迭代周期当中做好每一个阶段的工作也不是一件容易的事情。那么我们来梳理一些需要注意的

7、事项，希望能在产品迭代过程当中对大家有些帮助。1 1 科学设置迭代周期长度产品迭代一般是以周为单位， 每个周期为一到两周。 这样的时间设置最 为接地气，也最为科学，短于一周，分配给各个环节的时间都太紧，会导致 各项工作都草草了事。长于两周，各个环节的工作在时间上难以把控，很容 易造成迭代不能如期完成，难以形成稳定有效的规范。2.2.将信息传达落实到位任何工作能落实到纸面上，尽量落实，并让大家周知。例如，每次需求 评审都使用原型与文档辅助讲解；会议记录整理后用邮件发出；BUGBUG 通过jirajira 等项目管理应用统一提出等等，一方面避免了口头沟通易忘的风险，可 以帮助各部门同学记住重要信息

8、， 另一方面也可以借此规范迭代流程， 明确 各自责任，防止出现问题时互相推诿的现象发生。而且，落实到纸面上的信息，比如已经确定的产品策略、开发排期等等， 如非极其特殊的情况，尽量不要更改。即使只更改过一次，也会让其他部门 同学觉得“这个产品经理不靠谱，已经敲定的事还变来变去”，从而让纸面 上的规定失去效力。严重者甚至会引发团队间的信任危机， 对以后的周期化 迭代绝对是有弊无利的。3.3.优雅地跟进项目进度前面我们说到了，对其他部门工作的跟进，不等于监督他们的工作，即 没必要整天追着设计和技术同学问“ XXXX 需求怎么样了”。那么我们该如何 做，既不让他们感到厌烦，还能随时把握项目的最新进度呢

9、？有几点可供借 鉴：将本周期内的需求逐条整理，归纳成一份列表，每晚用邮件分享当天的 迭代进度，标注出当天该列表中需求的完成情况 （当然要明确各项需求的责 任人）。绑定需求的开发环境，随时跟进最新的开发进度。这样如果开发上有漏 洞，就可以第一时间获知到并与技术同学沟通。其实，大部分的设计和技术同学还是很负责任的， 有没搞懂的逻辑问题 都会主动来问你（不然工作没法继续进行）。所以最基本的是，一开始就把 所有需求点和其他部门同学都沟通清楚，从根本上免去不必要沟通的麻烦。4.4. 建立应急机制迭代周期化需要有一套应急策略，比如开发或测试工作没有如期完成， 影响了下一阶段的工作，此时应该如何做，是砍掉部

10、分相对不重要的需求，还是牺牲上线时间，视具体情况而定。5.5. 适当地贡献出你的碎片时间在两轮迭代周期之间，通常会有周末之类的空缺，这个时候产品经理还 是有很多事可做的，比如收集用户反馈，整理下期需求等等。这一条看似有 些苛刻，不过细细一想也可以接受。毕竟就算在工作时间，我们也会偷偷刷 微博，而工作时间之外我们也同样不可能完全放开自己的工作。6.6.关于正确的心态与做法我个人认为，一个迭代周期当中，产品经理应该本着一种“打杂心态”来协调和推进整个项目。下面我来解释一下何谓“打杂心态”。举个例子，设计同学在工作时，他会觉得除了按要求设计产品，其他事 情都不属于自己的工作范围，也就是他的“杂事”。

11、技术同学在编码时，也 会觉得除了编码这一本职工作之外，其他事情都属于“杂事”。“杂事”的 分类有很多，其他部门的工作可以算作“杂事”，因需求的模糊而去找产品 经理沟通也可以算作“杂事”。而“杂事”由谁来处理呢？产品经理自然当仁不让。我们可以这么想： 在产品迭代的各个阶段，都有相应的阶段主体，他们的工作对这个阶段的迭 代，起着决定性的作用。在需求初定阶段，可能产品经理是主体，但进入了 需求开发阶段，设计与技术同学就变成了主体，进入了测试阶段，测试同学 当然就是主体。如果一个阶段的主体为太多的杂事所累，那他进行的这部分 迭代工作情况当然不会很理想。作为跟进产品迭代每个阶段的角色，我们必须在迭代进入特定阶段的时 候，尽量协助充当这个阶段主体的同学，为他们免去尽可能多的杂事，换句 话说也就是替他们“打杂”。这样做的好处如下：一方面，我们可以规范迭代流程