newheader
手机登录
账密登录
验证码图片
登录
还没有账号? 马上注册
手机登录
账密登录
验证码图片
忘记密码?
登录
还没有账号? 马上注册
欢迎注册陪学网账号
已经有账号? 马上登录
标准化产品需求文档逻辑思路
YOYO
2018-04-03 12:15:16
628
0
PRD被公认为产品经理的标准文档,但你写PRD文档时是否做过这些事: 1. 下载模版,填入内容; 2. 不了解的章节内容,略过或删掉; 3. 找己经做好的PRD,做内容替换。 以前我所在的公司,PRD管理不太好。常常使用上一个迭代,或其它产品团队的PRD模版,做内容替换。

PRD被公认为产品经理的标准文档,但你写PRD文档时是否做过这些事:

1.         下载模版,填入内容;

2.         不了解的章节内容,略过或删掉;

3.         找己经做好的PRD,做内容替换。

 

以前我所在的公司,PRD管理不太好。常常使用上一个迭代,或其它产品团队的PRD模版,做内容替换。

按理解删减,严重的就只留下产品功能的内容。结果是需求没有可读性,长篇大论,甚至需求遗失,团队沟通成本极高,项目延期严重。

我们都说产品PRD是没有人看的,但对于大型项目PRD有着重要的地位,如果对PRD理解不够,应付了事,在项目开发过程中会造成极大的损失。


PRD
是什么

MRD文档表达的是做什么,PRDMRD的延续,只一个表达主题是:产品怎么做。

PRD文档是市场想法落地设计方案的文档,是承上启下的重要文档。尤其在开始过程中,是开发人员的重要参与文件。

因此在产品实现过程中,PRD的重要性不言而喻。对于PRD文档,我们必定明确:

1.
谁看这PRD文档
PRD
的读者包含但不仅限于以下角色:产品总监、研发、UI、测试、相关产品团队(含硬件团队)、运营、客服。

最常关注的读者是:UI、测试、开发


2. PRD
文档怎么写

 

PRD文档没有模板

 

适合的就是最好的,适合自己团队的文档需要产品经理做内容规划。

现在项目开发,多采取敏捷模式,提倡过程中文档的合适数量。因些,很多公司对PRD形式没有特殊要求。

这时,产品经理要制作合适团队的PRD文档,大公司的模版不一定适用小公司。

 

例如,有的团队研发能力强,配合度高,团队有长期磨合经历。无需过多表达就能理解产品经理的隐性需求,PRD当然可以不写,当然,这是项目规模不太大的情况下,对于大型项目,还是建议产品经理要制作正式的PRD文档。

同样的,合作度高的团队,他们的PRD文档,也许并不合适其它团队用,解释很久可能还要返工。

团队合作情况、项目状况。这些都是形成恰当PRD文档的参考因素。

 

l  可以参考Volere产品需求模板

虽然,前面说没有标准的团队PRD文档。但有没有一个规范的PRD模板文件,能够让我们对内容按需调整,形成自己的PRD文件呢?

这里给大家介绍一个极全面的一个PRD文档模板,Volere需求模板。大家可以利用这个模板,进行调整。我收集了很多模板,就是这个是最全面的了,这里分享给大家。


整体概览如下,后面对每个章节分解说明:




 

基本结构
先从前说起,一个需求文档,最前面的内容通常是产品相关信息介绍。但很多产品经理只重视产品功能描述,对其它信息空着,或随便填充内容,是一种误区。

文档是沟通用的,我们认为不言而喻的事,别人未必十分清楚。所以对于前面的内容,也应该有必要的关注。

 

A.        项目驱动

这部分内容表达了构建新产品的根本理由。

它描述了客户面对的业务问题,解释了产品将如何解决该问题,一定程度上可以展示公司和团队形象。

其中有两部分内容:项目目标和利益相关人

项目目标:描述我们希望产品做什么,以及它将为工作的整体目标带来什么好处。

这里的内容不用太长,简短地解释项目目标,通常比长而杂乱的论述更有价值。

 

利益相关人:描述了产品干系人,即与产品有利益关联的人。

这部分的内容可以让产品经理花时间确定与产品利益相关的人,不知道他们的后果可能非常严重。项目开发过程中,上线后,忽略与产品有利益关系的人,产品经理会掉入自挖的坑中。

 

B.        项目限制条件

这部分主要是描述对产品最终设计的可能形成限制的条件。

它们限制了你能做的事,从而塑造了产品。限制条件像其他类型的需求一样,需要有描述、提出的理由和验收标准。

 

例如,这个限制条件:产品的运行环境应在移动设备中

 

C.         功能需求

 

l  工作的范围

工作范围描述了产品中包含的业务领域的边界,工作上下文范围图明确了产品要完成的业务边界。

 

l  业务用例

详细确定业务用例( BUC)对的响应过程,当用户发起产品任务时,应执行的详细业务响应流程,这里是发现详细需求提供基础。

这部分的内容非常的多,也是产品经理主要完成的内容


l  业务数据模型和数据字典

 

例如:

地区气象产品的类:

在这个模型中,每个矩形代表业务数据的一个类。该类的属性在数据字典中定义

 

l  数据字典

数据字典确定下面的内容。

1.数据模型中的类。

2.这些类的属性。

3.这些类之问的关联。

4.所有模型的输入和输出。

5.输入和输入中的数据元素。


l  产品的范围

这部分的内容主要是用例图,它确定了用户与产品之间的边界。

 

Ø  产品用例清单

这部分描述产品中包含的所有用例,并能够确定用例中的输入和输出数据。

 

Ø  单个产品用例

对产品用例清单中的单个产品用例描述细节。包含每个产品用例的场景或模型。

例如

Ø  文本场景描述。

Ø  故事板。

Ø  低保真原型。

Ø  高保真原型。

Ø  正式的用例规格说明书,包括异常和可选场景。

Ø  序列图、活动图、数据流图或项目团队熟悉的其他类型的模型。

 

l  功能需求

每项需求的详细说明,是最细节的功能内容。

写这部分内容时,建议大家用表格一块块去,我尝试过很多次。表格式的详细需求,可读性是最强的。


D.        非功能需求

这部分包含了与产品质量相关,用户体验的所有需求。对于产品的体验性需求都记录在这部分中。

这里的内容重点是需求的可验证,也就是产品实现后,能够对这里的功能进行测试。

 

E.         项目问题

这部分主要描述产品的现阶段存在的问题:如:己经被提出但没有答案的问题、产品可以即刻使用的解决方案、产品出现的新问题、产品开始进度总体计划、费用风险和产品培训等问题。

这部分的内容是动态添加的,因为在产品开发过程中,产品所处的环境是随时在发生着变化的。

长按二维码或加微信pexuepexue
进陪学产品交流群回复:资料分享
免费获取资料:每日更新 免费课程、学习资料、报告、招聘面试
标签:
登录 后参与讨论
发表
全部评论
没有更多评论了
newfooter
陪学网专注于产品管理类课程的开发与制作,
志在为产品经理、交互设计、平面设计、需求人员分享最新、最好的产品类课程。
陪学网:陪伴学习、陪伴成长
粤ICP备18075915号