双周迭代
前言
需求的整个实现过程，涉及到多个岗位之间的工作协同。为了提高协同效率，缩短需求研发时间，持续进行高质量、有价值的研发交付，提升组织的敏捷研发能力。推出双周迭代制度，用以规范团队交付节奏。
第一部分
从工作协同来看：
1、确定版本是第一个环节：
周三的时候产品经理/业务顾问，需要确定本次双周迭代的需求范围，考虑到一些不可控的非主观因素，做了部分的兼容处理，周三确定迭代范围后，到下周一正式进行需求宣贯前，还可以进行小范围的计划调整，加入紧急需求，顺延一些还未进入开发的低优先级需求等操作。以确保本次的双周迭代更贴近产品、项目的时间要求。
在周一就会截止本次双周迭代，需求范围的排期变动，以保证后续的研发不会受到需求变更带来的干扰，更好的保障迭代的完成时间点。
2、紧跟在确定版本之后的第二个环节就是，需求宣贯环节：
周二的时候就会针对上一环节（确定版本）圈定的需求，进行需求宣贯，宣贯的目的是为了让研发，测试，业务，对本次的需求有一个全面的、一致的认识和理解。以保障研发目标、测试目标、业务验收目标是一致的，消除信息不对称带来的任务延期。
这是怎么来的，需要说明一下。我们对需求宣贯的标准做了定义，在我们的研发流程中会有更加详细的描述。需求宣贯，是在需求描述清晰，并在此基础上完成了对需求的核心设计，输出的需求文档、设计文档满足业务需求，能对研发起到指导作用的前提下组织的。我们的产品设计，是在周三确定版本之后就先与我们的研发人员参与需求分析和需求设计的，并在此基础上与产品经理、业务顾问达成一致，从而确定最终迭代版本的，所以从第一个周三初次版本确定到第二个周一最终版本确定这个时间段，产品经理不是一个人在战斗，而是产品经理和产品设计共同努力，对需求梳理后的成果。
这个成果的功效，直接决定了我们后续的研发有多大程度的沉浸式工作时间。
3、需求宣贯之后就进入了我们的研发环节：
这个环节就是我们的研发使劲输出的时间，我们上一个环节（需求宣贯）的成果越好在当前研发环节中输出的有效伤害就越高，对任务的消灭效率就越高。
研发过程中，为了减轻全部需求研发完成后，雪崩式的提交给测试，导致的测试人员迫于版本发布时间节点的压力，测试得人困马乏的心衰。我们确定了两次提测时间，分别是第二个周五和第三个周二，分这两次提测是为了分解测试的压力，分批次提测不同需求，让测试的同学有更多的测试时间，能对每个需求测试得更加充分，更加深入。
4、最后说一下测试环节：
测试环节大部分的工作是在研发提测后进行的，从图上可以看出主要集中在第二个周五到第三个周三，这段时间。但实际上测试工作分三块，除了我们刚才提到的测试工作之外，在需求宣贯环节就有部分测试人员参与进来了，他们主要的任务就是在学习，了解需求后，制定需求的测试方案、编写测试用例、编制测试数据，以此来对研发成果进行全面、深入的验证。测试最后一个工作，就是在第三个周四的版本发布，只有通过了测试的需求，才能出现在周四的版本发布清单中。
自此正常的双周迭代工作完成。
从初次版本确定，到最终的迭代版本确定我们预留了3个工作日。最终版本确定进入研发到版本发布我们用了2周时间，这就是我们的双周迭代制度。
第二部分
从单一岗位工作来看：
产品经理/业务顾问：每单周三有固定的迭代版本范围确定，每双周二有固定的需求宣贯。
产品设计/交付设计：每双周二有固定的需求宣贯，每周有固定的需求设计。
产品研发/交付研发：每周有固定的任务研发，每周五、周二有固定的功能提测。
产品测试/交付测试：每周有固定的测试任务，每双周四有固定的版本发布。
特殊需求或者特殊情况下，可以在单周四进行版本发布。
总结
每个岗位都有固定的沉浸式工作时间，也有固定的输出，交流，沟通时间，既相互协同又能相互独立。