设计IPD流程图，主线是四层结构：先划分阶段，再设置决策评审点与技术评审点，然后用泳道安排角色活动，最后为活动挂上交付物与准入准出条件。流程图的服务对象决定画到哪一层——用于评审和培训，画公司级主流程即可；用于系统配置，则要细化到活动和状态。下文按“定边界—搭结构—分角色—看示例—做验收”的顺序展开，适合正在从零设计或重构IPD流程的研发管理团队参考。
要点总览（TL;DR）
- 先确定流程图的服务对象与颗粒度：评审和培训用公司级主流程，系统配置需细化到活动与状态。
- 按五步搭建：划分阶段、设置决策与技术评审点、泳道分配角色、挂交付物与准入准出、补充异常路径。
- 决策评审点（DCP）判断是否继续投入，技术评审点（TR）判断技术方案是否达标，两者在图上分开标注。
- 泳道按角色划分并标注交接传递物，用角色—阶段—交付物对应表检查职责空档与重叠。
- 发布前逐项验收，并用一个在研项目试运行，把高频绕行点作为下一版修订输入。
先定流程边界：IPD流程图要画到哪一层
动笔前先回答一个问题：这张图给谁看、用来做什么。同一套IPD机制，给决策层评审用、给新员工培训用、给审计对照用、给系统配置用，需要的颗粒度完全不同。把四种用途压进一张图，结果往往是高层看不到决策逻辑，执行层找不到自己的动作。
建议先写一份流程边界说明，包含三项内容：主流程的起止点、分层清单、与相邻流程的接口点。
主流程起止点通常从概念或机会点识别开始，到产品发布及发布后评估结束。起止点写清楚，可以避免流程图无限外扩到战略规划或售后运维。
分层清单按使用场景拆分：
| 层级 | 主要内容 | 适用场景 |
|---|---|---|
| 公司级主流程 | 阶段划分、决策评审点、关键交付物、主要角色 | 管理层评审、全员培训、流程审计 |
| 产品线级流程 | 在主线基础上补充产品线特有的评审要求与交付物模板 | 产品线内部执行与考核 |
| 项目级执行流程 | 具体活动、任务状态、审批流转、系统字段 | 工具配置、项目日常执行 |
子流程是否单独成图，判断标准是它是否有独立的评审逻辑和交付物。需求管理、测试验证、变更控制这类子流程，活动多、角色交叉多，单独成图再在主流程上标注接口，比塞进主图更清晰。
接口点要写具体。例如主流程在计划阶段结束时需要一份基线化的业务计划书，这份文件由哪个子流程产出、在哪个评审点被使用，应在边界说明中注明。接口写清楚，后续画泳道时才知道箭头从哪里进、从哪里出。
核心答案与操作步骤：四层结构搭出IPD流程图
四层结构对应五个设计步骤，每步都有明确的输入、动作和输出。按顺序推进，前一步的输出就是后一步的输入。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 划分阶段 | 流程边界说明、产品类型 | 确定阶段名称与顺序，为每个阶段写一句目标 | 阶段清单及阶段目标 | 每个阶段能用一句话说清“本阶段结束时要得到什么” |
| 2. 设置评审点 | 阶段清单、历史评审问题 | 在每个阶段末设置决策评审点，在阶段内设置技术评审点，写明评审内容、评审人、通过标准 | 评审点清单 | 每个评审点都有明确的评审人和“通过/有条件通过/不通过”的判定标准 |
| 3. 泳道分配角色 | 评审点清单、组织角色 | 按角色划分泳道，把活动放入对应泳道，标出跨泳道交接的输入输出 | 泳道活动图 | 每条交接箭头两端都有明确的交付物或信息 |
| 4. 挂交付物与准入准出 | 泳道活动图、模板库 | 为每个活动关联交付物模板，为每个阶段和评审点写明准入条件与准出条件 | 交付物清单与准入准出表 | 任一活动都能查到“交什么、什么标准算完成” |
| 5. 补充异常路径 | 主流程图、历史异常记录 | 画出评审不通过、需求变更、阶段回退的处理路径与责任人 | 含异常分支的完整流程图 | 每种异常都有下一步动作和重新评审的入口 |
阶段划分可以参考概念、计划、开发、验证、发布五个阶段的组织方式，这也是ONES IPD解决方案展示的阶段口径，企业可结合自身产品特点调整名称和数量。阶段目标要写成可判断的结果，例如计划阶段的目标是“明确产品实现路径并完成业务计划基线”，而不是“做好计划工作”。
评审点分两类，在图上用不同符号区分。决策评审点（DCP）回答“是否继续投入资源”，由决策评审组做判断；技术评审点（TR）回答“技术方案是否达标”，由技术专家做判断。两类评审混在一起，容易出现技术问题被当成投资决策、投资问题被当成技术讨论的情况。评审内容、评审人和通过标准三项缺一不可，只写“召开评审会”不构成可执行的评审点。
泳道按角色划分，比按部门划分更容易暴露交接空档。一个活动跨两个部门但由同一角色负责时，按部门画会出现两条泳道之间的无效箭头；按角色画则能直接看出谁在什么时点把什么东西交给谁。
异常路径与主路径同等重要。评审不通过时，是退回上一活动修改还是降级处理，由谁决定；需求变更在哪个阶段可以受理、走什么审批；阶段回退后哪些交付物需要重新基线。这些分支不画出来，流程图在实际执行中就会被绕开。
角色与交付物：谁在哪个节点交什么
泳道画完后，用一张角色—阶段—交付物对应表做交叉检查，确认每个阶段都有角色负责、每项交付物都有明确的责任人和使用方。
| 角色 | 主要参与的阶段 | 关键交付物 | 评审关系 |
|---|---|---|---|
| 产品经理 | 概念、计划、发布 | 产品概念说明、业务计划书、上市方案 | 在决策评审点做汇报 |
| 项目经理 | 计划至发布 | 项目计划、阶段状态报告、风险清单 | 组织评审、跟踪准出条件 |
| 研发 | 计划、开发、验证 | 总体技术方案、详细设计、原型 | 在技术评审点接受评审 |
| 测试 | 开发、验证 | 测试方案、测试报告、缺陷闭环记录 | 在技术评审点提供验证结论 |
| 采购 | 计划、开发 | 供应方案、物料齐套计划 | 参与计划阶段评审 |
| 市场 | 概念、验证、发布 | 市场需求输入、上市准备评估 | 参与决策评审点 |
| 决策评审组 | 各阶段末 | 决策结论与资源承诺 | 主持决策评审点 |
每个决策评审点要区分三种身份：汇报人负责准备材料并陈述，评审人负责提出专业意见，决策人负责给出结论。三种身份由同一人兼任时，评审容易流于形式。技术评审点同理，被评审方案的作者不宜同时担任该评审的主持人。
交付物清单要标注所属阶段、模板位置和使用方。同一份交付物被多个评审点引用时，注明哪一次是基线版本，避免后续评审拿着过期材料做判断。对应表做完后，横向看每个阶段是否都有交付物产出，纵向看每个角色是否都有明确动作，空档和重叠会直接显现出来。
示例：一条产品开发主流程的泳道画法
以下示例为说明画法而设，假设某团队开发一款软硬结合产品，采用五阶段结构，评审点编号沿用常见IPD口径。示例条件仅用于演示，实际设计需按企业自身流程调整。
时间轴从左到右依次为概念、计划、开发、验证、发布五个阶段。阶段之间的竖线是决策评审点，阶段内部的横线位置标注技术评审点。概念阶段结束设概念决策评审，计划阶段内设TR2、TR3，阶段末设计划决策评审（PDCP），开发阶段内设TR4、TR5，验证阶段内设TR6并在阶段末设可获得性决策评审（ADCP），发布阶段结束设生命周期评审入口。
泳道自上而下可设为决策评审组、产品经理、项目经理、研发、测试、市场与采购。以计划阶段为例：产品经理泳道中画“编制业务计划书”，箭头指向决策评审组的“PDCP评审”；研发泳道中画“输出总体技术方案”，先经TR2、TR3评审，评审通过的箭头再汇入PDCP的材料包。这样画，评审组在PDCP上看到的是已经过技术验证的方案，而不是未经检验的初稿。
交接箭头上写清传递物，例如“基线业务计划书”“测试样机及验证报告”，不写“沟通”“同步”这类无法核对的词。跨泳道箭头尽量少交叉，交叉过多说明角色分工或活动顺序需要调整。
异常路径用虚线表示。TR评审不通过时，虚线回到对应设计活动，标注“限期整改后重新评审”；PDCP不通过时，虚线指向“项目暂停或终止”与“退回计划阶段修订”两个分支，并注明由决策评审组判定。需求变更在开发阶段受理时，虚线指向变更控制流程，变更影响技术方案的重走TR4。阶段回退时，在回退箭头上标注需要重新基线的交付物清单。
这个示例可迁移的规律有三条：评审点放在阶段转换处和关键技术节点上；每条泳道内的活动有先后，泳道之间靠交付物连接；异常路径与主路径使用同一套角色和交付物名称。具体阶段数量、评审点编号和角色设置，按产品类型和组织结构替换。
流程图定稿后，需要工具承载阶段状态、评审记录和交付物版本。ONES研发项目管理平台遵循IPD的理念和方法，通过市场管理与需求管理的流程支撑，并支持从需求挖掘、收集、结构化到开发决策、研发落地的全流程管理。在ONES IPD解决方案的阶段口径中，计划阶段的技术评审（TR2&TR3）验证整体技术方案与各子系统设计，阶段决策评审（PDCP）基于评审结果批准基线版本的业务计划书；验证阶段的技术评审（TR6）完成技术定型，ADCP综合评估市场准入、生产成熟度与合规性后判定是否具备发布资格。将这些评审点与交付物在系统中对应起来，流程图上的每个判断就能留下可追溯的记录。
完成检查：流程图是否可执行的验收项
流程图发布前，用以下清单逐项核对。任何一项无法回答，说明该处还停留在示意层面。
- 每个阶段是否有一句可判断的目标，以及明确的结束标志（如某份交付物完成基线）。
- 每个决策评审点是否写明了汇报人、评审人、决策人和通过标准，是否区分了“通过、有条件通过、不通过”三种结论的处理方式。
- 每个技术评审点是否写明了评审对象、评审依据和遗留问题的关闭要求。
- 每个活动是否对应到具体角色，并关联至少一项交付物或状态产出。
- 每条跨泳道交接是否标注了传递物，接收方是否明确。
- 评审不通过、需求变更、阶段回退三类异常路径是否完整，是否标注了责任人和重新评审入口。
- 流程图上的交付物名称是否与模板库、评审记录中的名称一致，能否一一对应查到。
- 是否指定了流程维护责任人，以及更新触发条件，例如组织调整、评审点变更、工具配置变化。
检查通过后，建议先用一个在研项目试运行一轮，观察评审材料是否按图准备、异常路径是否被实际使用。试运行中暴露的断点，比评审会上的讨论更能说明流程图是否可执行。流程发布后，维护责任人应定期收集执行偏差，把高频绕行点作为下一版修订的输入。
常见问题
公司级主流程和项目级执行流程，应该先画哪一个？
建议先画公司级主流程，再向下细化。主流程确定阶段划分、决策评审点和关键交付物，这些是产品线级流程和项目级执行流程的共同骨架；骨架稳定后，产品线补充特有评审要求，项目级再细化到活动、状态和审批流转。反过来先画项目级，容易出现各项目画法不一致、无法汇总到统一流程的问题。
如果企业已有在执行的流程文件，也可以从现状梳理入手，但梳理结果仍需回到主流程层面统一口径。
评审点数量多，流程图会不会过于复杂？
评审点的数量取决于需要卡住的关键判断，而不是越多越严谨。设计时可以问：这个评审点不通过时，项目会改变什么决定？如果答案只是“再改一改文档”，它更适合作为活动内的检查项，而不是独立评审点。
决策评审点通常放在阶段转换处，技术评审点放在关键技术节点上。评审点较多时，可在主流程图上只标决策评审点，技术评审点放到子流程或阶段详图中，保持主图可读。
流程图发布后，团队仍然按习惯执行、绕开评审，怎么处理？
先区分是流程设计问题还是执行习惯问题。检查被绕开的节点是否缺少可用的交付物模板、评审人是否长期无法到位、评审结论是否没有后续跟踪。这些属于设计缺陷，需要修订流程图本身。
如果流程本身可执行，则通过试运行收集偏差记录，把高频绕行点列出来，由流程维护责任人判断是调整流程还是加强执行要求。评审记录与交付物版本在系统中留痕，也能让绕行行为变得可见。
软硬结合产品和纯软件产品，IPD流程图需要做哪些调整？
阶段框架可以共用，差异主要体现在技术评审点的设置和交付物上。软硬结合产品通常需要在开发阶段关注原型验证、小批量试产和质量性能确认，验证阶段关注技术定型与生产成熟度；纯软件产品的评审点更多围绕架构设计、版本发布和质量验证展开。
调整时保持阶段名称、评审点编号规则和角色命名的一致性，只替换阶段内的活动与交付物，便于跨产品线对比和统一管理。
流程图里的交付物和评审记录，需要放到工具里管理吗？
当流程涉及多个角色、多个评审点和版本迭代时，放在工具里管理更容易保持一致性。流程图上的交付物名称、模板版本和评审结论如果分散在文档和邮件中，容易出现评审使用过期材料、结论无法追溯的情况。
ONES 研发项目管理平台遵循 IPD 的理念和方法，支持从需求挖掘、收集、结构化到开发决策、研发落地的全流程管理，可将阶段、评审点与交付物在系统中对应起来，让每个判断留下可追溯的记录。具体配置方式需结合企业自身流程规划确定。
