产品经理如何写PRD文档-产品需求说明书

内容导航：

产品经理如何写PRD文档-产品需求说明书

产品经理的PRD到底该怎么写

产品经理效率工具之《产品需求文档-PRD前瞻篇》

产品文档 | PRD写作手册

一、产品经理如何写PRD文档-产品需求说明书

要活学活用，之前说的产品设计的内容，不要用一套自我主义思维打天下，强调下产品结构的几种特点：矩阵结构【一个页面阐述大量的内容，并不是有大量的分层，多个维度来统计能功能】，线性结构【某个骨干流程按照某个线的方式，某个场景往下串】，层级结构【按照用户自行选择，需要干的事情，做的层级，1.足够偏，功能足够的多。2.层级足够的深，每次选择的足够少，统一认为第二种的用户体验比较好】。不要小看产品的结构设计，这是产品经理的基础。结构设计是思考一个功能第一想的问题，不先想界面长什么样子，先想是什么层级，什么结构的产品，然后在想有几个界面有几个判断。开始今天的内容，画原型和写PRD，主要是PRD和原型的对应关系，核心是说说PRD。

（一）回顾下上篇文章① 交互所在层级

主要说了界面交互，低保真原型的设计。

② 交互设计三步走

（二）产品原型及需求文档的撰写① 开发人员最讨厌的PRD

PRD里面讲的逻辑限制开发了代码，这块就去查某个表，做某个参数，定义的变量都写出来了，觉得很崩溃，照这样写出了问题算谁的，明明理解了业务，有别的方式不这么做，用更好的处理方法，出了bug算谁的？PRD到底写成什么样的，描述业务好不好。

② 产品设计阶段

早期的PRD不叫PRD，叫开发规格，真的很限制人的，PRD是产品设计的第三个环节，根据原型设计进行讨论，修正原型的正确性，也可以跟研发进行评判，对整个系统的开发工作量进行估值，需求文档往往是后置的，一般来需求文档就是需求评审之后，代码就开工了。在原型设计之后研发就会做一些开发的准备。PRD也不能当饭吃，一堆人在写PRD，写了这些也不能产生价值，写这些文档干什么用呢。

③ 为什么要写需求文档需求文档给谁看？

交互设计、视觉设计【需要了解场景进行设计】、项目经理【PRD认领，符合PRD管理规范的】、开发【开发的基本，开发需要PRD中将业务逻辑讲清楚】、测试【依据PRD出测试用例的，怎么进行测试，测试用例的变更和新增】、其他产品经理【讲述可能有遗漏不如直接看PRD】、其他需要了解业务逻辑的人。

2.需求文档的作用是什么？

准确、直观、完整传达产品需求，保证各角色沟通有依据，保证产品质量控制有标准，存档。

④ 需求文档覆盖的范围

⑤ 需求文档主要结构

⑥ 需求背景及目标1.需求背景

让项目参与者明白为什么启动该项目，如果来此竞品分析，分析下竞品，竞品实现的功能是什么样子的。

2.项目目标

让项目参与者共识目标，找到价值感。目标尽量量化。上线后验证目标达到情况的依据。

3.编写人

修订日期、修订人、修订说明、修订原因、修订文档版本号。

⑦ 功能列表

拆分成最小的功能点功能点之间相互独立方便参与者理解需求，评估工作量

⑧ 功能点拆分

拆分：一定要拆出来一个功能的组合。一定有个优先级最高的就是产品的灵魂，需求点。P0级的功能.P0是灵魂，没有它就不是这个产品。P1和P2是对用户体验有绝对性意义的东西。P3是对产品的存活有决定性作用的东西，拉新留存。P4是锦上添花的作用。功能拆分的时候不光光的讲有几个按钮，几个值，首先优先级。是不是拆分出来的每一个功能列表。

⑨ 逻辑展示

为什么需要逻辑展示？弥补与程序员的种族差异，帮助自己梳理思路。不免需求遗漏，考虑不周。

多角色流程图（泳道图，跨职能流程图：多角色，多系统，多模块流程）

单角色流程图（基本流程图：单角色，单系统，单模块流程）

流程图：基本元素

基本结构：顺序结构

选择结构

循环结构

页面流程，这是UED和前端最喜欢看的流程图

⑩ 详细描述

想不到那么多情况怎么办？善用工具，帮助整理思路，表达清晰。向测试学习，多看测试用例，善于总结。

⑪ 数据需求

数据需求的采集标准

理论上所有用户端新增功能都需要采集。改动、优化需要进行前后数据对比版本的核心数据指标

数据采集的类型基础数据，交互数据，用户路径

业务数据，服务端存库，用户行为数据，前端埋点。

⑫数据需求

如果没有BI支持，需要茶品经理自己定义埋点事件，不同的数据统计工具，不同的埋点的规范

⑬风控说明

可能出现的风险点和策略

PS：PRD是一个文件，文件是写给人看的，文件什么样不取决于产品经理想写成什么样，取决于读者。大家认为好才好，为别人写的不是为自己。文档是核心：以表达为目的，让查看的人清晰易懂，文档完整性很重要，文档表达方式灵活：axure、word、wiki、脑图、表格，逻辑严密，表达清晰。产品经理技能宏观至战略，又能微观至一个文本框的各种边界和异常。

一、产品经理的PRD到底该怎么写

PRD（Product-Requirement-Document，产品需求文档），写作目录如下：
1、文件命名（编号）
文件的编号很关键，因为产品迭代过程会有不同的文件版本，一般命名规则“公司名+产品名+PRD+D1.0”（以第一版为例），这样命名有利用版本号的迭代。
2、修订控制页
一般有这么几项：编号、文档版本、修订章节、修订原因、修订日期、修改人。
3、目录
4、请与以下部门讨论PRD
PRD作为一个承接作用的“载体”，会与技术、运营、财务等人员的沟通，而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上，需要与相关人员确定“沟通内容”，这对于产品整体流程将是很重要的。
5、概述
概念就是总结，它包括的点有：名词说明、产品概述及目标、产品roadmap、产品风险。
6、使用者需求
使用者需求一般只有个需求描述。需求描述有以下几项内容：目标客户、需求描述、场景描述、优先级。
7、可选方案
列出所有可以选择的达到该产品目标的方案要点（主要思路），给各方案适当的评价，并推荐最优方案。
8、效益成本分析
产品经理是个全才，在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面：效益预测、产品技术中心成本、非产品技术中心支持成本。
9、功能需求
功能需求一般是由四部分组成，功能总览、功能详情、整合需求、BETA测试需求。
10、整合需求
产品经理很重要的一个能力就是体现在产品整合能力上，利用公司现有的资源或外部资源（合作公司等）实现产品功能需求的整合。
11、BETA测试需求
很多产品都有BETA版本放出，为了就是收求意见和一些性能测试。
12、非功能性需求
都说产品经理是全才，在这点上得到彻底的体现。很多产品经理在这点上忽视了，但很多方面使用到的，只是在产品过程中弱化了。
13、上、下线需求
上线时限需求：此产品预定上线日期？上线日期有无任何特殊依据或规定？
下线需求（活动类需求必须明确下线时间）：此产品预定下线日期？下线日期有无任何特殊依据或规定？
14、运营计划
说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户，产品经理是核心需求的把握者，参与到产品整体运营计划显得特别的重要。
……
写PRD并不是产品经理的全部工作，但却是不可少的一部分，很大程度上反应了产品经理的思维和产品核心功能把握上，同时对产品经理沟通、协调、规划等
想学习更多PRD文档写作方式，可以来官网学习

二、产品经理效率工具之《产品需求文档-PRD前瞻篇》

PRD是什么？

迄今为止，这是我知道的关于产品需求文档（PRD）最好的字面定义，完整表达了产品的一切。

不揣测、不定义，只是准确传达需求，让技术专家给出需求的最优解。

需求来源生活，产品经理体验生活，切身感知需求。需求宽泛，因而需要从两个维度理解产品需求文档：

这一系列文章内容侧重的是战术思考。

产品需求文档的本质上是一个产品工具（product tool，简称Pt），是产品经理的刻画外部客观世界的媒介，一种表达方式。人们普遍认为只有技术研发才是非常专业的工作，并拥有特有的行业开发工具，如微软visual studio、Code，苹果Xcode，而产品经理的工作都局限于经验性的操作，没有任何专业性可言。

NO. 产品经理是一个强专业性的工作。

很多产品经理的工作是从写产品需求文档开始的，我也不例外，并且我一直都觉得很幸运，因为这是一件有确定性的事。产品三年工作至今，我似乎更加喜欢借助PRD输出需求的本来样子。随着工作需要、个人理解，产品工具——产品需求文档/PRD持续迭代，最大程度适配解决问题的效率，刷新最优解。

在产品设计过程中， 写产品需求文档是一件极为有仪式感的事 。因而，一直以来我更愿意称之为< 设计文档 >。

产品工具之《产品需求文档/PRD》设计文档的全过程：

《礼记·中庸》有言：凡事预则立，不预则废。从产品需求文档的定义出发，发现文档不是目的，而是确定的结果。因而动笔之前，需要做好三个方面的准备工作，这里不赘述细节，仅给出概括性内容（计划以独立文章详细描述）。

得到用户的诉求，沟通确认用户基本需求后，借助需求工具实现需求的量化管控。我们需要将想法梳理转化为结构化、可实现的产品需求。

保证产品经理对产品需求的理解，为产品需求文档注入一定的可靠性、准确性。

当我们清楚知道产品的需求之后，产品需求由概念化阶段进入到图纸化的阶段，验证制定的用来满足用户需求的解决方案和界面设计的可行性。

论证需求产品化的流程MVP，增强产品需求文档的易理解、可视化、可理解。

需求管控、原型设计完成了产品需求的预备粗加工，进一步置于一个怎样的表达范式中对外呈现。一个基础文档内容结构是对需求内容的扩展和压缩。

有很多穷尽信息的手法，借助思维导图、表格文档，再将文字内容文档化。

这些准备帮助PM/用户清晰的理解产品需求，并且越来越清晰。当完成以上三个准备工作，产品经理对需求已了然于胸，写文档自然如有神助，而不是一堆不知所云的YY之词。

产品经理迭代至今，产品需求文档可依赖的交付载体日益多样。起初，我是不愿意讨论形式的问题的，因为过于强调形式无形之中会反向削弱需求内容本身的重要性。三年产品一线亲自实战，我逐渐意识到在一个好的形式的的加持下，传递表达事半功倍。主流的PRD形式：

所述三种形式一致采用了“文字+图片”的表达元素，而工具一切的迭代都为提高内容输出的效率。做产品的同学都有一个共同感受：有时候，时间确实很紧。

除了要选择PRD的表达载体，那么文档内容本身的容量和密度还需继续判断，从文档内容粒度上讲，产品需求文档/PRD分为：

PRD内容结构取决于：

我曾切碰到文档交付的麻烦，刚入职新团队时，对新团队的分工协作模式一知半解，就自以为是沿用以往日的PRD模式交付，不符合要求，影响理解效率而被邮件投诉。

产品需求文档（PRD）是一款产品的全生命周期的记录，知晓每产品的每一个细节变化的原委。
产品需求文档（PRD）是一款专业的产品管理的效率工具，产品经理的必须掌握的专业产品工具。

【产品经理的效率工具】系类将以主题形式呈现，下一篇将分享 《产品工具之产品需求文档/PRD》实战篇 ，设计一个产品需求文档/PRD，敬请期待。

生如白溪，一苇以航。
我是白苇，很开心在产品世界遇见你。
Date：2018年10月01日 6:00am

三、产品文档 | PRD写作手册

写PRD是产品经理的基本功，但很多时候，我们无法得到系统的指导，全靠野蛮生长，简称野生产品经理。我们的PRD可能会面临很多问题，在开发过程中由于需求描述不明确，不断地进行修改最后导致延期。文档被领导挑出毛病，打击自信心，在同事中信誉度降低等等。

减少无效的沟通，提高工作效率，是一篇清楚的PRD带来的好处。

（1）PRD是什么

PRD是Product Requirement Document的简称，我们叫它产品需求文档，它的诞生意味着产品从概念化到图纸化的进化。

（2） PRD的对象有哪些？

以开发团队为主的研发、测试、视觉设计师、交互设计师等相关业务人员。

（3）PRD有什么作用？

（1）这个需求在解决什么问题
很多情况是一个需求提过来，产品经理立马着手开始设计，甚至有时候需求方会附带自己的设计方案，有的产品经理也没有经过思考直接就执行了（早些时候我也这么干过，别人指哪打哪）
事实上一个需求最重要的是发现问题，发现问题比立马出解决方案更加重要。因为没有探究问题是什么，可能一开始设计的方向就是错的了。

我们需要考虑以下内容：

这里有一种设计技巧可以使用，叫做 RTPA设计框架 ，他的核心就是重新发现问题。我们可以使用以下的步骤：

可以看到，最后才是设计，在设计之前我们重点要搞清楚的是问题所在。

（2）需要多少资源
为实现这个需求，需要多少资源，多少人力，多少时间来完成，需要做一个大致的评估。

（3）是最简单的解决方案吗？
当前的设计是最简单的解决方案吗？实现起来难度怎么样？值不值得去做？

（4）有风险吗？
主要考虑做出来后能不能投入使用，会不会违反法规，或者违反第三方的规则导致不能使用。或者功能会影响别的方面，如线上bug引起的崩溃，或者导致什么数据下降。

（5）设计是否创新
有没有调研过竞品对于这个功能是怎样设计的，对于这个问题是怎么处理的，有没有行业内比较先进的做法。

总之 ，我们在设计之前需要考虑以上的问题，想清楚了再进行设计，可以少走弯路。

做完了设计之前的工作，就可以开始设计了。编写中有三个大的方向：
（1）搭框架
这一步主要定产品的大致框架，包括产品架构、信息架构、功能结构。
首先通过角色将系统划分开，系统中又包含子系统，再将系统中的功能按照模块划分成功能模块，再列出每个模块下的功能就成了。

（2）业务流程
分为主业务流程和子业务流程。每个业务中包含业务流程图、状态流转图、时序图。
业务流程图：

状态流转图：

登录时序图：

（3）文档细节
在对功能的描述中，【输入】【处理】【输出】是最关键的步骤，用户在前置条件下进行输入操作后，系统会进行怎样的处理，最后输出什么样的结果。文档主要在描述这些内容，以及一些有辅助作用的数据表，交互细节等。

记录每次文档的修改信息，主要有，修改的功能、具体内容、修改的时间、谁修改的等信息，以便在以后查找起来方便。在Axure之类的平台中做文档还可以对每次修改添加一个超链接，快速定位到迭代。

从现状、方案、目标3方面描述。

列出项目架构图和功能结构图。

主要包含需要对全局统一处理的一些描述，如名词解释、异常流程处理、其他默认规则。

列出核心业务流程与子系统业务流程，一般功能性的业务流程都在功能描述里写。

了解有关的法律法规，有与第三方合作的需要了解别人的规则，提前避免风险。
或者功能会影响别的方面，如线上bug引起的崩溃，或者导致什么数据下降。

主要记录相关的需求是谁提的，以便有不清楚的地方可以快速定位到相关人员。

这块是细节最多的地方，每个功能说明都包含：设计背景（非必须）、功能描述（非必须）、用户场景（非必须）、输入/前置条件、后置条件、界面交互、业务流程、分支流程、异常处理、数据字典（非必须）

这里的示例针对上面的第8点功能需求进行举例说明。

（1）功能描述
提供给商户进行账号登录。

（2）前置条件
输入正确的账号和密码进行登录操作

（3）后置条件
登录成功后，根据用户登录的账号与对应的角色进入到相应的首页。
如果选择了记住密码，需要保持登录30天，每一次登录都刷新这个token记录。

（4）界面

（5）业务流程

（6）异常流程

（7）数据字典

链接如下，自取哦~
链接: 链接:
提取码: rkxv