《现代企业应用设计指南》连载三：产品需求文档

产品需求文档

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

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

1)产品设计的目标是解决哪些用户的哪些问题?它对企业的商业目标的实现起到了什么作用?(即要做什么。)

2)开发项目的投入资源怎样?可以有多少产品研发人员?给出了多长的时间窗口?(即能有多少资源。)

3)我们要交付的最小化产品需要达到什么标准?是否有对标的竞争产品或者其他产品可以帮助衡量?(即至少要做到什么样。)

PRD 的常见误区

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

2)缺乏经验的设计者会因为担心遗漏而追求一个过度完整的PRD，不仅事无巨细，而且把远期和非必要的需求罗列得过多，从而模糊了交付标准的界限。实际上，软件产品使用第一版 PRD 的时间都不会太久。要么需要持续迭代现有的 PRD，要么需要为后续升级版本撰写新的 PRD，因此设计者无须追求 PRD 的绝对完整。

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

4)过度使用视觉辅助工具，而忽略对需求实质的描述。产品设计者喜欢大量使用脑图等图表来表达逻辑结构，却对需求的实质缺乏自然的描写。虽说一图胜千言，但在需求文档中，除参数和标准等具体的表格信息外，其他视觉内容起到的主要作用是辅助表达。

5)与过度使用视觉辅助工具相反，另外一个极端也是 PRD 中容易出现的问题，那就是对于复杂的需求缺失视觉辅助类呈现，导致管理层和开发人员需要花很长的时间来阅读和理解 PRD。因此，产品设计者需要按照实际表达的需要组合使用图文。

PRD 的基本构成和扩展

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

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

1)开发目的

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

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

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

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

(2)服务受众

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

继续上面慈善组织软件的例子，这个产品可能要服务的对象如下。

• 公关市场经理:使用捐款人管理模块管理捐款人信息，定向并按照自动规则发送营销 E-mail。

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

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

• 财务经理:复核和经办善款支出，记录和核对募款信息，形成相关财务凭证。

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

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

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

3)命名约定

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

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

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

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

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

我们继续以募款管理软件的用户故事为例来讲述。

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

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

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

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

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

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

5)特性组合

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

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

(1)从特性地图(Feature Map)开始

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

结合上文提到的慈善项目管理应用的例子，下面给出了这个应用的一个简化的特性组合图。用脑图来表达这样的结构关系会很有条理。脑图还能够表达出用户在一个产品上的基本使用路径以及各功能特性之间的联系。

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

(2)页面要素(Page Component)

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

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

• 用户在页面上能看到什么?

• 用户在页面上能够做什么?

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

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

•  关键词搜索募款项目。

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

•  募款项目统计的仪表板，列出当前募款项目数、累计项目数、

•  累计募款额、本月募款额，点击任何一个数值，进入募款统计首页。

•  新建募款项目的按钮。

(3)用户使用流程(User Flow)

对于复杂的软件产品，各个不同的用户角色可能都有多样的任务，仅仅用特性地图和页面要素罗列出有哪些页面或者窗口，可能无法说明清楚用户的使用流程和任务。这时候，可以选择添加专门的“用户使用流程”，对于核心的用户任务进行详细说明。

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

流程 1:创建募款项目

第1步  在首页点击“募款管理”选项。

第2步  点击“创建”按钮，进入新募款项目创建页面。

第3步  填写完成后提交。

第4步  添加募款项目成员，指定更多管理员。

第5步  选择或添加对应的财务科目。

第6步  提示是否需要导入募款记录。
             •  是，进入募款记录导入页面。

             •  否，进入下一步。

第7步  提示项目创建成功。

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

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

(4)原型(Prototype)设计

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

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

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

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

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

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

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

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

PRD 还有两个可选的模块，可以帮助我们进一步说明应用开发需求，更清楚地阐明我们要把产品做到什么样子。

6)竞争标杆

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

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

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

7)发布标准和时间要求

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

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

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

•  产品设计的目标是解决哪些用户的哪些问题?它对企业的商业目标的实现起到了什么作用?(即要做什么。)

•  开发项目的投入资源怎样?有多少产品研发人员可以参与开发?给出了多长的时间窗口?(即能有多少资源。)

•  我们要交付的最小化产品要达到什么标准?是否有对标的竞争产品或者其他产品可以帮助衡量?(即至少要做到什么样。)

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

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

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