产品PRD自查清单以及需求评审

编辑导语：完成一份产品PRD需求不难，但是需求产出后的各项设计细节也非常容易被遗漏，因此准备一份产品PRD自查清单就显得很重要，它能够确保你更加有效地完成整个过程。

一、产品PRD自查清单

即：针对产品经理写的需求方案PRD文档进行各项指标检查的检查清单。

对产品经理来说：

• 需求的产出不难，但是需求产出后的设计细节容易有遗漏（包含各方面）；
• 很多PM产出需求后自己不**进行严格审查，在一些综合原因情况下，很多需求都是急急忙忙的产出，然后快速评审推进开发测试落地，后续**发现或多或少的细节漏洞或者明显缺陷；
• 在需求到测试用例、UX设计、技术方案、开发落地时，回头一看或者被人戳住需求漏洞，猛然醒悟，噢，这里漏了，稍等，我补一下，然后修改原型、PRD、沟通项目经理、研发、测试，大一点缺陷甚至有推翻部分设计的可能或者想办法牺牲一下方案的完美度来弥补。

需求的自查、有效有用的自查，是一个非常有效也有用的方法之一，也是成本最低的方法之一，能避免PRD文档出现低级错误或者明显的遗漏，导致后续时间成本、沟通成本、人力成本的增涨。

针对具体需求的背景介绍、表单、业务、场景、数据、交互、发布初始化、测试、报表/图表 每一项细节都需要进行一一排查是否有遗漏，而每次检查不是临时想到要检查哪些内容，需要针对需求自查清单梳理出一个标准检查表，根据标准检查表逐步排查。

当然不同的行业、项目、产品细化成需求后，检查项都**有比较大差异，需要针对产品、行业或者项目针对性的列出自己的标准，而后逐步迭代完善。

提供一个RPD需求自查清单模板，仅供参考。

二、需求评审

产品的需求通常都要经历好几轮评审，这是非常重要的过程，可以帮助产品经理将需求梳理的更清晰、更合理、更完善。

需求评审通常包含4轮：

1. 需求版本迭代规划评审

需求迭代版本规划完成后需要进行一次评审，确定产品需求的版本以及上线时间，且每个版本的需求优先级。评审的时候需要对每个版本的需求情况进行简述，说明需求背景、重要程度、解决问题、需求优先级等，然后确定这个需求做不做、放入哪个版本做。

2. 产品需求方案PRD内审

确定需求版本规划后，产品经理要开始产出需求方案PRD文档，完成后要进行需求方案PRD内审，内审即产品团队内部评审，需求负责人将需求方案PRD文档详细讲解一遍，然后评审人员提问以及相关讨论。

主要评审人为团队负责人还有产品相关同事，对需求的重要性、合理性、完整性、整体性以及细节交互进行评审。

需求评审时，如果需求问题不大，只是一些小细节调整，那么**后调整完即可，如果需求有些漏洞或逻辑、流程问题等，则需求**被认定为评审不通过，下次还要继续进行需求内审。

3. 产品需求方案PRD技术评审

通过需求内审后，需求方案PRD要和技术经理或技术负责人进行评审讨论，确定从技术的角度考虑需求时，技实现起来没什么问题。

有时候技术**希望换一种实现方式，因为涉及到很多技术方案、框架等问题，这时产品经理要和技术经理达成共识。

有些复杂需求或者偏技术性需求在需求方案在设计时，就需要先和技术经理私下讨论，确定方向上实现上是没有问题的，否则在技术评审时，技术负责人说这个需求方案实现不了，那就很尴尬了。

4. 产品需求方案PRD公审评审

需求公审是在技术评审后，需求评审人员比较多（产品经理、项目经理、 技术经理、开发人员、测试经理、测试人员、UX、UI），产品经理要提前发起需求公审**议，并发需求方案PRD发出来。

技术经理、测试经理要提前分配每个需求对应的开发负责人以及测试负责人，所有评审人员需要提前查看方案进行预审，如果有问题要准备好问题，以便需求评审能高效快速且有质量的完成。

需求评审的注意事项：

• 注意控制好每次的评审时间，要控制好**议的节奏。
• 评审**议要提前发出来，需求评审前要对需求提前预审。
• 产品经理要进行需求自查。
• 需求评审的人员要安排好，特别是公审时，具体开发人员不用每个需求都全部参加，通常是参加自己负责得部分即可。
• 每次需求的评审记录要记录清楚，主要是需求评审后的待办事项以及问题。

版本需求迭代评审表：

下面举例列出一个需求版本迭代评审表，用于某个版本的需求评审时，对版本所有需求以及需求状态的统一管理，仅供参考，可以根据公司情况进行调整。

本文由 @瞬移的蚂蚁 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议