故事 · Intercom 团队的改写
Origin Story · Paul Adams and Alan Klement at Intercom
客服软件公司 Intercom 的 Alan Klement 带团队写需求时撞了墙：用户故事开头那句「作为某某角色」逼着大家先去定义「这是哪类用户」，
中间那句「我想要某个功能」又把答案提前钉死 —— 还没开始讨论，方案就被写进了需求里。
于是他们改写成任务故事：去掉角色，换成「当我处在某个情境下」；去掉功能，换成「我想达成某个目标」。
一句话之差，团队的讨论从「谁该用哪个按钮」转向了「人在那个当口到底想干成什么」。
方案不再是前提，而是留给设计去回答的开放问题 —— 创新的空间，就是这样被那句没写出来的话腾出来的。
At customer messaging company Intercom, Paul Adams and Alan Klement kept hitting the same wall writing requirements: the opening "As a [role]" pushed the team to label customers before understanding them,
and the middle "I want a [feature]" pre-committed to a solution before the conversation even started — the answer was baked into the ask.
So they reshaped it into the job story: drop the role, replace it with "When I'm in this situation"; drop the feature, replace it with "I want to achieve this outcome."
One sentence of difference and the conversation moved from "which button does which user tap" to "what is this person, in this moment, actually trying to get done."
The solution stopped being a premise and became an open question for design to answer — the room for innovation came from the line they refused to write.
1 同一需求，两种写法并排生成 Same requirement, two formats side by side
点左侧高亮按钮2 逐句拆：每一格在说什么 Clause by clause: what each one says
用户故事在锁什么What the user story locks down
任务故事在锁什么What the job story locks down
任务故事故意留白的「方案」 → 创新空间
The "solution" the job story deliberately leaves blank → the room for innovation
3 现实里的两种需求写法 The two requirement formats in real life
用户故事：「作为…我想要…以便…」。绑角色 + 绑方案，适合方案已定、要拆活排期的执行阶段。
User story: "As a [role], I want [feature], so that [value]." Locks role and solution — best when the solution is decided and you're slicing tickets for the sprint.
任务故事：「当…我想…以便…」。只锁情境与结果，适合还在探索「该做什么」的发现阶段。
Job story: "When [situation], I want to [motivation], so that [outcome]." Locks context and outcome only — best when you're still in discovery, figuring out what to build.
留出方案空间：不预设功能，团队才会问「为什么」、才可能想到更好的解法，而非默认第一直觉。
Leave room for the solution: without a pre-baked feature, the team is forced to ask "why" and can land on a better answer than the first instinct.
聚焦情境：同一个人在不同情境下任务不同。任务故事用「当…」把情境讲清，比贴一个角色标签更有指向。
Anchor on situation: the same person has different jobs in different moments. "When..." pins the context far more precisely than slapping a persona label.
一句话In One Line
用户故事最隐蔽的代价，藏在那句「我想要[某个功能]」里 —— 它把方案当成了需求的前提，
团队还没讨论就默认了第一个想到的解法。任务故事只做一件事：把那句方案删掉，换成一个开放的目标。
于是讨论的焦点从「谁要用哪个按钮」回到「人在那个当口，到底想干成什么事」。
这不是说用户故事错了 —— 方案定了、要拆活排期时，它依然好用。而在还该探索「做什么」的阶段，少写一句方案，才留得住创新的空间。
写需求时先问自己：我是在描述目标，还是已经悄悄把答案钉死了？
The hidden cost of the user story hides inside "I want [a feature]" — it smuggles the solution into the requirement,
so the team defaults to the first instinct before any real discussion. The job story does one thing: delete that solution clause and replace it with an open outcome.
The conversation snaps back from "which button does which user tap" to "what is this person, in this moment, actually trying to get done."
This isn't a claim that user stories are wrong — once the solution is decided and you're slicing tickets, they still work great. But in the stage where you should still be discovering what to build, writing one fewer solution is what keeps room for innovation.
Before writing your next requirement, ask yourself: am I describing the goal, or have I quietly pinned the answer already?
常见误用Common Mistakes
任务故事里偷偷塞进具体方案（「我想点这个红按钮」）。只写想达成的结果，把「怎么做」留给设计。
Sneaking a concrete solution into a job story ("I want to tap this red button"). Write only the outcome you want; leave "how" to design.
以为任务故事能取代一切用户故事。方案已定、要拆活排期时，用户故事依然好用，看阶段选。
Assuming job stories replace user stories everywhere. Once the solution is decided and you're slicing tickets, user stories still earn their keep — pick by stage.
「当…」那句情境写得空泛（「当我用 App 时」）。情境越具体越有指向：「当我赶时间又单手操作时」。
Writing a vague "when..." clause ("when I'm using the app"). The more specific the context, the sharper the direction: "when I'm in a rush and using one hand."