自动驾驶产品需求文档(PRD)的评审与验收

作者 | 陈龙

荐 言：

今天推荐Vehicle公众号主理人陈龙老师的新书《自动驾驶产品经理》，这是一本基于大量案例分析和实战经验，构建起系统且全面的知识框架。本书通过自动驾驶基础与产品核心、产品研发与交付流程、产品运营与商业化、未来展望与行业趋势和产品经理的成长路径五个分，细讲解了自动驾驶产品“从0到1”和“从1到N”的全生命周期概念与知识，以及自动驾驶产品经理的职业要求和发展路径。特别推荐给大家！

本文节选自书籍第4章“产品需求文档（PRD）的撰写与管理”。更多内容可以点击下方链接了解。

正 文：

撰写PRD只是第一步，真正的挑战在于通过评审让所有相关方达成共识，比如领导的资源支持，同事的配合开发推进。PRD评审是一个多方“讨价还价”的过程（图4-2），考验着产品经理的沟通、协调和权衡能力。

图4-2 PRD评审流程

1）内部预评审：在正式大范围评审前，先与核心研发工程师、测试负责人进行小范围预评审。通过预评审能提前发现大量技术可行性问题、理解偏差，避免在正式评审中浪费时间。

2）明确评审目标：告知所有参与者本次评审的目的（如确认需求范围、技术方案可行性、风险评估）。

3）准备充分的材料：除了PRD本身，可能还需要原型图、流程图，甚至简单的演示视频。

4）邀请关键利益相关者：

① 研发团队：可能包括感知、定位、预测、规划、控制、HMI、数据、测试等模块的负责人及核心工程师，具体视组织架构而定。

② 设计团队：UI/UX设计师。

③ 测试团队：质量保证（QA）负责人。

④ 运营团队：负责产品上线后运营和用户反馈的团队。

⑤ 安全团队：对于自动驾驶领域，安全团队的参与至关重要。

⑥ 法规合规团队：确保功能符合法律法规要求。

评审的过程就像一个正式的“讨价还价”的过程，会包括对技术和资源等方面的探讨（图4-3），一般需要注意和考虑以下方面。

图4-3 自动驾驶PRD评审过程

1）倾听与理解：积极倾听不同团队的反馈和质疑，理解他们关注的点，辨析是技术实现有难度或测试覆盖不足，还是存在安全风险或用户体验不佳。

2）权衡与取舍：

① 功能取舍：面对研发资源有限或技术难度过高的情况，产品经理需要决定哪些功能是核心的、必需的，而哪些功能是次要的、可以延期或放弃的。这通常涉及莫斯科法则（MoSCoW laws），也就是优先级排序法则，分为必须有（Must-have）、应该有（Should-have）、可以有（Could-have）和不会有（Won't-have）四级。

② 优先级调整：根据投入产出比、用户价值和商业价值，调整功能的优先级。

③ 技术方案妥协：某些功能可能有多种技术实现方案，产品经理需要与研发团队共同评估，选择在安全性、性能、成本和时间上达到最佳平衡的方案。例如，在某个特定场景下，纯视觉方案可能难以满足需求，需要考虑是否增加毫米波雷达或激光雷达。

④ 排期调整：需求的复杂性和技术难度会直接影响开发周期。产品经理需要与研发团队协商，合理评估开发时间，并在必要时与业务方沟通调整上线时间。

3）聚焦核心问题：在评审中很容易出现讨论话题跑偏的情况。产品经理需要扮演“主持人”的角色，引导团队成员聚焦于PRD核心问题，避免陷入不必要的细节争论。

4）记录与决议：详细记录评审中提出的所有问题、建议、争论点和最终达成的决议，包括谁负责什么、完成时间等。未解决的问题应明确后续如何跟进。

5）产品范围（Scope）：明确哪些功能或场景在当前版本中不予支持，避免范围蔓延（Scope Creep）。这在自动驾驶领域尤为重要，因为它的场景复杂度高，需要严格限定功能边界，例如明确“城市NGP版本不包含掉头”。

评审过后会产生新的方向和结论，这时需要考虑和完成以下事项。

1）更新PRD：根据评审决议及时更新PRD，并发布最新版本。

2）邮件或会议纪要周知：将评审结果和最新版本PRD告知所有相关方，确保信息同步。

3）持续沟通：PRD不是一成不变的。在研发过程中，可能会出现新的问题或发现新的解决方案。产品经理需要与研发团队持续沟通，及时更新和调整PRD。

4）形成共识：评审的最终目的是达成共识，让所有团队成员对要做的产品、如何做，以及目标是什么有一致的理解。

通过PRD评审后，产品定义和交付就有了详细且可执行的路线图。而在产品交付后，还要做好验收和可能的需求变更工作。

需求验收是确保最终产品符合PRD定义和用户期望的关键环节。在自动驾驶领域，这需要结合传统的软件测试和复杂的实车测试。

验收标准是判断功能是否“完成”和“合格”的条件。它们应该是具体的、可测量的、明确的。首先，在PRD中需要有明确的验收标准，这应当在PRD中与需求点同步定义，以便研发和测试团队在开发阶段就明确目标。

此外，还有很多与场景结合的主客观验收（图4-4），这时必须描述功能在场景下是否满足、性能如何以及主观感觉如何。

图4-4 场景结合的主客观验收

示例：

① 高速NGP百公里接管次数≤5次（这是一个高层面的指标）。

② 车辆在自动泊车过程中，与两侧障碍物最小距离≥10cm（这是一个安全性细节）。

③ 用户通过App发起遥控泊车指令后，车辆在3s内开始响应（这是一个体验细节）。

④ 在指定测试路段上，城市NGP的通行时间与人工驾驶模式的通行时间差异在±10%以内（这是效率和舒适性指标）。

⑤ 系统在发生传感器故障时，能自动安全降级到L0状态，并及时向驾驶人发出警告，且不影响车辆基本驾驶功能（这涉及安全性和故障降级）。

产品的总需求明确后，各个系统会基于需求分解形成产品设计文档。在产品设计文档里会对各个零部件和其他系统专业的需求进行拆分，也就是对产品需求进行分解。落地到零部件设计后，就会开展如图4-5所示的验收测试流程。

图4-5 自动驾驶验收流程

1）冒烟测试（Smoke Test）：在开发完成后，由测试团队进行初步的功能验证，确保基本流程无误，可以进行后续的详细测试。

2）功能测试（Functional Test）：严格按照PRD中定义的功能和场景进行测试，确保每个功能点都符合预期。 

① 单元测试（Unit Test）：工程师对代码的最小单元进行测试。

② 集成测试（Integration Test）：将不同模块组合在一起进行测试。

③ 系统测试（System Test）：对整个系统进行端到端测试。

3）系统性能测试（Performance Test）：针对PRD中定义的性能指标进行测试，如响应时间、系统稳定性、资源占用等。

4）安全测试（Safety Test）：针对自动驾驶系统特有的安全要求进行测试，包括故障注入测试、异常场景测试、入侵测试等。

5）硬件在环/软件在环（HIL/SIL）测试：在仿真环境中进行大量测试，模拟各种极端和危险场景，以验证系统在虚拟环境下的安全性。

在上述测试中，产品经理主要配合项目管理关注和走查，监控产品设计走势，确保DRE或设计团队执行和完成。以下是产品经理主要验收的工作节点。

1）场测（Track Test）：在封闭测试场地进行实车测试，验证系统在真实物理环境中的表现，包括各种极限工况、危险场景复现等。

2）路测（Road Test/Public Road Test）：在开放道路进行大规模实车测试，收集真实交通数据，发现“长尾效应”问题，不断完善系统。

3）产品经理验收（PM Acceptance）：在测试团队确认通过后，产品经理需要亲自或组织核心团队进行最终验收。

① 回归需求：确认所有需求点都已实现。

② 体验评估：站在用户角度，评估功能的整体体验、流畅度、舒适度。

③ Bug优先级：与研发和测试团队共同评估发现的Bug的优先级和修复计划。

4）用户验收测试（User Acceptance Testing，UAT）/小范围灰度测试：在正式发布前，邀请一小部分真实用户进行测试，收集真实使用反馈，这是发现产品与用户期望之间差异的有效方式。后文会讲解从内测到公测的种子团、千人团等机制。自动驾驶产品与运营团队在这一验收流程中会更关注最终用户使用时的整体体验。

在验收过程中发现的Bug需要被记录、分类和管理。

1）优先级分类：通常分为P0（紧急，阻断性问题）、P1（高，严重影响功能使用）、P2（中，影响体验但不阻断）、P3（低，不影响功能，可优化）四级。

2）自动驾驶领域的特殊性：任何与安全相关的Bug都必须被视为最高优先级（P0）并立即修复。即使是看起来很小的体验问题，如果可能导致用户不信任系统而发生危险接管，也必须给予足够重视。

3）Bug修复与回归测试：Bug修复后需要进行回归测试，确保修复没有引入新问题。

PRD撰写和管理是自动驾驶产品生命周期中的基础，其重要性不言而喻。一份清晰、准确、全面的PRD，配合严谨的评审和验收流程，是确保自动驾驶产品安全、高质量交付的基石。