diff --git a/doc/20260904/Codex多角色项目推进总流程图-V0.15.html b/doc/20260904/Codex多角色项目推进总流程图-V0.15.html index 808b4c2..a0e3aea 100644 --- a/doc/20260904/Codex多角色项目推进总流程图-V0.15.html +++ b/doc/20260904/Codex多角色项目推进总流程图-V0.15.html @@ -713,8 +713,8 @@
| 阶段 | 正式成果 | 主责角色 | 首次形成/提交 | 评审、修订与确认 | 正式分发/下游使用 |
|---|---|---|---|---|---|
| 1 业务需求 | 项目背景说明 | 业务 | F1.1 | F1.2 条件修订;F1.7 业务确认 | F1.3 评审分发;F1.8 正式基线给产品 |
| 1 业务需求 | 项目目标与里程碑计划 | 业务 | F1.1 | F1.2 条件修订;F1.7 业务确认 | F1.3 评审分发;F1.8 正式基线给产品 |
| 1 业务需求 | 客户里程碑要求 | 业务 | F1.1 | F1.2 条件修订;F1.7 业务确认 | F1.3 评审分发;F1.8 正式基线给产品 |
| 2 产品定义 | 立项资料 | 产品 | F2.2 | F2.3–F2.6 专业评审与修订;F2.7–F2.8 业务批准 | F3.1 方案设计输入;F4.1 项目规划输入 |
| 2 产品定义 | 测试验收标准 | 产品 | F2.2 | F2.3–F2.6 测试评审;F2.7–F2.8 业务批准 | F3.7 测试计划 输入;F6.1 测试输入;F7.1 验收输入 |
| 2 产品定义 | 客户里程碑要求 | 产品 | F2.2 | F2.3–F2.6 专业评审;F2.7–F2.8 业务批准 | F4.1 项目计划 输入;S.2 状态同步 |
| ID | 触发条件 | 发送 → 接收 | 正式载荷 | 约束/确认 | 对阶段的影响 |
|---|---|---|---|---|---|
| F1.1 | 收到新的客户需求或业务机会,且业务已完成原始信息收集、自查和负责人确认。 | 业务 → 项目Hub | 正式成果草案:项目背景说明、项目目标与里程碑计划。 附带内容:负责人确认、来源引用、成果版本和实际文件。 | 项目Hub不重复判断业务内容质量,只检查形式和跨来源一致性。 | 进入中心登记。 |
| F1.2(条件流) | 仅当文件结构、版本、证据不合规,或与已登记正式信息发生冲突时触发;不存在上述问题时跳过。 | 项目Hub → 业务 | 过程记录:形式校验问题清单或冲突清单。 关联成果:受影响的项目背景说明/项目目标与里程碑计划及其字段、版本、冲突来源和修正要求。 | 项目Hub不能生成业务缺失项或替业务补写事实;无错误或冲突时不得发起此流。 | 触发后,错误或冲突关闭前阻塞登记;未触发则直接进入 F1.3。 |
| F1.3 | 业务成果通过项目Hub的文件、版本、证据和跨角色冲突检查并完成登记。 | 项目Hub → 产品 | 评审分发成果:待评审的项目背景说明、项目目标与里程碑计划。 附带内容:成果版本、状态、证据、待确认项和回复时限。 | 必须标明这是待评审版本,不得冒充正式基线,产品不得据此直接启动阶段 2。 | 产品获得早期风险识别所需上下文。 |
| F1.4 | 产品审阅业务成果后,判断存在需要其他专业角色提前确认的风险。 | 产品 → 项目Hub | 过程记录:早期风险预检请求。 关联成果:项目背景说明/里程碑计划的相关字段与版本;另含预检原因、问题、目标角色、期望输出和时限。 | 是否预检、预检范围及对象角色均由产品负责指定;项目Hub不代替产品判断。 | 按产品指定名单创建预检任务。 |
| F1.5–1.6 | 产品预检请求格式完整,且指定的对象角色均为当前项目有效成员。 | 项目Hub ↔ 产品指定的对象角色 | 过程记录:角色预检任务 / 预检结果(角色预检任务/结论)。 关联成果:项目背景说明、项目目标与里程碑计划;返回本专业红线、风险、证据、待澄清项和受影响字段,作为后续 项目风险 输入。 | 项目Hub必须主动提醒全部关联角色,只校验、路由和汇总,不得自行增删产品指定名单。多角色结论冲突、影响较大或无法异步收敛时,建议由产品组织线下会议;参与角色统一确认的结论按 E.3 回传后,才能继续当前流程。 | 补充业务澄清和早期风险登记;复杂问题进入 E.1–E.4,闭环前保持阻塞。 |
| F1.7 | 业务内部审查、中心形式校验和预检问题均已关闭。 | 业务 → 项目Hub | 确认成果:完成负责人确认的项目背景说明、项目目标与里程碑计划。 附带内容:确认状态、确认时间、确认条件和版本。 | 角色内部确认状态、时间和版本必须记录。 | 门禁可进入评审。 |
| F1.8 | 业务确认完成,项目Hub已登记并留档正式版本且阶段门禁通过。 | 项目Hub → 产品 | 正式基线:项目背景说明、项目目标与里程碑计划的当前有效版本。 附带内容:成果版本、基线与证据引用、阶段 2 任务和确认时限。 | 只允许分发已经确认并留档的当前有效版本;分发事件和接收状态必须登记,草稿或过期版本不得作为产品定义输入。 | 产品接收后开启阶段 2。 |
| F1.1 | 收到新的客户需求或业务机会,且业务已完成原始信息收集、自查和负责人确认。 | 业务 → 项目Hub | 正式成果草案:项目背景说明、客户里程碑要求。 附带内容:负责人确认、来源引用、成果版本和实际文件。 | 项目Hub不重复判断业务内容质量,只检查形式和跨来源一致性。 | 进入中心登记。 |
| F1.2(条件流) | 仅当文件结构、版本、证据不合规,或与已登记正式信息发生冲突时触发;不存在上述问题时跳过。 | 项目Hub → 业务 | 过程记录:形式校验问题清单或冲突清单。 关联成果:受影响的项目背景说明/客户里程碑要求及其字段、版本、冲突来源和修正要求。 | 项目Hub不能生成业务缺失项或替业务补写事实;无错误或冲突时不得发起此流。 | 触发后,错误或冲突关闭前阻塞登记;未触发则直接进入 F1.3。 |
| F1.3 | 业务成果通过项目Hub的文件、版本、证据和跨角色冲突检查并完成登记。 | 项目Hub → 产品 | 评审分发成果:待评审的项目背景说明、客户里程碑要求。 附带内容:成果版本、状态、证据、待确认项和回复时限。 | 必须标明这是待评审版本,不得冒充正式基线,产品不得据此直接启动阶段 2。 | 产品获得早期风险识别所需上下文。 |
| F1.4 | 产品审阅业务成果后,判断存在需要其他专业角色提前确认的风险。 | 产品 → 项目Hub | 过程记录:早期风险预检请求。 关联成果:项目背景说明/客户里程碑要求的相关字段与版本;另含预检原因、问题、目标角色、期望输出和时限。 | 是否预检、预检范围及对象角色均由产品负责指定;项目Hub不代替产品判断。 | 按产品指定名单创建预检任务。 |
| F1.5–1.6 | 产品预检请求格式完整,且指定的对象角色均为当前项目有效成员。 | 项目Hub ↔ 产品指定的对象角色 | 过程记录:角色预检任务 / 预检结果(角色预检任务/结论)。 关联成果:项目背景说明、客户里程碑要求;返回本专业红线、风险、证据、待澄清项和受影响字段,作为后续 项目风险 输入。 | 项目Hub必须主动提醒全部关联角色,只校验、路由和汇总,不得自行增删产品指定名单。多角色结论冲突、影响较大或无法异步收敛时,建议由产品组织线下会议;参与角色统一确认的结论按 E.3 回传后,才能继续当前流程。 | 补充业务澄清和早期风险登记;复杂问题进入 E.1–E.4,闭环前保持阻塞。 |
| F1.7 | 业务内部审查、中心形式校验和预检问题均已关闭。 | 业务 → 项目Hub | 确认成果:完成负责人确认的项目背景说明、客户里程碑要求。 附带内容:确认状态、确认时间、确认条件和版本。 | 角色内部确认状态、时间和版本必须记录。 | 门禁可进入评审。 |
| F1.8 | 业务确认完成,项目Hub已登记并留档正式版本且阶段门禁通过。 | 项目Hub → 产品 | 正式基线:项目背景说明、客户里程碑要求的当前有效版本。 附带内容:成果版本、基线与证据引用、阶段 2 任务和确认时限。 | 只允许分发已经确认并留档的当前有效版本;分发事件和接收状态必须登记,草稿或过期版本不得作为产品定义输入。 | 产品接收后开启阶段 2。 |
| ID | 触发条件 | 发送 → 接收 | 正式载荷 | 约束/确认 | 对阶段的影响 |
|---|---|---|---|---|---|
| F2.1–2.2 | 阶段 2 启动。 | 项目Hub ↔ 产品 | 输入基线:项目背景说明、项目目标与里程碑计划。 产品提交的正式成果草案:立项资料、测试验收标准、客户里程碑要求。 参考输入(非阶段成果):项目已有的器件规格、板框约束、平台 SDK、串号表、平台对接文档和开发规范。 | 产品先自审,所有资料必须引用阶段 1 基线;专业评审由产品发起。 | 进入专业评审路由。 |
| F2.1–2.2 | 阶段 2 启动。 | 项目Hub ↔ 产品 | 输入基线:项目背景说明、客户里程碑要求。 产品提交的正式成果草案:立项资料、测试验收标准、客户里程碑要求。 参考输入(非阶段成果):项目已有的器件规格、板框约束、平台 SDK、串号表、平台对接文档和开发规范。 | 产品先自审,所有资料必须引用阶段 1 基线;专业评审由产品发起。 | 进入专业评审路由。 |
| F2.3 | 产品提交可评审草案和评审请求。 | 项目Hub → 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试 | 评审分发成果:按角色裁剪上述三类产品定义成果草案。 参考输入:只附与评审问题相关的现有器件、板框和平台资料;另含成果版本、基线引用、评审范围、问题和时限。 | 项目Hub只校验和路由;技术负责人看总体,嵌入式应用层看功能,嵌入式底层看 BSP/HAL,硬件看器件/板框,测试看可测性。 | 并行评审。 |
| F2.4 | 各角色完成评审。 | 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试 → 项目Hub | 过程记录:角色评审结果(角色评审结论)。 关联成果:三类产品定义成果的具体字段;提交结论、缺失、风险、证据、建议和是否阻塞。 | 不得只回复“可行/不可行”。 | 形成冲突矩阵。 |
| F2.5–2.6 | 存在冲突或缺口。 | 项目Hub ↔ 产品 | 修订成果:受影响的 立项资料、测试验收标准、客户里程碑要求 新版本。 附带内容:字段级修订清单、变更影响和关闭说明。 | 产品在内部确认最终版本后统一发出。 | 问题未关闭则暂缓推进。 |