码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2018-04-11 16:13:20      阅读:202      评论:0      收藏:0      [点我收藏+]

标签:active   除了   技巧   任务   验证   深入浅出   不同的   分配   info   

产品需求文档(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不是一蹴而就的,产品经理们要时刻准备着。

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

标签:active   除了   技巧   任务   验证   深入浅出   不同的   分配   info   

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

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!