在产品迭代的浪潮中，用户故事往往被迫做“功能型”填空：
『作为一个用户，我想要在 时间 内完成 操作 以便 得到结果 』。这听起来像一句英文句子，却隐藏了一个核心缺陷——它把用户视作被动的“操作对象”，而不是主动追求某个“工作”的主体。

这时，“工作‑完成”模型（Jobs‑to‑Be‑Done, JTBD） 就像一盏照亮思考的灯。它告诉我们：用户不是想要一项功能，而是想要完成某个目标（Job）——在特定情境下、带着一定情绪、并且想要解决痛点。

举例来说，传统故事写作时可能会说：
『作为一名常旅客，我想要快速登录，以便不耽误登机』。这条故事在表面上完整，却忽略了「快速登录」背后真正的工作：
『当我在机场熙熙攘攘的行李传送带前想要确认航班信息时，我想要在 10 秒内完成登录，以便马上拿到登机牌，避免错过航班』。

要把 JTBD 注入用户故事，先做三步：
1️⃣ 明确 Job：描述用户的主要目标和情境；
2️⃣ 明确 Desired Outcome：用户期望的结果是什么（比如时间、成本、情绪）；
3️⃣ 明确 Constraints：限制条件（技术、预算、市场）。
然后把这些点写进故事的三部分：
『当 情境 时，我想要 工作 以实现 期望结果，因为 约束』。

下面给你一个完整重写的例子：
原始故事：『作为用户，我想要快速登录』。
重写后：『当我在机场排队等候登机时，我想要在 5 秒内完成登录，以便立即获取登机牌，避免因排队时间过长错过航班』。

这么改动的好处很直观：
• 目标更聚焦，跨部门团队更易共识；
• 结果导向驱动技术决策（比如生物识别、单点登录）而非仅仅“加快速度”；
• 业务指标（登机率、NPS）与故事直接挂钩，跟踪价值实现更透明。

Netflix 的推荐算法就是 JTBD 的一个典型案例。
他们把用户的工作定义为：『当我感到无聊、没有时间筛选影片时，我想要一部符合我口味的电影，让我能立刻投入观看，节省时间并获得满足感』。正是因为这个“工作”定义，Netflix 投入数十亿研发资源，最终形成了“精准推荐”——直接驱动了用户粘性和收入增长。

然而，JTBD 也不是万能符。常见的误区包括：
• 把“情境”写成“功能需求”而不是“工作场景”；
• 忽视情感工作（比如“我想要在忙碌后感到轻松”）；
• 只靠数据而忽略用户访谈的深度洞察。
因此，团队在使用 JTBD 时，最好先进行至少两轮用户访谈，捕捉“为什么要做这件事”而非“怎么做”。

总结：把用户故事从功能型切换到工作‑完成型，等于给团队装上了“价值引擎”。它让每一次迭代都更接近用户真正想要的结果，也让业务 KPI 与产品工作对齐。你准备好在明天的 backlog 里，把那条“我想要快速登录”的故事改写成真正的工作故事了吗？