博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
顶级产品经理是如何写产品需求文档(PRD)的
阅读量:5889 次
发布时间:2019-06-19

本文共 2629 字,大约阅读时间需要 8 分钟。

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

转载地址:http://dkwsx.baihongyu.com/

你可能感兴趣的文章
PHP队列的实现
查看>>
单点登录加验证码例子
查看>>
[T-SQL]从变量与数据类型说起
查看>>
稀疏自动编码之反向传播算法(BP)
查看>>
二叉搜索树转换成双向链表
查看>>
WebLogic和Tomcat的区别
查看>>
java类中 获取服务器的IP 端口
查看>>
调用约定__stdcall / __cdecl
查看>>
occActiveX - ActiveX with OpenCASCADE
查看>>
redmine
查看>>
css 序
查看>>
DirectshowLib摄像头拍照的”未找到可用于建立连接的介质筛选器组合“ 解决办法...
查看>>
wcf-1
查看>>
三种简单排序
查看>>
[Java]读取文件方法大全
查看>>
【NopCommerce源码架构学习-二】单例模式实现代码分析
查看>>
动态规划大合集II
查看>>
MySQL忘记密码后重置密码(Mac )
查看>>
web.xml中的url-pattern映射规则
查看>>
图像的下采样Subsampling 与 上采样 Upsampling
查看>>