需求分为几个阶段：获取需求阶段、讨论和设计阶段、待开发阶段、开发阶段、复盘阶段
本章节着重讲讲开发阶段、复盘阶段。
开发阶段
开发需求的次序，未必完全按照需求池里的需求优先级进行。
按照工作量确认了本次迭代的需求，提交开发之后，要关闭本次迭代的需求。也就是说，原则上本次迭代不再加入新的需求。
在开发中，“扯皮”的问题归纳起来有三种：需求太多，没按时做完；需求有改动，导致了额外工作量，引起开发人员的不满；有新的紧急需求，导致发布延期。导致出现这三种问题的原因如下：
1．产品方案不完整
方案不完整往往是没有考虑全面。这个跟需求管理本身没关系，就是在出方案的过程中看能不能把事情想全。经常出现这样的情况，在实际开发的时候技术人员才发现某个逻辑没想通。再喊产品经理来一起讨论的时候，大家才发现需要加一些功能才能完善逻辑。最终结果就是周六加了个班，大家都很不开心。
解决方案：
分析需求时，先梳理逻辑再出方案。能画流程图的画流程图，能画逻辑图的画逻辑图，能画脑图的画脑图，穷举整体的逻辑。
讨论方案时，所有产品经理参与小组讨论，一起提出疑惑，发现问题。
在做可行性评审时，技术人员要尽可能从逻辑角度提出质疑，多发现问题。之后再出问题，会回溯原因。如果是前两个环节出的问题，那就是产品经理的责任；如果问题出在产品经理并不熟悉的技术逻辑，那就是在可行性评审中技术同事的责任。
2．需求方的主观改动
这种情况基本上是需求方或者产品经理的问题，他们在提交方案前没有完全想清楚。
有一种情况是需求方跟产品经理对接时出了问题。表述有误并且方案没有跟他们核对清楚，结果产品功能上线后，才发现并没有解决问题。
解决建议：
要在需求（比如具体方案、时间点）发生变化时，跟需求方同步。让他们知道我们的情况，也获取他们的意见和建议。
3．无法预测的客观原因
无法预测的情况导致需求的变动引起一些问题，是客观上唯一能够接受的原因，不需要有谁承担责任。
在这种情况下，作为产品经理最重要的是安抚技术的同事，尤其是跟他们解释清楚背景和详细的原因，不要让他们误以为是产品和其他部门的同事办事不力造成的。
复盘阶段
需求从获取到上线走完生命周期之后，还要有一个很重要的复盘阶段，尤其是在需求管理出过故障和问题的时候。
负责任的团队都会有复盘的机制，主要是防止问题再次发生。解决问题很简单，完全规避下次再出问题则很难。要清楚之前出现问题的所有逻辑和流程，再去看在哪些环节可以做些什么，以防止问题再次出现。
