【人人圆桌】第六期 产品需求文档PRD模版
人人圆桌
人人圆桌是在群讨论的基础上,通过筛选人员、限制讨论时间的一种讨论模式,以达到帮助新人成长、发散思路和学习交流的目的;而且因圆桌讨论的特殊性,也能在讨论中暴露出一些工作和思维上的问题,避免工作时再次犯错。
规则介绍
人人圆桌开启时间为每月第二个周四晚上20:30,历时60分钟。圆桌主题确定后会提前在众多报名者中,选择10名合适的成员单独建群讨论。
圆桌主题则在圆桌招募初期即公布,成员在获知主题内容后都有思考、收集资料的时间,但不允许私下讨论。
圆桌时间仅有一个小时,无论是否得出结果都必须结束。因而对参与者的思维能力、话题把控能力、沟通能力、时间管理等都是一大挑战。
本期话题
对于产品经理来说最重要的三个需求文档是商业需求文档、市场需求文档和产品需求文档,而关于文档的模板资料,质量却参差不齐。本次讨论选取产品需求文档作为讨论的话题,让大家在圆桌讨论中分享各位关于产品需求文档写作思路的干货。
任务目标
针对一个工具类App应用(以zaker为例),设计一个合理、可用、完整的产品需求文档模板。
圆桌记录
2014年11月13日晚8点30分,经历了严格筛选的产品老鸟们开始了为期一小时的思维碰撞,力求解决“产品需求文档到底该怎么写“这一终极难题。
首先大家一致确认了PRD的重要性,积极的Phoenix抛出了一个可供大家讨论的模版。
经过大家确认,一致认为效益成本分析是MRD中已经确认的内容,不应该在PRD中讨论,所以去掉了效益成本分析这一块。
接下来按顺序分析
1.概述
关于概述大家都有不同的想法
Phoenix提出概述应该包括名词说明;产品概述及目标;产品roadmap;产品风险,节奏提出既然是概述肯定要概括的说明产品的背景;产品的目标;产品的基本介绍等,基于经验大家又发现需要对数据的进行部分说明增添了数据字典的模块,需要对PRD的阅读对象进行分工定义,增添了文档阅读对象。
发散思维的各种讨论后,讲概述确定为
1.1产品概述及目标—-包括背景介绍和产品目的
1.2名词解释—-声明文档中出现的名词含义
1.3数据词典—-介绍本产品中数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等。
1.4文档阅读对象—-声明本文档输出的阅读对象和注意事项
确认了概述时已经时间用去三分之一,各大神明显觉得时间过得好快。。。所以接下来的讨论加快了速度,快速的确认接下来主要讨论的内容:产品描述和功能描述。
2.产品描述
讨论完概述后,大家一致认为使用者需求这个词语容易造成歧义且范围过窄,所以将名称改为了产品描述。
产品描述章节介绍了产品的整体逻辑流程,概括性的描述产品需求、产品版本规划、产品整体的框架结构以及功能列表。产品整体流程与产品框架都需要使用相应的图表展现方式
产品描述经过确认包括
2.1产品整体流程-—展示产品框架图和用户流程图。
2.2产品需求描述—-描述产品核心功能,解决哪些情景下的哪些需求。
2.3产品版本规划—-叙述产品版本迭代计划,版本号、主要模块、功能点、计划开发时间、计划结束时间、备注。
2.4产品框架—-展示页面层级及备注信息
2.5功能列表—-展示产品功能名称、对应模块、功能说明、备注等信息。
3.功能描述
功能需求章节需详细描述产品所涉及的各个功能点。将整体框架拆成数个独立的功能点,分别描述每个功能点的逻辑流程图、界面、字段说明以及业务说明。统一采用usercase方式进行描述。
这块其实是pm比较熟悉的部分,所以基本上是大神们毫无歧义的就敲定了如下内容:
3.1流程图
3.2界面
3.3字段说明(包括数据字典)
3.4业务说明(usercase)
此时 最初的PRD框架已经被细化为一个 有细化分支的 详细框架,如下
此时时间已经过去四分之三,开始讨论非功能需求、附录及部分大家没有之前想到的东西。
比较重要的是非功能需求和上下线需求及后续运营计划。
4.非功能需求
关于非功能需求,大家的考虑又开始出现分歧,主要是由于各公司的定义不同,造成内容不同的差异化,总结了下大家提及到的是安全、可用性、伸缩性、数据统计、易用性、接口需求,通过沟通消除各公司的语义差别和部分理解偏差,最后提供了一个可供参考的、比较合适的非功能需求内容。
4.1安全需求
4.2统计需求
4.3性能需求
4.4可用性需求
此时已经接近尾声,大家大致讨论了下上下线需求的内容和运营计划该写的方向,加上其他声明的附录,产出了文档。
最后的成型模版框架为:
写在最后:
本次圆桌在筛选人员上进行了十分严格的人员把控,力求选取工作一线上经验丰富的产品人员,通过圆桌讨论的方式将接触到的文档进行还原与输出,大家在讨论中也表现出了经验赋予产品经理的睿智,和产品经理应有的自检自查,高效沟通的素质。一小时的讨论过程是对自己经验的总结、考验,也希望产出的模板在以后的实际工作中能给大家带来参考和指引。
更多圆桌
感谢人人都是产品经理以下成员参与讨论(排名不分先后):
林维艰-产品-SH、节奏-产品-北京、Ted-PD-北京 、Phoenix、Lunatic-纯洁-魔都、Jason-移动社交、Darrick-本地服务
感谢 Phoenix 童鞋整理文档
感谢 Ted 童鞋产出总结文件
本文由人人都是产品经理原创,未经许可,禁止转载。
产品小白,希望大家能给点帮助,这些名词真的好绕。
1# 2.1和2.4的产品框架图有什么区别?
2# 2.1的用户流程图是什么意思,用户操作流程吗?
3# 2.4的产品框架是指什么?页面流程图?还是信息架构/功能架构图?
4# 3.1的流程图是什么意思?是每个功能实现的详细任务流程图吗?
5# 3.4的业务说明,是用例图?还是业务流程图?
已被自己绕晕……
我想问有多少PM会写字段说明/数据字典???
我不会,头一次听说数据字典的概念 ➡
就是数据表,mysql没有听过吗?
听说过,我做开发工具的也会写代码,但作为 PM 从来不需要写数据表。
有没有实例的需求文档 能否发一份参考。
产品是若干版本迭代出来的,每个迭代版本都有需求文档。这个文档适合若干个版本之后的整理的基线文档,不适合迭代过程中的需求文档。
赞
请问2.1的产品框架图和2.4的产品框架有什么区别?页面层级的框架图怎么画
数据项、数据结构、数据流、数据存储、处理逻辑、外部实体 怎么写
http://wenku.baidu.com/link?url=BAyvtbnBzXXyWAMd-IuNqIy9L4H4lWnxG1KYoCXtJcpRU9pwn75ggrKsxizGggxxUN5lRPz3C8Mk8lGNX27KQ15zAiO0cqCc-fx88UTVk07
主要是高保真原型+特殊需求说明就可以了,这个文档着实复杂
原型图更重要点吧 交互和效果能很好地展示
这么写,完全没有考虑到程序员对需求的可读性,要知道程序员根本没有耐心看这些长篇大论,导致的最终结果是不按需求开发或者是要点遗漏,尤其是一个app只由一两个程序员,并且随时还要切换到其他项目开发的时候的时候…
你说的很有道理,很多程序员跟我抱怨还如看流程图来着实在
所以为什么写这个文档的时候不加入流程图?不是有产品整体流程吗?
鱼精说道 完全可以给实例的,别害羞
什么是安全需求?可否给个例子? ➡
同求实例
能否给一个实例
[呵呵]
老婆买了大瓶的可乐,让我拧开。我拧了一分钟都没反应,老婆说:你还是不是男人啊,这点力气都没有。我说:那你去找别人拧吧。老婆就抱着可乐去找隔壁王大哥,过了十五分钟,隐隐约约听到老婆在隔壁说:王大哥用力用力啊。呵呵,我心里乐了,都二十五分钟了【微信号:今日爆笑排行榜】