怎样写好一份高质量的产品需求文档（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）开始

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

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

伯虎产品社区

如果开发的是一个Web应用，这个特性地图基本就等同于未来的站点地图（sitemap）了。设计特性地图并没有绝对的格式要求，只要能够表达清楚各个功能特性之间的逻辑包含关系即可，然后将其作为特性组合部分的指导目录。开发人员将会很乐意将这个地图打印出来贴在案头，在产品开发的整个周期内频繁使用它，无论是后端还是前端开发者都需要这么一个序列来评估开发工作的工时和进度，如果能够将这个地图条目编上1，2，2.1，2.2这样的数字编号，沟通的有序性会进一步提高。

页面要素（Page Component）

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

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

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

2）用户在页面上能够做什么？

简化的页面要素表达可以用章节结构，把前面列出的特性地图中的页面详细展开说明。例如例子中的募款管理页面，需要包括以下内容：

现有募款项目列表，可以点击进入募款项目详情列出项目名称，开始日期，负责人，累计募款额，完成比例，状态

关键词搜索募款项目

按照组合条件筛选募款项目

募款项目统计的仪表板列出当前募款项目数，累计项目数，累计募款额，本月募款额点击任何一个数值，进入募款统计首页

新建募款项目的按钮

用户使用流程（User Flow）

对于复杂的软件产品，仅仅依赖特性地图和页面要素可能还不够。不同的用户角色可能有多样的任务要完成，如果只是罗列出有哪些页面或者窗口依然不能说明清楚用户的使用流程和期望。这时候，可以选择加入“用户使用流程”的专门章节，对于核心的用户任务进行详细说明。

用户使用流程的表达有文本和图形两种方式，设计者可以根据需要选择。文本模式的用户使用流程用用户任务的名称开始，然后用1，2，3这样顺序的步骤说明用户期望的交互路径。

例如：

流程1: 创建募款项目

首页点击募款管理

点击“创建”，进入新募款项目创建页面

完成填写后提交

添加募款项目成员，指定更多管理员

选择或添加对应的财务科目

提示是否需要导入募款记录？

Yes- 进入募款记录导入

No - 进入下一步

7. 提示项目创建成功

当然，文本的流程说明也很容易用对应的流程图来表达。在这样的用户使用流程图中，可以约定用矩形框表达对应的页面或者窗口名称，这样用户使用流程的描述就能够和前面的特性地图、页面要素中的命名对应起来。

伯虎产品社区

在复杂的企业软件中，有时候完整的用户使用流程是非常复杂和漫长的。这时候，就需要按照一定的阶段将流程切分，分板块来表达，否则读者将很难使用。下图的用户使用流程来自一个复杂的企业工作流软件，如此复杂的表达也仅仅呈现了整个使用路径的一个局部。

伯虎产品社区

原型设计（Prototype）

我们终于进入了原型设计部分，这是构成特性组合板块的最后一部分。对于很多产品设计人员来说，这部分是特别熟悉的。不少软件产品设计者终日都在Adobe的设计工具上，产出的大多数是原型设计图稿。但是，我们在进入原型设计之前，居然花费这么多笔墨在视觉之外的内容上。

为什么企业应用不能直接从视觉化的原型设计开始呢？和消费者应用相比，企业应用很难依靠单纯的视觉原型来说明清楚软件开发需求，因为交互与视觉原型很难说明清楚背后的逻辑，因为不同的数据状态要进行的容错处理也要比个人应用复杂得多。更重要的是，企业应用质量的核心的确在于它的可靠性和精确性。界面的美观和易用当然是我们追求的重要目标，但它如果离开了可靠和精确后，一文不值，因为它无法帮助用户完成任务。

虽然我们不能仅仅依赖视觉原型来说明清楚需求，但是如果有直观的原型设计，的确能够帮助说明过程。有了它，也能够帮助节省PRD的文字篇幅，开发团队可以更加精准地理解设计意图。

在这个行业中，产品架构师、界面设计师和交互设计师都可能需要进行原型绘制。而且，就连客户和老板都会喜欢用原型来表达或确认需求，但他们提供视觉设计的完成度是完全不同的。在分工完整的团队中，完整的原型和交互设计最好由专业的交互设计师来主导。在产品需求的逻辑面完整以后，专业的视觉设计师可以保证交互界面的匀称、一致和加入情感元素。

现在，因为交互设计的范式库建设（我们在后面的章节会专门介绍设计范式），交互设计工具的发展，更多的设计成员都可以更容易地提供高保真的设计原型。高保真原型不仅能够用像素级标准来固化需求，还能够提供用户操作的模拟反馈，甚至包括动效。但是，对绝大多数的企业应用来说，高保真原型的主要价值并非去提供一个严丝密缝的需求规范，而是给客户方提供一个可以预见和感知的效果。过于强调高保真的实现会限制开发者灵活运用解决方案，做出合理取舍的可能。从团队协作产出最大化的角度而言，框线图和高保真图都是可以接受的原型绘制方案。

有些团队还发展出把用户使用流程和原型图结合在一起的模式。通过原型中的UI元素之间的连接线或者索引编号，把用户使用产品的流程直接叠加在原型图上。只要团队能够沟通和磨合好，也不失为一种提高协作成效的方式。如下图就是一个完成度比较高的视觉和文字结合的原型图。

伯虎产品社区

从特性地图、界面要素、用户使用流程到最终的原型图，包括它们之间的组合使用方式都是为了清晰完整地表达一个软件实现的具体需求。一个企业应用到底要用怎样的表达方式组合则完全取决于项目内在的需要。一般而言，复杂和高风险的产品会要求更加完整的表达，产品和开发协作困难（比如是两个企业之间）的也会要求高完成度的需求描述。反之，如果是比较小型的产品，非敏感和关键的系统，协作配合度很高的团队则可以有选择地使用这些表达工具，不必面面俱到。

但不管产品文档有多完整，产品设计者永远需要和开发者与客户之间建立高频度的面对面沟通。需求沟通得越完整，越准确，产品实现的质量就越高，这一点是毋庸置疑的。

接下来PRD还有两个可选的模块，可以帮助进一步说明应用开发需求，它们都是为了更清楚地说明我们要把产品做得有多好。

6）竞争标杆

顾名思义，竞争标杆部分需要列出应用所对标的产品，指明它们可参照的产品特性和实现标准。对于产品型公司来说，这一点至关重要，因为我们不仅希望设计一款需求明确的产品，还希望设计能够超越竞争对手的产品。

当然，每个企业都有自己的独特优势，所以竞争标杆也不是列出一堆竞争对手的产品名字，而是要指出每个特性所对标的产品。比如在“用户管理”方面超越或达到A，在“活动管理”方面超越或达到B。竞争标杆的树立也可以帮助我们在需求说明当中减少篇幅，因为有的时候，竞品的存在事实上提供了可参照的原型。

但是，在每个特性上都建立一个标杆在商业上未必合理。任何一个软件产品，首先都还是要有自己的独特性，在某些优势特性上出类拔萃。而对一般特性、支持性模块或者难以差异化的部分，通过其他优秀产品的定标是完全应该的。尤其是企业应用产品如果能够选择好某个消费者应用产品的优异体验作为标杆，对于提高用户交互体验度是很有帮助的。

7）发布标准和时间要求

在实践中，设计阶段很有可能对应用产品的最小交付标准还无法确定。同时，为了方便开发人员规划完整的架构，需求说明可能会包含需要渐进实现的特性列表。所以，在PRD的最后或者使用独立的文档来规范应用发布时的最小化要求。如果规划多个版本连续发布，也可以配套上对应的时间要求。

经常有团队对一个产品的最小化交付标准争执不下。有时候是需求方认为最小化标准过于简单，需要增加功能特性，有时候是设计方认为我们不应该在第一个版本塞进这么多功能。这种争执可能是企业应用设计过程中最广泛存在的团队分歧。

这些争执似乎很难有一个客观的标准，但是出现这些争执的主要原因来自于团队对本章开头部分所要求明晰的产品目标未能达成足够的共识。我们可以再回顾一下。在动手写作PRD之前，团队需要厘清：

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

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

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

理想的工作方式要求我们在项目定义的时候就尽力达成一致，而不是在开发的晚期再去争执这些问题。项目未展开之前，团队成员和管理层尚能保持清醒的头脑来沟通和决策这些目标和交付标准。一旦项目展开，需求开始被成更加具体的表达，就会有增加和变更需求的冲动。公说公有理，婆说婆有理的事情就多了。这就是为什么我们要早起确定和文档化以上三点的原因。控制项目边界的任务在很多情况下是落在产品设计人员身上的。

任何的交付标准都和配套的资源相关，对于软件开发来说，资源就是指人力和时间。所以，设计人员需要对开发团队的人力分布和资源情况有清晰的认知才能控制一个项目的边界。

也有人认为软件产品就是应该敏捷迭代，不要拘泥于项目定义。这个观点混淆了新产品研发项目和产品长期改进的差别。对于任何一个企业，一个IT系统能否投入销售或使用，直接影响到它对业务产出的影响，需要配合的营销和销售投入，运营系统的建立等协同事务，它初次交付的标准和时间要求是没有太多宽容度的。但是，应用上线以后，基于初始版本和事实的使用反馈，不断迭代改进则是完全另外一个逻辑，所谓的SCRUM敏捷开发模式主要指的是后者，而不是一个新软件产品的初始打造过程。

3.4 有关产品需求设定的检查清单

我们花了不少篇幅来专门讲“需求”，它是制约一个企业应用开发和交付质量的源头。大多数失败的软件开发都可以溯源到需求分析和表达阶段的重要瑕疵。因此，作为本章的小结，我提供了一个9点的检查清单，帮助设计者在最终评定需求阶段工作质量的一个工具。

明确的目标服务的受众是谁？

明确了要解决他们的哪些问题？

明确了应用给用户企业的成本和收益带来的影响？

明确了可以投入在应用开发上的人手？

明确了初次版本要交付的时间？

提供了导航性质的特性地图？

提供了关键用户流程的描述？

特性地图上的每个特性提供了页面列表、元素列表和视觉原型，并方便开发者找到？

项目资源满足最小化的发布标准和时间要求？