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

产品周期化迭代的流程和注意事项 当产品基础框架开发完成，进入成熟期后，产品的周期化迭代就变得非 常重要。所谓产品迭代，就是在一定时间内，对该产品一定量的新需求加以 评估、筛选、开发、测试以及上线的一系列行为的总称。而产品迭代的周期 化，即是指固定产品迭代的流程，一般为一到两周。 那么，为什么要进行周期化的产品迭代呢？这是因为，固定的周期有助 丁为项目团队形成规范，从而提高开发效率。如果迭代被周期所限制，那么 团队就会被引导去选择一个能与这个周期长度相适应的开发量， 而不是盲目 增加需求或放不开手脚。 而在固定周期内，当确定开发量时，我们经常需要对一定量的需求进行 筛选，固定不变的周期可以帮助我们逐渐找到适合自己的节奏， 也可以帮助 我们对需求进行优先级排序。此外，固定的迭代周期还有助丁在整个迭代过 程中，加强项目团队的时间观念，从而形成规范，比如周一主要由谁来做什 么工作，周二由谁来做什么工作，以此类推。 在产品迭代的流程中，产品经理其实更多地扮演了项目经理的角色，需 要跟进整个迭代的进度，也需要及时协调各方资源，保证迭代成功进行。我 个人认为，产品经理作为产品的“爹”，作为对产品直接负责的角色，跟进 产品的开发和测试本来就无可厚非。 具备必要的项目管理能力，不应该是产 品经理的加分项，而应该是对其最低限度的要求。 卜面我们简单梳理下一个固定周期中，产品进行迭代的流程。 需求初定 先由产品经理从需求池当中取出部分需求，作为本周期内需要开发的内 容，并进行优先级排序，一般 P0、P1、P2三级即可。优先级分类太多，彳艮 容易导致在不同需求的优先级排序上造成不必要的时间浪费。排序完成后， 产品经理还可以先预估一下开发成本， 如果感觉开发负担太重，那么就有必 要砍掉一些优先级或投入产出比低的需求。 需求评估 召集设计同学、技术同学和测试同学，进行本周期的需求评估，以确定 最终的开发内容，以及各部门工作的排期。这部分流程最好能通过一次稍微 正式些的会议来进行。在会议这种正式场合上，大家表达意见一般都是经过 认真思考的，给出排期时也会较为谨慎，而且有利丁形成规范。会议结束后， 可以发一封邮件给整个项目团队，说明会议内容与排期确定情况，越详细越 好。这样将项目流程初步落实到纸面上， 一定程度上可以防止迭代规划流丁 空谈。 需求落地（设计与开发） 这是一个至关重要的环节，直接决定着本周期内的需求迭代能否成功。 在上一个流程即需求评估阶段， 我们已经确定了最终的开发内容， 但这并不 代表迭代进入这个阶段后我们就没事可做了。 作为产品经理，我们在产品生 命周期的每一个阶段，都需要保持活跃。而这个阶段我们需要做的，就是跟 进产品的设计、开发进度，以保证产品能够在拟定的期限内开发完成，达到 可测试水平。 不过，“跟进”并不等丁 “监督”，我们是产品经理而不是包工头。不 需要整天跟在设计和技术同学后头问“ XX需求做得怎么样了”，一方面无 益丁项目的实际进度，另一方面也会让别人觉得你自身能力不够， 却只会一 味要求别人，从而影响到你们在项目当中的合作。 需求测试 在这个环节，我们要将本周期内开发完成的需求全部提交测试。需求测 试分为两部分，第一部分是产品经理自测整体逻辑， 也就是说不需要关注细 节与极限问题，只要逻辑总体上没有问题，此部分测试便可通过。第二部分 是提交QA测试，简称“提测”。与需求落地环节一样，这个阶段中的产品 经理看似无事可做，实则不可或缺。我们需要跟进测试进度，在测试同学对 提测内容和逻辑有疑问时，需要及时解答。 产品上线 到需求测试为止的工作全部完成，即意味着本周期内需要开发的需求已 经全部实现，且没有任何问题，产品可以上线。不过上线后，产品经理还需 要进行一次线上回测，最大限度地确保产品不存在任何问题。 如果不幸测试 出了在测试环节未能及时发现的 BUG, 一定要第一时间提给技术同学去修 复，未能修复的也需要告知运营同学， 并协助运营同学做好对用户的解释与 安抚工作。产品上线标志着一个迭代周期的结束， 同时也意味着产品经理需 要开始梳理下一个周期的迭代内容。 我们可以看到，一个产品的迭代实际上是循环往复不问断的。要在连续 更替的迭代周期当中做好每一个阶段的工作也不是一件容易的事情。 那么我 们来梳理一些需要注意的事项，希望能在产品迭代过程当中对大家有些帮 助。 科学设置迭代周期长度 产品迭代一般是以周为单位，每个周期为一到两周。这样的时间设置最 为接地气，也最为科学，短丁一周，分配给各个环节的时间都太紧，会导致 各项工作都草草了事。长丁两周，各个环节的工作在时间上难以把控，很容 易造成迭代不能如期完成，难以形成稳定有效的规范。 将信息传达落实到位 任何工作能落实到纸面上，尽量落实，并让大家周知。例如，每次需求 评审都使用原型