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

简介: 10年产品经理经验,我总结的那些产品需求文档写作技巧

产品需求文档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不是一蹴而就的,产品经理们要时刻准备着。
相关文章
|
Web App开发 前端开发 JavaScript
网页前端项目评审参考标准
网页前端项目评审参考标准
92 0
|
数据库
产品需求文档(PRD)的写作方法之笔记一
1、写前准备(思维导图): http://www.woshipm.com/?p=80070 1.在写之前,请先很区分清楚什么是MRD文档(市场需求文档),BRD文档(商业需求文档),什么是PRD文档(产品需求文档) 可查阅知乎https://www.zhihu.com/question/19655491 2.规划产品的思维导图(信息结构图)   在写作这份文档前,我们需要先做一些准备,把BRD、MRD的相关需求消化并融合规划出产品的结构图。
2081 0
|
BI 数据安全/隐私保护 UED
以产品经理的角度去讲解原型图---会议OA项目
以产品经理的角度去讲解原型图---会议OA项目
108 1
|
前端开发
「前端经验总结」大型业务项目中,前端如何撰写设计文档
设计文档可以帮助开发梳理业务功能,呈现优质的开发思维的载体。另外,当开发思路逐渐丰富,开发速度也就提上来了。所以本篇分享笔者前端的开发中尤其是大型业务项目,是如何撰写设计文档的。
1375 1
|
关系型数据库 MySQL 数据库
MinDoc:针对IT团队的文档、笔记系统
作为一名IT从业者,无论是在公司团队中,还是在平时自己写一些笔记、博客等文档,我都习惯使用markdown来进行书写。在使用过许多支持markdown语法的系统或软件(如Typora、未知、我来、思源、觅道等)后,我总觉得它们不能满足我的需求。直到我发现了MinDoc这款针对IT团队开发的简单好用的开源文档管理系统。我们下面将介绍一下这个项目及如何使用docker-compose 快速部署。
271 1
MinDoc:针对IT团队的文档、笔记系统
|
程序员 开发工具
[老文拾遗]如果我当上技术经理如何展开工作(三)
[老文拾遗]如果我当上技术经理如何展开工作(三)
|
存储 Java 程序员
如何写好技术文档——来自Google十多年的文档经验
如何写好技术文档——来自Google十多年的文档经验
563 2
如何写好技术文档——来自Google十多年的文档经验
|
数据可视化
R文档沟通|Dashboards入门(1)
在本章中,我们将介绍基于 flexdashboard[1] 包的仪表盘。 仪表盘在业务风格的报告中特别常见。它们可以用来突出报告的概要和关键内容。仪表盘的布局通常是基于网格搭建的,各个组件排列在各种大小的“盒子”中。
150 0
R文档沟通|Dashboards入门(1)
|
前端开发 JavaScript 数据可视化
R文档沟通|Dashboards入门(3)
前面推了两期有关dashboards的推文,可见:R文档沟通|Dashboards入门(1);R文档沟通|Dashboards入门(2)
220 0
R文档沟通|Dashboards入门(3)