IPD流程图模板用一张阶段表承载从概念到生命周期管理的决策评审与技术评审节点。每行对应一个阶段，列明阶段目标、关键活动、交付物、评审点、决策角色、通过标准与流转去向。使用路径是：先复制空白表，再按字段说明逐列填写，最后参照示例核对必填项是否齐全。模板适用于需要把IPD流程固化为可执行、可评审、可追溯表单的产品与研发团队。
要点总览（TL;DR）
- 模板由阶段流程主表、评审节点登记表和流程走向说明栏三部分组成，先复制空白表再逐列填写。
- 阶段、阶段目标、关键活动、交付物、评审点、决策角色、通过标准、下一阶段为必填列，交付物责任人、计划时间窗、风险与依赖可按需启用。
- 填写时区分关键活动与交付物，评审点名称后标注决策或技术类型，回退与并行路径统一写入流程走向说明栏。
- 示例以计划阶段演示字段对应关系，并同步展示评审登记与流转规则的填写方式。
- 阶段划分与评审密度可按项目类型和组织规模裁剪，调整后需同步更新主表、登记表和走向栏，并记录版本变更。
可复制空白IPD流程图模板
模板由两张表和一个填写区组成。阶段流程主表描述“每个阶段做什么、产出什么、由谁评审、达到什么标准才能进入下一阶段”；评审节点登记表把主表中的评审点展开为可跟踪的评审记录；流程走向说明栏用于补充阶段之间的交接条件与回退路径。三部分配合使用，主表保证阶段完整，登记表保证评审可追溯，走向栏保证流转规则清楚。
表一：阶段流程主表（空白）
| 阶段 | 阶段目标 | 关键活动 | 交付物 | 评审点 | 决策角色 | 通过标准 | 下一阶段 |
|---|---|---|---|---|---|---|---|
表二：评审节点登记表（空白）
| 评审名称 | 类型 | 触发条件 | 参与角色 | 输出结论 | 流转去向 |
|---|---|---|---|---|---|
流程走向说明栏（空白）
按“从某阶段 → 到某阶段：交接条件 / 回退路径”的格式逐条填写，例如：
- 正向流转：阶段A → 阶段B，交接条件为______，交接责任人为______。
- 回退路径：阶段B → 阶段A，触发情形为______，回退后需重新评审的节点为______。
- 并行或跳转：______，适用条件为______，需补充的评审为______。
字段说明：每一列填什么
字段说明的作用是统一填写口径，避免不同人填出的表无法横向比较。下表逐列解释含义、填写方式与常见错误，填写时以本表为准，示例章节也按同一口径展开。
| 字段名 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 阶段 | 流程中的一个管理区间 | 使用团队统一采用的阶段名称，如概念、计划、开发、验证、发布；一行只写一个阶段 | 把子活动当成阶段，导致行数膨胀 |
| 阶段目标 | 该阶段结束时要达成的结果 | 写成可判断是否达成的结果句，聚焦一个主要目标 | 写成“做好需求分析”这类无法验收的表述 |
| 关键活动 | 为达成阶段目标必须完成的主要工作 | 列3–6项，用动词开头，写清对象 | 把交付物名称混进活动列 |
| 交付物 | 活动完成后形成的可评审产物 | 写具体文档、方案、样件或数据包名称，可标注责任人 | 只写“相关文档”，无法核对是否齐全 |
| 评审点 | 该阶段设置的决策评审或技术评审 | 写评审名称并标注类型，如“概念决策评审（决策）”“TR2 技术评审（技术）” | 只写“评审”不区分类型，无法安排参与角色 |
| 决策角色 | 对评审结论负责的角色或会议体 | 写角色名称而非个人姓名，如产品决策委员会、技术负责人 | 写具体人名，人员变动后模板失效 |
| 通过标准 | 判定评审通过的条件 | 写成可核对的条目，如“关键交付物齐套且无未关闭的高等级问题” | 写成“大家认可即可” |
| 下一阶段 | 评审通过后的流向 | 填写下一阶段名称；存在多条去向时注明条件 | 留空，导致流程断点 |
关键活动与交付物的区分是填写中最容易混淆的地方：活动回答“做什么”，交付物回答“做完留下什么”。例如“完成系统架构设计”是活动，“总体技术方案文档”是交付物，两者成对出现，评审时才能既检查动作是否执行，也检查产物是否齐套。评审点类型建议在名称后统一标注“决策”或“技术”，决策评审关注是否继续投入资源，技术评审关注技术方案是否可行、接口是否一致、风险是否可控。
下一阶段与回退路径的填写规则是：主表“下一阶段”只写正常通过后的去向；回退、并行、终止等非正常路径统一写入流程走向说明栏，并注明触发情形和回退后需要重新执行的评审。这样主表保持简洁，异常路径也不会丢失。
必填与选填：哪些列不能空
必填列决定这张表能否支撑一次完整的阶段评审，选填列用于补充管理信息。建议先保证必填列全部填写，再根据团队管理精细度决定选填列是否启用。
| 字段 | 必填/选填 | 理由与适用情形 |
|---|---|---|
| 阶段 | 必填 | 流程骨架，缺失则无法排序和对照 |
| 阶段目标 | 必填 | 评审时判断阶段是否完成的依据 |
| 关键活动 | 必填 | 明确阶段内的工作范围，防止漏项 |
| 交付物 | 必填 | 评审的核对对象，缺失则评审无据可依 |
| 评审点 | 必填 | 流程控制节点，决定何时停下决策 |
| 决策角色 | 必填 | 明确谁对结论负责，避免评审无人拍板 |
| 通过标准 | 必填 | 把评审从主观判断变为可核对条件 |
| 下一阶段 | 必填 | 保证流程连续，缺失即形成断点 |
| 交付物责任人 | 选填 | 交付物较多、跨团队协作时建议填写 |
| 计划时间窗 | 选填 | 需要与项目计划对齐时填写，模板本身不绑定具体日期 |
| 风险与依赖 | 选填 | 技术复杂度高或外部依赖多的阶段建议补充 |
必填项暂时无法确定时，不要留空后直接提交评审，可先填入“待定”并在备注中写明责任人与确认时间，评审前必须补齐。若某阶段确实不设评审点，应在评审点列写“本阶段不设评审”并说明理由，而不是留空，避免读者误以为漏填。选填列在团队尚未形成统一口径时可以整体不启用，待流程稳定后再逐列增加。
填写示例：一条完整流程怎么填
以下为演示情景，用于说明字段之间的对应关系，不代表任何真实项目数据。示例选取“计划阶段”一行，并给出与之对应的评审登记和流程走向填写。
| 阶段 | 阶段目标 | 关键活动 | 交付物 | 评审点 | 决策角色 | 通过标准 | 下一阶段 |
|---|---|---|---|---|---|---|---|
| 计划阶段 | 明确产品实现路径，形成可执行的开发计划 | 完成系统架构设计；划分模块与接口；编制详细开发计划；识别关键风险 | 总体技术方案；详细开发计划；风险清单 | TR2、TR3 技术评审（技术）；PDCP 阶段决策评审（决策） | 技术评审委员会；产品决策委员会 | 技术方案通过 TR2、TR3 验证，接口一致、风险有应对措施；PDCP 批准基线版业务计划书 | 开发阶段 |
逐项对应关系如下：阶段目标对应“明确产品实现路径”，与关键活动中的架构设计、计划编制形成因果；交付物三项分别对应架构、计划和风险三类活动产物；评审点中 TR2、TR3 属于技术评审，PDCP 属于决策评审，与字段说明中“名称后标注类型”的口径一致；决策角色按评审类型分别填写委员会，而非个人；通过标准写成可核对的条件，并区分技术验证与业务计划批准两层；下一阶段填写“开发阶段”，保持流程连续。
对应的评审节点登记表示例：
| 评审名称 | 类型 | 触发条件 | 参与角色 | 输出结论 | 流转去向 |
|---|---|---|---|---|---|
| TR2 技术评审 | 技术 | 总体技术方案初稿完成 | 技术评审委员会、架构负责人、模块负责人 | 通过 / 有条件通过 / 不通过 | 通过后进入 TR3；不通过退回方案修订 |
| PDCP 阶段决策评审 | 决策 | TR2、TR3 均通过且业务计划书定稿 | 产品决策委员会、产品经理、项目经理 | 批准 / 有条件批准 / 不批准 | 批准后进入开发阶段；不批准退回计划阶段 |
流程走向说明栏对应填写：“计划阶段 → 开发阶段：交接条件为 PDCP 批准且基线版业务计划书归档，交接责任人为项目经理；回退路径：开发阶段 → 计划阶段，触发情形为技术方案出现重大变更或关键风险失控，回退后需重新执行 TR2、TR3 与 PDCP。”这段填写把主表中的“下一阶段”和登记表中的“流转去向”连接起来，形成可执行的流转规则。
当这些阶段、评审与交付物需要在团队日常协作中持续跟踪时，可以把模板中的阶段作为项目阶段、评审作为关键节点、交付物作为待办事项落到协作平台中。ONES 的 IPD 解决方案按概念、计划、开发、验证、发布等阶段组织研发管理，支持从需求挖掘、收集、结构化到开发决策、研发落地的全流程管理，团队可在同一平台协同管理项目事项、过程信息和关键节点，减少市场、产品、研发等角色之间的信息断层。模板负责定义规则，平台负责让每次评审和交付物状态可查、可交接。
调整与维护：按团队情况改模板
模板需要随项目类型和组织规模调整，调整的重点是阶段划分与评审密度，而不是推翻字段结构。以下规则可作为裁剪时的判断依据。
阶段划分的裁剪与合并
- 项目周期短、技术不确定性低时，可将相邻阶段合并为一行，但合并后仍需保留原阶段的关键交付物与评审点，避免控制点丢失。
- 产品线复杂、多子系统并行时，可在开发阶段下拆分子阶段行，每行单独设置技术评审，决策评审仍保持在阶段边界。
- 裁剪以“是否影响决策依据”为判断标准：影响资源投入判断的交付物和评审不能删，仅影响内部记录颗粒度的内容可以简化。
评审节点的增减判断
新增评审的条件通常是：该节点之后资源投入显著增加、存在跨团队接口需要确认、或历史项目在该位置反复出现问题。删除评审的条件通常是：该评审长期无实质结论、与其他评审内容重复、或对应风险已由其他机制覆盖。增减评审后，需同步更新主表评审点列、登记表条目和流程走向栏，三处保持一致。
版本与变更记录
| 记录项 | 填写内容 |
|---|---|
| 版本号 | 按 V1.0、V1.1 递增，结构性调整升主版本 |
| 变更日期 | 实际生效日期 |
| 变更内容 | 增删了哪个阶段、评审或字段 |
| 变更原因 | 对应项目问题、组织调整或体系更新 |
| 影响范围 | 涉及的产品线、项目类型与需同步更新的文档 |
定期复核的触发条件
建议在以下情形发生时复核模板：组织架构或决策角色调整；产品线新增或业务模式变化；连续多个项目在同一评审点出现延期或结论反复；IPD 体系本身更新。复核时重点检查必填列是否仍能支撑评审、评审密度是否与项目风险匹配、流程走向栏是否覆盖了新出现的回退情形。复核结果记入变更记录，并向使用该模板的团队同步。
常见问题
模板中的评审点名称和编号必须与示例一致吗？
不必完全一致。示例中的 TR2、TR3、PDCP 等名称用于说明评审类型的标注方式，实际填写时应采用团队所采用的 IPD 体系中的评审名称与编号。关键是保持主表评审点列、评审节点登记表和流程走向说明栏三处名称一致，并在名称后标注“决策”或“技术”类型，便于安排参与角色和输出结论。
如果某个阶段确实没有设置评审点，表格应该怎么填？
在评审点列填写“本阶段不设评审”并简要说明理由，不要留空。留空容易被误读为漏填，也会让后续核对必填项时无法判断是遗漏还是有意省略。若该阶段后续新增评审，需同步更新评审节点登记表和流程走向说明栏。
流程走向说明栏和主表中的“下一阶段”列是什么关系？
主表“下一阶段”只填写评审通过后的正常流向，保持表格简洁；回退、并行、终止等非正常路径统一写入流程走向说明栏，并注明触发情形和回退后需要重新执行的评审。两者配合使用，正常路径一眼可见，异常路径也不会丢失。
团队规模较小、项目周期短，可以合并阶段吗？
可以合并相邻阶段，但合并后仍需保留原阶段的关键交付物与评审点，避免控制点丢失。判断标准是看该交付物或评审是否影响资源投入决策：影响决策依据的内容不能删，仅影响内部记录颗粒度的内容可以简化。合并后建议在变更记录中注明合并了哪些阶段以及理由。
模板填写完成后，如何在日常协作中持续跟踪评审和交付物状态？
可以把模板中的阶段作为项目阶段、评审作为关键节点、交付物作为待办事项落到协作平台中。ONES 的 IPD 解决方案按概念、计划、开发、验证、发布等阶段组织研发管理，支持从需求挖掘、收集、结构化到开发决策、研发落地的全流程管理，团队可在同一平台协同管理项目事项、过程信息和关键节点，减少市场、产品、研发等角色之间的信息断层。模板负责定义规则，平台负责让每次评审和交付物状态可查、可交接。
