项目集干系人沟通中，责任与交付要求写得含糊，常见后果是评审会上才发现交付物不符合预期、跨团队依赖无人认领、变更口头确认后难以追溯。本文给出一套可直接套用的做法：用四类角色划清职责边界，把交付要求写成可验收的条目，再用固定沟通节点和确认动作把责任固化下来，并附责任矩阵、条目模板、节点对照表和完成检查清单。
要点总览（TL;DR）
- 按决策、交付、协同、知会四类角色划分项目集干系人，每个关键交付物只保留一个交付责任人，协同方写明提供什么、何时提供。
- 交付要求固定为五个字段：交付物、验收标准、时间节点、依赖方、确认人；验收标准要能逐条核对，确认人具体到人。
- 把责任矩阵和交付条目嵌入启动、阶段评审、变更、收尾四类沟通节点，每个节点明确谁确认、确认什么、留下什么记录。
- 行动项在下次会议开头逐条核对，逾期按预设路径升级；变更和例外以书面确认为准，确认后同步更新条目和矩阵。
- 用完成检查清单定期自查，任何一项拿不出证据，就回到对应章节补齐动作，而不是在会上口头强调。
先定责任框架：四类干系人与职责边界
项目集涉及的角色往往横跨多个项目团队、业务部门和职能条线。责任划分的第一步，是把干系人按其在沟通中承担的动作归入四类：决策、交付、协同、知会。分类依据是“这个人在某件事上要做什么动作”，同一个人在不同交付物上可以承担不同角色。
四类角色的职责边界与典型岗位
| 角色类型 | 职责边界 | 典型岗位 | 在沟通中的动作 |
|---|---|---|---|
| 决策 | 对范围、优先级、资源投入、重大变更做最终裁定；对争议给出结论 | 项目集经理、业务发起人、 steering 层负责人 | 审批变更、裁定分歧、确认阶段结论 |
| 交付 | 对某一交付物的内容、质量和时间负责，组织完成并提交验收 | 子项目经理、模块负责人、技术负责人 | 提交交付物、说明完成情况、响应验收意见 |
| 协同 | 提供依赖输入、参与联调或评审、按约定时间反馈 | 接口人、上游团队负责人、共享资源负责人 | 确认依赖时间、提供输入、参与评审 |
| 知会 | 接收状态与结论信息，不参与该项交付的执行 | 相关业务方、职能支持部门、上级管理层 | 接收纪要、了解进展与风险 |
划分时有两个容易出问题的地方。一是把“协同”写成“配合支持”，没有具体动作和时间，导致依赖方无法被追踪；二是同一交付物上出现两个“交付”角色，验收时互相推诿。检查方法是：每个关键交付物只保留一个交付责任人，协同方必须写明提供什么、什么时候提供。
用责任矩阵落到具体交付物
责任矩阵的行是角色或具体人员，列是关键交付物，单元格填写角色代号。项目集层面不必追求完整 RACI，用简化版即可：D 代表交付责任，A 代表决策确认，C 代表协同输入，I 代表知会。填写完成后做三项检查：每列至少有一个 D 和一个 A；每个 C 都对应明确的输入内容和时间；没有一列出现两个 D。
| 交付物 | 子项目经理 | 项目集经理 | 接口团队负责人 | 业务方 |
|---|---|---|---|---|
| 集成测试报告 | D | A | C（提供接口环境） | I |
| 上线切换方案 | D | A | C（确认窗口期） | C（确认业务停机安排） |
| 阶段验收结论 | C（提供材料） | D/A | I | A（业务确认） |
矩阵建好后应在项目集启动会上逐列过一遍，让每个 D 和 A 当场确认。口头认可之后，矩阵作为项目集基础文档发布，后续新增交付物时同步补列，避免矩阵停留在启动时的版本。
把交付要求写成可验收的条目
“月底前把方案给出来”这类约定无法验收，因为它没有说明给谁、按什么标准算完成、依赖谁。可验收的交付要求应固定为五个字段：交付物、验收标准、时间节点、依赖方、确认人。五个字段齐全，条目才能进入跟踪。
交付要求条目模板与填写示例
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 交付物 | 写明名称和形态，如文档、报告、环境、接口清单 | 集成测试报告（含缺陷清单与回归结论） |
| 验收标准 | 可核对的条件，避免“完整、及时”等形容词 | 覆盖全部 12 个接口；遗留缺陷不超过 2 个且均为低优先级；附回归测试记录 |
| 时间节点 | 提交时间和评审时间分开写 | 3 月 20 日提交初稿，3 月 25 日完成评审 |
| 依赖方 | 写明依赖内容和提供时间 | 接口团队 3 月 15 日前提供测试环境与账号 |
| 确认人 | 具体到人，不用部门名称代替 | 项目集经理与业务方代表共同确认 |
从口头约定到书面条目
会议或沟通中形成的口头约定，应在会后当天转化为条目：记录人按五字段补全，缺失字段标注“待确认”并指定补齐责任人，发回相关方确认。转化时保留原始约定的时间点，便于对照。对于跨团队依赖，依赖方字段必须由依赖方本人确认，而不是由提出方代填。
颗粒度控制与里程碑对应
条目颗粒度以“能被一个人负责、能在一个评审节点上验收”为准。过粗的条目拆到子交付物，过细的条目合并到所属交付物下作为验收标准的一部分。每个项目集里程碑应能对应到一组条目，里程碑评审时逐条核对状态，避免里程碑只剩一个日期而没有可核对的交付内容。
用沟通节奏与确认动作固化责任
责任矩阵和交付条目是静态定义，要让它们在项目集运行期间持续有效，需要把它们嵌入固定的沟通节点，并在每个节点设置明确的确认动作和记录产出。
| 沟通节点 | 谁确认 | 确认什么 | 产出记录 |
|---|---|---|---|
| 项目集启动 | 项目集经理、各交付责任人、业务方 | 责任矩阵、关键交付条目、沟通节奏 | 启动会纪要、责任矩阵基线版 |
| 阶段评审 | 确认人、交付责任人、协同方 | 交付条目是否达到验收标准、遗留问题处理方式 | 评审结论、行动项清单 |
| 变更评审 | 决策角色、受影响交付责任人 | 变更对交付物、时间节点和依赖的影响 | 书面变更确认、更新后的条目 |
| 项目集收尾 | 项目集经理、业务方 | 全部交付条目关闭情况、未关闭事项的移交 | 收尾报告、移交清单 |
会议纪要与行动项闭环
纪要的价值在于把结论回写成可跟踪的记录：每条行动项写明动作、责任人、截止时间、关联交付物，并在下次会议开头逐条核对状态。行动项逾期时，由项目集经理在固定沟通节点上提出，按预设路径升级给决策角色，而不是在私下沟通中消化。
变更与例外的书面确认路径
变更和例外是责任最容易脱落的场景。约定一条固定路径：提出方提交变更说明，交付责任人评估影响，决策角色书面确认，确认后同步更新交付条目和责任矩阵。口头同意可以作为过程沟通，但条目更新以书面确认为准，确保后续追溯时有据可查。
当项目集需要跨多个项目统一查看交付进度、里程碑和资源投入时，可以把上述条目和节点记录承载在管理工具中。ONES Plan 提供项目集管理能力，支持多项目总览、自定义项目属性、里程碑与甘特图，并可查看关联项目的进度与工时数据，便于在阶段评审前集中核对各交付条目的状态；具体功能范围以官网产品页描述和实际版本为准。
示例：一次阶段评审如何明确责任与交付
以下为演示情景，用于说明前述框架和模板的使用方式，不对应真实组织。
示例背景与参与角色
某项目集进入第二阶段评审，涉及三个子项目。参与角色包括：项目集经理（决策与整体确认）、子项目经理甲（负责集成测试报告）、接口团队负责人（协同，提供测试环境）、业务方代表（决策，确认业务验收口径）。
评审前准备的交付要求条目
| 字段 | 内容 |
|---|---|
| 交付物 | 集成测试报告（含缺陷清单与回归结论） |
| 验收标准 | 覆盖 12 个接口；遗留缺陷不超过 2 个且为低优先级；附回归记录 |
| 时间节点 | 评审前 3 个工作日提交初稿 |
| 依赖方 | 接口团队提前 5 个工作日提供测试环境与账号 |
| 确认人 | 项目集经理、业务方代表 |
评审中的确认与分歧处理
评审会上，子项目经理甲逐条说明完成情况：12 个接口中 11 个已覆盖，剩余 1 个因环境问题未测。接口团队负责人确认环境延迟的原因和时间。业务方代表提出该接口涉及核心交易，不能带入下一阶段。项目集经理据此裁定：该条目暂不通过，补充测试作为行动项，同时评估是否影响里程碑日期。分歧当场形成结论，不由会后私下协调。
评审后行动项与记录
| 行动项 | 责任人 | 截止时间 | 关联交付物 |
|---|---|---|---|
| 补齐剩余接口测试并更新报告 | 子项目经理甲 | 评审后 5 个工作日 | 集成测试报告 |
| 确认环境问题根因并给出后续保障措施 | 接口团队负责人 | 评审后 3 个工作日 | 集成测试报告（依赖项） |
| 评估里程碑影响并提交结论 | 项目集经理 | 评审后 2 个工作日 | 阶段计划 |
纪要当天发出，下次评审会开头逐条核对。这个示例体现了三个动作：评审前条目齐全、评审中分歧当场裁定、评审后行动项带责任人和截止时间。
完成检查：责任与交付要求是否真正落地
以下清单用于定期自查，建议在项目集启动后一个月和每个阶段评审前各执行一次。
- 责任矩阵覆盖全部关键交付物，每列有且仅有一个交付责任人，且都有决策确认人。
- 每个协同角色都写明了提供什么输入、什么时间提供，并由协同方本人确认。
- 交付要求条目五字段齐全，验收标准可以逐条核对，确认人具体到人。
- 条目与项目集里程碑一一对应，里程碑评审时能逐条核对状态。
- 启动、阶段评审、变更、收尾四类沟通节点按计划执行，并有纪要或确认记录留存。
- 行动项在下次会议上逐条核对，逾期项有明确的升级路径和升级对象。
- 变更和例外均有书面确认记录，确认后条目和责任矩阵已同步更新。
- 新增交付物已补入矩阵和条目清单，没有游离在跟踪之外的约定。
清单中任何一项无法给出证据，说明对应机制尚未真正运行，应回到相应章节补齐动作，而不是仅在下一次会议上口头强调。
常见问题
项目集里同一个人既参与交付又参与决策，责任矩阵该怎么填？
按交付物分别填，不按人一次性定角色。同一个人在不同交付物上可以承担不同角色：在集成测试报告上是 D（交付责任），在阶段验收结论上可能是 A（决策确认）。填写时以“这一列交付物上他要做什么动作”为准，并在启动会上逐列确认。需要留意的是，同一交付物上决策与交付由同一人承担时，验收环节缺少独立确认，建议为该列补一个业务方或上级作为 A，或在评审记录中写明由谁代为确认。
交付要求条目写到什么程度算合适，写太细会不会增加管理负担？
以“能被一个人负责、能在一个评审节点上验收”为颗粒度标准。过粗的条目拆到子交付物，过细的条目合并为所属交付物的验收标准之一。判断方法是：如果一条交付要求找不到唯一责任人，说明太粗；如果一条要求需要单独开一次评审会才能确认完成，说明可以再合并。条目数量应与里程碑数量保持可对照的关系，每个里程碑对应一组条目即可，不必把日常任务全部条目化。
跨团队依赖方不认可我们填的依赖时间，沟通上怎么处理？
依赖方字段应由依赖方本人确认，提出方代填的条目只能算待确认。遇到不认可的情况，把分歧带回阶段评审或专门的依赖协调会，由决策角色裁定优先级和资源安排，形成结论后回写条目。若依赖时间调整影响里程碑，应同步评估影响并按变更路径书面确认，避免条目和计划各说各话。后续核对时以确认后的条目为准，口头承诺只作为过程沟通记录。
项目集已经运行一段时间，责任矩阵和交付条目没有随新增工作更新，怎么补？
先做一次盘点：把当前在跟踪的交付物列出来，与矩阵和条目清单逐项比对，找出没有对应列的交付物和没有条目的约定。补录时优先处理跨团队依赖和临近里程碑的交付物，其余按阶段分批补齐。补录完成后在最近一次阶段评审上过一遍，让新增的 D 和 A 当场确认。此后把“新增交付物同步补列”写入变更确认动作，作为条目更新的固定步骤，避免矩阵再次停留在旧版本。
行动项逾期后升级给谁、按什么节奏升级？
升级路径应在项目集启动时约定并写入沟通规则：行动项到期未完成，由项目集经理在下次固定沟通节点上提出，先由责任人说明原因和新的完成时间；影响里程碑或跨团队依赖的，升级给决策角色裁定资源或调整计划。升级节奏与沟通节点对齐，例如连续两次评审未关闭即升级，不必等到问题扩大。升级结论同样要回写成行动项，写明责任人和新的截止时间，并在下次会议开头核对。
