PRD被公认为产品经理的标准文档,但你写PRD文档时是否做过这些事:
1. 下载模版,填入内容;
2. 不了解的章节内容,略过或删掉;
3. 找己经做好的PRD,做内容替换。
以前我所在的公司,PRD管理不太好。常常使用上一个迭代,或其它产品团队的PRD模版,做内容替换。
按理解删减,严重的就只留下产品功能的内容。结果是需求没有可读性,长篇大论,甚至需求遗失,团队沟通成本极高,项目延期严重。
我们都说产品PRD是没有人看的,但对于大型项目PRD有着重要的地位,如果对PRD理解不够,应付了事,在项目开发过程中会造成极大的损失。
PRD是什么
MRD文档表达的是做什么,PRD是MRD的延续,只一个表达主题是:产品怎么做。
PRD文档是市场想法落地设计方案的文档,是承上启下的重要文档。尤其在开始过程中,是开发人员的重要参与文件。
因此在产品实现过程中,PRD的重要性不言而喻。对于PRD文档,我们必定明确:
1.谁看这PRD文档
PRD的读者包含但不仅限于以下角色:产品总监、研发、UI、测试、相关产品团队(含硬件团队)、运营、客服。
最常关注的读者是:UI、测试、开发
2. PRD文档怎么写
l 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. 项目问题
这部分主要描述产品的现阶段存在的问题:如:己经被提出但没有答案的问题、产品可以即刻使用的解决方案、产品出现的新问题、产品开始进度总体计划、费用风险和产品培训等问题。
这部分的内容是动态添加的,因为在产品开发过程中,产品所处的环境是随时在发生着变化的。