prd文档是什么(PRD文档的作用是)

2.市场文件

MRD市场需求文档是一个产品项目从“准备”阶段到“实施”阶段的第一个文档，它的作用是“在市场层面解释一个产品”。本文档重点定义产品的市场、客户、购买者、用户和市场需求，并通过原型可视化。该文档的质量直接影响产品项目的开发和公司产品战略意图的实现。本文件在产品项目中起着承上启下的作用。“向上”是对积累的市场数据的整合和记录，“向下”是对后续工作的方向说明和工作指引。文件的主要内容如下。

市场描述:目标市场、市场规模、市场特征、未来3-5年发展趋势、当前市场存在的问题和机会。总的来说，我们在这里会得到一个有市场商业价值的结论。

l用户描述:分析目标客户的共性、共同的用户特征(要求准确:年龄、收入、地域、学历)，通过用户画像建立虚拟用户角色:可视化、用户名、用户技能、与产品相关的用户特征、示范场景、用户在时间地点完成的某件事的故事。从技术层面分析市场，通过对用户心理的案例分析，洞察影响用户使用的主要因素【张1】(动机和目标不一致)。

l产品定位:我们用什么样的产品来满足用户或用户市场；针对什么用户，做什么。

l产品价值:解决目标市场和用户的核心需求(核心价值具有最高优先级)。

l产品架构:整体结构，不是功能结构。它是产品的核心目标、市场定位和产品定位的直接体现。

l产品路线图:以时间为节点，以任务为导向。

l产品功能需求:用户注册、留言等。

l非功能性需求:有效性、性能、可扩展性、安全性、健壮性、兼容性、可用性、用户体验等。

3.设计文件

PRD产品设计文档就是把我们要做的事情变成一个清晰的“图纸”，让R&D的人员看到这个“图纸”，知道我们要做什么，需要做到什么程度，大概需要什么技术，并能对成本做出一个估算。不同平台、不同行业的产品设计文档不一样，但思路都差不多。以这里的网站为例，设计文档一般包括网站结构图、线框图、网页描述表。产品设计文档伴随整个产品生命周期，帮助产品团队与R&D团队和高层领导达成共识，然后定义R&D计划，指导R&D过程。不同的公司，不同的产品，会有自己不同的需求和模板，但是这里我想提醒大家一些需要注意的点。

l保持简短:对于产品设计文档来说，重要的是保持简短，因为越简短，包含的错误越少，越容易阅读，越有可能带来简洁的设计。但要在穷尽的基础上简洁，不要为了简洁而忽略一些细节。在产品设计中，每一个小细节对产品的质量都非常重要。所以一定要认真仔细的思考。

l消除错误:错误的文档会耗费R&D团队大量的时间，甚至会导致大规模的变更。在这个时候，没有人会为R&D感到高兴，而且一个接一个会想把你撕碎。有点夸张了。但心里肯定有一万个“操***的”！同时，这也会让产品团队在R&D团队面前看不起。当然，你也不必太在意。毕竟没有错误的文档，就像没有错误的代码一样，是不存在的。我们要做的是尽可能的消除误差，让误差变得可以承受。错误有很多种，包括产品逻辑错误(最致命的)，需求冲突的多个错误，错别字等级别的低级错误。在撰写产品设计文档时，产品团队应组织评审会议，对相应的产品逻辑进行充分的讨论和测试，并通过审批的方式进行检查。

l不对别人(主要是R&D人员)的工作指手画脚:就是不要在设计文件中提到一些技术性的东西。比如存储在数据库的新表中，连续存储，优化查询效率。不要提这样的要求，你很可能会在细节上犯一些错误。己所不欲，勿施于人，别人在你的领域里对你指手画脚，你会很恼火。如果是技术专家，可以私下交流。不要把应该写在技术文件里的东西写在设计文件里。

l以适当的方式表达需求:选择一种适当的方式来呈现特定的信息是产品经理的一项重要技能，在面对R&D团队和最终用户时应该用到。如何把我们的要求表达出来，让R&D或者客户能够快速有效的理解，这一点非常重要，不仅可以提高工作效率，还可以避免很多因为理解不当而导致的错误。理解不一致是常见的错误，不同领域的人要求理解不当也是常见的。选择恰当的表达方式非常重要。比如用叙述性的文字说不清楚，我们就会用表格或者其他东西，有时候还需要选择一些图形工具。

l使用肯定性语言:在产品设计文档中，使用肯定性、确切的语言，不要使用“也许、可能”等词语。我们提交的最终文件都是确切的、可执行的，所有模糊的东西都要剔除。如果有你不确定的事情，在做决定之前把它放在房间里充分讨论。

l不要忽视沟通:很多产品新人在写产品设计文档的时候都是埋头工作，写完之后再出去沟通，这样有99%的概率文档会被大幅修改，相当于做了无用功。所以，在写设计文档的时候，不要忽视与团队的沟通。

4.详细功能

FSD功能规范定义了产品功能需求的所有细节，是一个可以直接让工程师创建产品的文档。FSD基于BRD、MRD和PRD。从这一步开始，它开始与发展挂钩。产品UI和业务逻辑的细节要确定，文档要细化并保持更新。功能是对所有产品功能的描述和规划。以互联网产品为例，包括以下内容。

l简述:介绍这个功能的用途，包括它的来源或背景，能解决什么问题。

l场景描述:产品在什么情况下会被用户使用，即用户场景模拟。这也是产品经理讲“好”故事的必要条件。

l业务规则:每个[张2]产品在开发过程中都有相应的业务规则。应该清楚地描述这些规则，以便开发人员和测试人员可以直观地理解这些规则，而不会产生歧义。业务规则必须完整、准确且易于理解。如果业务规则描述涉及页面交互或页面修改，建议给出页面草图或页面截图，说明要修改的内容。此外，还建议说明页面的输入框和下拉框的内容格式、长度、控件之间的关联性，以及何时可见、何时不可见、灰显或亮起来的条件都在文档中说明。方便读者理解商业规则。

l界面原型:前面提到，说到页面交互，产品经理需要设计页面原型。原型设计通常需要产品经理和UI设计师协同工作。建议的做法是，产品经理可以设计一个页面框架，把页面上要呈现的字段，它们的特点，以及页面上要使用的场景，向交互设计师解释清楚。之后，交互和可视化设计师完成产品的原型设计。

用户描述:说明产品的用户，可以并入简要描述。

l前提条件:这个要求所依赖的前提条件。比如上传照片的时候，需要一个有图片的文件。

l后置条件:操作后触发的后续处理。

l主流程:把主流放在最后才有意义。结合以上，对主要流程做一个描述，对各个功能流程做一个逐点的描述(这个很重要)。

我看过很多prd(包括FSD)。文档中既没有前置条件，也没有后置条件，只解释了主要流程。但在描述主流程时，只有一个主趋势，让人感觉PRD成了操作手册。其实分支的引入很重要，开发和测试中提出的各种问题都和分支定义不清有关。一份合格的PRD不仅要描述主流程，还要阐述分流程中的各种问题，并给出解决方案。PRD的特点必须清晰全面的说明需求和各种异常情况的处理，而不是等到开发和测试阶段发现问题后才给出答案(虽然PRD不能100%覆盖所有可能性，但最大限度的思考所有业务问题是我们在编写PRD时必须遵守的原则)。另外，在描述功能需求时给出的方法中不能出现“可能”、“或者”等词语，必须是清晰准确的描述。如果有其他方案，建议写“备选方案”。产品构建初期的备选方案可以为功能实现提供更多的选择。方案确定后，可以在单据中注明这次使用哪个方案。