找回密码
YOYO
614
0
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. 项目问题
这部分主要描述产品的现阶段存在的问题：如：己经被提出但没有答案的问题、产品可以即刻使用的解决方案、产品出现的新问题、产品开始进度总体计划、费用风险和产品培训等问题。
这部分的内容是动态添加的，因为在产品开发过程中，产品所处的环境是随时在发生着变化的。
.png)
