回答

问题的背景：
在项目开始时，客户通常表述的任务不够明确：目标可能是笼统的，而细节则没有描述。这对于新方向的启动或传统流程的数字化是典型的。分析师面临着利益相关者之间矛盾的需求和对未来产品的零散想法。

问题：
需求的不确定性导致了设计错误的风险、冲突、期限延误和预算增加。瓶颈在于利益相关者之间的矛盾和无法评估工作量。

解决方案：
分析师应组织分阶段的需求识别：

1. 与主要利益相关者进行采访和促进会议，识别不仅是显性的，也包括隐藏的期望。
2. 使用原型设计和创建MVP的技巧以快速获取反馈。
3. 应用分析工具：用户故事、业务流程图，以及澄清问题的方法（5个为什么、澄清“成功意味着什么”等）。
4. 记录所有假设并与业务协商——这可以减少不确定性的程度。

关键特征：

• 结构化方法来明确不完整的需求
• 使用多种技术来收集隐藏的信息
• 必须记录和提请假设进行协商

误区问题。

在隐性需求下，需要什么样的文档：仅仅记录用户故事是否足够？

用户故事是一个有用的工具，但如果需求模糊，它并不能揭示所有细节。需要开发额外的工件：屏幕原型、使用场景示例和业务规则表。

启动时，快速获得结果（MVP）更重要，还是尽可能完整地收集需求更重要？

速度和完整之间的平衡取决于情况。在启动阶段，最重要的是最小可行产品（MVP），它提供反馈并帮助快速调整视角，而不是长时间协商所有需求。

能否仅依据客户的话作决策？

不能。客户表达需求时，可能没有考虑技术细节和限制。分析师必须通过理解过程来验证需求，征求替代意见，并分析后果。

常见错误和反模式

• 盲目相信客户的话而未经详细的过程分析
• 将模糊的需求直接转换为开发任务
• 忽视对阶段性结果的反馈

实际案例

负面案例： 分析师仅记录了客户的需求并将其传递给开发者。结果：实现的功能没有解决真实的商业问题。 优点：开发迅速开始。 缺点：产品未被使用，进行大量的修改。

正面案例： 分析师与用户进行了系列会议，构建了原型，确认了场景。需求得到了澄清——MVP迅速为业务带来了价值。 优点：快速的价值，积极的反馈，最小的修改。 缺点：在需求收集阶段花费了稍多的时间。