IPD流程图通常按概念、计划、开发、验证、发布、生命周期管理六个阶段展开，并在阶段交界处设置概念决策评审、计划决策评审、可获得性决策评审和生命周期决策评审等关键决策点。图中需要表达阶段、决策评审点、跨职能角色与阶段交付物四类要素，操作级任务细节留在下层流程图。本文说明各阶段的起止含义、评审点的判断内容，以及流程图应画到哪一层。
要点总览（TL;DR）
- IPD流程图通常按概念、计划、开发、验证、发布、生命周期管理六个阶段展开，阶段交界处设置概念决策评审、计划决策评审、可获得性决策评审和生命周期决策评审。
- 图中应同时表达阶段、决策评审点、跨职能角色和阶段交付物四类要素，缺一容易退化为时间轴或任务清单。
- 决策评审点关注商业价值、资源投入与风险放行，技术评审关注方案成熟度，两者在图中分开标注，技术评审结论作为决策评审的输入。
- 流程图止于管理决策与阶段交接层，需求分析、测试执行、项目排期等操作级内容放到下层流程或项目计划。
- 流程图落地后，可把阶段配置为项目阶段或里程碑、评审点配置为关键节点工作项，让评审材料与决策结论形成可追溯记录。
IPD流程图的核心要素与阶段划分
IPD流程图是对产品从概念形成到退出市场这一全过程的管理性表达。它回答三个问题：工作按什么区间推进、在哪些节点做投资与放行判断、由谁在节点上提交和确认什么。阶段划分的依据是决策评审点——两个相邻决策评审点之间的工作区间构成一个阶段，评审点本身就是阶段交界。
典型的六个阶段及起止含义如下：
| 阶段 | 起点 | 终点 | 阶段工作的核心任务 |
|---|---|---|---|
| 概念阶段 | 产品机会或需求进入评估 | 概念决策评审 | 描述产品概念，评估需求完整性、技术可行性与商业价值 |
| 计划阶段 | 概念决策通过 | 计划决策评审 | 明确实现路径，输出总体技术方案与详细开发计划 |
| 开发阶段 | 计划决策通过 | 开发完成、转入验证 | 各专业领域协同研发，完成从设计到实物的转化 |
| 验证阶段 | 开发成果具备验证条件 | 可获得性决策评审 | 系统化测试与验证，确认功能、性能与质量标准符合性 |
| 发布阶段 | 可获得性决策通过 | 产品正式上市并稳定运行 | 完成上市准备、渠道与交付就绪 |
| 生命周期管理阶段 | 产品上市 | 产品退出或生命周期决策 | 持续经营产品，处理变更、优化与退市 |
流程图需要承载四类要素：阶段（横向或纵向的工作区间）、决策评审点（阶段交界的判断节点）、跨职能角色（泳道）、阶段交付物（各阶段输出并与评审点关联）。四类要素缺一，图就会退化为时间轴或任务清单。阶段名称与数量在不同企业存在差异，有的组织将开发与验证合并，有的单列生命周期管理，落地时应以企业自身流程定义为准。
关键决策评审点及其判断内容
决策评审点（Decision Check Point，DCP）是阶段交界处由管理层或投资决策团队做出的放行判断，关注商业价值、资源投入与风险，而非技术方案本身是否成熟。四个典型评审点的位置与判断内容如下：
| 决策评审点 | 位置 | 主要判断内容 | 典型结论 |
|---|---|---|---|
| 概念决策评审（CDCP） | 概念阶段末 | 产品概念与市场需求的匹配度、需求覆盖范围、技术可行性、商业价值 | 进入计划阶段，或终止项目 |
| 计划决策评审（PDCP） | 计划阶段末 | 总体技术方案与详细开发计划是否可行，资源投入是否有正式依据 | 批准基线版本的业务计划，进入开发 |
| 可获得性决策评审（ADCP） | 验证阶段末 | 市场准入条件、生产成熟度、合规性，产品是否具备商业化发布资格 | 允许发布，或限期整改后再评 |
| 生命周期决策评审（LDCP） | 生命周期管理阶段关键节点 | 产品经营表现、延续、重大变更或退市的必要性 | 继续经营、调整策略或启动退市 |
决策评审点与阶段评审、技术评审需要区分。技术评审（如TR2至TR6）由技术专家对方案与设计成熟度做专业确认，输出技术结论；阶段评审检查本阶段工作是否按计划完成；决策评审点则由决策团队基于前两者结果做投资与放行判断。三者可以相邻发生，但在图中应分开标注，避免把技术评审的通过直接等同于阶段放行。
决策评审点的输入材料通常包括阶段交付物、技术评审结论、风险与资源评估、业务计划或市场评估。决策结论一般分为通过、有条件通过、退回补充和终止四类；有条件通过需明确整改项、责任人与复评时间，否则评审点会失去约束力。
跨职能角色与阶段交付物在图中如何表达
跨职能团队是IPD流程的执行主体，通常包括市场、产品管理、研发、采购、制造、质量、服务、财务等角色。在流程图中，最清晰的表达方式是泳道：每个角色或职能团队占一条横向泳道，阶段作为纵向区间，角色在对应阶段内的活动用方块标注，跨泳道的连线表示交接与协同。决策评审点横跨所有泳道，表示由决策团队统一判断，而非某一职能单独决定。
阶段交付物与决策评审点应成对出现。概念阶段对应产品包需求与概念评估材料，计划阶段对应总体技术方案、详细开发计划与业务计划书，开发阶段对应原型与测试样机验证记录，验证阶段对应测试报告与技术定型结论，发布阶段对应上市与交付就绪材料，生命周期阶段对应经营与变更记录。图中可在每个决策评审点旁标注“输入交付物”，使读者一眼看出评审依据什么材料做判断。
画法上有三点建议：一是泳道数量控制在主要职能层面，过细会淹没阶段主线；二是交付物用统一图形标注并编号，与评审点建立对应关系；三是角色活动只写到“完成某类交付物”的颗粒度，具体任务分解放到下层流程。这样图既能用于管理层沟通，也能作为下层流程的索引。
流程图应止于哪一层：与操作级流程的边界
IPD流程图的职责是表达管理决策与阶段交接，它回答“在哪个节点、由谁、依据什么材料、做出什么放行判断”，不铺开操作级任务。需求如何分析、测试用例如何设计、项目如何排期与分配资源，属于对应业务主题的下层流程或项目计划，画进总图会让阶段主线失焦。
常见的误解有三类。第一，把流程图当成任务清单，在每个阶段下列出几十项具体活动，结果图变成工作分解结构，评审点反而被淹没。第二，把流程图当成排期表，标注具体日期与工期，一旦计划调整图就失效；流程图应表达顺序与判断关系，时间信息放在项目计划中。第三，把技术评审与决策评审混为一谈，用技术评审节点代替阶段放行，导致投资决策缺少独立关口。
判断颗粒度是否合适的简单标准：如果某个方框的内容需要跨职能团队开会讨论才能确定由谁负责，它更适合放在下层流程；如果某个节点需要管理层做投入或终止的决定，它应当出现在总图上。
一个简化的IPD流程图示例
以下为演示情景，用于说明要素组合方式，不代表任何企业的实际流程。某制造企业计划开发一款新型智能终端，其IPD流程图可这样组织：
- 泳道设为市场、产品管理、研发、制造与质量、财务五条。
- 概念阶段：市场泳道提交机会评估，产品管理泳道组织需求与概念描述，财务泳道给出投入初算；阶段末设概念决策评审，输入为产品包需求与概念评估材料，结论为进入计划或终止。
- 计划阶段：研发泳道输出总体技术方案，产品管理泳道牵头详细开发计划与业务计划书，技术评审确认方案可行性；阶段末设计划决策评审，批准基线业务计划后进入开发。
- 开发阶段：研发、制造与质量泳道并行推进原型与试产准备，技术评审验证原型与样机；本阶段不设投资决策点，阶段完成以开发成果具备验证条件为标志。
- 验证阶段：质量泳道组织系统化测试，研发泳道闭环修复缺陷，技术评审完成技术定型；阶段末设可获得性决策评审，判断市场准入、生产成熟度与合规性，决定是否允许发布。
- 发布与生命周期阶段：市场与制造泳道完成上市与交付准备；产品上市后进入生命周期管理，在关键经营节点设生命周期决策评审，判断延续、调整或退市。
这个示例可迁移的规律是：阶段数量可以按企业实际合并或拆分，但每个阶段都应有明确的起止标志；决策评审点只放在需要投资与放行判断的位置，技术评审作为其输入而非替代；角色泳道与交付物标注共同构成图的骨架。示例的适用边界在于它描述的是管理框架，具体活动内容、评审材料清单与角色分工需按企业产品类型和组织结构另行定义。
用协作工具承载流程图与评审流转
流程图确定后，真正的管理难点在于阶段推进是否可跟踪、评审材料是否齐全、决策结论是否留痕。以概念阶段为例：产品管理角色提交产品包需求与概念评估材料，市场与财务角色补充输入，阶段负责人发起概念决策评审；评审通过后，项目状态从概念阶段流转到计划阶段，未通过则记录终止原因并归档。这条链路中的每个动作都需要有对应的承载对象。
ONES可围绕项目计划、阶段推进、任务协同和研发过程管理支持IPD项目管理，团队可在同一平台协同管理项目事项、过程信息和关键节点。具体落地时，可将六个阶段配置为项目阶段或里程碑状态，将四个决策评审点配置为关键节点工作项，把评审材料作为交付物关联到对应节点，决策结论与整改项记录在节点下并指派责任人。这样阶段状态、评审输入与结论形成一条可追溯的记录，跨职能角色在交接时能直接看到上一节点的判断依据。ONES IPD解决方案按概念、计划、开发、验证、发布五个阶段组织研发过程，生命周期管理阶段与生命周期决策评审的承载方式需结合企业实际配置确定。
常见问题
IPD流程图中的决策评审点和技术评审是什么关系，能不能只画技术评审？
两者判断的对象不同。技术评审由技术专家确认方案与设计的成熟度，输出技术结论；决策评审点由管理层或投资决策团队基于技术评审结论、阶段交付物和业务评估，做出投入、放行或终止的判断。只画技术评审，投资决策就缺少独立关口，阶段放行容易被技术通过直接替代。建议在图中把技术评审标在阶段内部，把决策评审点标在阶段交界，并用连线表示前者是后者的输入。
企业阶段数量和本文的六个阶段不一致，流程图还能用吗？
可以。阶段划分的依据是决策评审点，两个相邻评审点之间的工作区间构成一个阶段，因此阶段数量会随企业设置的评审点变化。有的组织把开发与验证合并，有的单列生命周期管理，只要每个阶段有明确起止标志、每个需要投资与放行判断的位置设有决策评审点，图的结构就成立。落地时应以企业自身的流程定义为准，并保持阶段名称与评审点名称在组织内一致。
决策评审“有条件通过”时，流程图和后续管理要注意什么？
有条件通过意味着放行附带整改条件，需要在评审记录中写明整改项、责任人和复评时间，否则评审点会失去约束力。在流程图上，可以在该决策评审点旁标注复评节点或整改回路，表示阶段推进与整改并行。后续跟踪时，把整改项作为独立工作项关联到该评审节点，复评完成后再更新阶段状态，避免条件被遗忘而直接进入下一阶段。
流程图里角色泳道画多细比较合适？
泳道数量控制在主要职能层面，例如市场、产品管理、研发、制造与质量、财务，过细会淹没阶段主线。角色活动只写到“完成某类交付物”的颗粒度，具体任务分解放到下层流程。一个可操作的判断标准是：如果某个方框需要跨职能团队开会才能确定由谁负责，它更适合放在下层流程；如果某个节点需要管理层做投入或终止决定，它应当出现在总图上。
流程图确定后，怎么让阶段推进和评审结论真正可跟踪？
关键是把图中的要素转成可管理的对象：阶段配置为项目阶段或里程碑状态，决策评审点配置为关键节点工作项，评审材料作为交付物关联到对应节点，决策结论与整改项记录在节点下并指派责任人。ONES 可围绕项目计划、阶段推进、任务协同和研发过程管理支持 IPD 项目管理，团队可在同一平台协同管理项目事项、过程信息和关键节点。这样阶段状态、评审输入与结论形成一条可追溯的记录，跨职能角色交接时能直接看到上一节点的判断依据。
