怎样简洁明了地说清楚产品需求？

在《为什么我们总是说不清「需求是什么」》中，我们介绍了「需求的本质」，并大致介绍了三个描述需求的「结构化语言工具」。这篇文章，希望进一步跟大家分享其中两个工具：

任务规格书 Job Spec
任务故事 Job Story

工具一：任务规格书 Job Spec

「任务规格书」是比较完整又复杂的语言工具，实务中较少用到。呼应前面「产生需求的过程」，《创新者的窘境》一书的作者Clay Christensen 将任务界定为「用户在特定场景下想获得的提升」，任务一定和特定的情境脉络有关，他进一步说：

任务「使得」用户在特定「场景」中，能获得「提升」。
A job enables the progress that an individual seeks in a given situation.

如果要记录一个任务，他提出了「任务规格书」这个语言结构，其实也是个「文件结构」：

用户处在什么「场景」中？
想达成什么「提升」？想要的提升，有哪些功能面、社会面、情感面的任务？
有哪些进步的「阻碍」？有哪些焦虑和阻碍？
用户勉强接受哪些「不完美的方案」？我们必须赢过哪些方案？
如何定义良好提升的「品质」？为了品质，用户愿意做哪些「取舍」？

如果我们做完需求探索、用户研究，可以按照以上五个问题，做成一份 1–3 页的 A4 文件。因为这个结构相对完整、复杂、不够简洁，所以更适合以下情境：

当作「介绍用途理论」的工具。
产品或研究团队「交接、浓缩研究结果」的工具，先让读者看完较短的文字摘要，再进入各种 UX 工具、图表、影音呈现的研究结果，加速读者的理解速度。
专案或产品启动时，先提供更浓缩、更简短的叙述，然后提供前项摘要的连结，给「想进一步了解用户需求」的队友参考。

工具二：任务故事 Job Story

「任务故事」是目前最被广泛使用的工具，但也遭受很多用途理论研究者的批评，因为它过度简化，容易被误用。同时，提出者 Alan Klement 是个充满争议的人物，因此得罪了很多用途理论的开创者。不过，Job Story 仍然是个实用的语言工具。

下面这张图，简洁地说明了 Job Story 任务故事的结构：

任务故事的格式，用任务故事代替用户故事。

这个方法进一步被 Intercom 发扬，他们进一步解释 Job Story 任务故事：

When (Situation)：引发需求的场景
I Want to (Motivation)：用户在场景中的选择动机
So I can (Expected Outcome)：在场景中的期待提升

然后，他们会用 1–2 页 A4，提交一个名为 “Intermission” 的文件，当作一份产品/功能提案。在这份文件中，其中一段就是 Job Story，要能在几百字内讲完用户需求。推测 Intercom 之后就用这几百字的 Job Story 代表此产品/功能，在内部快速解释用户需求、沟通开发目的。

然而，实际上找出 Intercom 的 Job Story 案例，会发现几个问题：

某些 When 其实并没有说明 Situation，遗失了场景，只是把 As a user 改写成 When I am a user ，可以把 user 替换成各种画像、角色、职业等等；
例如，我们看过这种写法：When I am a Customer Support Manager… 和 When I manage a Customer Support Team…
Motivation 和 Expected Outcome 的重复率很高，有时根本可以删去一个。

如果有以上问题，那 Job Story 就丧失了意义。若能避开上述问题，任务故事就适合用在以下场景：

即时口头沟通时，把用户需求浓缩成 3 句话，跟队友说明。
放在任务或需求池中的 Description「任务描述」中，简短解释用户需求。
模仿 Intercom，当成 PRD 或产品/功能提案的其中一段，解释用户需求，勾起读者兴趣，进而去看更详细的「任务规格书」或「用户研究报告」。

这篇文章，介绍了二个「结构化语言工具」：

任务规格书 Job Spec
任务故事 Job Story

但这两个工具都有明显的缺点，如何弥补这两个工具的缺点呢？有没有更简洁明了的语言工具？

下一篇文章，小编将继续跟大家介绍最后一个语言工具「期望成果 Desired Outcome」，并且还会跟大家说明该如何串连这三个工具，以及如何和原有的工具一起相辅相成。

本文作者: Jason HOU
文章来源: Medium

「LigaAI」的趣味分享与敏捷实践… 请关注 LigaAI@CSDN，持续接收更多干货分享~ 进一步了解我们的产品，请访问 LigaAI -新一代智能研发协作平台