双轨是什么
双轨模式让产品发现与交付并行：发现轨通过访谈、原型与数据验证需求与方案的假设，交付轨持续生产可发布增量。两条轨共用同一迭代节奏，共同参与规划与回顾；发现轨的结论以故事与验收标准的形式进入产品待办，并附上支撑证据。需要强调的是，发现轨不是文档前置阶段：它的产出是可验证的假设与证据，而不是一份完整设计文档。
基本信息
| 发现轨 | 问题验证、方案探索、原型测试与可用性验证 |
|---|---|
| 交付轨 | 拆分、实现、测试与发布，产出可发布增量 |
| 衔接方式 | 发现结论以故事与验收标准进入产品待办，附证据材料 |
| 节奏要求 | 两轨同一迭代节奏，共同参与规划与回顾 |
| 常见偏离 | 发现轨变成写需求文档的瀑布前置阶段 |
典型使用场景
- 需求不确定的新方向，需要先验证问题是否真实存在再投入交付
- 交付团队等待需求文档，需要把发现工作前置并在迭代中并行
- 方案存在多个选项，需要用原型与数据在交付前收敛
- 上线后效果不佳，需要复盘发现阶段验证是否充分
- 跨职能团队（产品、设计、技术）需要共同参与验证而不是各自串行
衔接检查
衔接检查
结论形态：以故事与验收标准进入产品待办，而非设计文档
证据附件：访谈记录、原型测试结果与数据随故事归档
验证范围：明确要验证的假设与成功标准，避免无边界的调研
合并对表：每迭代一次两轨对齐，确认发现结论与交付范围一致
角色配置：发现与交付由同一团队承担，避免两拨人互不交流两轨对照
| 对比项 | 发现轨 | 交付轨 |
|---|---|---|
| 核心活动 | 问题与方案验证 | 实现、测试与发布 |
| 主要产出 | 假设、证据与方案选项 | 可发布的增量 |
| 成功判断 | 假设是否被证实或推翻 | 功能是否满足验收标准 |
| 常见风险 | 变成前置文档阶段 | 脱离验证结论自行实现 |
发现轨不是文档前置：其产出是可验证的假设与证据，而不是完整设计文档。如果发现轨变成产出长篇需求规格说明书，双轨就退化回串行的瀑布流程。