明道创始人任向晖3.3产品需求文档3.3.1开始撰写(组图)

本文来自《现代企业应用程序设计指南》一书的试点章节：第 3 章，“理解、分析和表达用户需求”。

欢迎阅读并提出改进建议，并在知乎上关注我。作者邮箱 phil.ren@mingdao.com

文/明道创始人任向辉

3.3 产品需求文档

3.3.1 启动产品需求文档前的准备工作

在软件产品设计领域，PRD（Product Requirements Document）是最重要的文档。很多产品设计师在接到设计任务后就迫不及待的开始写作，同时也非常关心PRD表格的完整性。网上也有大量公开的PRD模板，感觉填表就可以完成。但是，不要太仓促。在开始写PRD之前，我们需要通过与需求方的沟通和确认，提前就以下内容达成共识：

1）很明显，产品设计的目标是解决哪些用户的哪些问题，在实现企业的商业目的中起到什么作用？ （怎么办）

2）开发项目投入了哪些资源？可以有多少产品开发人员？给定的时间窗口多长？ （有多少资源可用）

3）我们要交付的最低产品是什么？是否有可以帮助衡量的基准竞争对手或其他产品？ （怎么做）

3.3.2个对珠三角的常见误区

1）状态要求混合不分层次，缺乏从总到分、从高到低、从粗到细的层次结构。这个问题通常是由于在起草 PRD 之前没有充分组织的讨论和总结造成的。结构化的脑图可以帮助团队在写作之前建立这种层次结构，或者作为 PRD 文档的一部分。

2）缺乏经验的设计师生怕遗漏，追求过于完整的PRD，不仅细化而且过度列出长期和非必要的需求，模糊了交付标准的界限。事实上，依赖PRD第一版的软件产品已经管理太久了。要么PRD需要不断迭代，要么需要建立PRD后续升级版本，设计者不需要追求PRD的绝对完整性。

3）设计师太过分了，没有描述需求，而是描述了解决方案。这看似是综合能力的体现，却为高产出的协作制造了障碍。根据专业分工的要求，产品设计人员应该专注于对需求和实现目标的描述，而不是代替架构师和工程师来设计具体的数据表结构和逻辑实现方法。

4）过度使用视觉辅助来描述需求的性质。产品设计师喜欢用脑图等图表来表达逻辑结构，但缺乏对需求本质的自然描述。虽然一张图值千言万语，但在需求文档中，除了参数、标准等具体的表格信息外，其他视觉内容主要起到辅助表达的作用。当然，另一个极端也是PRD文档容易出现的问题，就是缺乏对复杂需求的可视化辅助，导致管理人员和开发人员要花很长时间去阅读和理解。在意义、文字和图片之间，产品设计师需要根据实际表达的需要进行组合使用。

3.3.3 PRD的基本构成和扩展

我们已经做了很多讨论、分析和总结，下一步就是真正写第一个产品需求文档。一个优秀的PRD绝对不是来自于它的模板结构，也不取决于它的长度，而是用最小的长度让开发者准确理解产品的开发意图。一个相对标准化的珠三角总会包含一些不可或缺的内容。根据应用产品的性质，可能还需要更丰富的扩展内容。完整性和细节取决于设计和开发团队的成熟度和应用产品本身。重要性和质量风险。

下面列出了一个完整的 PRD 可能包含的所有模块，其中一些模块可以根据需要进行扩展。为了让您更清楚地了解每个组件的性质和作用，我们自始至终都使用了一个慈善筹款管理软件的示例。

1）开发目的

用最自然、最流行的语言来解释为什么要开发这个企业应用程序，以及它能给用户企业带来什么价值。这是看似简单但容易被忽视的部分。我们之前介绍过“三级需求分析”的方法，所以在“开发目的”一章中，“总体业务目标”应该用通俗易懂的方式表达清楚。

如果您正在为您的公司开发自定义应用程序，那么您需要向您的公司描述业务意义；如果你是一家软件公司，你正在开发一个软件产品，向目标服务客户公司描述它的价值。对于软件产品开发公司来说，开发产品的目的是为了进入某个市场，获得客户和收入并不是珠三角应该描述的开发目的。

让我们以软件产品开发的目的为例。比如一个慈善组织的筹款管理软件，可以用下面简洁的文字来明确开发目的。

帮助慈善机构管理筹款流程、捐助者资料和援助项目预算和实际支出信息，从而提高慈善机构核心工作流程的准确性和效率，增加筹款信息的透明度，提高捐助者的满意度和忠诚度。

2）服务受众

在本节中，产品设计师列出了产品所服务的多层次角色。他们是谁，他们有什么工作目标，这个产品将帮助他们解决什么问题。在枚举服务受众的角色时，要穷尽所有可能，不要使用“经理”、“普通用户”等模糊的角色名称。

继续上面慈善软件的例子，这个产品可以服务：

公关营销经理：使用捐赠者管理模块来管理捐赠者信息，根据自动规则定位和发送营销电子邮件。

筹款项目经理：通过捐助者和筹款管理模块记录筹款记录，并出具收据。

慈善项目经理：通过慈善项目管理模块管理支出并生成项目财务报表。

财务经理：审查和处理捐赠，记录和核实筹款记录，建立相关财务文件。

负责人：使用统计模块了解捐款分布情况，捐款人分布及行为分析，完成项目费用审批。

管理员：配置产品使用所需的参数、创建用户和分配权限。通常由负责人负责。

通过服务对象的列表，可以帮助我们不断建立产品需求，遍历可能的用户故事，设计必要的产品功能。同时对整个产品的开发规模也有更准确的预估。

3）命名约定

名称是所有产品技术文档的核心，其质量甚至会影响开发和编码。缺乏命名约定的文档可能难以编写或阅读。在 PRD 中，所涉及的主要数据对象、参数、概念、功能和用户操作应以标准化的方式命名和解释。这个名字一旦确定，就需要统一使用，在PRD文档全文、后期扩展的原型设计、研发沟通过程、未来用户帮助文档的编写中统一使用，不能统一使用随意更改。

用户入职和教育在企业软件中是一个非常困难的过程，命名是维护和加强这个过程的重要基础，否则以后编写用户帮助文档时会很混乱。

当然，PRD 的命名不必详尽无遗，只要应用程序中的唯一对象有命名约定即可。对于一般领域的一般概念产品功能需求文档模板，我们只需要在设计范式上达成一致即可。例如，“筹款”是需要在产品PRD中定义的功能模块，但命名约定中不需要出现“删除”和“导出”的概念。

4）用户故事

用户故事，也称为“用户场景描述”，是产品 PRD 在输入功能需求描述之前从非产品角度表达用户需求的一种方式。它完全是站在用户的角度，描述了使用产品完成未来一项重要工作的全过程。如有必要，也可以对未使用该软件产品的相应解决方案进行比较和说明，以便产品设计人员对软件产品将要解决的问题有更清晰的描述。

用户故事不需要涵盖所有的用户场景，只需选择那些核心的用户问题，尤其是那些占用户80%时间的20%用户场景。

让我们继续一个筹款管理软件的用户故事：

用户故事：募捐项目经理输入一批捐款信息

募捐项目经理通过与公关和市场部的合作，通过微信公众号获得了数百名捐助者支付的5万元捐款。微信支付后台已经导出了所有捐助者的订单和支付信息。捐赠者资料和联系方式已合并到一个 Excel 文件中，每笔捐赠有一行，其中已标记付款完成状态。

现在筹款项目经理需要直接通过软件导入这些捐赠记录。通过募捐管理的导入募捐记录功能，他直接上传Excel文件，系统会提示创建募捐项目批次。上传完成后会显示符合条件的记录数。导入时，将创建一个新的捐赠者（由 ID 号字段标识）作为新的捐赠者记录。在导入的捐赠记录中，已经标注了对应的募捐项目编号。导入完成后，系统会提示导入成功的记录总数、创建的捐赠记录数量和捐赠总额。筹款项目经理通过与原始数据的对比，确认导入工作已经完成。

通过这个例子，我们会发现用户故事的描述和产品特性的描述有相似之处，但侧重于不同的角度和细节。有用的功能设计的源头其实就是这些用户故事场景的还原。很多PRD往往会忽略用户故事的描述，直接进入功能特性的设计描述，容易出现用户体验上的重大故障。比如上面的例子，为什么要创建一个募捐项目批次，并在批次下导入具体的捐赠数据，这与用户的实际工作场景是分不开的。如果设计者将此功能设计成在线输入单条捐赠记录，或者不批量直接导入多行捐赠记录，都会让以后的用户陷入使用的痛苦中。

书面用户故事本身看起来并不复杂，相反，它可能是整个 PRD 文档部分中最人性化的部分。如果拿PRD文档给普通用户看，这大概是他们喜欢看、最容易理解的部分。然而，用户故事的写作并不依赖于好的写作，它来自于细致的用户观察和研究。在上面的例子中，如果不与多个慈善机构的筹款项目经理交谈，就不可能了解多个慈善机构工作中的确切痛点。而且，在实践中，大多数企业用户在主动描述需求时都不是很完整，一些对其未来使用至关重要的细节在表达需求时很容易被忽略。

一些产品设计师非常依赖他们的直觉，尤其是那些具有设计消费类应用程序经验的设计师。他们试图跳过繁琐冗长的用户研究，直接进入设计阶段，但在企业软件世界中，这是绝对不可能发生的。不研究医院工作人员和管理人员的工作是不可能设计出医疗服务管理应用程序的，不拜访工程项目经理是绝对不可能设计工程项目管理软件的。直觉在企业应用程序需求管理中的价值远低于其他领域。

5）功能组合

属性组合是PRD文档的主体。在明确说明开发目的、服务受众、建立命名约定、描述用户核心需求场景后，我们需要通过功能组合，完整详细地列出产品开发需求。

在编写本节之前，请务必重申，产品需求文档的主要受众是软件开发人员，因此请务必记住，需求是通过功能组合而非解决方案来表述的，这一点很重要。过于简单的特性描述并不能完全传达需求，但过于详细的特性描述也容易限制开发者解决问题的灵活性。

从特征图开始

为了有条不紊地描述一个复杂的企业产品的需求，首先需要通过大纲或视觉的方式，以一种逻辑结构的方式列出所有的特性。表格和脑图都是很好的表达工具，它首先勾勒出整体特征组合的全局分布。这和我们前面讲的产品需求的三个层次是一样的。事情越复杂，就越需要从简单的大局开始。

结合上面提到的慈善项目管理软件的例子，下图给出了这个应用程序功能集的简化可视化表示。通过思维导图绘制这样的图表会很有条理。脑图还可以表达用户的基本使用路径与产品功能特征之间的联系。

如果开发一个 web 应用程序，这个特征图基本上相当于一个未来的站点地图。设计特征图没有绝对的格式要求，只要能清楚地表达各个功能特征之间的逻辑包含关系，就可以作为特征组合部分的指导目录。开发人员将很乐意打印此地图并将其贴在办公桌上，并在整个产品开发周期中频繁使用。后端和前端开发者都需要这样一个序列来评估开发工作的工时和进度，如果可以的话，如果这个map条目用数字编号，例如1、2、2.1、< @2.2，沟通的秩序会进一步完善。

页面组件

因为现在绝大多数企业应用都是基于Web的，即使是移动应用也可以称为页面或屏幕，所以我们可以用“页面元素”来指代软件界面中的组件。

在功能组合部分，页面元素是核心内容。它的性质可以用两句话来概括：

1）用户可以在页面上看到什么？

2）用户可以在页面上做什么？

可以在章节结构中使用页面元素的简化表示来详细说明前面列出的特征图中的页面。例如，示例中的筹款管理页面需要包含以下内容：

用户流

对于复杂的软件产品，仅仅依靠特征图和页面元素可能是不够的。不同的用户角色可能需要完成各种任务。仅仅列出页面或窗口仍然无法说明用户的使用过程和期望。这时候可以选择增加“用户使用流程”的专门章节，详细描述核心用户任务。

有两种方式来表达用户的使用过程：文字和图形，设计者可以根据自己的需要进行选择。文本模式下的用户使用流程以用户的任务名称开始，然后依次使用步骤 1、2、3 来描述用户想要的交互路径。

例子：

流程 1：创建筹款项目

在首页点击筹款管理，点击“创建”，进入新的筹款项目创建页面。填写完成后提交添加募捐项目成员，并指定更多管理员选择或添加相应的财务主体。需要导入筹款记录吗？

7.提示项目创建成功

当然，文字的流程描述也很容易用对应的流程图来表达。在这样的用户使用流程图中，可以约定用矩形框来表示对应的页面或窗口名称，这样用户使用流程的描述就可以与前面的特征图和页面元素中的名称相对应。

在复杂的企业软件中，有时完整的用户使用过程非常复杂和冗长。这时候就要按照一定的阶段来划分流程，分段表达，否则读者使用起来会很困难。下图中的用户使用流程来自于一个复杂的企业工作流软件，如此复杂的表达方式只是呈现了整个使用路径的一部分。

原型

我们终于进入了原型设计部分，这是功能组合部分的最后一部分。这部分是很多产品设计师特别熟悉的。许多软件产品设计师整天都在使用 Adob​​e 的设计工具，输出的大部分是原型设计图稿。但是，在开始制作原型之前，我们在非视觉内容上花费了大量笔墨。

为什么企业应用程序不能直接从可视化原型开始？与消费者应用相比，企业应用很难依靠纯可视化原型来解释软件开发需求，因为交互和可视化原型背后的逻辑很难解释，因为不同的数据状态需要比个人更多的容错处理。应用程序要复杂得多。更重要的是，企业应用质量的核心真正在于它的可靠性和准确性。界面的美观和易用性当然是我们追求的重要目标，但没有可靠性和精确性就一文不值，因为它无法帮助用户完成任务。

虽然我们不能仅仅依靠视觉原型来阐明需求，但拥有直观的原型设计可以帮助说明流程。有了它，还可以帮助节省PRD的文字空间，开发团队可以更准确地理解设计意图。

在这个行业中，产品架构师、界面设计师和交互设计师可能都需要进行原型设计。而且，即使是客户和老板也喜欢用原型来表达或确认需求，但他们提供视觉设计的程度却大相径庭。在一个分工完整的团队中，完整的原型设计和交互设计最好由专业的交互设计师主导。在产品需求的逻辑端完成后，专业的视觉设计师可以保证交互界面对称、一致，并添加情感元素。

现在，由于交互设计范式库的构建（我们将在后面的章节中介绍设计范式）和交互设计工具的开发，更多的设计成员可以更容易地提供高保真设计原型。高保真原型不仅可以用像素级标准固化需求，还可以提供用户动作的模拟反馈，甚至是运动效果。然而，对于绝大多数企业应用来说，高保真原型的主要价值并不是提供严格的需求规范，而是为客户提供可预测和可感知的效果。过分强调高保真实现会限制开发人员在使用解决方案和进行合理权衡方面的灵活性。从最大化团队协作输出的角度来看，块图和高保真图都是可接受的原型设计解决方案。

一些团队还开发了结合用户流程和原型设计的模式。通过原型中UI元素之间的连接线或索引号，将用户使用产品的过程直接叠加在原型图上。团队只要能很好地沟通和工作，也是提高协作效率的一种方式。下图是视觉和文字结合完成度比较高的原型。

从特征图、界面元素、用户流程到最终的原型图，包括它们的组合，就是清晰完整地表达一个软件实现的具体要求。企业应用程序使用的表达式组合完全取决于项目的内在需求。一般来说，复杂、高风险的产品会需要更完整的表达，而难以协同开发的产品（如两家公司之间）也需要高度完整的需求描述。反之，如果是一个比较小的产品，一个不敏感的关键系统，一个合作度高的团队，可以选择性地使用这些表达工具，而不是全部使用。

但无论产品文档多么完整，产品设计师总是需要与开发人员和客户建立高频的面对面交流。毫无疑问，传达的需求越完整准确，产品实现的质量就越高。

Next PRD 有两个可选模块，可以帮助进一步说明应用程序开发需求，这两个模块都旨在让我们更清楚地了解我们希望如何做好产品。

6）竞争基准

顾名思义，Competitive Benchmarking 部分需要列出应用所针对的产品，标明他们可以参考的产品特性和实施标准。对于一家产品公司来说，这一点至关重要，因为我们不仅要设计具有明确需求的产品，还要设计出超越竞争对手的产品。

当然，每家公司都有自己独特的优势，所以竞争标杆不是列出一堆竞争对手的产品名称，而是针对每个功能指出目标产品。例如，在“用户管理”中超过或达到A，在“活动管理”中超过或达到B。竞争基准的建立也可以帮助我们减少规范中的空间，因为有时，竞争产品的存在实际上提供了一个参考原型。

但是，为每个功能建立基准可能没有商业意义。任何软件产品首先都必须有自己的独特性产品功能需求文档模板，并在一些优势特性上脱颖而出。对于一般特性、配套模块或难以区分的部分，通过其他优秀产品的校准是完全合适的。尤其是企业应用产品如果能够选择一款消费类应用产品的优秀体验作为标杆，对于提升用户交互体验是非常有帮助的。

7）发布标准和时间要求

在实践中，应用产品的最低交付标准很可能不会在设计阶段确定。同时，为了让开发者更容易规划一个完整的架构，规范中可能会包含一个需要增量实现的特性列表。因此，在 PRD 的末尾或使用单独的文件来指定应用程序发布的最低要求。如果计划连续发布多个版本，也可以匹配相应的时间要求。

团队经常在产品的最低交付标准上存在分歧。有时需求方认为最低标准太简单，需要添加功能，有时设计师认为我们不应该在第一个版本中打包这么多功能。这种争执可能是企业应用程序设计中最普遍的团队分歧。

这些争议似乎很难有一个客观的标准，但造成这些争议的主要原因是团队在本章开头所要求的明确产品目标上没有达成足够的共识。我们可以再回头看看。在编写 PRD 之前，团队需要澄清：

1）很明显，产品设计的目标是解决哪些用户的哪些问题，在实现企业的商业目的中起到什么作用？ （怎么办）

2）开发项目投入了哪些资源？可以有多少产品开发人员？给定的时间窗口多长？ （有多少资源可用）

3）我们要交付的最低产品是什么？是否有可以帮助衡量的基准竞争对手或其他产品？ （怎么做）

理想的工作方式要求我们努力就项目的定义达成一致，而不是在开发后期争论这些问题。在项目开始之前，团队成员和管理层可以保持清醒的头脑来沟通和决定这些目标和交付标准。一旦项目展开并且需求开始以更具体的术语表达，就会有增加和更改需求的冲动。父亲说大众有道理，母亲说母亲有道理。这就是为什么我们要早起识别和记录以上三点。在许多情况下，控制项目边界的任务落在了产品设计师身上。

任何交付标准都与支持资源有关。对于软件开发，资源是指人力和时间。因此，设计师需要对开发团队的人员分布和资源状况有一个清晰的了解，才能把控项目的边界。

也有人认为软件产品应该是敏捷和迭代的，而不是拘泥于项目定义。这种观点混淆了新产品开发项目和长期产品改进之间的区别。对于任何一个企业来说，一个IT系统能否投入销售或使用，直接影响到它对业务产出的影响、需要协调的营销和销售投入、操作系统等协同事务的建立、初始交付标准和时间。要求没有太大的容忍度。但应用上线后，根据初始版本和用户实际反馈，不断迭代改进是完全不同的逻辑。所谓SCRUM敏捷开发模式主要是指后者，而不是一个新软件产品的初始构建过程。

3.4 产品需求设置检查表

我们在“需求”方面投入了大量篇幅，这是限制企业应用程序开发和交付质量的来源。大多数失败的软件开发都可以追溯到需求分析和呈现阶段的重大缺陷。因此，作为本章的总结，我提供了一个 9 点清单，这是一个帮助设计师在最终需求阶段评估其工作质量的工具。