回答。

问题的背景： 在项目的早期阶段，客户经常会提出模糊或矛盾的需求，这些需求需要分析师转化为清晰和可验证的以便后续实现。

问题： 模糊的需求导致业务与开发团队之间理解的不一致，从而增加了任务回退、错误和不满意用户的数量。

解决方案：

• 举办研讨会和澄清会议：分析师促成与客户的会议，使用澄清技术（示例映射、事件风暴、故事映射）。
• 使用原型和线框图：可视化建模有助于业务更准确地表达期望。
• 分阶段澄清直到准备标准（Definition of Ready）：将任务分解为子任务，形式化场景，收集边缘案例。

关键特点：

• 渐进式澄清 — 是一个持续的过程，包括问题和快速检查的循环（反馈循环）。
• 吸引多个参与者，以考虑不同的观点。
• 分析师记录变体和限制，即使是与“原始”的需求一起。

误导性问题。

“在收集模糊需求时，是否可以仅依赖客户的言辞？”

不，重要的是使用示例、图表、草图，并提出额外问题以识别真实需求。

“是否只需一次确认需求的澄清就足够？”

不，确认是一个迭代过程：随着细节的出现，需求需要重新确认。

“是否总能在不涉及最终用户的情况下澄清需求？”

不，实际用户的参与有时对识别边缘案例和使用场景至关重要，这些场景对业务和IT而言都不明显。

常见错误和反模式

• 尝试在没有形式化的情况下实现模糊要求。
• 忽视澄清会议。
• 仅用文本记录需求，而不进行可视化和示例。

生活中的例子

负面案例： 客户要求“方便的搜索机制” — 记录后开始“按惯例”实现。

优点：

• 任务快速启动。

缺点：

• 结果未能满足用户；需要不同的搜索和过滤。

正面案例： 在类似任务中，分析师召开了研讨会，收集了用户场景并绘制了原型。

优点：

• 实现与业务期望的90%相符。

缺点：

• 确认和澄清花费了更多时间。