敏捷项目要不要做风险管理，判断起点是看不确定性是否会影响迭代承诺或交付结果，而非是否套用完整风险登记册。小团队通常值得保留一套轻量做法，但正式到什么程度，需要结合团队规模、风险影响面和决策可逆性分档。本文围绕适用边界与简化程度给出可对照的判断条件，并说明哪些情况应转入问题管理或项目组合层面。
要点总览（TL;DR）
- 判断起点是看不确定性是否影响迭代承诺或交付结果，而非是否套用完整风险登记册；单团队、短周期、低外部依赖的项目可以只做口头跟踪。
- 简化程度分三档：口头跟踪、轻量风险清单、带责任人和复查节奏的风险台账，随风险暴露程度升降，不必一次定死。
- 满足多团队协作、强外部依赖、合规安全资金等高风险影响面、决策不可逆或返工成本高、干系人分散等条件越多，越应正式化。
- 边界划分：尚未发生的不确定性归风险管理，已发生的阻塞转入问题管理，跨项目资源与优先级平衡归项目组合层面。
- 可用一个迭代做试点，观察风险是否被提前识别处理，以连续两个迭代的复查结果决定升档或降档。
条件式结论：什么情况下值得做、做到什么程度
小团队或敏捷项目值得保留风险管理，前提是存在尚未发生、但可能影响迭代目标或交付结果的不确定性。如果团队每个迭代都能按承诺交付，外部依赖稳定，风险发生后也能快速回退，那么把风险管理做成正式台账的收益有限。判断时先问三个问题：这个不确定性是否会影响本迭代或近期交付承诺？影响面是单个任务、一个迭代，还是跨团队、跨项目？一旦发生，决策是否可逆、返工成本是否可控？
回答完这三个问题，再选择简化档位。三档之间可以随风险暴露程度升降，不必一次定死。
| 档位 | 做法 | 适用触发条件 | 主要产物 |
|---|---|---|---|
| 一档：口头跟踪 | 在站会或迭代计划会上口头提出，由团队自行跟进 | 单团队、迭代周期短、外部依赖少；风险影响面小且可快速回退 | 站会记录或迭代计划中的一句备注 |
| 二档：轻量风险清单 | 维护一份简短清单，记录风险描述、影响、应对动作和提出人 | 存在若干外部依赖或跨角色协作；风险可能影响迭代承诺，但影响范围可控 | 迭代级风险清单，随迭代更新 |
| 三档：带责任人和复查节奏的风险台账 | 每条风险有明确责任人、复查时间和状态，在固定节奏中复查 | 多团队协作或强外部依赖；合规、安全、资金等高风险影响面；决策不可逆或返工成本高 | 风险台账，含责任人、复查节奏和状态流转 |
档位选择的核心是让风险信息在需要的人之间可见、可追。一档适合风险少且团队坐在一起的情况；二档适合风险开始跨角色但仍在单团队内；三档适合风险影响超出单个迭代或单个团队的范围。档位升高意味着增加记录和复查成本，因此只在风险暴露程度支持时才升。
敏捷项目为什么仍需要风险管理：目标问题与价值机制
敏捷节奏缩短了反馈周期，同时也把不确定性压缩到更短的时间窗口里。迭代承诺一旦确定，外部依赖、接口变更、人员可用性、第三方交付延迟等尚未发生的问题，都可能在迭代中途影响承诺兑现。风险管理的作用是在这些不确定性变成阻塞之前，让团队有机会调整范围、顺序或应对方案。
风险信息需要在团队已有的沟通节奏中流动，而不是另开一套会议。站会上可以同步当前风险的变化和需要协助的事项；迭代评审时对照交付结果检查风险应对是否有效；回顾时复盘哪些风险被提前识别、哪些被漏掉。这样风险信息跟着迭代节奏走，记录成本低，也容易被团队接受。
提前暴露和延后暴露的代价差异，是判断是否值得做风险管理的关键。提前暴露时，团队可以在迭代内调整任务顺序、拆分需求或提前协调资源，代价通常是一次讨论和一次计划调整。延后暴露时，风险已经变成阻塞，可能造成迭代承诺落空、返工或跨团队协调被动，处理成本明显上升。风险管理并不消除不确定性，它的价值在于把处理时点前移，让团队在还有选择空间时做决定。
适用条件：哪些团队和场景应当正式化
以下条件不需要全部满足，但满足越多，越应当把风险管理从口头跟踪提升到有记录、有责任人的档位。可以逐条对照自评。
- 多团队协作或强外部依赖。当迭代交付依赖其他团队、供应商或外部系统时，风险的影响会跨出本团队边界，口头同步容易遗漏，需要有清单让相关方看到同一份信息。
- 高风险影响面。涉及合规、安全、资金、生产环境稳定性的项目，风险一旦发生，后果超出迭代范围，需要明确责任人、复查节奏和应对预案。
- 决策不可逆或返工成本高。架构选型、数据迁移、对外承诺发布时间等场景，错误决定的纠正成本高，值得在决策前把不确定性列出来并逐条评估。
- 干系人分散、信息不对称。当业务方、技术团队、管理层对项目状态的理解不一致时，一份共同可见的风险清单可以减少反复确认和事后争议。
- 迭代承诺经常落空且原因集中在少数几类。如果回顾中发现交付偏差反复来自同类未提前处理的不确定性，说明口头跟踪已经不够，需要把这类风险固定记录并指定跟进人。
这些条件指向同一个判断：风险的影响是否超出了单个人在站会上口头提醒就能覆盖的范围。超出时，正式化带来的可见性和追责清晰度，能够抵消记录成本。
投入与前提：简化风险管理需要准备什么
轻量风险管理要落地，需要几项最小投入。这些投入不追求完整，但缺一项就容易退回到口头提醒。
- 明确风险责任人与复查节奏。每条进入清单的风险指定一个跟进人，并约定在哪个节点复查，例如下次站会、迭代评审或固定日期。没有责任人的风险条目通常会在两周内失效。
- 统一风险描述字段与状态。至少包含风险描述、可能影响、应对动作、责任人和当前状态。字段保持少而稳定，团队才愿意持续填写。状态可以用简单的“待处理、跟进中、已关闭、已转为问题”区分。
- 与现有会议结合，控制会议成本。风险复查放在站会末尾或迭代计划会中完成，不单独增加会议。每次复查只处理状态有变化或临近复查时间的条目，避免逐条通读。
- 工具承载与信息可见性。风险清单需要放在团队成员和干系人都能访问的位置，并支持状态更新和责任人字段。使用协作工具时，可以把风险作为工作项或文档条目管理，让站会看板、迭代记录和风险信息在同一处可见。例如在ONES的敏捷研发管理场景中，团队可以在每日站立会议借助敏捷看板对齐迭代进度与风险、排除问题，迭代回顾时再通过燃尽图、工时日志等报表复盘偏差，并用Wiki沉淀经验；风险条目本身的具体字段和台账配置，需要结合团队实际流程在工具中设定。
这些前提的准备成本通常集中在前一两个迭代。字段和节奏稳定后，维护成本主要来自复查动作本身，而不是工具配置。
暂缓条件：什么时候可以只做口头跟踪或暂不单列
以下情况可以暂缓正式化，避免为低暴露的不确定性付出记录成本。
- 单团队、短周期、低外部依赖。团队规模小、成员坐在一起、迭代内任务基本自给自足时，站会口头提醒足以覆盖大多数不确定性。
- 风险影响面小且可快速回退。如果某个不确定性发生后的纠正动作在半天内可以完成，且不影响迭代承诺，单独建条目跟踪的收益低于沟通成本。
- 已经发生的阻塞转入问题管理。风险管理处理的是尚未发生的不确定性；一旦风险已经变成阻塞、缺陷或明确的待办事项，应转入问题管理流程，按问题跟踪和解决，避免风险清单里堆积已经发生的事项。
- 跨项目资源与优先级平衡归项目组合层面。当不确定性涉及多个项目之间的资源争用、优先级排序或整体投入平衡时，单个敏捷团队的风险清单无法解决，应在项目组合层面统一评估和协调。
边界划分可以用一句话检验：尚未发生、可能影响目标的不确定性，放在风险管理；已经发生、需要处置的阻塞，放在问题管理；跨项目的资源与优先级平衡，放在项目组合层面。三类事项混在一起，会让风险清单失去预警作用。
试点判断：用一个小周期验证简化程度是否合适
档位是否匹配，可以用一个迭代作为试点周期来验证，不必先在全团队推行。
- 选定试点迭代和初始档位。选择一个有代表性的迭代，按当前判断选择一档或二档作为起点，并明确本迭代要观察的风险范围，例如外部依赖、接口变更或人员可用性。
- 在迭代中记录风险动作。记录每次风险被提出的时间、提出时的状态、采取的动作和结果。重点观察风险是在影响交付之前被识别，还是在变成阻塞之后才被处理。
- 在回顾中对照观察指标。可用的观察指标包括：迭代内提前识别的风险数量、转为阻塞的风险数量、因风险调整范围或顺序的次数、复查动作实际发生的次数。指标用于判断档位是否够用，不用于考核个人。
- 据复查结果调整档位。如果多次出现风险在变成阻塞后才被处理，说明当前档位偏低，应升到有责任人和复查节奏的台账；如果清单条目长期无人复查、记录成本明显高于收益，说明档位偏高，可以降回口头跟踪或更短的清单。
- 把结论写入下个迭代的计划。试点结束后，在迭代计划中明确下一周期采用的档位和复查节奏，并在下一次回顾中再次验证。档位调整以连续两个迭代的观察为依据，避免因单次事件频繁变动。
试点方法本身不依赖特定工具。使用协作工具时，风险记录、责任人和复查时间可以与迭代工作项放在同一处，让站会和回顾直接引用；工具承载的是信息的可见性和状态流转，档位判断仍由团队根据实际暴露程度决定。
常见问题
团队已经在站会上口头提风险，还需要单独建风险清单吗？
取决于口头提醒是否覆盖得住。如果风险影响范围在单团队内、发生后能快速回退，口头跟踪就够用。出现以下信号时建议升级为轻量清单：风险开始跨角色或跨团队，站会上提过但后续无人跟进，或回顾中发现交付偏差反复来自同类未提前处理的不确定性。清单的作用是让风险有记录、有提出人、有应对动作，减少口头信息在迭代中途丢失。
风险清单和问题列表要不要分开维护？
建议分开，因为两者处理的对象不同。风险是尚未发生、可能影响目标的不确定性，需要跟踪的是它会不会发生以及如何应对；问题已经发生，需要的是处置和关闭。把已发生的阻塞留在风险清单里，会让清单越积越长，预警作用被稀释。实际操作中可以在同一工具里用不同状态或类型区分，风险转为问题时有明确的流转动作，而不是简单改个标签。
小团队只有五六个人，做风险台账会不会太重？
五六人的单团队通常从一档或二档起步更合适。三档台账的价值在于跨团队可见和明确追责，团队规模小、成员坐在一起时，这部分收益有限，而记录和复查成本是实打实的。可以先只维护一份简短清单，字段控制在风险描述、影响、应对动作和提出人几项，复查放在站会末尾完成。等出现跨团队依赖或高风险影响面时再升档。
试点一个迭代后发现风险还是经常变成阻塞，该怎么调？
先看是档位问题还是执行问题。如果风险被提出了但无人跟进、复查没有实际发生，问题在责任人和节奏，升档之前先把这两项落实。如果风险在提出时就已临近发生、团队没有调整空间，说明识别时点太晚，需要把风险讨论前移到迭代计划阶段。连续两个迭代都出现同类情况，再把档位升到带责任人和固定复查节奏的台账，并观察下一个周期的变化。
用协作工具管理风险，最低需要满足什么？
最低要求是三点：团队成员和干系人都能访问同一份风险信息；每条风险能挂责任人和状态；复查时间到了能被看到。满足这三点，工具就够用，字段不必求全。以ONES为例，团队可以在每日站立会议借助敏捷看板对齐迭代进度与风险、排除问题，迭代回顾时通过燃尽图、工时日志等报表复盘偏差，并用Wiki沉淀经验；风险条目本身的具体字段和台账配置，需要结合团队实际流程在工具中设定。
