如何写好一篇完整的产品需求文档(prd)模板

产品需求文档(prd)模板:https://pan.baidu.com/s/1c1WIlFU

产品经理的整体思维体现在:

1、提炼核心需求

2、思考满足核心需求的方式

3、评估方式优劣选定方案

4、思考功能概要

5、思考支撑功能和关联功能

6、细化设计功能

7、子功能(功能间迭代)

PRD其实就是将以上的思维整体走向写出来,同时将产品的思想提炼出来,用文字表示给开发者,给UI、给视觉、给老板……PRD给的是一种思想,将产品的整体思想和核心需求灌输给产品的相关人员,都说PRD是个承上启下的功能,因为上接MRD,下对MRD进行技术性的描述。

网上已经有太多互联网公司的PRD文档,淘宝、百度、腾讯等这类大型互联网公司都有自己的PRD规范,适合企业的需要的PRD才是真正PRD。以淘宝的PRD为例,讲解一下PRD的主要内容。

1、文件命名(编号)

文件的编号很关键,因为产品迭代过程会有不同的文件版本,一般命名规则“公司名+产品名+PRD+D1.0”(以第一版为例),这样命名有利用版本号的迭代,如果是小的产品需求变动可以直接命名为“公司名-产品名-PRD-D1.01”,如果涉及到功能需求增加可以命名为“公司名-产品名-PRD-D1.1”,当出现产品第二版时,可以命名为“公司名-产品名-PRD-D2.0”。

2、修订控制页

一般有这么几项:编号、文档版本、修订章节、修订原因、修订日期、修改人。编号只是为了给个修改的顺序,文档版本显示的当前修改的内容是在哪个版本中出现,修订章节是具体到哪个章节哪个功能模块的修改,修订原因说明此功能修改的问题所在。修订日期以修改当日的日期为修订日期,修改人显示修改内容模块的人,可能是当前用户也可能是其它产品人员。

3、目录

不建议自己去添加一个新的目录,你可以去其它的文档中拷一个过来,不考虑目录的内容,等写完PRD可以再去更新。但建议用Mind manager来整理一下思路。

4、请与以下部门讨论PRD

PRD做为一个承接作用的“载体”,会与技术、运营、财务等人员的沟通,而与这些人员沟通的主题都将会出现在子功能或在细节细化的基本上,需要与相关人员确定“沟通内容”,这对于产品整体流程将是很重要的。同时对于产品核心功能的提取也是一个重要环节。产品经理很重要的一个职能就是沟通。例与客服中心:客服服务部,讨论的内容:预测客服成本、工作量;讨论客服如何支持;协助评估诈欺/数据窜改风险:欺诈/数据窜改风险、不正使用风险。这就是要写在与其它部门讨论PRD中的。一个产品经理需要考虑如何与其它部门之间的沟通合作,文档很大一部分的功能是提醒你要做的工作,同时不断补充将要面临的工作。

5、概述

概念就是总结,它包括的点有:名词说明、产品概述及目标、产品roadmap、产品风险。

名词说明:名称、说明。名称就是对文档中会出现的比较新的名称,说明则是对这些名称进行解释。

产品概述及目标:解释说明该产品是干什么的,为什么需要这样的产品。同时产品想要达到什么样的目标。产品概述及目标就是对产品核心功能讲解,同时希望可以达到的期望。

产品roadmap:产品分期目标,阶段描述,以及时间点的确定,产品是个不断演进的过程,很多时间一期产品只完成了产品70%的功能,二期才会继续去完善剩下的30%,同时有可能会推翻了重新推出第二版。产品roadmap并不及着全部规划好所有的阶段目标,而是更多的通过维护来保持产品的更新和迭代。

产品风险:描述产品可能存在的风险,比如商务谈判的风险,外部合作的风险,不当使用的风险等等。风险级别为高中低。

6、使用者需求

使用者需求一般只有个需求描述。需求描述有以下几项内容:目标客户、需求描述、场景描述、优先级。

目标客户即为产品的最终用户,确定产品的最终使用者。

需求描述是对目标客户的需求描述,表达用户最需要的是什么,找到用户的最根本需求。

场景描述,产品在哪种情况下会被用户使用,就是用户场景模拟。

优先级是指用户对于当前产品功能需求的优先级,哪些是用户最想要的功能优先级则排前。

7、可选方案

列出所有可以选择的达到该产品目标的方案要点(主要思路),给各方案适当的评价,并推荐最优方案。你在做这个产品规划时一定有很多的备选方案,别放弃这些方案,永远没有过时的idea,只有最适合时机的idea。所以可以写出几个可选方案,或许是你下期产品改版一个方向。

8、效益成本分析

产品经理是个全才,在这点上得到了体验。产品经理得知道财务知识。很大一部分是产品的环境搭建成本和支持人员的成本。一般的效益成本分析包括三个方面:效益预测、产品技术中心成本、非产品技术中心支持成本。

效益预测是指提供在各种产品环境中的效益预测,并标明主要的变量及假设,最好能包含现在和过去的效益数据。如网站的PV值,软件的使用数都是效益预测数据。

产品技术中心成本是指设计及部署此产品的产品技术中心所需的资源需求,包括人力成本,软硬件支出等。很大时候这份成本需要由项目经理来协助,需要有什么样的人才加入产品中需与人力协助。

非产品技术中心支持成本,产品不是只有产品组完成的,同样需要其它部门的配合与协助。比如:需要客服部投入多少的资源用于该产品的服务,需要运营部投入多少的资源运营该产品。

9、功能需求

功能需求一般是由四部分组成,功能总览、功能详情、整合需求、BETA测试需求。

功能总览一般包括二个部分,一个是流程图,一个是功能表。流程图是对产品的整体走向的流程的规划,流程图是用来对产品整体功能的梳理。所以在做产品前建议所有的产品经理先梳理一下产品流程。功能表是将流程图文字化,同时将列出产品的功能点。

功能详情,这是所有的产品功能的描述和规划。包括以下内容:

简要说明:告诉此功能主要干什么的。

业务规则:每上产品在使用时都有自己的规则,而产品的业务规则则是将产品的流程细化。个人建议将这个功能的业务规则,包括一些细节,如排版形式、日期显示方式全定好,这样方便其它人员的沟通和理解。

界面原型:产品经理在这时做的原型界面只是显示的框架,别细化,这样会给交互和UI造成错觉。只需做一个简单的界面即可,更多的时候只是个框架图。

执行者:产品使用者。

前置条件:具体的操作。

后置条件:操作后的展示。在UC(user case)中后置条件又是另一种情况,所以对于建议在PRD中的前置条件和后置条件结果合起来。

主流程:把主流放在最后是有道理的,结合上面所说的,做出主流程说明。将此功能的流程走向做个分点说明。

10、整合需求

产品经理很重要的一个能力就是体现在产品整合能力上,利用公司现有的资源或外部资源(合作公司等)实现产品功能需求的整合。实现功能贯穿的同时,更多的如何在新产品上实现功能的拓展来辅助核心功能。

11、BETA测试需求

很多产品都有BETA版本放出,为了就是收求意见和一些性能测试。这部份内容不是必须的,但现在很多产品已经开始先推出BETA版本再推出正式版,当然也可以通过升级来解决。所以BETA测试需求并不是一定需要的。如果有BETA测试需求,则需写出BETA版测试的要求和期望达到的目标要求。

12、非功能性需求

都说产品经理是全才,在这点上得到彻底的体现。很多产品经理在这点上忽视了,但很多方面是用到的,只是在产品过程中弱化了。

一般情况下非功能性需求包括以下几个部分:产品营销需求、规则变更需求、产品服务需求、法务需求、财务需求、帮助需求、安全性需求等。与其说是全方位的掌握技能,还不如说是沟通,如何与不同的部门人员之间的沟通,让更多的人协助产品的正常使用与上线。

13、上、下线需求

上线时限需求:此产品预定上线日期?上线日期有无任何特殊依据或规定?

下线需求(活动类需求必须明确下线时间):此产品预定下线日期?下线日期有无任何特殊依据或规定?

14、运营计划

说明产品的后续运营计划。包括与运营部的协作运营。更多的是给产品经理如何让更多的产品功能展示给用户,产品经理是核心需求的把握者,参与到产品整体运营计划显得特别的重要。

产品定位

这是产品设计的方向,也是需求文档和设计产出的判断标准。

此外,产品定位也是团队成员形成统一的目标和对产品的认识,提高团队的凝聚力和工作效率,可以这么说,产品定位是需求中的需求。

那什么是产品定位呢?

一些产品经理和设计师沟通时候,往往会把功能、业务逻辑梳理得很清楚,但却忘记了把产品主要面向对象、他们的使用场景如何,还有产品的功能、特色等也说清楚,这就会导致设计师很难做决策。

这里可以看出,产品定位实际上就是关于产品的目标,范围、特征等约束条件,主要包括两个方面的内容:产品定义和用户需求。

产品定义由PM得出,用户需求由UED得出,但这一般只出现在大型项目or有充足团队配置的情况中,实战案例更多是PM一手操办,Orz,三头六臂的哪(P)吒(M)啊。

其中产品定义中的主要功能、产品特色和用户需求中的目标用户形成了产品定位中最核心的内容,是产品设计最主要的依据和方向。

产品定义

产品定义就是用一句话概括某个产品,一般可以这么说:

该产品主要面向XX用户提供XX功能,具有XX特色。

这里可能会有疑问,对于一些全用户的产品例如微信、淘宝怎样准确描述呢?这其实有个小小的误区,对于这些发展历程已久,业务迭代升级变化较大的产品,现在的意识形态早已不是当初的样子。微信当初不就是想取代手机短信的功能吗。所以产品定义也是会升级迭代的。

如果你的产品很难用一句话描述清楚,要么就是定位不清晰、方向不明确,要么你正在做的是类似微信一样的超级产品,企图连接一切。而对于创业者来说,连自己都无法流利简洁描述你的产品,那么跟着混的兄弟似乎就要对这个leader多一点存疑了。

举个栗子:陌陌

使用人群:80后、90后单身人群

主要功能:发展基于地理位置的陌生关系

产品特色:LBS搜索用户和群组

有了产品定义之后,可以迫使产品经理努力思考产品的方向和机会,在竞争中寻找差异化,也限定大致的范围,让团队不至于茫然。

用户需求

用户需求就是在具体场景中,目标用户的目标事件。根据一定方法(头脑风暴、调研访谈等),可以得出用户需求示意列表。

值得注意的是,用户类型不是绝对的互斥和独立,更多是以主要取向为区分标准,这不影响后面的筛选和匹配。

其中目标用户是最为关键的,明确目标人群可以使你更专注于服务某一类特定人群,这样更容易提升这类人群的满意度,也更容易使产品做到差异化和成功。

产品是给用户用的,钱也是用户掏的。选择哪种类型的用户作为目标用户,需要综合权衡用户对公司的价值和潜在用户量。

通常会优先考虑最右上角的用户(潜在量大,价值高)。

确定目标用户类型后,就可以筛选匹配出相应的场景和需求。整个过程包含大量思考和决策,因此产品经理需要做足准备工作,包括:了解市场调研结果(趋势、相关联行业或者产品的态势)、了解市场上同类产品的情况(竞品分析)、了解潜在用户的基本情况、了解公司、团队的优势和劣势等等。

需求来源

确定产品定位之后,然后通过不同的方式来收集大量的需求,然后根据这些需求的有效性和真实性、产品定位和项目资源情况进行筛选和匹配,提炼出产品需求,定义出优先级。从产品定位到需求优先级,整个过程不仅涉及对用户的分析和理解,还包括了对产品定位、项目资源的考虑。

需求来源可以大致分为以下几种,其中竞品分析、产品数据、用研是从产品层提出,老板敏锐的眼光则是“人为”思考的结果。

通过五花八门的渠道收集到一堆需求之后,不可能全部都能做,需要按照一定规则和流程,筛选出来最有价值的需求,将有限的投入产出最大化。

其中有一个较重要的环节,也是考验PM能力的地方,透过现象看本质,挖掘用户的真实需求(有个经典的故事:汽车之父亨利·福特曾有一个经典的句子:“如果我问客户他们想要什么,他们总是说想要更快的马。

这里谨记两条:

倾听用户不等于听从用户

用户想要什么不等于真实需求

需求文档

经历完需求筛选和优先级定义之后,通常可以得到需求列表,负责各个功能的产品经理就可以领任务去写PRD了(对于一般更新迭代的需求,可能筛选完之后只有一两条需求,优先级都不需要定义,就可以直接开写了)。

下面是标准需求文档的内容示例:

  1. 文档备案:包括文档日期、版本号、修改人、修改内容和审核人等信息,一般以表格形式位于文档开头。

  2. 目录:方便阅读

  3. 背景描述:为什么要做这个产品/模块,市场行情,业务目标,产品定位等

  4. 用户类型:简单地描述目标用户的情况

  5. 项目时间安排:启动、结束等时间节点

  6. 信息结构:简单理解为内容和页面的层级

  7. 业务流程说明:以流程图形式说明业务各个状态间的切换逻辑(例如:游戏服务器满人时候需要切换到排队登录状态)

  8. 需求说明:每一条需求的详细说明(包括:使用场景、UI描述、功能描述、优先级、输入/输出条件、处理流程、补充说明等)

  9. 涉及关联业务部门的支持,还需要特别备忘。

如同设计稿,代码一样,需求文档很难一次成型,需要不断修改,在评审中发现问题是很正常的。

需求分析广义上看包括了需求获取和分析筛选两个方面。产品定位是确定产品需求的根本依据,而目标用户则是产品定位的标尺。要想得到正确的需求,PM需要全程参与,充分准备,深入到各个关节中,并且充分听取不同成员的意见。

上述方法论是标准化流程,实战运用,不同公司不同项目会有更接地气的一套过程,本文谨对新人作分享和启发之用。需求文档的撰写同理,引用在京东实习时候,曾经就PRD模版和导师有关一些讨论,最后导师给出的意见是:根据需求和进度来灵活变通,切勿迷恋所谓模版。尤其移动互联网时代。仅以此话与诸君分享。

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/376.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息