顶级产品经理是如何写产品需求文档(PRD)的

产品需求文档(PRD)对每个产品经理来说都不陌生,它是产品项目由"概念化"阶段进入到"图纸化"的转折和体现,作用是"对市场需求文档(MRD)中的内容进行指标化和技术化",PRD质量的好坏直接影响到研发部门是否能够明确产品的功能和性能,是否能够研发出符合预期的产品,所以PRD也是体现产品经理专业程度的一个重要指标。

可以理解为,PRD是产品经理关于产品功能的宣导和传达,它通过清晰扼要的表述将产品意图呈现给阅读者,PRD的阅读者一般包括开发人员,设计师,测试人员,甚至包括产品及项目负责人(一般是项目总监)及公司老板,每个公司的情况有所不同。PRD不仅是产品功能的详细说明文档,PRD的作用更在于,它是产品质量控制的执行标准,是将产品从概念落实为实际的开端。

PRD应该包括哪些内容呢?

1,产品名称

产品名称也就是对于文档的大概说明。一般包括标题+版本+时间+编写人+相关人这些基本信息。

标题就是文档名称,是待讨论版本还是正式开发版本,及该版本对应的制作时间,需要哪些人员的参与等等都需要写明。

2,目录

目录用来展现文档结构,一般不要超过三级,否则就显得过于凌乱。当然,不同的公司PRD呈现内容的详尽不同,目录也就不同,详细来说,文档内容可以包括需求描述,角色说明、流程图、页面及功能、与其他系统交互接口、效果预期、数据指标、PRD迭代记录。很多公司的PRD还包括引言,概述,名词定义,使用场景,产品目标及竞品分析等非常多的内容,如果是公司内开发用的PRD,还会写明该功能的呈现形式、交互方案、操作规范、相关开发人、负责人、开发时间等,使得PRD非常厚重,目录也就相对比较多。简单来说,PRD可以仅围绕功能需求展开,那么,目录就简单的多,基本就包括功能需求的大标题。下图是我曾经读到的一份PRD的目录,从目录就可以看出这个文档的内容其实是非常多的。

3,功能说明

功能说明是PRD的主体部分,我的写作习惯是宁简勿繁,功能说明详细介绍,其他能省则省。因为大多数程序员在产品的开发中并不会过多关注这些长篇大论,他们往往只关注那些可以迅速转化的内容,文档内容太多反而会造成一定的干扰。所以,适当精简,加强可读性,表明产品意图才是最珍贵的。

在具体的功能描述中我们经常会借助一些其他方式,比如产品功能结构,产品信息结构,用户使用流程等,把文本内容可视化表现,不仅让文档更加轻松和直观,也能减轻阅读者的阅读负担。很多团队用原型图及图片来辅助就是非常聪明的做法。如下图这个论坛发帖流程图。

说到简化,其实现在很多的互联网公司也在强调多沟通少文档,他们甚至没有PRD。国内知名的项目管理工具禅道
就提倡按照功能点的方式来写需求,简单来讲,就是将原来PRD中的每一个功能点摘出来,录在禅道里面,作为一个个独立的功能点。产品项目相关人员通过讨论确定需求,然后以需求为中心,进行任务分解分配,进度监控,测试,发布。

这时候需求不再是最终守则,而是允许变更和取消的。这里的需求状态(status)就被分为四种状态,草稿(draft)、激活(active)、已变更(changed)和已关闭(closed)。其状态流转图和需求变更图如下:

这种方式多用在时下比较常见的敏捷开发模式中,这些互联网公司更加强调沟通、开放、快速解决,这种方式的好坏与否我们不做评判。但是作为专业性比较强的规范文档,PRD跟项目管理工具的结合其实是更多企业的选择。下面我们继续回到PRD上来,说说PRD需要具备的一些原则吧。

一份合格的PRD文档应该具备哪些特点?

我总结了“二无二可”原则,也就是说PRD需要做到“无错误无歧义,可检验可追溯

无错误是PRD的最基本要求,这里无错误既包括文档内容的正确定义,不能出现文法错误,又要保证做到对产品经理思路和意图的正确表达。

无歧义要求一句话表达一个意思,要做到文档的众多阅读者读到的是同一个意思。

可检验说的是可监测和可验证。要求PRD中的功能性描述要实现可测试可衡量的效果指标。不要出现无法定性的词汇,如:效率高,交互完美等,都是无法验证的。

可追溯指的是,对于每个功能性需求的来源应该是清楚的,我为什么要这么做,应该有理有据,而不是一拍脑袋做决定。

做到“二无二可”也是PRD的基本要求,下面我们说一下我在工作中总结的几个写作技巧,算是我的一点心得吧。

说说那些值得分享的PRD的写作技巧:

1, 表达适当通俗

说到底,PRD还是专业文档,少不了专业术语和词汇,但这并不代表专业词汇越多越好,过分堆砌专业词汇让人不知所云才是最失败的PRD。用尽量通俗的语言做到专业性的表达是难能可贵的,因为易于理解和操作是PRD更为重要的使命。我在写完一份文档以后,通常会给到尽量多的人去看,除了技术人员,运营,销售甚至你的亲友都可以,他们会提出不同的意见和疑问,其实这是一个很好的修正途经,也是发现问题的过程。

2, 逻辑尽量清晰

因为PRD是关于产品需求的阐释,其中所涉及到的大小功能非常多,而且各个功能点之间联系紧密,这就要求产品经理的逻辑要非常清晰,将抽象思维进行具象化表达,这是对产品经理的硬性要求。由于人的思维逻辑性受制于先天因素,上面也提到了我们可以借助软件工具去辅助实现,表现形式有很多种,比如原型、流程,也可以是其他的形式。形式格式不重要,要记住一切以清晰传达为目的。

3,切记突出重点

突出重点也就是核心功能重点说明,辅助说明尽量简化,有主有次,有舍有得,做到深入浅出的去表达。其实写PRD跟我们小时候写作文差不多,有标题,有内容,有分析,有总结,重点部分重点突出,自然需要花费更多的笔墨。很多产品经理往往力求完备,就怕有遗漏,每一个细节都要顾及到,其实这个是完全没有必要的,PRD不是写论文,不需要反复论证,只要把事情讲明白看得懂就足够了。

总结

PRD考验的其实是产品经理的综合素质。要写好PRD,产品经理除了本身专业素养的提升,更需要保持对产品的敏感度和好奇心,加强逻辑思维能力及文字表达能力。文中说到的都是在PRD的撰写过程中需要注意的地方。其实一份完备的PRD在产生之前,你可能需要一个长期的信息搜集过程,任何人都可能成为你的灵感来源,用户、竞争对手、研发团队、销售队伍、运营人员等等,他们都可能为你提供建设性的建议和创意点,所以多倾听他们的声音,不断积累和收集,PRD不是一蹴而就的,产品经理们要时刻准备着。

原文地址:https://www.cnblogs.com/xiaobai007/p/8794552.html

时间: 2024-12-23 01:03:14

顶级产品经理是如何写产品需求文档(PRD)的的相关文章

产品需求文档(PRD)的写作方法

无论我们做什么事都讲究方式方法,写产品需求文档(以下称PRD文档)也是如此,之前我通过四篇文章分享了自己写PRD文档的一些方法,而这一篇文章主要是对之前四篇文章进行整体的摘要介绍,帮助大家快速了解写作流程. 产品需求文档(PRD)的写作 四篇章:1.写前准备(信息结构图)2.梳理需求(产品结构图和用户流程图)3.原型设计(手绘原型,灰模原型,交互原型)4.撰写文档(PRD文档)5.用例文档(UML用例图.流程图) 1.写前准备(信息结构图):http://tangjie.me/blog/52.h

产品经理应该先写需求文档还是先画原型?

江洋@知乎上的回答: 先做模型,再画原型,最后PRD 模型:对产品形态结构的梳理,包括功能模块,逻辑关系,信息架构,业务流程等,可以用脑 图,use case图,业务流程图来表示,根据不同产品,产出物的侧重点不同.但模型很必要,是可以帮助产品经理将一个想法,或是脑子中的模型梳理清楚,在做这些工作的同时,可以及时发现自己没有想清楚的细节,这些是指导后面产品设计师(或产品经理)进行原型设计的.同时,描述模型的产出物可以做为传递,帮助别人理 解你的产品形态. 软件:MindManager,Visio

产品经理应该先写需求文档还是先画原型图

先做模型,再画原型,最后PRD 模型:对产品形态结构的梳理,包括功能模块,逻辑关系,信息架构,业务流程等,可以用脑 图,use case图,业务流程图来表示,根据不同产品,产出物的侧重点不同.但模型很必要,是可以帮助产品经理将一个想法,或是脑子中的模型梳理清楚,在做这些工 作的同时,可以及时发现自己没有想清楚的细节,这些是指导后面产品设计师(或产品经理)进行原型设计的.同时,描述模型的产出物可以做为传递,帮助别人理 解你的产品形态. 软件:MindManager,Visio 原型:即画出产品la

产品经理常用的四种需求收集方法简述

A 客户访谈 客户访谈是通过面对面的交流方式了解具体客户对产品.对流程的需求.观点和看法. 客户访谈的内容可以包括: 1.了解哪些需求对客户比较重要. 2.就了解到的一些需求请客户协助进行优先排序. 3.就问题改进建议的初步想法与客户进行讨论,确认是否能够满足客户需求. 客户访谈的优点包括: 1.由于是面对面的交流,因此在调查内容上更加灵活,可以随时根据问答状况就一些内容进行深入讨论,获得更多的客户感受. 2.客户可以再调查人的协助下,进行一些较为复杂的问卷调查. 3.客户访谈方式的适用面广,可

【产品】好的产品需求文档(PRD)怎么写?

PRD(Product Requirement Document,产品需求文档),顾名思义是阐述产品需求的一种文档,其核心是将需求描述清楚. 通过PRD可以看出一个产品经理对产品理解的逻辑思维,产品经理在相关领域的认知和专业的深度以及对产品全局的认识.如何才能写出好的PRD,让产品研发团队成员,开发.测试.运营同学了解产品需求,让其他人能从该文档中看到产品的价值和意义,估计很多人都思考过,如何让PRD不被其他人挑战,如何获得他们的认可估计是产品经理经常考虑的问题.也有人可能认为PRD只要中心思想

如何写好产品需求文档?

常常有人问我怎么写prd,在深受市面上流行的功能需求模板“残害”之后,我现在一般不会向别人推荐任何所谓的“模板”. 需求文档是产品需求的表达方式,而其中需要描述什么内容取决于产品经理想要描述什么,即产品经理的需求.如果产品经理的需求是明确的,而且产品经理脑中有物,那么需求文档自然而然就出来了.最可怕的是产品经理自己都不知道自己要描述的是什么内容,这个时候即使有模板,写出来的东西也是一团糟. 互联网产品以用户为中心,所以prd也应该站在用户的角度来描述,如果不知道自己要写什么,在写文档之前产品经理

产品需求文档(PRD)到底怎么写?

做产品经常会写PRD,但是如果没有一套完整的写作思路和框架,写出的PRD质量就不会太好,导致遗漏重要信息,在项目过程中被开发.前端.测试吐槽.趁这个周末有空,来梳理下一下写PRD的逻辑. 一.什么是PRD? PRD为Product Requirement Document的简称,其中文翻译为:产品需求文档.该文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档.当然,这个定义针对的是一个全新的产品.广义上来讲,产品需求的描述,应该包含有产品的战略和战术,战略是指:产品定位.目标市

互联网产品经理应该具备的技能(需求篇)

产品经理的需求技能,包含需求获取.需求筛选.需求分析.需求执行,这一系列过程是对产品经理综合素质的一个考验和全面衡量.如:对知识的要求,对行业市场的理解和经验. 而且在这整个过程中,我们如何快速.高效的完成需求工程,也对我们有着越来越高的要求. 一.写需求的八项思路 1.合理的建立全局观,把握整体框架; 2.合理的建立业务模型; 3.合理的拆分系统需求; 4.合理的预留系统扩展; 5.合理的处理好业务流,信息流,以及数据流; 6.合理的遵从:业务原理(逻辑)"→系统实现原理(逻辑),然后细分到-

程序员爱看的产品需求文档,转给你的产品经理

假如产品需求文档(PRD)是一个产品,如何做出一个拥有良好用户体验的PRD? 让我们先来考察下PRD的用户群体(User Persona):主要是开发人员,在繁忙的开发任务中最希望看到"简洁易懂"的产品需求文档. 梳理下PRD的功能:传达出产品需求:管理记录产品迭代过程:各部门共享产品信息,以促进沟通: 因此一个好的PRD的原则是:结构清晰:语言简洁易懂:实时共享. 我们具体如何制作? 一个PRD文档即可 现在,越来越多的产品经理采用将文本说明和原型结合成一个PRD文档的方式,因为之前