关于撰写功能需求

我被要求领导一个团队的产品开发工作。 这对我来说是一个全新的旅程，因为我通常习惯于 称自己为网页设计师，而不是产品经理或策略师。

这份工作中最难的部分是整理我的思路。 我已经为我们正在构建的产品编写了执行摘要，做了一些竞争对手研究，甚至为了进行 SWOT 分析 而重新拾起了我有限的 MBA 教育。哦，是的，现在看起来我好像知道自己在做什么了！

我们许多定期阅读 CSS-Tricks 的人可能都需要进行战略思考才能胜任自己的工作，无论是在设计、开发还是两者兼而有之。 然而，我发现，战略性思考与战略性行动完全不同。 战略性思考是一个停留在你脑海中的内部过程，而战略性行动则需要精心策划，以及能够以团队成员可以共享和理解的方式记录内部想法的能力。

当我坐下来为这个项目编写功能需求时，思考与行动之间的差异从未像现在这样清晰地呈现在我面前。 我认为我应该分享一下我在早期撰写需求时学到的东西。

在我开始之前，我想说的是，处理功能需求的方法有很多。 我即将分享的内容主要借鉴了我从网络上搜寻答案，并以适合我的方式将它们拼凑在一起的一些片段。

认识你的偏见

我必须学会接受的第一件事是，我在处理需求时存在偏见。 我是一名网页设计师，因此，我的思维倾向于事物的视觉方面。 我可以整天素描线框图和制作模型，但并非团队中的每个人都以这种方式看待或思考问题。

偏向于视觉思维并没有错，但认识到这一点并记住你的文档需要对其他人有意义是很重要的。 就我而言，我非常喜欢绘制布局草图，并绘制一堆代表用户如何浏览产品的正方形。 这帮助我将想法从脑海中提取出来，以便开始记录它们的过程。 你的过程可能是项目符号列表或图表。 使用对你来说有意义的方法，并知道你需要为其他人翻译这些工作。

讲故事

我还了解到，将功能视为故事来思考非常有帮助。

想想看：一个故事有一个主人公（用户），她发现自己身处某种境地（用户流程），然后遇到一个引发事件（要完成的任务），以便找到解决方法（预期结果）。 谁知道史蒂芬·金一直以来都是撰写功能需求的大师呢？

到目前为止，我的过程是列出所有关键的产品功能，然后从最终用户的角度讲述他们如何使用每个功能的故事。 我们的团队将这些称为用户故事，每个功能可以包含一个或多个故事，具体取决于用例，少则一个，多则十几二十个。

用户故事很棒，因为它们迫使你从用户的角度思考，并专注于预期结果。 假设我们正在编写帐户创建的需求。 以下是我们构建每个用户故事的方式

作为…	我期望…	以便…
[识别用户]	[描述任务]	[解释预期结果]

假设我们正在编写帐户创建的需求。 以下是如何编写一个用户故事的示例

作为…	我期望…	以便…
任何新客户	我可以使用我现有的 Google 或 Facebook 帐户进行注册	我可以更快地注册并管理更少的帐户

我在这里要插一句，这项练习要求你对你的用户是谁有非常好的了解。 当然，上面的示例相当通用，因为它针对的是“任何新客户”，但是，仔细思考你的用户是谁，记录他们的个性，甚至为他们取名字，这将使你能够在编写用户故事时更加具体和有上下文。 MailChimp 有关于他们创建用户角色过程的 精彩文章，对我来说非常有帮助。

记录用户流程

如果用户故事有助于为功能需求设定期望，那么用户流程则提供了用户如何到达那里以及在完成任务后最终到达何处的上下文。

回到我个人对视觉思维的偏见，对我来说，用图表来查看它是最有意义的。 然而，我知道并非每个人都像我一样思考，因此我一直都在概述用户完成任务所需的步骤，并使用图表来说明更复杂的流程。

以下是我如何为我们之前在帐户创建功能中使用的社交登录用户故事编写流程

用户流程 ID	描述
UF-1	客户响应营销网站上的号召性用语以创建帐户
UF-2	客户选择在“帐户注册”屏幕上使用 Google 或 Facebook 帐户注册新帐户
UF-3	客户选择 Facebook 或 Google
UF-4	系统提示客户通过验证其身份来授权使用其选择的帐户注册帐户
UF-5	客户可以 拒绝授权，并被引导回到“帐户注册”屏幕 批准授权，并被引导到用户故事 2

请注意，每个步骤都分配了一个 ID，每个 ID 可以分支到子任务中。 这些 ID 有助于在与团队中的其他人讨论时能够参考文档中的特定点。 这当然会变得很混乱，这时一个漂亮的图表就能派上用场了。

记录需求

学习如何编写需求中最疯狂的部分是，在你真正开始编写需求之前需要进行多少预先思考。

一旦确定了功能，编写了用户故事并概述了流程，我就进入实际的需求阶段，使用与用户流程相同的格式。

同样，回到我们的社交登录示例，一些简单的需求可能是

需求 ID	描述
RQ-1	一个 Google Analytics 漏斗来衡量转化率和流失率
RQ-2	OAuth 集成
RQ-3	Facebook 和 Google 选项

你可以根据需要详细说明。 我尽量保持谨慎，尽可能多地编写需求，同时又尽量避免过于严格地定义，以免在设计和开发过程中扼杀创造力。

对假设保持透明

我了解到，我做出的每一个决定都充满了假设。 很难意识到所有的事情，但是承认你可能认为理所当然的任何事情都很重要，因为它为决策过程提供了一个窗口。 记录假设可以让其他人了解你的逻辑，并提供一个机会来引发进一步的讨论。

让我们在我们的运行示例中记录一些假设

假设 ID	描述
AS-1	社交登录是有价值的。 MailChimp 写了一篇 很有说服力的文章反对使用它们，但这篇文章可以追溯到 2012 年，他们后来承认这可能有用，具体取决于网站。
AS-2	这篇来自 2015 年的 TechCrunch 报道 仍然有效，即 Google 和 Facebook 是最常用的社交登录方式，其他登录方式对于我们来说过于边缘化，不适合在初始发布时考虑。
AS-3	我们将存储此信息，并在用户登录到她选择的社交帐户时一直保持用户登录状态
AS-4	我们将希望鼓励使用此选项而不是电子邮件选项，因为它可以节省时间。

相信我，我没想到一个看似简单的任务会包含如此多的假设！ 这真的很有帮助。

注意可能的约束条件

约束条件是指可能超出你控制范围的限制。尽早确定这些限制可以帮助团队中的其他人进行计划。我发现请其他人帮忙识别约束条件也很有帮助，因为有时候你不知道自己不知道什么。

约束条件 ID	描述
CT-1	Google OAuth 2.0 限制
CT-2	Facebook 关于 网页权限 的指南

示例文档

我整理了一个 Google Doc，将所有这些概念整合在一起。任何时候当你需要编写功能需求时，都可以随意将其用作起点。

查看文档

总结

我真心希望这对任何正在摸索功能需求的人有所帮助。如前所述，这里没有任何内容旨在具有规范性。这仅仅是我在产品开发初期旅程中发现有用的内容。

也就是说，你可能会发现以下一些额外资源很有帮助

• 实用设计发现：Dan Brown 在 A List Apart 上撰写了一份全面的指南，介绍如何将设计需求分解成团队可以团结一致的解决问题的原则。
• 编写脚本：Chris 在回复 Jeremy Keith 的帖子时写下了这段话，提醒我们代码需求可以写成遵循代码结构的叙述。
• Sketch 与 Figma： Christian Krammer 比较了这两个用于线框图的应用，并说服我尝试使用 Figma。