精心整理的产品需求清单有助于开发成功的产品：它包含了新的见解和经验，并提供了已具备实施条件的产品特性（功能&非功能）。但是应该什么时候整理需求清单呢？在新的迭代版本开始之前还是之后？如何决定哪种选择是合适的？我将讨论四种方案及其优缺点，以帮助你做出正确的选择。
方案1：在迭代版本评审会议上
第一种方案是在迭代版本评审会议上梳理产品需求清单。Scrum指南建议：假设当前已经完成了一个产品增量的开发，并且会议中有合适的人员在场，你可以根据与会者的反馈做出相关的产品决策并更新需求清单，如下图所示。
这种方法确保在下一个迭代版本开始之前更新需求清单。这使你能够立即根据新的见解进行调整，从而降低将产品带入错误方向的风险。此外，需求清单是协同工作的产物。采用这种方法能获得迭代版本评审会议与会者的大力支持。
但是，只有当与会者能够提供相关的反馈，愿意合作，并且对于必要的需求清单变更能够迅速达成一致时，这种方法才起作用。更重要的是，反馈不能过于复杂导致需要深入分析，或者导致更大的需求清单变更。如果当前需求清单中存在大量的不确定性和变化——例如，你正在研发新产品或延长产品的生命周期——请不要使用这种方法。
方案2：在迭代版本策划之前的独立研讨会上
第二种方案是在下一次迭代版本计划会议之前召开单独的产品需求清单研讨会。与会者应该包括产品负责人、开发团队和交付负责人。协同分析数据和梳理需求清单，降低由于认知偏差而得出错误结论的风险。这有助于利用团队的创造力和知识，增加理解和认同，整理出更好的需求。
如上图所示，我的建议是在下一个迭代版本刚刚开始时举办研讨会。这违反了Scrum规则，即策划会议必须是每个迭代版本的第一项活动。但这么做使你能够在随后的迭代版本中有充足的时间对反馈做出响应，不必匆匆忙忙或者放弃迭代版本回顾，也不必工作到很晚或者周末加班。此外，这么做还有将数据收集与分析工作分开的好处：它让你可以在反馈提供者不在场的情况下回顾反馈。它还让您有更多的时间来评估反馈，得出正确的见解，做出正确的产品决策，并相应地更新产品需求清单。这使得处理困难的反馈和需求、执行更大的产品需求清单变更变得更容易。
注意，这种方法仍然假设你能够在迭代版本评审会议上收集相关的反馈，例如通过产品演示、可用性测试或解决方案访谈。如果你决定将产品增量直接发布给（选定的）用户，那么这种方法可能不太奏效，因为根据我的经验，收集相关数据通常需要花费好几天时间。我们来看看下一个方案。
方案3：在迭代版本策划之后的独立研讨会上
如果你是通过向（选定的）用户发布软件来验证产品决策，那么方案3可能适合你。它建议在下一个迭代版本策划活动完成后举办一个邀请开发团队和交付负责人参与的产品需求清单研讨会（如下图所示）。这种方法假设你需要几天时间来收集相关的用户数据，然后才能对其进行分析并进行适当的需求清单更新。它还假设你不用等拿到数据后才能决定下一个迭代版本目标，相反，你可以在收集数据的同时继续下一个迭代版本。
虽然方案3让您能够定量地验证产品，但它也有一个缺点：由于迭代版本过程受到保护，你可以响应需求清单变更需要的最早时间点是迭代版本+2。因此，建议从方案一和方案二入手，一旦解决了需求清单中的关键风险，就改用方案三。另外，你应该关注迭代版本 n+1中与迭代版本 n不同的特性，以避免基于错误（或过时）的决策来确定后续工作的风险。
方案4：持续进行
如果你不需要等到迭代版本结束后才能发布新的或改善过的功能，那么第四个方案很适合你：不断收集数据，分析数据，并相应地更新需求清单。你可能希望每天早上额外花30分钟来查看最新数据并从中得出正确的结论，最好能邀请开发团队或其中部分成员共同参与。
请注意，方案4假设你要么通过小规模增量方式对产品进行完善，要么通过运行多个交叠的实验来检验新增功能或改进功能的想法，例如发布伪功能或MVF（最小可行性功能）。
严格来说，Scrum并不能很好地支持这种方法。该模型假设一个跨职能的开发团队必须在一起工作好几个星期，以实现一个共同的迭代版本目标并交付一个产品增量版本。迭代版本旨在运行一个实验或实现相关的产品功能。它并不特别适合执行多个测试并持续发布较小的升级包和修复包。因此，您可以考虑从Scrum更改为基于看板的流程。
在翻译教稿的过程中，翻译团队的小伙伴们讨论的很多轮，最后确定了几个关键术语的翻译和原因，如下：
Sprint：我们翻译为迭代版本。 很多中文书籍翻译为冲刺，看起来很炫酷，也是新词，但是总是给人一种只用往前跑的潜在影响。从迭代方法的核心思想上来看，每一轮迭代都要关注可交付性，每个版本都要有其发布的定义和验证方法。所以我们还是用比较通俗的词语，传递要关注交付。
Backlog：我们翻译为需求清单项。 我们还是想更贴近日常工作，同时也想表达需求包含不同的层次和维度，客户需求、产品需求；功能需求、非功能需求；这些都是要考虑的，也都要列到清单项里，这样才能在交付时更顺利。
活学活用是IT从业人员的灵魂，任何书上的管理方法都只能覆盖很少一部分场景，毕竟写书的人没法穷举这世上所有的可能性然后整理一套银弹模式。我们在学习每一种方法的时候，既要去实战感受方法的可用性，也要去思考如果遇到不同的场景怎么基于有效的方法来变换以满足动态的业务场景。研发管理是个融专业性和艺术性为一体的工作，这也是我非常喜欢研发管理的原因之一。
以上文章分享了4个不同场景下的需求清单梳理时机方法，发布后很多感兴趣的小伙伴也积极留言展开讨论，摘录一部分分享给大家。
Q1:
你好，
我认同用这四种方法来梳理用户故事。但是，同样重要的是，我们想要多早开始进行梳理。我们应该在给定的功能已经在路线图（Roadmap）中有较高优先级时再更新需求清单，还是应该随机进行，即使在路线图中这些功能最近还不需要实现。
我认为只有当我们确定给定的功能在路线图中的计划实现时间足够接近（并且具有一定的优先级）时，才应该进行梳理，以便尽可能多地适应范围变更，并确保团队已经解决了在之前的开发环节中产生的所有技术依赖事项。
A1:
感谢你的意见。我建议及时完善或梳理产品需求清单，至少在你的产品还在不断变化时应该这么做。这让你能够通过收集用户反馈和数据及时获得最新的见解，利用这些最新的见解来做出正确的产品决策。同时，我还建议过产品需求清单内容应该聚焦在下一个主要版本上。这些对你有帮助吗？
Q2:
你好,
您准确地指出了我们中的一部分人也认同的、当前我们执行的敏捷方法的一个重要改进点，即调整团队组成，以便每个人都有能力攻克一个完整功能。
缺乏相关知识的现象比较常见，以至于在需求梳理、甚至迭代版本策划会议上需要邀请其他团队的成员参加，来解释一些主题或者回答团队开发人员自己无法回答的问题…
非常感谢您的回答！
受益匪浅。
A2:
感谢你的反馈。很高兴听到我的建议对你有帮助。祝你的团队和产品一切顺利。
Q3:
你好,
在我看来，我们对术语的理解和使用需求梳理技巧的方式与此处介绍的略有不同……
在我们的敏捷/ Scrum环境中，我们为术语“需求梳理”赋予了更广泛的含义。在吸纳用户反馈的同时，我们的观点在某种程度上从“以客户为中心”转变为“让团队更多的参与进来”，更重视用户故事的二次剖析， 即对话。
基本上，我们的梳理工作包括产品经理和客户之间就“做什么(What)”和“为什么做(Why)”进行功能相关的对话，然后是产品经理和团队之间进行讨论，目的是清楚地沟通这两个W，但是接下来，团队内部和团队之间的开发人员之间还会进行许多其他更偏重技术性的对话，这些对话会深入到“如何做(How)”的未知领域。
根据我们的经验，我们发现，每当没有进行上面提到的最后一种对话时，我们的迭代版本策划会议都会进行的很困难、漫长，有时甚至令人沮丧。
考虑到所有这些，我们实际上只有一个选项，“方案1：在新开发开始之前进行需求梳理”，并且只要有可能，我们就尝试在当前迭代版本的后半段时间中开展梳理工作，而不是像文中的图片所示在迭代版本之间进行。
我很想知道您对我们的需求梳理过程的想法。
您认为把我们在迭代版本策划之前做的这些准备工作仍然称作“需求梳理”合适吗？
对我们来说，继续将“ 迭代版本计划”之前进行的整个准备工作称为“整理”是明智的吗？
欢迎您提出任何的改进建议，我们将不胜感激。
谢谢。
A3:
你好,
谢谢你分享了你的需求梳理方法。你似乎把技术对话加入到了我的需求梳理过程的第五步（我称之为“准备好故事”）中，在我看来，这没什么问题。不过，我建议将对话限制在解决团队之间的依赖关系上，在计划会议上再详细讨论如何实现用户故事。如果做不到这一点，那么说明团队可能缺乏交付这些功能的相关知识。增加一些Spike(探索研究）任务，或者调整团队人员的组成有助于解决这个问题。
如果你还没有这样做，也可以想办法将团队之间的依赖程度降到最低，例如：按功能而不是按构件来划分团队。理想的团队设置应该让每个团队基本上能够在不依赖其他团队的情况下整理他们自己的需求清单或需求清单中他们负责的部分（以及自主地实现和测试软件）。
不知道以上内容对你是否有帮助？
提问才能真实的感受到读者在思考和实践，只有实践才能推动方法的进一步细化和变换。 欢迎对这个主题感兴趣的小伙伴提出你们的实际问题和思考点发给我，张老师来跟大家讨论和解答。
因为现在公司微信公众号没法开评论功能，大家可以给我发邮件（henryzhang_ws@163.com），也可以加我微信（13476185218）。
惟特翻译团队版权声明----------------