SuperAPI AI 工具集

tool-foundation-sprint-readiness

办公与效率

查看项目

更新于 10-15 18:08

技能介绍

用途

Foundation Sprint Readiness 是一个冲刺前诊断技能,用于评估 Foundation Sprint 是否适合团队当前的情况。资料指出,大多数失败的冲刺本就不该被启动,而 30-45 分钟的可行性诊断可以在投入两天引导工作之前捕捉到这种失败模式。

该技能属于 foundation-sprint-skills 技能家族,遵循家族 frontmatter 与 Decider Checkpoint 要求。

主要能力

该技能运行一次推理过程,基于以下输入产出结论:

  • 计划描述:判断 Foundation Sprint 是否为合适工具(相对于问题框定、客户研究或 Design Sprint)。
  • 团队构成草案:对照 Foundation Sprint 角色要求检查名单,标记缺失角色。
  • Decider 姓名与可用性:确认 Decider 能否参加两天;部分可用会被标记为 Conditional Go 风险。
  • 现有客户/市场知识水平(自评 1-10):低于 5 表示需要先做深度发现;5-7 表示 Conditional Go 并需研究准备;8+ 表示 Go。
  • (可选)现有竞争对手与替代方案知识:标记可通过隔夜准备弥补的缺口。
  • (可选)后勤约束:确认两天时间是否真的能腾出。

如果关键输入缺失或置信度低,技能会明确标记,并提出在冲刺前弥补缺口的方式。

产出内容

该技能产出一个包含五个部分的打包工件:

  1. 可行性结论:Go / Conditional Go / Wait
  2. 诊断:哪些已具备、哪些缺失、哪些不确定
  3. 建议前置条件(当结论为 Wait 或 Conditional Go 时):团队应在冲刺前完成的前置工作
  4. 建议参会人员名单(当结论为 Go 或 Conditional Go 时):应在场的 3-5 人及角色期望
  5. 冲刺前活动(当结论为 Go 时):Day 1 之前几天需完成的准备工作

规范结构见 references/TEMPLATE.md,使用 Brainshelf 书目录线索的完整示例见 references/EXAMPLE.md。

使用方式

适用时机

  • 团队正在考虑启动 Foundation Sprint,需要在投入两天前快速诊断。
  • 创始人或 PM 有“我们是否应该运行 Foundation Sprint?”的问题,想要结构化输入而非凭感觉判断。
  • 日历上已有冲刺承诺,团队想验证前置条件是否到位。
  • 在假设被推翻后重新运行 Foundation Sprint:用于确认新上下文已就绪。

不适用时机

  • 团队已决定运行冲刺,只需要简报。应改用 tool-foundation-sprint-brief。
  • 团队需要深度客户发现:应先运行客户研究或问题框定;Foundation Sprint 依赖已有客户知识。
  • 决策很小,完整 Foundation Sprint 属于过度。应使用更轻量的优先级排序或决策工具。
  • 没有 Decider 且无法任命。Foundation Sprint 需要快速战略决策;没有权威只会产出选项而无承诺。

可行性标准(8 项规范检查)

技能依据以下八项标准评估团队,来源为 Knapp/Zeratsky (Click) 与 Character Capital 的 Foundation Sprint 指南:

  1. 计划已命名且具体。团队能说出项目、产品领域或战略问题。
  2. 利害关系有意义。错误的起始方向代价高昂。
  3. 团队已有知识。拥有真实客户、市场、竞争对手或领域上下文以做出知情选择。
  4. Decider 可用。冲刺期间能做出战略决策。
  5. 团队足够小。核心决策参与者最好不超过五人。
  6. 输入已收集。现有研究、客户示例、竞争对手笔记、指标已就绪。
  7. 产出有测试路径。团队之后可使用 Design Sprint、实验、客户研究或其他验证方法。
  8. 组织容忍明确取舍。Foundation Sprint 强制选择首要押注与备选,而非保留所有可能性。

结论模式:

  • 全部 8 项标准干净满足:Go
  • 1-2 项为“黄旗”但可在晚间准备中解决:Conditional Go,并记录准备事项
  • 3 项或以上失败,或第 1-4 项中任一项硬失败:Wait,并给出建议前置工作

标准应视为承重结构,而非可钻空子的清单。用“是的,技术上算”掩盖真实缺口的团队,应得到 Conditional Go 并暴露该缺口。

常见陷阱

  • 因为“反正要运行”而跳过诊断。这是冲刺失败最常见的原因。诊断花费 45 分钟;失败冲刺花费 16 小时团队时间加机会成本。
  • 把 Conditional Go 当作 Go 而不做准备。Conditional Go 意味着“关闭这些缺口后再 Go”。如果缺口未在 Day 1 上午前关闭,冲刺会进入诊断本要预防的失败模式。
  • 混淆可行性评估与问题框定。该技能评估是否运行 Foundation Sprint,而非团队是否有正确的问题。如果问题不清晰,结论为 Wait,前置条件为“先做问题框定”。
  • 没有 Decider 就没有冲刺。没有可用 Decider 的团队就是未就绪,没有例外。任命一个缺乏真实权威的“当日 Decider”解决不了这个问题。
  • 照搬式就绪。读标准并对八项全部回答“是”而不检查,不会产生就绪。该技能的价值在于诚实的诊断。

跨技能使用

该技能是 foundation-sprint-skills 家族的入口点,没有前置条件(metadata.prerequisites 字段有意为空)。

当结论为 Go 时,自然的下一步是调用 tool-foundation-sprint-brief 来设置冲刺后勤。当结论为 Wait 时,团队通常先做前置工作(问题框定、客户研究),然后重新调用该技能。

如果团队对 Foundation Sprint 是否为合适工具存在分歧,可在可行性对话期间调用一次 tool-note-and-vote。实践中这种情况很少见;诊断通常具有决定性。

Decider Checkpoint

该技能在 references/TEMPLATE.md 中以 Decider Checkpoint 结束。Decider 对结论(Go / Conditional Go / Wait)签字确认,并明确接受诊断。没有 Decider 签字,结论为建议性;有签字,则是触发(或推迟)冲刺的承诺。

规范来源

  • Knapp, J., and Zeratsky, J. Click: How to Make What People Want. Foundation Sprint readiness guidance.
  • Character Capital. "Foundation Sprint guide." https://www.character.vc/guide/foundation-sprint
  • Design Sprint Academy. "Foundation Sprint readiness criteria for enterprise." 用于企业上下文对规范就绪标准的调整。