简报不是隐藏的完整规格书
有效的简报说明项目为何存在、哪些工作需要改变，不必提前规定每个页面、技术选型和实现细节。
它的价值在于提供足够背景，让团队能够提出更准确的问题并比较不同路径。
用简洁段落说明业务背景
介绍组织、受影响的流程，以及为什么现在需要推进该项目。
说明增长、新服务、监管要求或旧系统替换等近期变化。
- 谁负责推动项目
- 为什么现在要做
- 哪些流程受到影响
- 如果不改变会发生什么
用真实案例让问题具体化
案例比形容词更有价值。不要只写“流程效率低”，而要说明具体步骤、等待、错误和重复沟通。
两三个具有代表性的场景通常比长功能清单更能说明问题。
示例：协调人员收到表单后，需要把数据复制到两个系统，手工核对规则，并发送多封邮件才能完成处理。
区分结果、功能与偏好
结果描述需要发生的改变，功能只是可能的实现方式，偏好则是团队当前设想的界面或方案。
将三者分开，才能在不削弱业务要求的前提下探索更优方案。
- 结果：减少重复录入
- 可能功能：自动同步
- 当前偏好：网页仪表盘
明确包含范围与排除范围
初步范围可以保留调整空间，同时明确用户、地区、语言、设备、数据和系统边界。
清晰的排除清单能够避免隐性预期。
- 用户与角色
- 优先业务路径
- 系统集成
- 数据迁移
- 内容与语言
- 后续阶段事项
把约束写成可验证条件
说明截止日期背后的原因、可用预算范围、安全要求、审批规则及外部依赖。
尚未确认的约束应标记为假设，而不是事实。
- 由业务事件驱动的日期
- 预算与审批流程
- 隐私和数据要求
- 指定技术条件
- 决策人员可用性
附上能够减少歧义的材料
流程图、现有工具截图或样例报表，往往比长文档更有帮助。
分享前应删除不必要的个人信息，并标识机密资料。
- 流程图
- 匿名化案例
- 现有原型
- 系统清单
- 核心业务规则
最后列出未决问题
高质量简报不会掩盖不确定性，而是明确缺失信息、待定事项和已知风险。
这样首次沟通就能聚焦真正需要决策的内容。