敏捷需求和传统需求的区别

来自知识星球《成为百万年薪敏捷教练》的提问：

第一：对于产品经理的工作，岂不是还是要针对需求做详细的描述和说明，那不就是将原先需求的名字换了一种写法而已？

从组织形式来说，在传统的需求文档中，偏重描述系统应该长成什么样，很少提及我们为什么要做这个特性，用户在什么场景下要用这个特性，用了有什么好处。这样的话，团队就只看到解决方案，直接去实施解决方案，看不到「问题」，就可能造成：无法和业务方及用户共情，难以接受需求变更，无法在早期提出更高性价比的方案。敏捷需求，最重要的变化是从「用户故事」出发，整个团队所有人都有机会首先站在同一个视角，就是用户视角来思考，从而就能理解为什么要做，为什么要改，为什么要先做这个后做那个。总结一下就是：传统需求文档更注重描述解决方案，就是功能特性，业务规则等。敏捷需求更注重传递用户痛点，优先级，验收条件，实例。

第二：以 Scrum 框架为例，产品经理对用户故事详细描述的这部分工作，应该放在哪个阶段呢？是在计划会之前，产品经理作为 PO 完成这部分工作？还是在 sprint 开始后，产品经理作为团队成员完成这部分工作？

在动手写代码之前，要有 AC，最好还有实例（Example）。但是对于谁来提供，什么时间做，没有标准答案。

谁来做？把用户故事细化出具体的验收条件和实例，是 BA 的工作，如果 PO 有这个能力，PO 就可以自己做 BA，如果 PO 偏对外，没有时间做或能力做，就需要团队中有人来做 BA，是一名专职的 BA，还是由开发或测试工程师来做，都可以，它是一个「角色」而不是一个「岗位」。
什么时候做？是在 Planning 之前做完，还是在一个专门的会议上做 Backlog Refine，亦或 Planning 之后，按优先级持续细化，就是需要通过迭代回顾不断调整的。

比较理想的做法是，PO 持续地对 Backlog 进行细化，在需要时请求资深开发和测试工程师的支持，在 Planning 的时候，故事大小合适，有线框图，有验收条件，这个时候图标，文案可以不确定，因为不影响工作量。Planning 后，PO，BA，UX 继续补充细节，比如高保真原型，文案等。开发人员领取故事后动手写代码前，跟 PO 和测试工程师 Kickoff，明确细节，尽量保证开发过程能顺畅进行。敏捷需求的核心是小批量，多层次，拉动和共创，不要期望一次性把所有需求沟通完。