模糊 Jira 工单的隐藏成本
一个模糊的 Jira 工单，起初通常并不显得有风险。真正的问题会在后面出现：不同的人用不同的理解去补全空白，结果几天高强度的工作，最后却做偏了方向。
为什么模糊工单总能存活下来
周一早上，一位后端工程师接手了一个工单。标题看上去很具体：“为订单更新添加用户通知”。描述只有两句话，外加一个三周前的 Slack 讨论链接。表面看起来已经够清楚了。于是她花了三天时间，做了一套在订单状态每次变化时都会触发的邮件通知流程。
到了周四，在 PR review 里，产品经理看了一眼说：“我不是这个意思。我们只需要针对发货事件的站内通知，而且用户应该可以关闭它。” 没有人做错。也没有人偷懒。只是工单里原本藏着的那些关键决策，从头到尾都没有被真正写出来。
没有人会故意写一个模糊工单。它往往是夹在会议之间，两分钟内匆忙写出来的。写的人心里其实想着，等会儿再回来补细节。只是这个“等会儿”通常不会发生。写工单的人把完整上下文都装在脑子里。他知道哪些事件重要，想到的是哪些通知渠道，也清楚会影响哪些用户。
只是这些内容都没有真正落到页面上，因为在他看来，这些都“很 obvious”。可对其他人来说，并不 obvious。
Jira 之所以会放大这个问题，恰恰是因为它太容易用了。它没有强制字段来要求你写清楚哪些内容明确不在范围内。它也不会因为描述少于二十个词就拒绝提交。你完全可以只在 summary 里敲三个词，描述留空，然后点 Create。Jira 不会拦你。这既是它的优点，也是它的陷阱。于是 backlog 里堆满了看起来像是“已经写完”的工单，但真正开始做时，大家才发现它其实模糊得厉害。
一个真正可实施的计划，到底包含什么
大多数工单只回答一个问题：我们想要什么？一个真正可实施的计划，会回答六个问题。
| 部分 | 它回答的问题 |
|---|---|
| 范围 | 哪些内容在内，哪些内容明确不在内 |
| 约束 | 哪些东西不能改，也不能被破坏 |
| 步骤 | 需要发生什么，以及先后顺序 |
| 边界情况 | 当最直观的路径走不通时会发生什么 |
| 依赖项 | 哪些前提必须先存在 |
| 完成定义 | 团队如何判断这项工作真的完成了 |
这不是说 backlog 里每一个微小 bugfix 都要套这一套。但凡是要进入 sprint 的工作，但凡很可能会占掉某个人不止几个小时的时间，在开始前都值得把这六个问题说清楚。团队最容易跳过的是“范围”。当大家都在兴奋地讨论要做什么时，“什么不做”看起来像是多余的。可很多返工，恰恰就是从这里开始的。
约束条件，往往就是那些不声不响却非常真实的要求：
- 不能破坏现有的订单邮件流程。
- 必须继续使用当前的通知服务。
- 这个 sprint 不增加新的基础设施。
这些细节很少被写下来，因为写工单的人会默认大家早就知道。其实并没有。而“完成定义”就是那条分界线，区分了“我觉得已经做完了”和“我们所有人都认同这件事真的完成了”。一个好的完成定义，应该是看得见、验得了的。
问题先于结构
几乎每一个 Jira 环境，最后都会走到同一个循环里。有人加了一个描述模板，里面分成“概述”“验收标准”“技术说明”“不在范围内”等几个部分。刚开始几周，大家会认真填写。再过一段时间，原本写在空白描述里的那种模糊语言，只不过是被分散到了更多有标签的框里。结构变好了，但思考方式没有变。
模板解决不了这个问题，因为问题本身不是结构问题，而是认知问题。写的人并不知道自己漏掉了什么。一个写着“边界情况”的空白栏目，并不能帮助一个还没想到边界情况的人。真正有帮助的是问题。具体的问题，能逼着人做判断的问题。
下面这五个问题，尤其擅长把隐藏决策挖出来：
- 系统行为到底会发生什么变化？
- 主要的使用者是谁，他们想达到什么目的？
- 有没有哪种情况下，这件事本来就不该发生？
- 如果这次不交付，会有什么东西受到影响？
- 这适用于现有用户、新用户，还是两者都适用？
这些问题之所以有效，是因为它们既具体到可以回答，又宽泛到几乎适用于所有功能型工单。回答这些问题的过程，本身就是规划。模板只是这些答案最后落脚的地方。
一个完整例子
来看实际中会发生什么。原始工单非常短：“为订单更新添加用户通知”。描述只说用户在订单状态变化时应该收到通知，并附带一句备注，说视觉呈现要和设计确认。这足以让它被拉进 sprint，但远远不足以支撑有把握地开始实现。
只要一轮很短的澄清，事情就完全不一样了：
| 澄清问题 | 回答 |
|---|---|
| 哪些状态变化算重要？ | 只有已发货和已送达 |
| 用什么渠道？ | 这个 sprint 只做站内通知 |
| 用户可以关闭吗？ | 可以，默认开启 |
| 用户离线时怎么办？ | 把通知排队，等下次登录再显示 |
| 适用于已有订单吗？ | 不，只有新订单 |
| 如果投递失败怎么办？ | 重试一次，然后记录日志 |
十五分钟后，这个工单对所有人来说就只剩下一种意思了。更新后的版本有真实的范围、真实的约束、有顺序的步骤、明确的边界情况，以及可以验证的完成定义。还是同一个工单，但清晰度已经完全不同。差别不在于模板更好，而在于真正开始工作前，多花了一点点心思去问对问题。
AI 在这个过程里适合放在哪里
AI 不写工单。工单是人写的。但 AI 在流程中的某一个时刻非常有用：意图已经出现，但结构还没定型的时候。语言模型很擅长读一段模糊描述，然后追问一句：“有没有考虑过用户离线时会发生什么？” 它也很擅长把 Slack 讨论里零散的回答，整理成范围、约束和步骤。它还擅长发现计划里提到了数据库迁移，但依赖项清单里却没有写明应该由哪些人审核。
但 AI 不擅长替你的产品做决定。它可以问这应该是邮件、推送，还是站内通知。它不能决定对你的用户、你的 sprint 来说，哪一种才是正确的。它可以生成一段看似合理的完成定义，但只有真正理解产品的人，才知道那段定义到底对不对。
这个模式其实很简单：人做决策，AI 负责整理。人来划定范围，AI 来补捉缺口。Jira 里的 Just on Atlassian Marketplace，本质上就是围绕这个模式构建的：先澄清，再规划，再执行。手工做也一样成立。AI 只是把这个循环加快了。
今天就能用上的三件事
- 在下一个 sprint 开始前，从 backlog 里挑出最模糊的那个工单，在任何人开始写代码前，先把这篇文章里的五个问题问一遍。你几乎肯定会发现，至少有两个关键决策其实还没有真正做出。
- 把答案写成范围、约束和可验证的完成定义，不要放在另一个文档里，而是直接写回工单本身，因为真正实施这项工作的人会在那里看到它。
- 把上面的模板当成起点，而不是死规矩。它应该适应你们团队自己的表达方式，但那些问题不要跳过。如果你想看更大的背景，理解为什么当模糊工单被直接交给 AI 时，这个澄清步骤会变得更重要，这个系列的第一篇文章已经详细讲过 alignment problem： 为什么大多数 Jira AI 工具会让对齐问题更严重，而不是更好。
