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

11.1什么是PRD文档

• 产品需求文档(Product Requirement Document)的英文简称
  • PRD文档向上是对MRD内容的继承与发展,向下则是要把MRD文档里面的各种理论要求技术化,向研发部门与设计部门说明产品的功能和性能要求
  • PRD文档是产品文档中最底层最细致的文档,所以写作的时候,需要细致耐心

11.2再谈BRD,MRD,PRD文档的区别于用途

• BRD-这么做有好处,并说明好处在哪里
  • 举例: 唐僧出发前,参见唐皇,告诉唐皇西去取经的重要意义与大兴佛法的好处,唐皇答应,并发放免签护照,于是唐僧呆着人物出发了.
• MRD-通过BRD明确了这个事情值得一做后,描述应该这么做,并说明这么做的原因
  • 举例:唐僧上路了,但是他需要选择走哪条线路,带几个人,为什么这么走,为什么带这些人,要说清楚:
    • A线路:妖怪多
    • B线路:神仙多
    • C线路:美女多
    • 经过分析,唐僧决定选择C线路,所以才有了三打白骨精,路过女儿国等经典故事(开个玩笑)
• PRD-获得了授权,而且已经确定了要走的路线,剩下的就是打造装备(产品)了
  • 要把装备的额需求给工匠(研发人员),就需要把你(PM)对(产品)的要求讲清楚
    • 金箍棒:组要能缩短到耳朵里面,直径1毫米,长度6毫米,需要金色,重量必须控制在1kg
    • 九齿钉耙:必须要9个齿,黑色,齿长8厘米,把手长1.5米,直径2.5厘米
    • 于是工匠(研发人员)根据需求,打造出了旷世的武器
• BRD>MRD>PRD是一个逐步论证并得出结果的过程,是产品经理思维升华的过程,是这三个文档三位一体的过程.

11.3PRD文档面向的对象

• 研发人员
  • 犹豫研发人员本身专注于功能的实现与性能,所以他们相对其他诸如运营,市场,设计等表现相对不太关心,对于产品更多的了解来至于产品经理的产品宣讲
• 设计人员
  • 涉及人员本身更多的会关注与产品的调性与原型图,所以对PRD文档的需求是相对较弱的
• 所以,PRD文档,根据阅读对象,就不要去耍花架子了用最平铺直叙最简单的话,把问题说的一清二楚就行,绕来绕去小心被程序员们掏出板斧劈成两半啊

11.4PRD文档的几种表现方式

• 说到PRD文档,很多朋友之前看过模板,都会不假思索的打开Word开始写作,其实PRD文档的目的在于把问题讲清楚,而不是用什么工具!
• 根据实际情况,能满足把问题讲清楚的方式大概有以下几种:
  • 文字模式(Word...最常见的)
  • 原型图模式(Axure...推荐使用)
  • 图片模式(有的产品经理本来就是美术转交互产品,所以他们擅长于此,有门槛的..)
  • 影像模式也可以,就是太浇油了

11.5Axure原型图描述功能

- 在Axure编辑界面,选择要说明的元件,然后输入你要说明的内容

- 发布以后,鼠标点击黄色描述标签,就能形象化的在功能中看到具体的需求表述了呦!

11.6Axure说明到处成为说明文档

- Axure导出说明文档,需要产品经理对Axure默认的导出规则有一些了解,然后在制作原型需求图的时候,就要考虑到Word导出后的一些规则,需要摸索一下,熟练以后,还是很好用的.

11.7常见PRD文档包含内容

• 文档说明
• 产品说明
• 全局功能说明
• 详细功能说明

11.8PRD文档包含的内容

11.7.1文档说明

• 产品版本号(1.26)
  • 版本号(1)
    • 重大调整升级
    • 产品结构功能等有调整
  • 子版本号(2)
    • 在原有基础上面对局部功能进行了升级或调整
  • 修正版本号(6)
    • 局部范围优化与BUg修复
    • 一般是不动功能性的东西
• 版本号的命名原则
  • 归零原则:前一个数字增加一位,后面的数字都归零
  • 收费原则:子版本号和修正版本号的变化,一般看做版本内升级,附加收费用,版本号变化则加收费用

11.7.2历史修订

• 编号
• 版本还
• 修订章节
• 修订原因
• 修订日期
• 修订人
• 历史修订的作用
  • 对修改前后进行比较
  • 有利于维护和管理PRD
  • 修订人
  • 修订日期
  • 方便查阅,可以只看修订部分

11.7.3.名词术语表

• 将一些产品里面不易理解,容易混淆,或者所写的词汇在开篇进行统一的列表说明,有利于阅读.