mcpField
T
tool-design-sprint-test-and-score

tool-design-sprint-test-and-score

github.com/product-on-purpose设计与 UI769625 次安装4 天前更新
代码仓库

关于 tool-design-sprint-test-and-score

用于 Design Sprint 周五测试与评估的 skill,帮助团队记录客户访谈、汇总观察并对照冲刺问题评分。它整理决策摘要,供 Decider 作出构建、迭代、转向或停止的决定。

主要功能

  1. 01记录逐位客户的访谈观察
  2. 02汇集关键客户原话
  3. 03按冲刺问题制作评分表
  4. 04归纳观察模式与团队判断
  5. 05形成 Decider 决策摘要

适用场景

  1. 01观察客户使用原型并记录行为
  2. 02汇总五位客户对冲刺问题的反馈
  3. 03识别已验证、未验证和未明结论
  4. 04在冲刺结束前确定后续行动

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/product-on-purpose/pm-skills --skill tool-design-sprint-test-and-score

安装后在 Claude Code 中输入/tool-design-sprint-test-and-score确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

HISTORY.md
references/
EXAMPLE.md
TEMPLATE.md

详细介绍

设计冲刺测试与评分(星期五)

星期五是冲刺的成果验收日。5 位目标用户画像中的客户试用原型,团队在旁观察;团队将观察结果汇总为针对冲刺问题的评分表;Decider 在当天结束前决定是构建、迭代、转向还是停止。本周投入的 35-40 人天,加上招募客户的成本,最终将转化为一个可执行的决策。

系列约定:docs/reference/skill-families/design-sprint-skills-contract.md。此技能属于 design-sprint-skills。

适用场景

  • 现在是设计冲刺第 5 天,且星期四的原型通过了试运行。
  • 已安排 5 位确认参加的受访者(标准人数;或 1 人取消且没有候补时为 4 人;少于 4 人则暂停)。
  • 团队可以实时观察访谈(线下或通过 Zoom 分组讨论室),并在当天完成汇总。
  • Decider 星期五下午在场参与访谈后评审(标准时间为 14:00-18:00 PT,涵盖观察第 4-5 场访谈,并由 Decider 在 17:30 PT 前完成评审)。

不适用场景

  • 星期四的原型未通过试运行。重新进行试运行;如果星期四 19:00 PT 时仍未通过,则推迟星期五的测试。
  • 确认参加的客户少于 3 位。根据已批准的决策 3,标准建议人数为 5 位客户;3-4 位或 6-7 位需记录警告;少于 3 位或多于 7 位则应重新决策(推迟或拆分测试)。注意:v0.1.0 系列验证器不会以机制方式强制执行这些阈值(群组人数记录在 EXAMPLE 工件中,而非前置元数据);强制执行是 v2.16 验证器扩展的候选项。
  • Decider 无法参加访谈后评审时段。没有 Decider,当天只能产出观察结果,无法做出决策。
  • 团队计划用此技能撰写高管备忘录。根据已批准的决策 4:高管备忘录撰写工作委托给 foundation-stakeholder-update(现有的 pm-skills 基础技能);此技能仅产出 Decider 摘要。

此技能的产出

一份包含六个部分的整合工件:

  1. 每位客户的访谈观察笔记:每位客户一节;涵盖对背景(第 2 幕)的反应、任务(第 4 幕)中的行为及时间戳、总结(第 5 幕)中的反应,包括定价。当天访谈进行时实时记录。
  2. 精彩引述:团队标记为最具信号价值的 5-15 条客户原话。用于 Decider 摘要,以及后续任何演示或规划工件。
  3. 评分表网格:行是冲刺问题(来自星期一);列是 5 位客户;每个单元格填写 Y / N / 部分 / 不明确,并附一行说明;最右列填写团队在当天结束时对每个问题的决定(已验证 / 已否定 / 无定论)。
  4. 观察到的模式:分为 4 类(有效、迟疑、信任受损、意料之外),每类包含 2-4 个模式。每个模式都注明有多少位客户表现出该模式。
  5. 个人直觉:每位团队成员用一小段话记录自己星期五的个人判断,以免小组综合讨论影响判断。在讨论前静默并行撰写。
  6. Decider 摘要:Decider 的决定(构建 / 迭代 / 转向 / 停止 / 重新界定),以及置信度最高的学习、团队对原型方向会做出的最重要修改,以及团队将产出的下一份工件(冲刺后的交付物)。

请参阅 references/TEMPLATE.md 了解标准结构,并参阅 references/EXAMPLE.md 查看 Brainshelf 图书目录星期五工件示例。

周五时间安排

周五是最长的一天:客户访谈一早开始(标准时间为 09:00 PT),Decider 评审在当天结束时完成(标准时间为 17:30 PT)。

  • 09:00-16:30:进行 5 场客户访谈,每场 50-60 分钟,时间分别为 09:00 / 10:30 / 12:00 / 14:00 / 15:30。每个时段安排:10 分钟准备 + 50-55 分钟访谈 + 5 分钟团队快速讨论,在下一位客户到来前记录观察结果。
  • 13:00-14:00:午餐(第 3 个时段约在 13:00 结束;午餐与第 3、4 个时段之间的缓冲时间重叠)
  • 16:30-16:45:完成最后一位客户的访谈;整理观察笔记
  • 16:45-17:00:团队成员并行、静默地写下各自的关键看法
  • 17:00-17:30:Decider 查看评分卡和关键看法;作出决定
  • 17:30-18:00:记录 Decider 总结;团队开始安排冲刺后的后续事项(下一步日程、下游交付物分配)

此技能的 270 分钟时间框涵盖综合分析环节(评分卡、规律、关键看法、Decider 总结)。5 场访谈本身(约 5 小时的访谈时间)与持续的观察记录并行进行。

评分卡机制

评分卡是一个二维网格。行对应周一确定的地图和目标中的冲刺问题(通常为 3-7 个)。列对应 5 位客户(使用匿名 ID)。每个单元格回答:这位客户的访谈是否验证、否定了该行的问题,或对此无法得出结论?

C1C2C3C4C5当日结束时的决定
Q1YYNYpartial已验证(4 人中有 5 人)
Q2NYunclearNN已否定(5 人中有 3 人为 N,5 人中有 1 人为 Y)
.....................

当日结束时的决定规则:

  • 已验证:5 人中有 4 或 5 人为 Y(强信号);5 人中有 3 人为 Y 且没有 N(方向性信号)。对于 4 人的客户组:4 个 Y 为“已验证”;3 个 Y 且没有 N 为方向性信号。
  • 已否定:5 人中有 4 或 5 人为 N。对于 4 人的客户组:4 个 N 为“已否定”;3 个 N 且没有 Y 为方向性信号。
  • 无法得出结论:其他所有模式。对此类问题安排后续跟进(进行规模较小的测试、定量实验或第二次 Design Sprint)。

Decider 可以推翻当日结束时的决定,但应记录推理依据。

常见问题

  • 观察笔记过于叙事化,而非描述行为。“客户似乎很困惑”是叙述;“客户将鼠标悬停在捕获按钮上 4 秒却没有点击,随后快速连续点击了两次”是行为。行为是数据;叙述是解读。
  • **通过共识填写评分卡单元格。**每位观察者都应填写自己对单元格的判断;应呈现差异,而不是取平均值。如果团队对 C1 的 Q1 判断分成 2 个 Y 和 2 个 N,该单元格应标为“意见分歧”,并附上说明。
  • **在小组综合分析之后才写关键看法。**小组综合分析之前,关键看法必须以静默、并行的方式写下。在小组复盘之后再写,只会产生共识,而不是信号。
  • **Decider 因为“我们想要更多数据”而犹豫不决。**周五的任务是根据已有数据作出决定。如果确实无法作出决定,那么决定就是“迭代”(调整后重新进行冲刺)。“推迟”不是答案。
  • **因为“我们周一再整理成文”而跳过 Decider 总结。**团队离开前,必须在周五记录总结。等到周一就太迟了;背景信息会迅速淡化。
  • **把“5 位客户”当作一个弹性目标。**根据标准研究,客户数达到 5 人时,对规律的信心会跨过拐点。少于 4 人会产生嘈杂的信号;超过 7 人则会导致综合分析负担过重,而边际信号增益不大。

跨技能使用

前置条件:tool-design-sprint-prototype-plan。周五环节会使用周四完成的原型和访谈脚本。若没有通过试运行的可用原型,周五环节便无法开展。

此技能不会调用 tool-note-and-vote。周五没有投票环节;评分卡中的各项由个人填写,Decider 摘要则由 Decider 决定。

根据已批准的决定 4,此技能不会撰写高管备忘录。如果团队需要高管备忘录或利益相关方更新,下一步应调用 foundation-stakeholder-update,并将 Decider 摘要作为输入。

冲刺结束后的后续调用:deliver-prd(如果 Decider 的决定是“构建”);measure-experiment-design(如果“迭代”需要开展规模更小的后续实验);iterate-pivot-decision(如果“转向”需要记录转向理由);foundation-stakeholder-update(如果上述任一事项需要与利益相关方沟通)。

权威来源

Decider 检查点

此技能以 references/TEMPLATE.md 中的 Decider 检查点结束。Decider 的决定(构建 / 迭代 / 转向 / 停止 / 重新定义)就是检查点;没有该决定,冲刺便无法结束。检查点还会记录团队负责产出的下一份成果(PRD、规模更小的实验、转向备忘录或利益相关方更新),以此触发周一的冲刺后工作顺利开始。

评论

支持 Markdown