需求圈定执行概要

什么是需求圈定？

需求圈定是指，在迭代研发的基础上，通过一次产研会议，确定本次迭代应该做哪些具体的需求。并非所有的需求都会通过迭代的模式来执行，类似系统新建等较大的整块改动类需求就不适合，这种需求因为锁定人力等缘故，虽不参与圈定，但也会直接影响圈定结果

为什么要进行需求圈定？

圈定的意义在于，每次迭代根据产能确定合理的需求量，并确保整体业务价值最大化。
在大多数时候，研发资源都不是绝对充裕的，即所有需求需要的总开发量往往都是超过现有研发产能的。另外研发产能在每个迭代之间也不是完全一致的，诸如部分人员已被锁定或上次迭代存在延期等，都会导致部分人力被占用。
在需求不能一股脑塞给研发团队的情况下，如何知道本迭代该做哪些呢？那就需要确定需求的综合优先级和关键时间节点，以及研发团队本迭代还剩多少产能。在这个基础上进行团队任务分配，是迭代研发可以进行的第一步

圈定的参与人员

1. 产品团队（代表人）：需要了解本期期望能做的所有需求，以及价值排列关系和关键时间节点，最好对需求改动对应的模块和复杂度有一个简单的认识。参与人数并不固定，一般来说是团队负责人以及需求优先级较高的几个产品来参加，如果本期期望池中没有自己的需求，那完全不需要参与
2. 各方向研发/测试团队（代表人）：研发/测试团队在这里需要细分，细分原则是以人力知情和裁定单元为粒度，例如后端组长没法知晓和分配前端团队的人力情况，前端也可能不止一个团队，那就都需要派代表人。最终要达成的效果是，在场代表人一起可以知晓和安排所有研发/测试团队的人力分配

需要提前需要准备的资料

1. 产品团队：需求期望池，就是本迭代所有想做且能做的需求池，并按照优先级进行排列，得出优先级自然也需要产品团队内部的充分讨论和老板拍板。池中的需求文档细节可以不太精细，但一定得说清楚大方向改动范围和功能点，并在会前就提前将期望池发到群里，方便研发/测试团队代表人评估工作量
2. 研发/测试团队：本迭代可分配人力情况，以及从高到低对本迭代期望池工作量的预估。并非要把所有需求都看一遍，而是只看到自己团队最大能承受的范围，例如前端团队本迭代剩余20人/天待分配产能，P0、P1、P2三个需求粗略估计就已经占用了19人/天，再考虑需要留一点Buffer，那P3的需求就不需要费时间再看。这也要求了每个团队的代表人可以粗粒度评估需求所需工作量

如何进行圈定

简单来说就是在需求期望池的基础上，根据各团队人力最大承载能力进行删减。为了节省会议时间，本次会议不需要太多描述需求的业务价值，而应该重点说明改动范围等影响研发/测试工作量的内容，因为期望池的优先级本身便代表了产品团队对业务价值的认知。下面举例说明如何操作：

1. 产品打开期望池，从P0开始，简单介绍本需求涉及的改动范畴，并解答研发/测试团队代表的疑问
2. 本需求相关的各研发/测试团队根据自身的剩余人力情况，确认是否可以圈定
3. 各团队都可以圈定的话重复上面流程，对下一个优先级的需求进行圈定确认
4. 如果其中某团队已达到人力瓶颈，原则上来说便不建议圈定，但也可以通过外借人力、删减需求内容等方式进行弥补
5. 在某团队已经出现瓶颈后，也可以继续圈定改动范围不涉及该团队的需求
6. 无法继续圈定时，圈定结束，并更新期望池中已圈定部分为本期迭代池

圈定的核心产出

达成共识的已圈定需求池，可按照业务优先级进行开发工作。理论上这个池子内的需求都应该是本迭代无风险完成的，因为已经充分考虑了人力分配情况。如果因为紧急插入需求、或人力突然释放等原因导致时间预估不再准确，则可以在期望池的基础上以同样的圈定原则酌情变动

为什么需要区分需求圈定和需求评审

为了最大可能减少会议占用的时间，一个所有人都参与的长时间大会也能起到应有的作用，但那不是我们需要的，我们应该努力让参会的每个人都不浪费时间，同时让每个人都不进行重复过的工作。圈定是为了确认和分配工作量，只要大方向确定谁来做，能不能做即可，这个过程只需要少量团队代表参与，关注点也集中在改动范围和工时安排。而需求评审则是针对单一需求功能和细节的确认，需要对应的产品和研发/测试仔细推敲研究，非本需求的开发人员完全不需要浪费时间参与旁听。另外业务价值对于研发团队来说属于非必要信息，更重要的是产品团队内部对于业务价值的排序需要达成共识