跳转至

Deep Research: How the discovery phase works - Service Manual - GOV.UK

  • Source: https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works
  • Snapshot: ../../sources/md/www-gov-uk-service-manual-agile-delivery-how-the-discovery-phase-28b6e97969d9.md
  • Category: Discovery & Product Strategy (product_discovery)
  • Chapters: 02-discovery, 01-method, 05-validation, 19-iteration

TL;DR

发现阶段（Discovery）是敏捷交付的侦察任务，通常持续 4-8 周，核心目的是在写下第一行代码前，通过深入调研将预设的解决方案还原为真实的用户问题，并厘清技术、法律与政策约束，最终依据成本效益分析决定项目是继续推进（进入 Alpha 阶段）还是及时止损。

核心观点

  1. 别急着动手，先搞懂问题：发现阶段的铁律是严禁开始构建服务。在这个阶段，你的任务是学习而非产出代码。必须克制住直接做个 App的冲动，转而探究用户到底想通过这个 App 完成什么。
  2. 把方案反向工程为问题：利益相关者往往会直接丢给你一个方案（例如我们需要一个 AI 聊天机器人）。你需要通过层层追问，将其重构为待解决的问题（例如如何让用户在非工作时间也能快速获得办事指引）。
  3. 区分铁板与木板约束：
    • 硬约束（Hard constraints）：如核心法律法规（GDPR、数据出境法等），通常无法撼动。如果硬约束导致问题无法解决，项目应立即停止。
    • 软约束（Soft constraints）：如现有的业务流程、遗留的技术架构。这些往往是可以被优化或重构的，不要让它们成为阻碍创新的借口。
  4. 不立项也是一种成功：发现阶段的终局不一定是继续做，如果调研发现投入产出比低，或者现有方案已经足够好，决定停止项目是为组织省钱的高价值决策，绝非失败。
  5. 用户旅程大于产品功能：用户并不是为了用你的软件而用软件，他们是在完成一个更宏大的任务（例如雇佣海外员工而非仅仅填写签证表）。你的视野必须覆盖端到端的服务全景，包括线下的交互环节。
  6. 尽早量化问题的价格：在动手前，先算清楚当前这个问题每年浪费了多少钱、多少时间。这不仅是立项依据，更是后续衡量 AI 降本增效成果的基准线。
  7. 跨部门借力：很多数据可能已经被其他部门采集了。发现阶段要排查重复造轮子的风险，利用现有的数据管道或 API 往往比新建更高效。

可落地做法

1. 面向产品经理（PM）

  • 实施方案清洗工作坊：收到需求时，列出所有隐含假设。例如需求是做个大模型知识库，假设是文档质量足够好和员工愿意搜。去验证这些假设。
  • 绘制全景服务蓝图：不仅画 App 的流程图，要画用户从产生念头到彻底解决问题的全流程，标注出哪些环节是痛点，哪些环节涉及跨部门/跨组织协作。
  • 建立停止/继续决策模型：设定红线指标（例如：如果无法获取合规的训练数据，则项目终止）。

2. 面向工程团队（Engineering）

  • 技术考古与摸底：在不写业务代码的前提下，探查遗留系统（Legacy Systems）的 API 限制、数据质量和并发瓶颈。
  • 数据资产盘点：对于 AI 项目，评估数据的可达性和可用性。数据虽然在那里，但如果清洗成本高于开发成本，就是硬约束。
  • 可行性预研（Spike）：针对最核心的技术风险点（如特定场景下的模型幻觉率）做最小成本的验证，而不是搭建完整架构。

3. 面向评测与 QA（Evaluation）

  • 定义成功的样子：在开发前就写下验收标准（Success Metrics）。不是模型准确率达到 90%，而是用户人工复核时间减少 50%。
  • 基准线测试（Baseline）：测量当前（无 AI 或旧系统）的效率数据，作为后续 ROI 计算的锚点。

检查清单：发现阶段退出标准（Exit Criteria）

在决定进入 Alpha（原型开发）阶段前，请确认团队已完成以下检查：

  • [ ] 问题定义：如果你必须用一句话解释我们要解决什么问题（而不是我们要建什么系统），全团队能达成一致吗？
  • [ ] 用户画像：我们是否清楚谁是核心用户？是否访谈过真实用户（而不仅仅是听老板描述）？
  • [ ] 约束图谱：
    • [ ] 是否识别出不可逾越的法律/合规红线？
    • [ ] 是否确认了必须集成的遗留系统及其技术债务？
  • [ ] 价值锚点：是否计算过该问题目前的成本（金钱、时间或风险）？
  • [ ] 可行性预判：是否存在一旦遇到项目就必死无疑的技术卡点？（如果有，必须先解决或终止）
  • [ ] 团队就位：Alpha 阶段所需的关键角色（开发、设计、领域专家）是否已确定人选？
  • [ ] 决策依据：如果是 AI 项目，是否确认了数据来源的合法性和持续性？

常见坑与对策

常见坑 典型表现 对策
分析瘫痪 (Analysis Paralysis) 调研了 3 个月还在画图，不敢做决定，总觉得信息不够。 设定时间盒（Timebox）。强制 4-8 周必须输出结论（Go/No-Go）。信息永远不会 100% 完备，关键是识别致命风险。
表演式发现 (Theatrical Discovery) 也就是走过场。心里早就定好要怎么做了，调研只是为了找证据支持既定方案。 引入红队思维。专门指派一人负责挑战假设，寻找为什么这个方案行不通的证据。
忽视软约束 既然是 AI 创新，就想推翻所有旧流程，结果上线后被业务部门抵制。 识别利益相关者。将业务流程的拥有者（如客服主管、法务）尽早拉入核心圈，区分哪些流程可以改，哪些是动不得的祖宗之法。
过度承诺 在发现阶段就承诺了上线日期和具体功能列表。 管理预期。明确告知发现阶段的产出是经过验证的假设和原型计划，而不是最终产品的甘特图。

可用于丰富《AI 辅助软件产品》的写作点

  • 对应章节：02-discovery (发现阶段)
    • 核心理念植入：引用 GDS 的观点，强调 AI 产品开发中问题定义比模型选择更重要。许多 AI 项目失败是因为那是拿着锤子（LLM）找钉子，而非真正解决了用户痛点。
    • 案例重构：可以编写一个反面教材——某团队接到做一个 AI 搜索的任务，直接开始 RAG 调优，结果发现用户其实只需要一个结构化的导航页。对比 GDS 的Reframe the problem方法。
  • 对应章节：05-validation (验证)
    • 方法论迁移：将 GDS 的硬约束 vs 软约束分析框架引入 AI 领域。
      • 硬约束：显存限制、数据隐私法（如不能上传 PII 到公有云模型）。
      • 软约束：用户习惯（如用户习惯了关键词搜索，不习惯对话式交互）。
  • 对应章节：03-prd (需求文档)
    • 指标设计：借鉴文中Quantifying the value部分，指导读者在 PRD 中不仅仅写功能需求，还要写当前痛点成本分析。对于 AI 产品，这通常对应 Token 成本 vs 人力成本的 账本。
  • 对应章节：01-method (方法论)
    • 流程图补充：绘制一张 AI 产品的生命周期图，将发现阶段明确标记为Go/No-Go的第一个关卡（Gate），强调在此阶段及时止损是最高级的降本增效。