课题设定表单
Issue definition worksheet
把问题转化为可执行课题，并记录目标、背景、对象和约束。
讨论混杂着症状、方案和愿望，需要先确定值得解决的具体问题时使用。把事实、影响、范围和约束写清楚。
具体事件或用户记录、受影响对象、时间范围、影响和资源约束。
一个有范围的问题定义、证据缺口和下一项调查。
先理解，再动手
使用步骤
把现象转为值得解决的课题，明确现状、期望、差距、证据、范围和约束。先定义问题和完成标准，不把某个解决方案提前写成唯一课题。
- 01
写清楚要解决的问题
- 02
定义期望结果和评价标准
- 03
记录相关背景、对象、范围和限制
- 04
补充已知事实、未验证假设和下一步调查事项
问题定义不等于指定解决方案；访谈样本不能直接代表市场比例。未确认影响、时间或责任时保留未知项。
看清框架结构
从一份空白提纲开始
复制到你的文档，填入真实的业务事实与判断。
查看空白提纲
课题设定表单 · 空白提纲 什么时候用：讨论混杂着症状、方案和愿望，需要先确定值得解决的具体问题时使用。把事实、影响、范围和约束写清楚。 需要准备：具体事件或用户记录、受影响对象、时间范围、影响和资源约束。 预期产出：一个有范围的问题定义、证据缺口和下一项调查。 使用边界：问题定义不等于指定解决方案；访谈样本不能直接代表市场比例。未确认影响、时间或责任时保留未知项。 工作问题： 期望结果： 已有证据与假设： 未知项与下一项核查： 填写说明：用待解决的问题表述课题。 1. 课题： 填写说明：有哪些事实和影响？ 2. 现状与证据： 填写说明：期望状态、指标和期限是什么？ 3. 目标与完成标准： 填写说明：现状距目标具体差在哪里？ 4. 关键差距： 填写说明：包括和不包括哪些对象或流程？ 5. 范围： 填写说明：资源、时间、权限等限制是什么？ 6. 约束： 检查清单 □ 课题表述能指导行动。 □ 目标和范围边界明确。 □ 已知事实与假设被区分记录。 考虑下一个框架 SMART: 已有范围明确的问题和基线，需要约定改善目标时，用 SMART 写出成功标准和测量窗口。 https://bizthinkframe.com/zh/frameworks/smart BizThinkFrame · https://bizthinkframe.com/zh/frameworks/issue-definition-worksheet
跟着案例走一遍
虚构教学案例给新手引导项目划定边界
组织、人物、数据和结果均为虚构，仅用于说明框架用法。
背景与问题
云桥的产品组有四周改进新用户体验，研发只能投入一人。
“提高用户体验”过于宽泛，候选需求已经超过十项。
手头有哪些材料
- 新团队七天激活率为 30%
- 四周周期，一名研发、一名设计
如何使用这个框架
- 将业务问题与本次可推进的课题分别书写。
- 把指标、对象、周期和投入放到同一张表中。
- 明确不纳入本轮的需求，避免执行中不断扩大范围。
形成可以排期和验收的新手引导课题卡。
课题卡写整齐了，仍可能有三种偏差
第一，课题只剩一个预定方案时，先退回问题。“做一个新看板”说的是实现方式，没有说明谁在什么情境遇到困难，也没有说明本轮需要支持什么决定。先写差距与待调查的任务，把方案保留为候选，不要规定调查只能得到“应该做”的结论。
第二，基线与目标口径无法对应时，不急着比较。团队七天激活率不能用访谈人数来核验，也不能把只观察两天的团队直接放进完整七天结果。需要保留入组条件、激活事件、窗口、排除项及缺失记录；没有的信息就列为核实任务。
第三，范围框不等于可以修改所有相关系统。调查中发现计费或权限依赖，应请有权决定的人重新确认范围，不能暗中塞进本轮。周期越短，越需要早说清这些依赖，而不是把边界留到验收时争论。
区分定课题、找解释和请求投入
课题卡用于把调查组织成可讨论的工作约定，是本站整理结构，不是经过验证的诊断量表。缺少的答案属于其他问题时，再选择相应方法。
| 问题与输入 | 方法 | 产出及限制 |
|---|---|---|
| 差距宽泛，资源有限，需求冲突 | 课题设定表单 | 有限课题、目标、不做事项与未知项。 |
| 指标有差距，需要排列解释分支 | 逻辑树 | 形成调查路径；分支仍需证据。 |
| 目标尚未明确如何测量与复查 | SMART | 写清目标与检查条件；不证明可达成。 |
| 已有产品应对方案、风险与估计 | 产品提案 | 形成投入或验证请求；不等于批准开发。 |
云桥的新手引导：把调查方向与根因分开
以下完整推演沿用虚构的云桥材料：四周周期，一名研发、一名设计，候选需求超过十项；当前新团队七天激活率30%，试点目标40%；访谈12人，其中7人不知道邀请入口。本轮只涉及注册后引导与邀请页，不改计费、权限模型与移动端。团队队列规模、访谈招募方式、具体激活事件都未给定。
先抄录事实，再写解释。7/12只描述这批受访者，不能改成七家团队，也不代表总体比例；30%则是团队指标，两者不能共用分母。反馈支持把邀请入口可发现性作为调查方向，并没有证明改入口就能填平激活差距。
据此把课题写为：在允许修改的页面内，调查管理员首次邀请同事的阻力。拟用原型请目标管理员在无提示情况下寻找并尝试入口，记录卡住的位置。这是待执行的观察程序，不是已经完成的测试；原材料缺失的采样条件也不能被顺手补成新事实。
| 已有记录 | 能够支持 | 仍需确认 |
|---|---|---|
| 基线30%，试点目标40% | 目标差距为10个百分点 | 合格团队、激活事件及相同观察窗口。 |
| 12名受访者中7人不知道入口 | 值得做可用性调查 | 采样偏差，以及与团队激活的关系。 |
| 四周，一名研发、一名设计 | 限定课题的资源边界 | 实际可用时间、批准与实现可行性。 |
| 只限注册后引导与邀请页 | 限定原型表面范围 | 依赖是否需要单独申请变更。 |
先约定怎样验证，再等待完整结果
课题卡先请求验证邀请入口原型，是否开发要看发现与相应决定。40%继续标为目标；在口径一致的前提下，30%到40%相差10个百分点，相对30%约增加33.3%。两种计算都不是实际改善，本例没有后续激活结果。
试点入组前，约定团队资格、激活事件、排除规则和缺失记录处理方式。第四周末加入的团队仍需完整七天，才能判断七天结果。可以延后复查，或把该队列标为待观察，不能为了按时交报告把未满窗口的团队算作失败。
复查分别记录原型发现、实际批准的范围变化、实际投入以及每个合格队列的完整结果。若入口更容易找到而激活没有改善，应重新检查二者的关系及其他障碍。课题调整保留版本与原因，让后来的人看见当时的依据，不倒改原始假设来制造“早就知道”的印象。
检查你的思考
再问自己几个问题
- 这个问题为什么现在必须作为课题处理？
- 解决完成后，谁会看到什么变化？
- 哪些范围不属于本次课题？
完成前的检查清单
- 课题表述能指导行动。
- 目标和范围边界明确。
- 已知事实与假设被区分记录。