干货坚果铺：如何写好一份产品需求文档.docVIP

干货坚果铺：如何写好一份产品需求文档 　　PRD写得好看还不如需求把握得准确，PRD写得好看还不如体验设计得顺畅。 　　 　　工欲善其事必先利其器。 　　产品需求文档（以下都简称PRD）对于大多数产品新人来说都并不陌生，它是产品工作中非常重要的一部分。一份PRD可以直接的看出一个产品人对自己所负责的产品的整体把控能力，也能间接的看出产品人的产品思维，表现出产品人对某一垂直行业的专业知识广度和需求洞察能力。 　　而PRD从本质上是服务于产品执行的一种工具，它并没有一种严格上的定式，不同产品不同项目都有这样或那样的区别，而只有能够最大程度的服务好产品的PRD才是好的PRD。 　　一个好的工匠是擅长于利用和打造工具的，产品人亦然。产品人除了要擅于打造PRD这个工具之外，还要善于利用它去服务产品的执行工作。 　　那么，接下来我将以我的个人经验分享一下我打造PRD这一工具的方法论。希望各位可以求同存异，不断迭代优化。 一、头部。1、文件撰写相关信息。　　这里的相关信息都是非常常规的信息，包括文件名称、文件撰写人、撰写日期、文件版本号、文件审核人、文件审核日期等。 2、文件声明。　　一般是文件使用权限声明、文件必威体育官网网址声明。 3、文件版本与修订记录　　PRD跟产品一样也需要不断的迭代更新优化，那么每一次PRD版本的更新与修改都需要做详细的记录。 　　如图： 　　 　　版本说明.png 　　这里的AMD分别代表：添加（added）、修改（modified）、删除（deleted），每次版本的相应操作都必须做出对应的标注。 二、前言1、编写目的。　　这部分主要阐述PRD的作用： 开发人员开发依据设计人员输入源产品经理跟进产品执行实现程度的依据测试人员编写功能测试用例的输入源外部人员产品理解或执行的依据等等2、产品（项目）周期。　　这部分则是阐述清楚产品需求、设计、开发、测试、上线等的相关周期（可用甘特图表示）。一个项目开发周期确定后，没有特殊情况下就必须严格把控和执行项目进度。 　　附上简单甘特图： 　　 3、相关参考文档资料。　　附上相关参考文档的信息。以便相关人员获取更详细的信息。 　　如图： 　　 三、产品（项目）概况1、产品（项目）简述。　　此部分主要是从整体的角度来去阐述一个项目或者产品，包括产品或项目解决的需求、包含哪些产品、包含哪些功能 　　1.1、产品或项目的整体描述。 　　整体上描述该产品或项目的全局，从解决的问题、如何解决问题、所创造的价值等方面进行阐述。 　　1.2、描述项目中包含的产品。 　　如果是一个相对较大的项目则需要分别阐述清楚项目下拥有的各个产品。比如，从客户端来说，有PC端、微信端、ios和安卓端；从用户端来说，有B端、有C端。简述各个产品在项目中发挥的作用。 　　1.3、描述产品中包含的功能。 　　接下则阐述各个产品所包含的主要功能。 　　如：对于某款K12实时一对一答疑辅导产品来说，他有老师端和学生端两款产品。老师端的主要功能有为学生解题。学生端的主要功能为上传问题。 2、专有名词解释。　　此部分主要解释产品中涉及的相关专业名词的解释。 　　如下图，主要为教育机构中的业务专有名词： 　　 3、产品（项目）用户角色描述。　　当今互联网产品中，产品的用户都不止一个，PRD需在概况中描述清楚产品中涉及的每一种用户角色。如下图：主要为教育机构中的各种业务角色： 　　 4、产品（项目）总体架构。　　此处画出产品的总体功能结构图：功能结构图根据产品的每个功能逐一深入画出结构图。如下图：为K12教育产品学霸君的功能结构图； 　　 5、产品（项目）业务流程图。　　此处画出产品总体的功能业务流程图：（该流程图为现阶段搜提类K12在线学习APP的大致业务流程，流程中并没有对子流程进行细化。实际工作PRD中的细化子流程或文档可在功能性需求中详细附上并详细描述。） 　　 　　流程图中的图示： 　　 四、产品功能性需求　　任何产品的需求都可以分为功能性需求和非功能性需求两类。 功能性需求一般是指产品中具体的、用户可使用和感知的功能需求，如登录注册功能、导航功能、文件下载功能、支付功能等等。非功能性需求则一般偏向产品的性能需求，如产品响应速度需求、产品测试环境需求、产品的安全需求等等。　　通俗的理解，就好比一部电脑功，能性需求是它能上网、能看电影、能听歌、能玩游戏等等；而非功能性需求则是它的CPU是双核还是四核，内存是4G还是8G，电脑构成材质是塑料还是金属等等。 　　某种程度上，一个产品的功能性需求决定了这个产品能不能用，一个产品的非功能性需求则决定了这个产品能用多久，而一个产品好不好用则是功能性需求及非功能性需求的双重体现。 　　以下将以“注册登录”功能为例，讲解在PRD中一个功能性需求的阐述。功能性需求的阐述也是一份PRD中最重要