回答。
标准化的解决方案演示（Demo）是IT团队与利益相关者之间沟通的重要部分。业务分析师负责准备结构、收集和描述案例、控制结果演示的完整性和逻辑性。
业务分析师：
- 根据客户的要求和痛点确定关键场景（flow）。
- 为产品/原型构建故事板或检查清单，重点关注用户期望的内容。
- 组织反馈，记录意见和修改请求。
演示应简短、结构化，仅展示重要点，而不是随意展示所有内容。
关键特性：
- 演示场景应反映用户任务，而不是技术实现。
- Demo不是开发者的考试，而是与业务沟通的工具。
- 始终记录反馈和正确的协议。
带有陷阱的问题。
在演示中是否可以仅展示“正常工作”的部分，忽略部分实现的内容？
不可以，如果客户事后得知问题，会失去信任。应该诚实地展示进度，并指出需要关注的领域。
业务分析师是否必须亲自进行演示？
不必须，但分析师应负责结构化场景，并确保展示功能从业务角度的适用性。
在演示中是否需要讨论所有开发的技术细节？
不需要，目标是展示业务价值，而不是架构决策；可以单独与技术利益相关者讨论细节。
常见错误和反模式
- 缺乏结构化的展示场景
- 演示与用户实际任务无关的功能
- 漏掉收集反馈，仅口头记录来自客户单一代表的反馈
生活中的例子
负面案例：
- 在客户的演示中，团队仅展示了标准屏幕，并未说明哪些对话已解决，哪些未解决。客户认为一切已准备就绪，实施后发现许多错误和复杂性。
优点： 快速进行演示。
缺点： 不明显的错误，信任缺失，实施版本与预期不符。
正面案例：
- 在首次发布前，业务分析师创建了展示的场景计划（user flows），并提前与客户确认。在演示过程中记录了所有问题和意见，并根据这些意见在发布前进行了修改。
优点： 高透明度，预期与实际结果一致。
缺点： 在准备清晰场景和记录反馈上花费时间。