产品需求文档:如何撰写一份敏捷的PRD文档?

20 评论 47633 浏览 320 收藏 10 分钟

编辑导语:产品需求文档是每个产品经理都需要学会撰写的,作为一名敏捷开发团队的产品经理,如何撰写一份适合敏捷迭代开发的PRD文档?本文作者为我们做了详细地解答。

前言:软件开发方式大概有这么几种,分别是瀑布模式、迭代增量式、螺旋模式、敏捷开发。敏捷开发相比其他模式,它的优点是开发周期短(1~2周为一个周期)、更强调队伍的高度协作、更迅速的响应。

在互联网时代时间就是金钱,多花一天时间开发就是多烧一天钱,因此现今比较常用的是敏捷开发模式。

敏捷开发最大的特性是迭代周期,一份敏捷版PRD文档必须要匹配这一特性,否则迭代就会被捣乱,轻则迭代延期,重则敏捷开发变瀑布开发,两周一个迭代结果慢慢拖成一个月一个迭代。

这里介绍一份由敏捷开发团队实战总结所得的PRD模板,不同于其他豪华繁重的模板,这份更适用于敏捷项目,能快速响应迭代开发所需。

下面来详细讲解一下这份敏捷版PRD文档。

一、PRD目录结构

产品需求文档:如何撰写一份适合敏捷迭代开发的PRD文档?

敏捷版PRD文档的目录结构包括:文档标识、产品概述、1~N期,其中产品概述中包括:功能架构、需求分期表、需求变更对比、研发计划表、流程图、角色权限、名词解释。

对于外包项目或投标项目还需要在产品概述处增加产品介绍、受众群体分析,请自行增加,此处不再另述。

二、文档标识

该页是填写项目的名称及产品经理的基本信息:

  1. 名称:顶部为项目文档的名称;
  2. 标识:右下角为项目负责人(产品经理)填写的基本信息。

三、功能架构

产品需求文档:如何撰写一份适合敏捷迭代开发的PRD文档?

该页放项目的功能架构图或页面架构图,这需要产品经理在做需求分析时把项目的功能/页面架构用思维导图或VISIO等软件整理出来并导出图片,再将图片复制到PRD中。

当后期版本迭代不断增加时,当初的功能架构图肯定会有所变动,所以:

  1. 整理功能架构图时,可以只整理大版块,就不用为了小功能点的变动而去修改该页;
  2. 若功能架构图整理得很细化时,则源文件一定要保存好,只要修改好源文件再导出图片,再插入进去即可;
  3. 最好按优先级或迭代周期,打上123456……的标识,以便项目组成员快速了解某一迭代的需求量,因为迭代周期很重要。

四、需求分期表

O1CN01ywUhRK2EIj8Y0paar-!!33448722

该页放整个项目的需求计划,产品经理在做完需求分析后,就需要将所有的功能点、页面整理出来,并做好分期。

  1. 分期的基本原则是以一至两周的工作量为一期,即一个迭代为一期;
  2. 需要将当期包含的主要页面或功能点罗列出来;
  3. 填写需求的创建日期修改日期,是方便产品经理对当期的开发进程把控;
  4. 评审时间、状态、审核人,是便于记录当期的评审结果,如果有复审的,则以复审时间为准。

五、需求变更对比

O1CN01C3ZCV32EIj8RKtQe9-!!33448722

该页填写同一页面中需求有变更、修改的记录,属于小变更、小修改的记录,以红字标记需求变更时间;至于大变更、大修改则以迭代的方式,安排到后面的需求分期中去。

六、研发计划表

O1CN01OVsckr2EIj8T5dXVl-!!33448722

该页填写每个迭代的研发时间表,包括UI设计、程序开发、测试、验收、发布上线等各个阶段的计划时间与实际时间;绿色表示提前及按期完成,红色表示延期完成,以便项目负责人掌控项目开发进度。

当然这是微小团队比较便捷的项目管理方法,最合适的是利用软件来管理项目进度,如禅道、TAPD、Teambition等。

七、流程图、角色权限、名词解释

流程图页放项目的一些流程图,可直接在AXURE上画,也可在VISIO等其它软件画好导出图片,再插入进去,但源文件一定要保存好以便修改时用到。

角色权限页放项目的一些角色用例、角色权限图等,可直接在AXURE上画也可在VISIO等其它软件画好导出图片,再插入进去,但源文件一定要保存好以便修改时用到。

名词解释页用于编写行业专用术语、不好理解或自我创新的词汇,对这些名词术语进行解释说明,方便新人对项目的理解,加快融入项目组。

八、迭代1~N期

前面罗列完项目的基本说明之后,接着就是原型页面了,这是敏捷版PRD最关键也是最不同的部分。原型页面以期数来划分成不同的文件夹,期数文件夹以降序排序(即54321,升序12345亦可):

  1. 若页面有小修改,则在原期的原页面上进行修改;
  2. 若页面有新增或大修改,则迭代到新一期中去,即在新一期中新建一个相同的页面,把变更的东西表达在该页上;
  3. 分期中可包含当期的流程图、用例图;
  4. 通用提示窗或交互,可单独汇总到一个文件夹中;
  5. 页面不需要加页码。

本模板的原型页面实则是包含原型和需求文档两部分,左边是页面的原型设计,右边是页面的需求文档。

主要是在左边的原型设计中加上标注码,右边以一个标注码为一行来书写需求文档,两者通过标注码来索引,如下图所示:

产品需求文档:如何撰写一份适合敏捷迭代开发的PRD文档?

上图具体说明如下:

1. 序号

即标注在左边原型设计上的标注码,用英文字母A-Z来表示。

2. 名称

指单个功能点或元素的名称。

3. 类型

包含初创、修改、新增、删除,各种类型说明如下:

1)初创

黑色字体,指该功能点是第一次创建的。

2)修改

蓝色字体,指该功能点在当页的需求发生变更。

3)新增

绿色字体,指该功能点在当面中是新增加的需求。

4)删除

红色字体,指该功能点已被废除。

4. 需求描述

书写对应功能点的需求描述,尽量详细、明了,最好分几大点几小点来书写,123表示大点,①②③表示小点。

若在某个功能点中发生需求变更时,则在对应的功能点某小点的后面加上说明,用红色字体,并打上日期,如下图所示(同时需要在需求变更对比表中体现出来):

5. 备注

填写该功能点的一些特别的说明,或附加说明。

九、结语

以上就是一份敏捷版PRD文档的大致说明,至于更详细的内容,或需要套用该PRD模板的同学,请移步至下面的作者简介处了解更多,或关注作者同名公众号。

作者:默林如斯工作室;公众号:默林如斯工作室

本文由 @默林如斯工作室 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Pexels,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 写竞品分析、PRD等产品工作的相关文档,看似普通又基础,却是产品经理在追踪行业情况、将需求落地为产品的过程中必不可少的步骤,并且将贯穿产品经理的整个职业生涯。然而,0-2岁的产品新人普遍存在盲目套模板、文档逻辑混乱等问题。

    为了帮助产品新人快速掌握文档撰写基本功,这里推荐由起点学院联合惠买集团产品总监@陈滨淋 老师打造的【15天掌握产品经理必备文档】学习计划。从实例出发,带你高强度系统性学习11大类常用的产品工作文档,快速帮你规范化日常文档,提升工作效率>>>http://996.pm/71GE5

    来自广东 回复
    1. 这广告打得,颇有只准州官放火不准百姓点灯的感觉

      来自广东 回复
  2. 写得挺好的

    来自广东 回复
  3. 需要了解更多关于该PRD模板的内容,或获取模板的同学,可以关注我同名公众号

    来自广东 回复
    1. 哥,请问哪里获取模板啊?公众号是指微信公众号吗?

      来自湖南 回复
    2. 默林如斯工作室(微信公众号/淘宝店)

      来自广东 回复
  4. 好像并不敏捷。若加上交互、流程图、界面布局、各种异常情况界面,还有这些文字描述,加上变更。我就试过一个2周迭代里面有10处变更,前后截图描述+提交工单,那一天啥也不用干了,净做这些文案性的事情

    来自广东 回复
  5. 写的太好了。可以转发吗?

    来自广东 回复
    1. 转到哪呢?

      来自广东 回复
    2. 想引用,打错字了

      来自广东 回复
    3. 我的微信公众号还在申请呢,等我开通了知会呢 ^_^

      来自广东 回复
    4. 好吧,那我可以复制到我的工作号里,我会注明转发,作者,已经原文链接的。主要还是方便自己找来反复看

      来自广东 回复
    5. 亲,我已经开通同名公众号,欢迎转发分享

      来自广东 回复
  6. 需求分期表中,关于状态,若审核未通过是否如何展示?在状态栏中可以考虑两种甚至更多状态,并添加备注栏,记录原因及提供修改意见,便于产品、交互和开发保持对文档的同步性。

    来自美国 回复
    1. 在一份正式输出的PRD中,是不需要记录这些的。需求评审都是当面讨论的,审核不通过就说明原型设计或需求描述还有问题,那就再次修改再次评审,产品经理自己在评审会议时做好记录就行。
      你说的情况偏向需求变更的情况,那个是很需要记录清楚的,并要及时知会各组负责人。

      来自广东 回复
    2. 那需求评审的会议记录咧,如果这个需求是合理的但是由于当时的某种原因被搁置掉了,后续翻案时,没有共识的记录产品经理怎么翻案呐

      来自美国 回复
    3. 那不是产品需求文档的范畴吧,那说明需求还在分析阶段,还不能形成正式的PRD文档。当然如果是你自阅的,可以加上评审状态和评审结果备注说明。

      来自广东 回复
    4. 如果是敏捷开发可以不必记录。但是长期版本迭代的话,还是追加一个比较好,毕竟Battle起来六亲不认,难道减少通用的产品迭代说明文档不香嘛

      来自美国 回复
  7. 哥,去哪里扫码啊

    来自浙江 回复
    1. 来自陕西 回复