风险责任人负责单项风险的持续跟踪和推动，项目经理负责整体风险治理与资源协调，职能或技术负责人提供专业判断并承接应对动作，评审组或PMO统一评级口径与升级决策，干系人提供影响信息并确认处置结果。把这几类职责写进风险登记表，配合固定的评审节奏和升级路径，分工才能在日常项目中运转起来。
要点总览（TL;DR）
- 风险责任人对单项风险的结果负责，项目经理对项目整体风险暴露负责，两者是点与面的关系，不能互相替代。
- 按风险生命周期划分主责环节：识别、监控、关闭以风险责任人为主，评估由风险责任人组织、职能负责人提供专业判断，应对由职能负责人指派执行人落实。
- 分工落地靠四步：登记表指定唯一责任人并写明应对动作、截止时间和触发条件；统一评级口径与升级阈值；固定评审节奏；关闭或升级时留下交接记录。
- 每个角色都有可核对的交付物：风险责任人交登记条目与状态更新，项目经理交优先级与资源决策，职能负责人交技术确认与执行人指派，评审组交评级口径与评审纪要，干系人交影响确认与结果反馈。
- 风险转为已发生的阻塞时移交问题责任人，原风险条目标注为已转化并保留关联，避免两套流程重复跟踪或遗漏。
先定分工原则：谁对风险结果负责
分工的起点是明确一项风险由谁对结果负责。风险责任人是单项风险的唯一跟踪人，对这项风险的识别质量、状态更新、应对推进和关闭建议负责。项目经理对项目整体风险暴露负责，决定优先级和资源投入，两者是点与面的关系，风险责任人的工作支撑项目经理的治理判断，项目经理的决策为风险责任人提供资源和授权。
按风险生命周期划分主责环节，可以避免多人负责却无人推进的情况。识别阶段由风险责任人主责，负责把不确定性描述清楚；评估阶段由风险责任人与职能或技术负责人共同完成，前者组织，后者提供专业判断；应对阶段由风险责任人推动，职能负责人指派执行人落实动作；监控阶段由风险责任人主责，持续更新状态并提报变化；关闭阶段由风险责任人提出建议，项目经理或评审组确认。下表给出边界说明。
| 角色 | 主责环节 | 不承担的事项 |
|---|---|---|
| 风险责任人 | 单项风险的识别、状态更新、应对推动、关闭建议 | 不决定项目整体风险优先级，不单独批准资源投入 |
| 项目经理 | 整体风险治理、优先级排序、资源协调、升级审批 | 不替代风险责任人逐项跟踪每项风险的日常状态 |
| 职能/技术负责人 | 专业判断、应对方案可行性确认、执行人指派 | 不承担风险状态的日常维护 |
| 评审组/PMO | 评级口径统一、评审组织、跨项目升级决策 | 不替代责任人推进具体应对动作 |
| 干系人 | 提供影响信息、确认处置结果 | 不承担风险跟踪与应对推动 |
需要区分风险与问题。风险指尚未发生的不确定性，按上述分工跟踪；一旦风险转化为已发生的阻塞或缺陷，应移交问题管理流程，由问题责任人按问题处理机制推进。移交时保留原风险条目与处理记录的关联，避免同一事项在两套流程中重复跟踪或遗漏。
风险责任人与各角色的具体分工
原则确定后，需要落到每个角色的输入、动作、输出和交接对象上。风险责任人是信息汇聚和推动的枢纽，其他角色围绕它提供判断、资源和确认。
与项目经理
风险责任人向项目经理提报风险状态变化、应对进展和资源需求，说明影响范围与时间窗口。项目经理据此决定优先级排序和资源投入，对需要跨团队协调或超出项目权限的事项作出审批。交接的关键是风险责任人给出可决策的信息，项目经理给出明确的结论，避免状态只停留在汇报层面。
与职能/技术负责人
风险责任人提出初步应对方案，职能或技术负责人确认技术可行性、评估成本与副作用，并指派具体执行人。风险责任人随后跟踪执行人的动作进度。这里的分界是：方案由风险责任人组织形成，技术判断由职能负责人给出，执行由被指派人完成。
与风险评审组或PMO
风险责任人按周期提交风险台账，评审组统一评级口径，检查评级依据是否一致，并对达到升级阈值的风险作出升级决定。风险责任人负责准备材料并说明变化原因，评审组负责口径与决策，两者共同保证不同项目之间的风险信息可比。
与干系人
风险责任人向干系人收集影响信息，例如交付时间、成本或范围的潜在影响，并在处置后反馈进展和结果。干系人的确认是风险关闭的重要依据之一，尤其是影响外部交付或客户承诺的风险。
与问题管理
当风险升级为已发生的阻塞时，风险责任人整理已有跟踪记录，移交给问题责任人，说明触发条件、已采取的动作和当前影响。移交完成后，原风险条目关闭或标注为已转化，后续跟踪转入问题流程。
| 角色 | 输入 | 动作 | 输出 | 交接对象 |
|---|---|---|---|---|
| 风险责任人 | 风险信号、执行进展、干系人反馈 | 登记、更新状态、组织应对、提出关闭建议 | 风险登记条目、状态更新记录 | 项目经理、评审组 |
| 项目经理 | 风险状态与资源需求 | 排序优先级、调配资源、审批升级 | 优先级结论、资源调配决定 | 风险责任人 |
| 职能/技术负责人 | 应对方案草案 | 确认可行性、指派执行人 | 技术确认意见、执行人指派 | 风险责任人 |
| 评审组/PMO | 风险台账 | 统一评级、组织评审、决定升级 | 评级口径、评审纪要、升级结论 | 风险责任人、项目经理 |
| 干系人 | 处置进展通报 | 提供影响信息、确认结果 | 影响确认、结果反馈 | 风险责任人 |
操作步骤：建立可执行的分工机制
分工机制需要落到登记、评级、评审和交接四个动作上，每一步都有明确的输入、动作、输出和完成标志。
第一步：在风险登记表中指定唯一责任人
输入是已识别的风险清单。动作为每项风险指定一名责任人，写明应对动作、截止时间、触发条件和当前状态。输出是一份字段完整的风险登记表。完成标志是每项风险都有且只有一名责任人，且责任人本人确认知情。责任人缺位或多人并列，都会导致跟踪中断。
第二步：明确评级口径与升级阈值
输入是项目对风险分级的管理要求。动作为由评审组或PMO统一评级维度，例如影响程度与发生可能性的组合，并设定升级阈值，说明达到什么条件需要上报项目经理或评审组。输出是书面的评级口径和升级规则。完成标志是所有风险责任人使用同一套口径填写，评审时无需逐项解释评级依据。
第三步：设定评审节奏与参会角色
输入是项目周期和风险变化频率。动作为确定固定评审节奏，明确参会角色包括风险责任人、项目经理、职能负责人代表和评审组，风险责任人在会上汇报状态变化、应对进展和需要协调的事项。输出是评审纪要和更新后的风险台账。完成标志是每次评审后风险状态、应对动作和责任人信息均已更新。
第四步：关闭或升级时完成交接记录
输入是达到关闭条件或升级阈值的风险。动作为风险责任人提交关闭依据或升级申请，说明已完成的应对动作和剩余影响；升级时由项目经理或评审组作出决定并记录；转为问题时完成向问题责任人的移交。输出是关闭记录、升级结论或问题移交单。完成标志是相关方确认，原风险条目状态与记录一致。
在工具承载上，风险登记表、状态更新和评审记录可以放在同一协作空间中管理。以ONES为例，风险可作为工作项维护责任人、截止时间和状态字段，应对动作与评审纪要可在文档中留存并与工作项关联，使责任人的更新、项目经理的决策和评审组的结论形成可追溯的记录链条。具体字段和流程配置按团队实际管理要求设置。
角色与交付物：每个角色交什么
分工是否清晰，最终体现在每个角色是否按时交出约定的产物。下表按角色列出交付物、提交时点和接收方。
| 角色 | 交付物 | 提交时点 | 接收方 |
|---|---|---|---|
| 风险责任人 | 风险登记条目、应对措施进展、状态更新记录 | 风险识别时登记，评审前及状态变化时更新 | 项目经理、评审组 |
| 项目经理 | 风险优先级决策、资源调配结论、升级审批 | 评审会上或收到资源需求后 | 风险责任人 |
| 职能/技术负责人 | 应对方案技术确认、执行人指派 | 收到方案草案后的约定时限内 | 风险责任人 |
| 评审组/PMO | 评级口径、评审纪要、跨项目升级结论 | 评审会后 | 风险责任人、项目经理 |
| 干系人 | 影响信息确认、处置结果反馈 | 风险影响评估时及处置完成后 | 风险责任人 |
交付物的价值在于可核对。风险登记条目要能看出责任人、动作、时间和触发条件；评审纪要要能看出评级依据和升级决定；干系人反馈要能看出影响是否被确认。缺少这些内容，分工就退化为口头约定。
示例：一次风险从识别到关闭的分工流转
以下为演示情景，用于说明分工机制如何运转，不代表真实项目数据。
某项目在交付节点前识别到供应商可能延期的风险。风险责任人首先登记该风险，描述触发条件为供应商未在约定日期前完成交付，初步评估影响为节点顺延，并提出备选供应商作为应对方案。随后风险责任人将方案提交职能负责人，职能负责人确认备选供应商在技术上可行，评估切换成本，并指派采购接口人作为执行人推进备选方案。
风险责任人将资源需求提报项目经理，说明启用备选方案需要额外投入和审批时间。项目经理结合项目整体优先级，批准资源投入并明确审批路径。评审组在周期评审中按统一口径对该风险评级，确认其达到升级阈值，决定将其纳入重点项目风险清单并跟踪。风险责任人按评审结论更新状态，定期向干系人反馈备选方案的推进进展，干系人确认交付影响范围。
若供应商最终按期交付，风险责任人提交关闭依据，经项目经理确认后关闭条目；若延期实际发生并造成阻塞，风险责任人整理跟踪记录，移交问题责任人，原风险条目标注为已转化，后续按问题流程处理。整个过程中，每个角色的动作都有对应的记录和交接对象，事后可以回溯谁在什么时点做了什么决定。
完成检查：分工机制是否落地
机制建立后，可用以下清单逐项核对，判断分工是否真正运转。
- 每项风险是否都有唯一责任人，且责任人本人确认知情，能够说清自己负责的风险和当前状态。
- 风险登记表是否包含应对动作、截止时间和触发条件，字段是否被持续填写而非一次性录入。
- 评级口径是否书面统一，升级阈值是否明确，评审中是否按同一口径执行。
- 评审节奏是否被遵守，评审纪要是否记录了状态变化、决策结论和责任人。
- 风险转为问题时是否完成责任交接，原风险条目与问题记录是否建立关联。
- 干系人是否在影响评估和处置完成两个节点收到必要反馈，并留下确认记录。
- 项目经理的优先级决策和资源结论是否有记录可查，风险责任人是否据此调整应对动作。
核对中发现的问题通常集中在两类：责任人不明确导致跟踪中断，交接无记录导致决策无法追溯。前者通过登记表字段约束解决，后者通过评审纪要和状态更新记录解决。定期用这张清单检查一次，比在风险发生后追责更能保证分工机制持续有效。
常见问题
风险责任人和项目经理对同一项风险意见不一致时，以谁为准？
按职责边界处理：风险责任人负责提出状态判断、应对方案和资源需求，项目经理负责优先级排序和资源投入决策。若对风险等级有分歧，先回到评审组统一制定的评级口径，用同一套维度重新评估；若对是否投入资源有分歧，由项目经理结合项目整体风险暴露作出决定，风险责任人据此调整应对动作并记录决策依据。分歧本身也应写入风险条目，便于后续复盘。
一个人可以同时担任多项风险的责任人吗？
可以，但需要控制数量并保证每项风险都有明确的跟踪动作。判断标准是责任人能否说清每项风险的当前状态、下一步动作和时间节点。当同一人承担的风险数量多到无法按评审节奏逐项更新时，应把部分风险转交给更贴近该风险执行环节的成员，转交时同步更新登记表中的责任人和交接记录，避免出现挂名责任人。
风险责任人没有直接管理执行人的权限，如何推动应对措施落地？
推动力来自机制而非职权。风险责任人在登记表中写明应对动作、截止时间和触发条件，通过评审节奏公开进展，遇到执行受阻时向项目经理提报资源需求或协调请求，由项目经理作出优先级和资源决定。职能负责人指派执行人时明确交付时点，风险责任人按此跟踪。这样执行动作有明确承接人，推动过程有记录可查，减少依赖个人催促。
小团队角色少，是否还需要区分这么多角色？
角色可以合并，职责不能空缺。小团队中项目经理可能同时承担评审组的评级口径统一工作，职能负责人可能直接就是执行人，但每项风险仍需指定唯一责任人，仍需有书面的评级口径和升级规则，仍需在风险转问题时留下交接记录。合并的是人头，保留的是动作和记录，否则风险跟踪容易退化为口头提醒。
风险关闭后还需要保留哪些记录？
至少保留三类内容：关闭依据，说明应对动作已完成或触发条件已消除；确认记录，由项目经理或评审组确认关闭结论；关联信息，若风险曾升级或转为问题，保留与原问题条目的关联。这些记录的作用是事后回溯当时的判断依据，也为同类风险再次出现时提供参考。关闭不等于删除，条目状态更新为已关闭即可。
