产品经理怎么撰写移动应用的PRD文档

PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是对MRD中的内容进行指标化和技术化，这个文档的质量好坏直接影响到研发部门是否能够明确产品的功能和性能。

产品经理的其中一个职责就是定义要开发的产品，而定义开发的产品则需要通过产品需求文档(PRD)来描述产品的特征和功能，在此，我来跟大家分享一下产品经理在平常工作中是如何撰写移动应用的PRD文档的？

1、PRD文档的作用

在学习如何撰写PRD（产品需求文档）之前，我们先要明白写PRD的目的是什么？PRD文档的作用又有那些呢？

（1）、“概念化”阶段进入到“图纸化”

我们之前在市场需求文档(MRD)中阐述到的功能，都是表达的一个意向，不考虑实现方法和细节，而PRD则是将概念图纸化，需要阐述详细的细节和实现模型，产品人员可以通过撰写PRD，梳理清楚方案实现过程中的各种问题和影响。

（2）、向项目成员传达需求的意义和明细

PRD的主要面向对象是项目经理、开发、设计和测试，如何向这些不同的角色表达清楚需求明细，就需要一份规范的PRD文档来描述，项目经理通过PRD文档可以迅速了解任务的规模和相关接口，而开发设计人员通过文档可以了解页面元素和用例规则，测试人员可以提前根据文档撰写测试用例，PRD文档在形式上是项目启动的必要元素之一。

（3）、管理归档需求

大都数的新需求都需要迭代几个版本后才能走向成熟稳定的阶段，如果没有PRD文档，在大型项目中，需求的迭代变更将变的无据可循，PRD的文档修订编号和命名也是项目规范化管理的主要方法之一（具体可查看马海祥博客《产品设计开发流程文档编制指南》的相关介绍）。

2、PRD的主要构成

一般企业内部的PRD文档选择wiki系统或word文档，wiki在协同和保密方面会有优势，而且能够记录修改文档的每一次变更，而word在阅读修改方面比较有优势，一般使用Word加SVN的方式来管理更新文档，这个可根据每个企业的管理规范来选择那种方法更合适。

一般来说，一份基础的PRD文档主要由三部分组成：引言、业务建模和业务模块。

（1）、引言

引言部分主要包括：需求背景、需求目的、需求概要、涉及范围、全局规则和名词说明，交互原型地址等，引言部分的写作目的是让阅读者快速理解需求背景和概要，如果是公司内部文档，引言部分可以从简写作。

（2）、业务建模

建模的目的是为了帮助阅读对象更好的理解需要开发的需求，常用的模型种类包括：用例图、实体图、状态图、流程图等（具体可查看马海祥博客《产品经理该如何写好一份产品需求文档》的相关介绍）。

（3）、业务模块

业务模块包含具体页面的元素、用例规则，以及相关的原型，流程图。

业务模块的描述是整个文档最核心的部分，下面马海祥就用案例来描述一下业务模块的编写方法。

3、案例介绍

需求的目标是在APP中展示相关国家/城市的旅游资讯内容，如下图所示：

那么我们在第一部分的引言中可以写下简单的需求描述：目的地攻略以城市/国家为单位，展示八个栏目下的文章列表。

初期运营指标为编辑所有涉及城市的归属国家攻略内容，相关城市暂不编辑；APP前台默认显示国家内容卡片，城市内容卡片无数据时隐藏。

运营系统提供内容生成对应的触屏网页，App读取和下载对应网页内容。

为了帮开发者迅速了解需求结构，我们需要建一个简单的流程图帮助开发理解功能，如下图所示：

相对复杂的运营系统，我们可以补充相关用例图和实体关系图，如下图所示：

引言和建模部分是为了帮助开发和测试人员快速理解需求，具体的页面和用例规则还需要通过第三部分的业务模块来描述，这里我们节选案例中的文章列表页来描述：

文章列表页共包含一个页面，四个用例，如下图所示：

那我们的描述结构就为：

（1）、文章卡片页面元素

文章卡片的页面元素描述如下所示：

（2）、收藏文章用例

收藏用例的描述如下所示：

（3）、分享文章用例

（4）、查看文章列表

（5）、查看文章(太简单可不描述)

总的来说，业务模块的描述一般是原型图+数据元素+用例描述，这样可以在原型图的基础上加上对应元素属性的描述，并通过动作描写的方式表达用例规则和各种流程，这样的写作方式不仅可以向不同对象传达产品经理的意图，而且可以帮助产品经理自己梳理需求的逻辑和各种异常流程。

马海祥博客点评：

该文档在产品项目中可以说起到一个“承上启下”的作用，“向上”是对MRD内容的继承和发展，“向下”是要把MRD中的内容技术化，向研发部门说明产品的功能和性能指标。