尽管用户故事（User Story）很有用，但其并不适用于所有团队。对于某些团队来说，工作故事（Job Story）是一个令人兴奋的替代方案。工作故事不太关注使用功能的用户，而更关注待办工作。工作故事起源于对讲机项目，艾伦•克莱门特（Alan Klement）对此做出过最好的解答。 工作故事模板 为了弄明白工作故事是如何从关注用户转变为关注待办工作的，让我们看一看所推荐的工作故事模板： 
- 当订单提交后……
- 当通过邮编搜索时……
- 当查找不到匹配信息时……
- 当正在查看近期订单时……
工作故事模板的第二个要素紧随着“我想要（ I want to）”，用于提供故事的“动机（motivation）”。可以把“动机”视为用户的既定目标或第一目标。
例如，我想今天晚上吃披萨。为什么今晚我会想吃披萨呢？因为今晚我约了些朋友一起看足球赛，而披萨易于让我们这群有着不同饮食需求和偏好的人吃饱。在这个工作故事的语境中，“易于让我们这群人吃饱”就被称为“期望结果”，它紧随着模板中的“以便我能（so I can）”。
如果把我想吃披萨写成工作故事，会是这样：
▪当今晚吃饭时，我想要吃披萨，以便我能易于让我的朋友们吃饱。
这并不是一个特别完美的工作故事，但它仍能说明“用户动机”与“预期结果”之间的差异。
对比工作故事和用户故事
为了弄明白什么情况下工作故事会比用户故事更适用，让我们看一些工作故事及其等价用户故事的实例。
当订单提交后……
让我们从这个工作故事开始：
工作故事：
▪当订单提交后，我想要看到一个警示信息，以便我能避免重复提交订单。
这个故事描述了在大多数电子商务网站都能看到的行为——警告用户不要重复提交订单。
等价的用户故事可能会是
用户故事：
▪作为一名消费者，我想要被显示一条信息，告诉我不要重复提交订单，以便我不会重复下单。
在这个例子中，有两个因素使得工作故事更适用。首先，本故事适用于在网站购物的每个人。因此，明确说明相关人员是一个消费者就不太重要了。（事实上，把相关人员称为“消费者”可能是一种误导，因为在下单前相关人员或许算不上是“消费者”。）
第二，工作故事相对更好是因为其额外提供了关于这件事情该何时发生的上下文信息——它发生在“当订单提交后”，因为工作故事已经明确告诉我们这一点。再看看用户故事，你会发现它并未告诉我们该何时显示信息。开发团队可能会通过在FAQ页面上添加一条警示条目——“不要重复提交订单”——来“成功”地实现用户故事。但几乎可以肯定，这绝不会是产品负责人想要的结果。
当订单提交后……
再让我们看下一条工作故事，是关于通过美国邮政编码来搜索地址的。
工作故事：
▪当通过美国邮政编码搜索时，我想被要求输入5位或9位数字编码，以便我不会浪费时间去搜索一个明显无效的邮政编码。
这个故事描述的是：在允许搜索前，如何确保用户输入合理的邮政编码（美国邮政编码是5位或9位的）。对这个故事而言，如果在邮政编码字段只输入了2个数字，用户将无法点击“搜索”。
等价的用户故事会是
用户故事：
▪作为一名买家，我想被要求输入5位或9位数字编码，以便我不会浪费时间去搜索一个明显无效的邮政编码。
这两个故事表明用户故事与工作故事间的差异存在于模板的第一部分。在本示例中，用户故事和工作故事的形式，只有“当……”和“作为……”从句是不同的，其余部分都相同。
同前一个示例一样，在这里工作故事更为适用，因为其额外提供了故事该何时被执行的上下文信息。而执行动作（也就是本示例中的搜索）的角色（用户故事中通常写成“作为……”的内容）并不重要。
该何时使用工作故事
在判断该何时使用工作故事时，我认为更重要的是要承认用户故事和工作故事各有所长。
我还发现，如果产品存在许多显著不同的用户，深入理解用户角色就会非常重要，这种情况下用户故事最有用，而这也是用户故事以“作为……”开头的原因。我们以这种方式作为用户故事的起始部分，是为了把用户角色置于首位。如果完成故事的人与其要做的事是同等重要的，就选择使用用户故事。
相反，对于工作故事而言，并不强调完成故事的角色。这使得当您产品用户的需求差异不大时，工作故事会是更好的选择。
如果您曾经写过冗长的用户故事集，并且每个故事都以“作为一个……用户”开头，那么您就会遇到了这个问题：当一大堆用户故事都以“作为一个……用户”开头时，您会获得一组用户角色都不太重要的故事。
这种情况下，将这些故事写成工作故事而不是用户故事，会更加有用。这样做，故事会额外包含何时执行的上下文信息。在某些情况下，知道故事何时发生，比知道谁来执行故事更重要。
结合工作故事和用户故事的优势
因此，既然工作故事和用户故事各有所长，就可以将它们结合起来，在故事描述中汇集两者的长处。让我们回顾一下邮政编码故事，看看如何做到这一点。
首先，我们有工作故事：
工作故事：
▪当通过美国邮政编码来搜索时，我想被要求输入有效的邮政编码，以便我不会浪费时间去搜索一个明显无效的邮政编码。
不清楚谁会执行这个故事。是普通用户、网站管理员，或者别的什么人？故事描述中并没有告诉我们。如果认为知道谁来进行此操作是很重要的，我们可以通过在故事中添加用户角色来（代替原本故事中的“我”）来扩大工作故事。这会使我们的故事描述变更为以下内容：
工作故事：
▪当通过美国邮政编码来搜索时，买家想被要求输入有效的邮政编码，以便其不会浪费时间去搜索一个明显无效的邮政编码。
文字修改之处以粗体突出。您能看出，我只是把“我想要……”改成了“买家想要……”，以及随后在故事后续部分做了相应的修改。
我们也能对用户故事进行类似的修改。初始、未修改的用户故事是：
用户故事：
▪作为一名买家，我想被要求输入有效的邮政编码，以便我不会浪费时间去搜索一个明显无效的邮政编码。
为了提供额外的上下文信息，我们增加一段话，用来告诉我们买家何时会做这件事。然后修订后的用户故事就会变成这样：
用户故事：
▪作为一名正在通过邮政编码搜索地址的买家，我想被要求输入有效的邮政编码，以便我不会浪费时间去搜索一个明显无效的邮政编码。
修订后的用户故事和工作故事在语义上是完全相同的。选择哪一种完全取决于您自己。我个人更喜欢修订后的用户故事而不是修订后的工作故事，因为它能使故事保留第一人称。我已经在其他场合阐述过故事采用第一人称的好处。
该何时使用用户故事
因此，何时您会更偏爱用户故事或工作故事呢？
首先，每种形式都很棒、有其优势。一直以来，无论是用户故事还是工作故事，我都在写。两种技术是完全兼容的，没有理由认为其水火不容。
如果您的产品存在多种用户，并且这些用户的需求在关键方面存在差异，我会推荐用户故事。用户故事额外重视执行动作的人员，进而会引发对用户行为的洞察。
然而，如果您的产品用户在关键之处并无差异，工作故事就可能会是更好的描述方式。
一个很好的开始是：在一个产品待办列表中同时纳入用户故事和工作故事。任何时候，如果您要写一批以同样“作为……用户”开头的故事集时，建议一开始就采用工作故事。
您的经验是什么？
您如何看待工作故事？它们对您的产品待办列表有帮助吗？您之前工作中使用过工作故事吗？它们有帮助吗？请在下面的评论部分中分享您的想法。
作者： Mike Cohn
译者：李洁（Jerry Li）
原文链接：Job Stories Offer a Viable Alternative to User Stories
