如何写好产品需求文档（PRD）

作为产品经理的必备技能，写PRD是基本功之一。但就是这么基础的要求，还是有部分产品经理不知道怎么写，或者刚入门还不会写。这篇文章，作者给我们详细说明了PRD的要求和写法，希望可以帮到大家。

在做一个设计任务时，需要收集现有情况、历史原因、设计阻碍点等信息，输出当前任务的设计文档，当前文档又可作为后续优化设计的方向和参考依据。

产品需求文档是产品工作流程中各个环节对需求描述和传达最快速的工具，减少沟通成本：每一个环节和任务协作人都需要理解需求的定义和描述，通过文档对需求的传达，能减少产品经理在各环节与各方的沟通交流。产品需求文档保证各部门沟通有理有据，还可以为产品质量控制做好保障：当产品设计研发过程中不断偏离需求时，此时需求文档作为一份需求评审时已统一目标的文档，有利于团队回归到产品设计的正轨上，保障产品按照目标顺利完成上线。产品需求文档有利于产品迭代管理中回溯：此前需求的设计及规划产品迭代管理中，我们可以回溯上一版需求文档中的迭代计划的背景及需求的目标，结合当前的效果及不足，做出新的迭代的规划。产品需求文档有助于新成员快速熟悉项目：对于组内新的产品经理来说，了解过往的产品需求文档可以更好地了解产品的内在逻辑和外在表现。

一般情况下，任务纳入迭代计划后，协作流程中第一个设计环节是产品设计，即输出需求文档。任务迭代过程中，协作人员需要阅览需求文档，依据需求文档做设计和开发，其使用场景如下：

要想写出好的需求文档，那我们首先要明白什么样的文档才算是一个好的需求文档。在我看来，一份好的需求文档至少要讲清楚以下几个问题：

方案是否合理：选择的方案是否为解决当前问题的最优解。功能规则设计是否详尽：功能改动点和业务规则描述是否合理且详尽，是否已存在逻辑漏洞。设计是否具有拓展性：对后续迭代和拓展是否提供了良好的基础。

第一点实际上就是要求我们去设计对的需求。第二个点是要求对我们所定义的需求，不仅要描述主流程还要将与该流程相配合的相关其他模块都描述清楚。第三点是在前两者的基础上进行一个升级，也就是当我们能正确的完整的描述一个需求之后接下来希望你所描述的需求能是最优方案，也就是能给用户带来更好的用户体验的一种方案。

需求是当前背景下的需求。这里的背景，需要写明白的内容可包括但不限于当前产品所处行业的现状，产品/功能模块所处的状态、目标，开发团队的资源限制、技术限制等。在作为用户体验其他竞品的一些功能时，不免吐槽，这里怎能这样做？应该那样做啊。对于自己所做的产品同样如此，应当明白，任何一个需求都受限于当时的背景状况、资源限制，抛开这些背景谈实现都是扯淡，产品经理要做的是在当前背景下，找到最佳的实现方案。因此，梳理需求背景是产品经理对当前资源现状的考量，是实现需求的第一步。

通过对历史原因和历史设计方案的梳理，可以让自己对当前任务的阻碍点更加明确，甚至可以为自己的解决方案提供新思路。简道云内，虽然各模块任务都是分开设计，但不同任务之间可能有关联关系，在需求背景梳理中，这些都可以明确。

来源于用户的需求才是最真实的需求，有些功能点无法满足用户需求，但是只有在具体业务场景下才能体现，通过对用户场景的分析，挖掘出当前要解决的问题以及后续衍生出的问题。

用户回访是其中一个重要环节，很多用户需求，都有替代方案可以解决问题，但是用户不愿意采用替代方案，内在原因需要深究。需求库里的需求是经过几次转手和加工的，可能会存在偏差和信息不对等，通过用户回访可以与用户直接沟通，消除信息误差。

竞品分析可分为两部分：

直接竞品分析：

直接竞品是否存在该问题是否解决了该问题。若没解决，原因是什么。若解决了，是用何种方式解决的竞品的解决方案是最优方案吗，是否存在更好的方案

非标竞品分析：

非标竞品中是否存在相似场景，该场景提供的适用范围有哪些交叉点成熟的非标竞品，一般具有更成熟的解决方案，当前解决方案是否适用于简道云产品中

方案是背景下需求的实现方案。既然需求会受到资源现状的限制，那么方案也必然有所不同，甚至可能会有折中妥协，会有不完整的方案。有时需求本身就是试验性质的，是为了快速测试效果，那么在方案上选择一些实现简单、开发难度较小的方案也就不足为奇了。

在写方案时，可以按照「用户-场景-问题-方案」这个框架简要写明实现方案，也就是什么样的用户在什么样的场景下遇到了什么问题，提供的解决方案是什么——这里要求方案要经过提炼，能够通过一句话说清楚。

价值是指实现这个需求能够带来什么样的价值，包括用户价值和业务价值，用户价值是指实现这个需求能够给用户带来什么样的价值，例如提升用户的使用体验等；业务价值是指实现这个需求能给产品的业务带来什么样的价值，例如提升用户留存或者提升业务收入等。

需求不一定要同时提供用户价值和业务价值，也不一定两个价值都需要为正（例如带来很大的业务价值而牺牲很小的用户价值也是可以的），具体需要依据产品当前的状态来考虑，但不能带来价值的需求一定是有问题的。

此外，在思考需求能够产生什么价值时，同时要思考的是以什么数据指标来评估这个价值，也就是需求上线后效果的好与坏要有量化的指标。不一定所有的需求都能够找到量化的效果指标，但一定要尽量找到这个指标。只有需求的效果能够被衡量，产品才能够往更优的方向迭代。

主要是需求实现的部分，详述需求解决方案和功能规则逻辑。业务逻辑部分描述的是需求中涉及到的数据流向和用户流向，特别是需求涉及到多个系统时，数据和用户在系统之间如何交互的。目前针对业务逻辑部分，我主要的输出是多通道的泳道图来描述系统间的交互。这里应该特别注意的是在说明数据流向时要兼顾考虑正常流程和异常流程，以及在说明用户流向时要考虑清楚需求边界。此外，需求的复杂程度不同，可能还会包含页面流程图、页面结构图等。

在需求文档中需要对交互形式和前端校验逻辑等做出简要说明，以此来协助交互和前端更好的理解和实现需求。尤其是对重要的地方进行文字说明，包括字段逻辑、按钮逻辑、页面逻辑等。对一些非逻辑的交互进行说明，例如某些字段、需要突出显示，页面变化时需要怎样的特殊效果等等。

凡是需求，必然要有验证效果的数据，而从每一个失败与成功的需求中不断总结和反思，是产品经理成长的重要途径。实际效果数据是衡量需求输出实现方案的其中一个标准，这既能够促使产品经理自己不断改进产品思路，也能够让参与需求的相关同事了解自己的工作成果。

初期写PRD，容易出现以下问题：

刚开始的PRD可读性较差，没有站在阅读对象的角度思考他们希望在PRD上获取什么信息，对于结果输出和总结内容，没有清晰明显的体现出来。PRD的信息同步有部分缺失，与研发或交互在同频信息时，部分信息没有传达到，在后续设计中需要再次沟通确认。当前任务边界不明显，对于本次需要解决的问题和以后解决的问题，该如何区分，区分依据的阐述不够清楚。

为了解决上述的问题，需要尝试从用户思维、结构化思维、闭环思维来帮助思考和解决问题。

用户思维，顾名思义，就是“站在用户的角度来思考问题”的思维。使得需求落地前期最为关键的一步，是将需求定义及描述清楚。为了让协同的人员理解需求，产品经理需要站在他们的视角，了解他们的工作场景及诉求，输出解决方案。

结构化思维的本质是框架。是从无序到有序的一种思考过程，将搜集到的信息、数据、知识等素材按一定的逻辑进行归总，继而让繁杂的问题简单化；从而让我们的大脑更快速、更有效的处理信息。

产品需求文档应从宏观到微观地进行铺展，因而需要先写总体需求（依据实际情况可附上业务流程、功能列表清单、功能结构图、信息架构图、角色权限等），再写具体需求（详细讲解需求的流程、规则和实现）。使用结构化思维去进行思考和表达时：结论先行，再去展开阐述，先突出重点，能够让对方更加轻松地理解我们想表达的观点。如编写背景及目标时，可先写总的结论，在分点详细阐述,对需要关注的地方进行加粗，避免大段文字的叙述。业务流程图绘制也可采用结构化的思维。在进行流程图的绘制过程中，只有一个流程主线，可使得流程图脉络清晰，业务明了。如果异常流程非常复杂，针对每一个流程节点，如果出现异常流程，可以建立子流程模块，在子流程中标记出异常场景的分支流程；然后把子流程链接到流程概图。

闭环思维是指我们在做一件事情时，要做到有始有终。不是仅仅把事情做了，而是要保证事情做了以后，是能够解决问题，或者有相应的见效或进展的。

依据评审后的讨论结果，不断修正产品需求文档。在需求评审前，产品经理已经输出了第一份产品需求文档。但这个产品需求并非初步方案就能够解决问题，在历经交互、开发评审后，才会最终敲定方案。因此，我们需要不断地修正需求文档并同步给各协同人员。当然，也应该附上相应的修订记录，但由于工具的发展，我们可以依赖工具的变更历史来回顾修订记录，因此不再需要在需求文档上附上修订记录。产品需求文档解决的不仅仅是当前的一个问题，也是规划推动下一个问题的解决。尽管每次迭代的目标细分不一样，但是总体的目标都是把产品做好。因而为了推动这个终极目标的实现，我们需要明确清楚每一次迭代需求的目标，并且规划好下一个迭代的需求，才能不断推动问题解决，得到良性循环。

产品需求文档是任务迭代流程中的重要内容。我们应当把PRD作为推动需求落地上线的指导纲领，提高产研效率的有效工具，将产品思维的思考方式运用到需求文档中。在一次次的需求文档撰写中，需要我不断总结思考，再运用到下一次的实践中，反复思考优化自己的方法论。

本文由 @xxy B端产品设计 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务