跨团队项目里，风险信息往往散落在各团队的周报、群聊和会议纪要中，同一件事被不同团队反复上报，归口人只能事后逐条比对。解决方向是先把登记口径统一，再设单一提交入口和归口角色，由归口人按固定节奏合并重复条目、回写唯一编号。本文给出一套可直接落地的收集流程、字段表、角色分工和上线检查清单，适用于尚未发生的不确定性管理；已发生的阻塞事项应转入问题管理。风险台账需要工具承载时，ONES 可用于集中登记条目、维护状态并支撑跨团队协作。
要点总览（TL;DR）
- 统一收集从统一口径开始：先定义跨团队共用的风险登记字段、编号规则和“原因—事件—影响”描述写法，再设单一提交入口。
- 去重靠两道关口：提交人按“同原因、同影响对象”先查台账，归口人按固定节奏合并重复条目并回写唯一编号。
- 角色分工写清提交人、归口人、风险责任人和评审会的职责与交付物，合并后按来源团队逐一反馈处理结果。
- 机制上线四到六周后按字段一致性、编号使用、入口唯一性、去重有效性、状态更新和反馈闭环逐项检查，按结果迭代。
- 风险台账需要工具承载时，ONES 可用于集中登记条目、分配责任人和更新状态，机制能否运转仍取决于字段、入口和节奏是否被执行。
统一收集机制的核心答案与操作步骤
统一收集要解决的是“谁在什么时候把什么信息交到哪里、由谁合并”的问题。建议按以下五步建立机制，每一步都有明确的输入、动作、输出和完成标志，避免流程停在制度文档上。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 定口径 | 现有各团队的风险上报模板、历史重复条目 | 确定必填字段、编号规则、风险描述写法 | 风险登记字段表与填写说明 | 各团队提交人能用同一模板填出一条完整风险 |
| 2. 设入口 | 字段表、团队清单 | 指定唯一提交入口（表单、工作项类型或指定文档），关闭分散的临时上报渠道 | 单一提交入口及访问方式 | 新风险只从该入口进入，其他渠道不再接收正式风险 |
| 3. 定归口 | 项目组织架构 | 指定风险负责人或 PMO 作为归口人，明确其合并、去重、台账维护职责 | 归口人任命与职责说明 | 每条新提交在约定时限内有人处理 |
| 4. 提交前查重 | 现有风险台账 | 提交人按“同原因、同影响对象”先检索台账，命中则关联已有条目并补充信息 | 带查重结论的提交记录 | 提交记录中能看到“新增”或“关联至某编号”的标记 |
| 5. 归口合并与回写 | 新提交条目、台账 | 归口人按固定节奏（如每周一次）评审新条目，合并重复项，分配唯一编号，回写责任人与状态 | 更新后的统一风险台账 | 台账中无重复编号，每条风险有责任人和当前状态 |
其中第4步和第5步是去重的两道关口。提交前查重减少明显重复，归口合并处理表述不同但实质相同的条目。固定节奏的汇总评审建议与项目例会绑定，例如每周例会前完成台账更新，会上只讨论高风险条目和升级事项，避免把评审会开成逐条读台账的流水会。
机制运行初期，归口人可在每次汇总后统计新增条目数、合并条目数和关联条目数，用这组数据判断查重是否有效。合并比例持续偏高，说明提交前查重没有做到位，需要回头强化填写说明和检索习惯。
风险登记表字段与去重判定规则
口径不一是重复上报的主要来源。两个团队用不同措辞描述同一件事，归口人只能靠人工判断。把字段和写法固定下来，重复条目在提交阶段就会大幅减少。
必填字段与选填字段
| 字段 | 类型 | 填写要求 |
|---|---|---|
| 风险编号 | 必填 | 由归口人分配，格式建议“项目缩写-R-序号”，提交时留空 |
| 风险描述 | 必填 | 按“原因—事件—影响”三段式书写 |
| 来源团队 | 必填 | 填写提交团队名称，便于追溯和反馈 |
| 影响范围 | 必填 | 写明受影响的对象：哪个里程碑、哪个系统、哪类交付物 |
| 可能性 | 必填 | 统一用高/中/低三档，附判定说明 |
| 影响程度 | 必填 | 统一用高/中/低三档，与影响范围对应 |
| 责任人 | 必填 | 负责跟进该风险的单一责任人，不填团队名 |
| 状态 | 必填 | 待评估、跟进中、已缓解、已关闭、已升级 |
| 应对措施 | 选填 | 初步应对思路，可在评审后补充 |
| 关联条目 | 选填 | 疑似重复或相关风险的编号 |
| 触发信号 | 选填 | 出现什么现象说明风险正在发生 |
风险描述的统一写法
统一采用“原因—事件—影响”结构：因为什么条件，可能发生什么事件，进而对什么对象造成什么后果。例如“第三方接口交付延迟，可能导致联调窗口压缩，影响上线里程碑”。这种写法让不同团队提交的条目可以直接比对原因和影响对象，减少因措辞差异造成的误判。
重复判定规则
- 合并：原因相同且影响对象相同，判定为重复，合并为一条，保留最早编号，其余编号标记为已合并并指向主条目。
- 关联：原因相同但影响对象不同，或影响对象相同但原因不同，不合并，建立关联关系，便于评审时一起看。
- 不处理：原因和影响对象都不同，作为独立条目登记。
编号与来源团队标记要同时保留。合并后主条目记录全部来源团队，后续反馈和状态通知按来源团队逐一回传，避免某个团队提交的风险被合并后失去可见性。
跨团队角色分工与交付物
收集机制无人负责就会退回到分散状态。以下角色分工可按项目规模裁剪，小项目可由一人兼任归口与评审，但职责边界仍需写清。
| 角色 | 职责 | 交付物 | 交接节点 |
|---|---|---|---|
| 各团队风险提交人 | 按模板填写风险，提交前检索台账查重，命中则关联并补充信息 | 风险提交记录（含查重结论） | 按约定周期提交，紧急风险随时提交 |
| 归口人（风险负责人或 PMO） | 接收新条目，按规则合并去重，分配编号，维护台账状态 | 统一风险台账、合并记录 | 每次汇总后向提交团队反馈处理结果 |
| 风险责任人 | 跟进所负责条目的应对措施，更新状态 | 状态更新与应对进展 | 评审会前更新，状态变化时及时回写 |
| 评审会参与人 | 确认高风险条目的评估结论，决定是否升级 | 评审结论与升级决定 | 固定评审会上形成结论，会后由归口人回写 |
高风险条目的确认与升级放在固定评审会上完成。判定为高可能性和高影响的条目，由评审会确认责任人和应对方案，超出项目权限的按升级路径提交上级决策。升级决定要回写到台账状态，形成从提交到决策的完整记录。
台账维护可以借助协作工具承载。ONES 提供从项目到任务的多层级管理能力，支持统一安排全局工作任务并实现自下而上的进度反馈，风险条目可作为工作项集中登记、分配责任人和更新状态；其瀑布项目管理方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，帮助在汇总评审时提早识别风险和问题。工具承载的是台账与协作动作，机制能否运转仍取决于字段、入口和节奏是否被执行。
示例：一次跨团队风险汇总如何完成去重
以下为演示情景。某项目进入联调阶段，三个团队在同一周分别提交了风险：研发团队提交“第三方支付接口文档迟迟未定稿，可能导致联调延期，影响上线里程碑”；测试团队提交“支付模块接口未冻结，测试用例无法定稿，影响测试进度”；项目经理在周报中记录“支付接口交付存在延迟，上线时间可能受影响”。
归口人按规则逐条比对：三条的原因都是第三方支付接口交付延迟，影响对象都指向上线里程碑及联调测试环节，判定为重复，合并为一条主条目，保留最早提交的编号，其余两条标记为已合并并指向主条目。合并前后的对照如下。
| 项目 | 合并前 | 合并后 |
|---|---|---|
| 条目数量 | 3 条独立记录 | 1 条主条目，2 条已合并关联 |
| 编号 | 三个临时记录，无统一编号 | 主条目分配唯一编号，已合并条目保留原记录并指向主条目 |
| 来源团队 | 研发、测试、项目管理各自记录 | 主条目记录三个来源团队 |
| 责任人 | 各自团队内部跟进 | 指定单一责任人，负责推动接口交付确认 |
| 状态 | 分散、口径不一 | 统一为“跟进中”，评审会确认后视情况升级 |
合并完成后，归口人回写编号、责任人和状态，并在固定评审会上说明合并依据。会后向三个来源团队分别反馈处理结果：主条目编号、当前责任人和下一步动作，同时告知已合并条目的关联关系，确保各团队知道自己提交的信息没有被遗漏。这一反馈动作是机制能否持续的关键，提交人看到信息被处理，才愿意继续按统一入口提交。
机制上线后的完成检查
机制建立不等于运转。建议在运行四到六周后，按以下清单逐项核对，判断统一收集是否真正落地。
- 字段一致性：抽查最近提交的风险条目，必填字段是否齐全，风险描述是否按“原因—事件—影响”书写，可能性和影响程度是否使用统一档位。
- 编号使用：台账中每条风险是否有唯一编号，是否存在无编号条目或编号重复。
- 入口唯一性：是否仍有团队通过群聊、邮件等非指定渠道上报正式风险，发现后是否引导回统一入口。
- 去重有效性：统计本期新增、合并、关联条目数量，检查是否存在原因和影响对象相同却未合并的条目。
- 状态更新：台账中处于“跟进中”的条目是否在约定周期内更新过状态，长期未更新的条目是否有人跟进。
- 反馈闭环：每个来源团队是否收到过其提交条目的处理结果，合并条目是否通知到原提交人。
- 异常处置：发现漏报时，确认是提交时点未执行还是入口不可达；发现重复未合并时，回溯是查重环节缺失还是判定规则不清，并针对性修正。
检查结果应形成简短记录，明确需要调整的环节和责任人。若合并比例持续偏高，优先强化提交前查重；若漏报集中出现在某类风险上，检查字段设计是否覆盖了该类风险的描述需要。机制按检查结果迭代，比一次性制定完整制度更能保证长期运转。
常见问题
跨团队提交的风险描述措辞差异很大，归口人如何判断是不是同一条？
判断依据是原因和影响对象两个要素，与措辞无关。要求各团队按“原因—事件—影响”书写后，归口人只需比对：原因是否指向同一个条件，影响对象是否指向同一个里程碑、系统或交付物。两者都相同即判定为重复并合并；只有一项相同则建立关联、不合并；两项都不同作为独立条目登记。为减少误判，可在字段表中把影响范围设为必填，并要求写到具体对象而非笼统写“项目进度”。
小项目人手有限，归口人和评审角色能否由同一人兼任？
可以兼任，但职责边界仍要写清。兼任时建议把合并去重和评审确认放在不同时间点完成：先在固定汇总时点处理新条目、合并重复项，再在项目例会上以评审身份确认高风险条目的责任人和应对方案。这样即使由一人执行，合并动作和升级决定仍有各自的记录，避免同一次操作里既合并又拍板导致依据不清。项目规模扩大后再拆分角色。
机制运行一段时间后合并比例一直很高，应该先改哪里？
优先检查提交前查重环节，而不是加严归口审核。合并比例高通常说明提交人没有检索台账就提交，或检索习惯尚未形成。可先确认台账是否可被各团队方便地检索、填写说明中是否明确要求提交前查重并标注结论，再抽查提交记录中“新增”与“关联至某编号”的标记是否真实填写。若查重已执行但重复仍多，再回头检查风险描述写法是否统一，措辞差异会让提交人检索不到已有条目。
某团队提交的风险被合并后，如何保证他们仍然知道后续进展？
合并时保留全部来源团队标记，反馈按来源团队逐一回传。归口人在合并后向每个原提交团队说明主条目编号、当前责任人和下一步动作，并告知其原条目已关联到主条目。状态变化时，通知范围覆盖主条目记录的所有来源团队。这一步是机制持续运转的关键：提交人看到自己提交的信息被处理并有回音，才愿意继续从统一入口提交，而不是退回群聊和邮件。
已经发生的阻塞事项是否也走这套风险收集流程？
不走。这套机制处理的是尚未发生的不确定性，已经发生的阻塞事项应转入项目问题管理，按问题的处置流程跟进。两者在台账中可以相互引用，例如某条风险触发后转为问题，在风险条目上标注触发情况和对应问题记录，但收集入口、责任人和状态口径分开维护。组合层面的风险平衡属于项目组合管理范围，也不在本机制的收集范围内。
