继续讲解IPD流程体系中的三级流程：验证阶段。
这个阶段的核心使命就是为了确保我们：
不仅“做了”，而且“做对了”。
直指开发成果是否符合预期、是否具备上市条件。
验证阶段是从“设计冻结”到“量产就绪”的桥梁：
紧跟在开发阶段（实现与初始测试）之后，是产品正式量产（GA）前的最后一道质量与风险管控关口。
其输出决定了产品能否成功进入市场发布和批量生产阶段。
这个阶段要求从三个维度做全方位审视：
一是客户视角：确保需求满足度；
二是业务视角：确保产品规格达成、量产可行性；
三是质量视角：确保功能、性能、一致性。
如果大家做过实际业务或者是开发，就会发现IPD的这套内容，很多都跟自己平常的工作很接近。
那为什么还要学IPD呢？
有一个重要原因是IPD更结构化、体系化，可以让你站在更高的位置来看待开发过程。
如果你不是实际的业务专家，IPD可以帮你规避很多实际问题。
比如，IPD会提醒你在项目前期就要拉通各个部门，拉上采购、拉上财务、拉上市场......，大家坐到一起过项目，过细节。
你做了这件事，后续环节就会更轻松；
不做这件事呢，项目也往往能正常推进，但越晚发现问题，大概率会导致项目延期，更严重的是丢客户。
比如有颗料厂家反馈3个月后就不生产了，供应链一看，现有产品也没怎么用就忽略了，但是研发不知道，就选了这颗料，等到生产的时候才发现就太晚了。
关键活动
验证阶段的主要活动：SVT、Beta测试、认证和标杆测试、TR6技术评审、发
布准备评估和可获得性决策评审等。
验证阶段也会涉及到一些必要的设计更改。
比如在验证活动中发现设计缺陷、性能不足、需求理解偏差、可制造性问题或可测试性问题等。
验证是一个“试金石”的过程，可以暴露前期设计或实现中的一些盲点。
当然了，更改也是要严格遵循一些原则要求：
一是必要性：
只针对影响产品核心功能、关键性能指标、安全性、法规符合性、量产可行性或重大客户体验的问题进行更改。
二是严格管控：
所有更改必须经过严格的工程变更请求/工程变更通知流程（ECR/ECN），评估影响范围（BOM、成本、进度、文档、库存等），并获得批准。
三是回归验证：
任何设计更改后，必须进行充分的回归测试，确保更改解决了问题，且没有引入新的缺陷。
核心关注点
一是要确保产品在市场上成功：
审视市场及客户需求，并关注变化情况，因为所有的验证活动本质上都是在回溯验证产品是否满足了从概念、计划阶段就定义并层层分解下来的需求；
审视产品及财务假设，并关注变化情况；
审视发布计划及销售使能器状态。
二是确保产品功能满足要求：
形成最终的产品规格；
修改设计，以满足规格要求。
三是确保制造准备就绪：
这个环节不仅仅是检查生产线是否搭建完毕。
它是一个全面的供应链和制造体系能力评估，确保整个系统已准备好高效、稳定、经济地持续生产出符合质量标准的产品。
比如：
确定最终的工艺文档；
确认是否已验证供应商；
验证制造工艺。
四是证实开发阶段的假设。
交付
修正的产品规格；
制造能力及产能计划；
生产构件的制造文档；
合格的产品及最终的产品发布计划。
需要说明的是，这一系列对IPD流程的拆解属于通用内容，主要目的是供大家辅助参阅和理解，落地跟业务实际相关。
比如之前根据电子硬件产品特点做过一期RPM-IPD的方案，涉及的表单也是跟电子硬件强相关的，其他领域就用不了。
如果是做纯软件类的产品，就是另一套东西了，差异巨大。
相关系列内容连载：
IPD流程落地：项目任务书Charter开发
IPD流程实战：产品开发概念阶段解读
IPD流程落地：产品计划阶段拆解
IPD流程实战：产品开发阶段拆解
IPD流程实战：TR技术评审点
IPD流程落地：产品规划目标、输入及输出
IPD 导入：PDP产品开发流程
卫朋
《硬件产品经理》作者，实战派产品及流程专家，人人都是产品经理受邀专栏作家，CSDN认证博客专家、嵌入式领域优质创作者，阿里云开发者社区专家博主。
下一篇：没有了