怎样写好一份高质量的产品需求文档 PRD

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

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

文/明道创始人任向晖

3.3 产品需求文档

3.3.1 开始撰写产品需求文档前的准备

在软件产品设计领域，PRD（产品需求文档）是最重要的文书。很多产品设计人员在接到设计任务后会急于开始撰写，同时非常在意PRD形式的完整性。在互联网上，也有大量的公开PRD模版可以获得，感觉可以按照填表格的方式来完成它。但是，不要过于着急。在开始撰写PRD之前，我们需要通过和需求方的沟通和确认，事先对以下内容达成了共识：

1）明确了产品设计的目标是为了解决哪些用户的哪些问题，它对企业的商业目的实现起到了什么作用？（要做什么）

2）开发项目的投入资源怎样？可以有多少产品研发人员？给出了多长的时间窗口？（能有多少资源）

3）我们要交付的最小化产品要达到什么标准？是否有对标的竞争对手或者其他产品可以帮助衡量？（要做到怎么样）

3.3.2 PRD的常见误区

1）混合而不分层次地陈述需求，缺失由总到分，由高到低，由粗到细的层次结构。这个问题通常是因为在PRD起草之前的讨论和总结不够有条理造成。结构化脑图可以帮助团队在动笔之前先建立好这个层次结构，将该脑图作为PRD文档的一部分也可以。

2）缺乏经验的设计者因为担心遗漏，追求一个过度完整的PRD，不仅事无巨细，而且把远期和非必要的需求罗列得过多，从而模糊了交付标准的界限。实际上，没有软件产品是依靠第一个版本的PRD管得太久的。要么PRD需要持续迭代，要么需要建立后续升级版本的PRD，设计者无需追求PRD的绝对完整。

3）设计者越俎代庖，不是描述需求，而是描述了解决方案。这个看似是全面能力的体现，但却对高产出的协作带来障碍。按照专业分工的要求，产品设计者应该着眼于需求和实现目标的描述，而不是替代架构师和工程师来设计具体的数据表结构和逻辑实现方法。

4）过度使用视觉辅助，而忽略对需求实质的描述。产品设计人员喜欢大量使用脑图等图表来表达逻辑结构，却对需求的实质缺乏自然的描写。虽说一图胜千言，但在需求文档中，除了参数和标准等具体的表格信息，其他视觉内容起到的主要是辅助表达作用。当然，另外一个极端也是PRD文档容易出现的问题，那就是对于复杂的需求缺失视觉辅助呈现，导致管理层和开发人员需要花很长的时间来阅读和理解。在义、文、图之间，产品设计者需要按照实际表达的需要组合使用。

3.3.3 PRD的基本构成和扩展

我们做了大量的讨论、分析和总结，接下来就是真的要动手写出第一份产品需求文档了。优秀的PRD绝对不是来自它的模版结构，也不依赖它的篇幅长短，而是用最小的篇幅让开发者准确理解了产品开发意图。一份相对规范的PRD总会包含一些不可或缺的内容，根据应用产品的性质，它可能还需要更加丰富的扩展内容，完整和详简程度取决于设计开发团队的成熟度、应用产品本身的重要度和质量风险等多个因素。

以下列出了一份完整的PRD可能包含的所有模块，其中有一部分是根据需要可选扩展的。为了让你更清晰地理解每部分内容的性质和作用，我们全程使用了一个慈善业募款管理软件的例子。

1）开发目的

用最自然通俗的语言说明为什么要开发这个企业应用，它能够给用户企业带来什么价值。这是看似简单，但很容易被忽略的部分。我们在之前介绍了“三层次需求分析”的方法，那么在“开发目的”的章节就是要将其中的“整体商业目标”通俗易懂地准确表达出来。

如果你要为本企业开发一个定制应用，那么你需要阐述对本公司的商业意义；如果你是一家软件公司，要开发一个软件产品，要描述它对目标服务客户企业的价值。对于软件产品开发企业，说明开发一款产品的目的是为了进入某某市场，获得客户和收入不是PRD应该描写的开发目的。

我们举一个软件产品开发目的的例子。比如一款面向慈善组织的募款管理软件，它可以用以下简明扼要的文字阐明开发目的。

帮助慈善组织管理好募款过程，捐款人资料和援助项目的预算和实际开支信息，从而为该慈善机构提高核心工作流程的准确度和效率，增加用款信息的透明度，提高捐款人的满意度和忠诚度。

2）服务受众

在这个章节，产品设计者要列出产品所服务的多层次角色。他们是谁，各自有什么样的工作目标，这个产品将帮助到他们解决哪些问题。在列举服务受众的角色时，要穷举所有的可能，而且不能含糊交叉，不要用“管理人员”、“普通用户”这样的概括性角色名称。

继续上面慈善行业软件的例子，这个产品可能要服务的对象有：

公关市场经理：使用捐款人管理模块管理捐款人信息，定向和按照自动规则发送营销Email。

募资项目经理：通过捐款人和募款管理模块记录募款记录，发放收款凭证。

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

财务经理：复核和经办善款支出，记录和核对募款记录，建立相关财务凭证。

负责人：通过统计模块了解善款使用分布、捐款人分布和行为分析，完成项目开支审批。

管理员：配置产品使用必要的参数，创建用户，分配权限。通常由负责人兼任。

通过服务对象的罗列，可以帮助我们继续树立产品需求，遍历可能的用户故事，设计必要的产品特性。同时，也对整个产品的开发规模有更加精确的预计。

3）命名约定

命名是所有的产品技术文档的核心，它的质量甚至会影响到开发编码的环节。缺少命名约定的文档无论是书写还是阅读都会很困难。在PRD中，要对涉及的主要数据对象、参数、概念、功能和用户动作进行规范命名和释义。这个命名一旦确定后，就需要连贯使用，在PRD文档全文、后期拓展的原型设计、研发沟通过程和未来的用户帮助文档撰写中统一使用，不能随意变更。

在企业软件中，用户引导和教育是一个非常艰巨的过程，而命名是维系和加强这个过程的重要基础，否则在未来写用户帮助文档的时候就会混乱不堪。

当然，PRD的命名不需要面面俱到，只要针对应用中独特的对象进行命名约定即可。对于通用领域的一般概念，我们只需要在设计范式中约定即可。比如“募款”是产品PRD需要定义的功能模块，但是“删除”、“导出”这些概念是不需要在命名约定中出现的。

4）用户故事

用户故事，也可以称为“用户场景描述”，是产品PRD在进入功能需求描述之前，用非产品视角来表达用户需求的一种方法。它完全站在用户的角度，描述他们将来使用这个产品来完成一项重要工作的全过程。如果有必要，也可以对比说明不使用这个软件产品的对应解决方案，从而让产品设计者对这个软件产品将要解决的问题有更加清晰的描述。

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

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

用户故事：募款项目经理录入一个批次的捐款信息

募款项目经理通过和公关市场部的协作获得了数百位捐款人通过公众号微信支付的5万元善款。微信支付后台导出了所有捐款人的订单和付款信息。捐款人的个人资料和联系方法已经合并到了一个Excel文件，每个独立的捐款记录一行，其中已经标记了付款完成状况。

现在募款项目经理需要通过软件直接导入这些捐款记录。通过募款管理的导入募款记录功能，他直接上传Excel文件，系统会提示创建一个募款项目批次，上传完成后显示有多少条符合条件的记录，Review一致后，所有的捐款记录都被导入，新的捐款人（根据身份证号字段识别）被创建为新的捐款人记录。在导入的捐款记录中，已经被标记上对应的募款项目ID。导入完成后，系统提示总计成功导入条数、创建捐款人记录数和捐款总金额。通过和原始数据的对比，募款项目经理确认完成了导入工作。

通过这个例子，我们会发现用户故事的描述和产品功能描述有类似的地方，但着眼于不同的角度和细节。好用的功能特性设计来源其实就是这些用户故事场景的还原。很多PRD容易忽略用户故事的描述，而直接进入了功能特性的设计描述，就容易产生用户体验的重大断层。比如上例中，为什么要创建募款项目批次，在批次下导入具体的捐款数据，这个和用户在实际工作中的场景是密不可分的。如果设计者把这个功能设计为在线输入单条的捐款记录，或者无批次地直接导入多行的捐款记录，就会让未来用户陷入使用的痛苦之中。

撰写出的用户故事本身看起来并不复杂，相反，它可能是整个PRD文档部分最富有人性的部分。如果拿着PRD文档给普通用户阅读，这可能是他们最喜欢阅读，也最容易理解的部分。但是，用户故事的撰写并不依赖好文笔，它来自细致入微的用户观察和调研。在上例中，如果不和多位慈善机构的募款项目经理交谈，是不可能了解他们工作中的准确痛点的。而且，在实践中，大多数企业用户在主动描述自己需求的时候，并不会很完整，有些对他们未来使用很关键的细节特性，他们自己却在需求表达时容易忽略。

有些产品设计者非常信赖自己的直觉，尤其是那些有消费者应用设计经验的人。他们力图跳过繁复冗长的用户调研，直接进入设计阶段，但是在企业软件世界，这是绝对不可能允许发生的。如果你不调研医院员工和管理层的工作，绝无可能设计出医疗服务管理应用；如果你不去拜访工程项目经理，也绝对不可能设计出工程项目管理软件。直觉在企业应用需求管理中的价值要远比在其他领域低。

5）特性组合

特性组合是PRD文档中的主体内容。在陈述清楚了开发目的、服务受众，建立了命名约定，描述了用户核心需求场景后，我们需要通过特性组合完整详尽地列出产品开发需求。

在撰写此部分之前，需要再次明确，产品需求的文档的主要读者是软件开发人员，因此，一定要牢记通过特性组合陈述需求，而不是给出解决方案。过于简单的特性描述没有完整传递需求，但是过度详细的特性描述也会容易制约开发者解决问题的灵活性。

用特性地图（Feature Map）开始

为了有序地讲述一个复杂企业产品的需求，首先需要通过一个纲要或者视觉列出所有特性的逻辑结构。表格和脑图都是很好的表达工具，它从整体上先勾勒出特性组合的全局分布。这和我们之前讲到的产品需求三层次是同一个道理。越是复杂的事物，越需要从简单的大局开始。

结合上文提到的慈善项目管理软件的例子，下图给出了这个应用一个简化的特性组合视觉表达。通过脑图来绘制这样的图形会很有条理。脑图还能够表达出用户在一个产品上的基本使用路径、功能特性之间的联系。