《简单明了丨如何写出好的PRD.docVIP

简单明了丨如何写出好的PRD 我要分享 PRD（Product Requirement Document，产品需求文档），顾名思义是阐述产品需求的一种文档，其核心是将需求描述清楚。 通过PRD可以看出一个产品经理对 产品理解的逻辑思维，产品经理在相关领域的认知和专业的深度以及对产品全局的认识。如何才能写出好的PRD，让产品研发团队成员，开发、测试、运营同学了 解产品需求，让其他人能从该文档中看到产品的价值和意义，估计很多人都思考过，如何让PRD不被其他人挑战，如何获得他们的认可估计是产品经理经常考虑的 问题。也有人可能认为PRD只要中心思想不变，阐明需求就已经足够，交给下游的同学他们理解了就完事了，但是这个文档是否被叫好，是否有用，是否有价值可 能从没考虑过。 在此将从PRD的用户侧分析好的PRD应该具备的要素或必要条件。 首先，先了解清楚PRD的阅读对象，使用者。 PRD的模版中一般有如下信息： PRD预期的读者包括：产品、开发、测试人员及相应的负责人和用户方代表。产品、开发、测试人员会从中了解到本次需求的背景和详细要求，以及每个需 求点未来的优化方向或对用户的价值。而用户方代表则可以通过该文档了解PRD中所描述内容是否是自己期望中的需求，是否符合以及是否都覆盖到了自己的预 期。因此PRD也是产品经理同相关角色确认开发任务的重要依据。当所有角色认可了PRD中的内容后，这份PRD将作为后续开发、测试、需求验证的依据。 其次，一个完整的PRD还应该具备的要素有 1、文档的命名和编号 文档的编号和命名很关键，每个产品都是经过若干个迭代才完成的，而每个迭代所完成的产品功能或者升级的需求都可能是不一样的，因此需要定义清楚该文 件属于产品的哪个迭代，修改了几个版本。文件命名的方法一般是通过版本号定义，比如简单的方法是，XX产品V1.0PRD_V2,前面的V1.0是产品迭 代的编号，后面的V2 PRD的版本号。稍微详细点可以定义成，XX产品XXXX需求PRD_V2,即对本次迭代的需求任务做命名，这样更便于阅读和记忆。 2、文档的版本历史 包括，编号、文档版本、章节、修改原因、日期、修改人。编号只是为了记录修改的顺序，文档版本显示的当前修改的内容属于文档的第几个版本（或第几次 修改，一次修改一般为一个版本），章节是具体到修改内容属于的功能模块，以便阅读人及时找到修改后的内容，修改原因说明为什么要修改该需求，让阅读者直观 的了解原因。日期是指需求文档修改的时间，修改人是指需求内容的修改者。 3、目录 不需要自己新建，文档完成后直接更新模版中的目录即可。目录是用来了解文档结构的 4、引言 这部分的内容有：产品概述及目标、产品roadmap、预期读者、成功的定义标准和判断、参考资料、名词说明 产品概述：解释说明该产品研发的背景以及核心功能。 产品roadmap：为产品规划的蓝图，每个关键阶段完成的核心任务。产品研发是个不断迭代的过程，需要经过若干个版本的迭代，，对一个功能点做了 N个迭代后最终又回归到了第一个迭代是很常见。产品经理需要做好心理准备。产品roadmap并不需要全部规划好所有的阶段目标，但是对产品未来发展趋势 的一种预估，要达到目标，需要更多的更新和迭代。清晰的呈现产品的roadmap可以帮助产品经理把握产品的全貌，更好的控制研发过程。 预期读者：文档的使用对象 成功的定义和判断标准：旨在说明产品的目标 参考资料：PRD的参考资料 名词说明：名称、说明。名称就是对文档中会出现的比较新的名称，说明则是对这些名称进行解释。 5、需求概述 需求概述通常包括需求概览、用户类与特征、运行环境、设计和实现上的限制、项目计划、产品风险等等 需求概览：分两部分，一是业务流程图，对产品整个业务流程的发生过程做图形化的展示，是对产品整体功能流程的阐释。二是需求清单，对本次要开发的需求任务做分类，给出简明扼要的需求描述并标注优先级。 用户类与特征：产品的最终用户，确定产品的最终使用者，并对使用者的角色和操作行为做出说明。 运行环境：该产品上线后的使用环境，比如支持的浏览器及其版本，操作系统、数据库的要求等等，测试人员在看到环境要求后会在测试时重点测试，而最终上线产品时需要把最佳的运营环境告知给用户。 设计和实现上的限制：比如控件的开发环境、接口的调用方式等等 项目计划：对于prd中要开发的内容，给出关键里程碑，比如需求评审通过的时间、开发的完成时间、上线时间等等 产品风险：描述产品可能存在的风险，比如性能瓶颈，没有解决的问题，用户不当使用的风险等等。 6.功能需求 功能需求一般是由功能详情和主流程说明两大部分。功能详情是所有的产品功能的描述和规划。功能详情包括以下内容： 简要说明：介绍此功能的用途，包括其来源或背景，能够解决哪些问题。 场景描述，产品在