项目团队在安排风险分析时，常会碰到一个顺序问题：先做定性分析，还是直接上定量分析。这个选择主要取决于三件事——风险清单是否成形、有没有可用的数据、结论要拿来做什么决策。多数项目的合理路径是先定性筛选，再对少数关键风险做定量。下面按条件给出判断依据、投入准备和验证方法。
要点总览（TL;DR）
- 先判断三件事：风险清单是否成形、有没有可用数据、结论要用于什么决策。多数项目先定性筛选，再对少数关键风险做定量。
- 风险清单未成形、团队对严重程度分歧大、缺少历史数据或决策窗口只有几天时，优先做定性分析更划算。
- 关键风险收敛到少数几条、有可参考的数据分布、结论要支撑预算或工期承诺时，应转向定量分析。
- 定性分析需要风险识别清单、统一的分级标准、覆盖关键角色的评审会和复评记录，缺一项就容易流于形式。
- 可先在一个早期项目试点，观察排序是否被采纳、清单是否收敛、责任是否落地，再决定是否推广或升级为定量。
先定性还是先定量：判断依据与结论
定性分析与定量分析回答的是两个不同层次的问题。定性分析回答“哪些风险值得优先关注、大致有多严重”，输出的是分级、排序和责任人；定量分析回答“这个风险可能造成多少金额、多少天工期偏差、需要留多少储备”，输出的是数值区间和概率分布。前者用于筛选和统一口径，后者用于数值决策。
优先做定性分析的信号比较明确：风险清单还在形成中，团队对风险严重程度的判断分歧较大，缺少可用的历史数据，或者决策窗口只有几天。这些条件下直接做定量分析，往往要先花大量时间补数据、建模型，结论的可靠性却受制于输入假设，投入产出不划算。
转向定量的时机同样有迹可循：关键风险已经收敛到少数几条，有历史项目数据或可参考的分布，结论要用于预算审批、合同工期承诺、储备金额设定等数值场景。此时定性分级已经无法区分“高”和“高”之间的差别，需要数值来支撑取舍。
两者是衔接关系。常见做法是先定性把风险清单压缩到十条以内，再挑出其中两三条影响金额或工期最大的做定量。下表按条件归纳判断顺序，便于对照。
| 判断条件 | 优先定性 | 转向定量 |
|---|---|---|
| 风险清单成熟度 | 清单未成形，条目多且混杂 | 关键风险已明确且集中 |
| 数据基础 | 缺少历史数据或建模经验 | 有可用数据、可建模的分布 |
| 决策用途 | 排优先级、分责任、定应对动作 | 定预算、工期承诺、储备金额 |
| 时间窗口 | 数天内需要形成共识 | 有数周时间做数据准备与建模 |
| 团队状态 | 跨职能团队口径不一致 | 评估口径已统一，分歧在数值上 |
定性分析解决什么问题：价值机制
定性分析的核心动作是给每条风险打上概率和影响两个维度的等级，再放进风险矩阵里定位。概率可以分高、中、低三档，影响可以按进度、成本、质量、范围分别评级。这个动作看起来简单，价值在于它把一长串描述各异的风险条目压缩成可比较的坐标，让团队能用同一把尺子讨论。
风险矩阵的作用是把坐标转成处置优先级。落在高概率高影响区域的风险进入重点跟踪，需要指定责任人和应对方案；落在低概率低影响区域的风险进入观察清单，定期复评即可。专家判断在这里提供的是分级依据：同类风险在过去项目中的表现、当前项目条件下的变化，都可以作为定级理由记录下来。
定性分析的输出直接支撑三件事。一是排序，团队知道先处理哪几条；二是责任分配，每条重点风险有明确的跟踪人；三是后续动作，哪些风险需要制定缓解措施，哪些需要补充数据后再评估。这些输出也是定量分析的输入——没有一份分级清晰的风险清单，定量分析连建模对象都选不出来。
在管理动作上，风险清单、分级字段和复评记录需要有地方承载。ONES 的瀑布项目管理方案支持设置项目计划和里程碑基线，实时对比计划与执行的偏差，帮助团队提早识别风险和问题；团队也可以围绕关键阶段和交付目标持续查看任务状态、阶段进展和待处理问题。这些能力承载的是风险识别与跟踪环节，风险分级字段和矩阵视图的具体形态，建议在实际产品中核验。
适合优先定性的项目条件
以下条件可以逐项对照自身项目，命中越多，越适合先做定性分析。
- 项目处于早期或启动阶段。需求、范围、技术方案都还在变化，风险条目每周都在增减，此时做定量分析等于给移动靶建模。
- 风险清单尚未成形。团队刚做完风险识别，条目数量多、颗粒度不一，有的写得像问题、有的写得像担忧，需要先归并和分级。
- 缺少可靠历史数据或建模能力。组织没有同类项目的数据积累，团队里也没有熟悉蒙特卡洛模拟、决策树等方法的人，定量分析的门槛会显著抬高。
- 决策周期短。比如项目立项评审在即，需要几天内拿出一份风险优先级清单供决策会讨论，定性分析能在一次工作坊内完成。
- 跨职能团队口径不一致。业务、研发、采购对“高风险”的理解各不相同，先通过统一的分级标准对齐认知，比直接争论数值更有效。
- 风险应对以管理动作主。多数风险的应对方式是加评审、调资源、设缓冲，这类动作依据分级就能决定，不需要精确数值。
需要说明的是，这些条件描述的是“先做定性更划算”，并不排除后续补做定量。项目进入执行期、数据逐步积累后，原先的定性结论可以作为定量分析的起点。
投入与前提：定性分析需要准备什么
定性分析投入不大，但缺少前置条件时容易流于形式。下表列出主要投入项和对应的准备要求。
| 投入项 | 具体要求 | 常见问题 |
|---|---|---|
| 风险识别清单 | 覆盖主要工作包和外部依赖，条目描述具体到可判断的对象 | 条目笼统，无法定级 |
| 评估口径 | 概率与影响的分级标准事先写清，各等级有可参照的描述 | 各人按自己的经验打分 |
| 参与者 | 覆盖业务、技术、交付等关键角色，有能拍板的人在场 | 只有项目经理独自填写 |
| 评审安排 | 一次集中评审会，逐条过风险并当场定级 | 分散填写，事后无人汇总 |
| 记录与复评 | 分级结果、定级理由、责任人、复评时间都留痕 | 评完即归档，不再更新 |
分级标准是其中最容易被忽略的一项。建议把概率分为三档并给出参照，例如“高”指本项目条件下发生可能性超过一半，“中”指有可能但不确定，“低”指仅在特定条件下发生。影响则按进度延误天数、成本超支比例等可观察口径描述。标准统一后，不同角色的打分才有可比性。
评审会的组织方式影响结论质量。逐条过风险、当场定级、记录分歧理由，比会后各自填表更有效。定级分歧本身是有价值的信息，说明该风险的不确定性高，可以标记为后续需要补充数据或做定量分析的对象。复评机制则保证清单随项目推进更新，建议按里程碑或固定周期复评一次。
这些记录需要有稳定的承载位置。ONES 支持围绕项目计划和任务状态跟踪进展，风险条目、分级结果和复评记录可以随项目工作项一并管理；ONES Assistant 可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与根因判断，供管理者在风险扩大前介入。具体字段配置和风险视图的组织方式，建议在试用中确认。
什么时候应暂缓定性、直接做定量
有些场景下定性分析提供的信息增量有限，可以直接进入定量。判断标准集中在四点。
- 关键风险已明确且集中。项目的主要风险就是两三条，比如关键设备到货延迟、核心供应商产能不足，团队对“是哪几条”没有分歧，此时再走一遍分级流程只是重复确认。
- 有可用数据与建模条件。组织有同类项目的历史工期、成本数据，或供应商有可参考的交付分布，具备做模拟或敏感性分析的基础。
- 结论要支撑数值决策。合同里要承诺完工日期、预算里要设定应急储备金额、投标要报出带风险溢价的报价，这些场景需要的是数值区间，分级标签无法直接使用。
- 定性已无法区分优先级。多条风险都被评为“高”，矩阵上挤在同一格，团队无法据此决定先处理谁，需要数值来拉开差距。
暂缓定性不等于跳过风险识别。即便直接做定量，风险清单仍是必要输入，只是省去了逐条分级和矩阵定位的环节。另外，定量分析的结论依赖输入假设的可靠性，数据来源和假设条件需要一并记录，便于后续复核。
试点判断：如何验证先定性是否有效
如果团队对“先定性”的效果没有把握，可以选一个小范围试点，用可观察的结果来验证，再决定是否推广。
试点步骤建议如下。第一步，选一个处于早期或刚完成风险识别的项目，规模不宜过大，一个迭代或一个阶段的跨度即可。第二步，按统一分级标准组织一次风险评审会，产出分级清单、责任人和应对动作。第三步，在下一个里程碑复评一次，记录清单条目的变化。第四步，对照观察结果决定是否对关键风险补做定量。
验证时重点观察四个信号：
- 排序是否被采纳。评审会产出的优先级顺序，是否在资源安排和会议议题中得到实际使用。
- 清单是否收敛。复评后风险条目是否减少或归并，重点跟踪的风险是否集中在少数几条。
- 责任是否落地。每条重点风险是否有明确的跟踪人，应对动作是否进入任务列表并有状态更新。
- 分歧是否显性化。定级时的争议是否被记录并转化为补充数据或定量分析的需求。
如果试点中排序被采纳、清单逐步收敛、责任落到人，说明定性分析在当前项目条件下是有效的，可以推广到同类项目。如果复评后发现多条风险仍无法区分轻重，或决策会反复要求给出金额和工期影响，这就是升级为定量分析的信号，应挑选其中影响最大的几条启动建模。
试点记录本身也是组织资产。几轮试点积累的分级标准、定级理由和复评结果，会成为后续项目做定性分析的参照，也为将来开展定量分析准备数据基础。
常见问题
风险定性分析和定量分析可以同时做吗？
可以，但建议有先后。常见做法是先定性把风险清单压缩到十条以内，再挑出其中两三条影响金额或工期最大的风险做定量。同时铺开容易造成两个问题：定性评审还没形成统一口径，定量建模的输入假设就缺少依据；团队精力分散，两边都做不深。如果项目已有成熟的风险清单和数据基础，也可以对关键风险直接定量，同时保留定性分级用于日常跟踪。
团队没有历史数据，还能做定量分析吗？
可以做，但结论的可靠性会受输入假设影响。缺少历史数据时，定量分析通常依赖专家估计的区间、供应商提供的交付分布或行业参考值，这些输入需要明确记录来源和假设条件，便于后续复核。如果连可参考的区间都难以给出，说明当前更适合先做定性分析：用分级和矩阵把风险排序，在项目推进中逐步积累数据，再对重点风险补做定量。
定性分析的分级标准由谁制定？
通常由项目经理或风险管理的牵头人起草，经关键角色评审后确定，并在项目内统一使用。标准要写清概率各档的参照描述和影响各档的可观察口径，例如进度延误天数、成本超支比例。跨职能团队参与制定过程本身有价值，业务、技术、交付对“高风险”的理解差异会在讨论中显性化。标准确定后，建议在复评时检查是否仍适用，项目条件变化较大时需要调整。
试点验证要跑多久才能判断定性分析是否有效？
建议覆盖一个迭代或一个阶段的跨度，并在下一个里程碑复评一次。时间太短，风险清单来不及变化，看不出收敛趋势；时间太长，试点成本上升。判断时重点看四个信号：评审会产出的优先级是否在资源安排中被实际使用，复评后风险条目是否减少或归并，重点风险是否有明确跟踪人且应对动作进入任务列表，定级分歧是否被记录并转化为补充数据的需求。信号不足时，先检查分级标准和评审组织方式，再考虑是否升级为定量。
风险条目在工具里怎么组织，才能支撑复评？
关键是让风险条目和项目工作项关联起来，并保留分级结果、定级理由、责任人和复评时间这几类信息。ONES 支持围绕项目计划和任务状态跟踪进展，风险条目、分级结果和复评记录可以随项目工作项一并管理；ONES Assistant 可围绕项目进展、工时投入、缺陷分布和资源配置生成进展分析与根因判断，供管理者在风险扩大前介入。风险分级字段和矩阵视图的具体形态，建议在实际产品中核验后再确定配置方式。
