项目风险识别模板要减少遗漏，关键在于同时设置两类维度：纵向字段保证每条风险记录完整，横向来源维度保证识别时不漏方向。下面给出一张可直接复制的空白表，并说明字段含义、必填规则、填写示例与维护方法，适合在项目启动会或阶段评审前使用。
要点总览（TL;DR）
- 模板同时设置纵向字段和横向来源维度：纵向字段保证每条风险可评估、可分派、可复核，横向来源维度保证识别时不漏方向。
- 核心字段覆盖风险编号、识别来源、风险描述、成因与触发条件、影响领域、概率、影响程度、风险等级、责任人、应对策略、应对动作、目标日期、当前状态、复核日期和备注。
- 风险描述统一写成“事件+条件+后果”，成因写根因、触发条件写可观察的预警信号，概率与影响程度使用团队统一分级口径。
- 防遗漏的做法是按 WBS/阶段、干系人、外部环境、资源与依赖、合规与安全逐项扫描，再合并去重，并对每个来源标注“已扫描”。
- 模板按项目类型裁剪来源维度行，核心字段保持稳定；已发生的阻塞事项转入问题管理流程，不留在风险表中。
可复制的项目风险识别空白模板
下表可直接复制到文档或表格工具中填写。表格按来源维度分组，每组预留若干空行，填写时先按分组逐项扫描，再把同一风险合并到一条记录中。表格不预填任何结论，风险等级与应对策略由项目团队评估后填写。
| 风险编号 | 识别来源 | 风险描述（事件+条件+后果） | 成因与触发条件 | 影响领域 | 概率 | 影响程度 | 风险等级 | 责任人 | 应对策略 | 应对动作 | 目标日期 | 当前状态 | 复核日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| WBS/阶段： | ||||||||||||||
| 干系人： | ||||||||||||||
| 外部环境： | ||||||||||||||
| 资源与依赖： | ||||||||||||||
| 合规与安全： |
使用时建议保留“识别来源”列的分组标签，即使某组暂时没有风险，也保留空行或标注“已扫描、暂无”，这样下次复核时能看出哪些方向已经覆盖。
模板各字段说明与识别维度设计
字段设计的目标是让每条风险都能被评估、分派和复核，而不是只留一句模糊的担心。下表说明每个字段回答的问题。
| 字段 | 回答的问题 | 填写要求 |
|---|---|---|
| 风险编号 | 这条风险如何被唯一引用 | 按项目前缀加序号，如 R-001，便于在会议纪要和任务中引用 |
| 识别来源 | 这条风险从哪个方向扫描出来 | 填写 WBS 节点、项目阶段、干系人类别、外部环境、资源依赖或合规安全中的具体来源 |
| 风险描述 | 可能发生什么，什么条件下发生，造成什么后果 | 统一写成“事件+条件+后果”，避免只写“进度可能延误” |
| 成因与触发条件 | 为什么会发生，什么信号出现说明正在逼近 | 成因写根因，触发条件写可观察的预警信号，两者分开写 |
| 影响领域 | 一旦发生会冲击哪些方面 | 覆盖进度、成本、范围、质量、资源、合规、干系人，可多选 |
| 概率 | 发生的可能性有多大 | 使用团队统一分级，如高/中/低或1–5分，口径在模板说明中固定 |
| 影响程度 | 发生后损失有多大 | 与概率使用同一套分级口径，避免不同人打分不可比 |
| 风险等级 | 这条风险需要多少关注 | 由概率与影响程度按约定规则组合得出，如高概率高影响为高等级 |
| 责任人 | 谁负责跟踪和推动应对 | 写具体角色或姓名，避免写“项目组” |
| 应对策略 | 打算怎么处理 | 在规避、减轻、转移、接受中选择，并说明理由 |
| 应对动作 | 具体做什么 | 写成可执行的动作，必要时拆成多条 |
| 目标日期 | 应对动作何时完成 | 写明确日期，便于在例会上检查 |
| 当前状态 | 这条风险进展到哪一步 | 使用统一状态，如待评估、跟踪中、已缓解、已关闭 |
| 复核日期 | 下次什么时候再看 | 与项目例会或阶段评审对齐 |
| 备注 | 补充什么信息 | 记录关联任务、历史相似风险或讨论结论 |
横向来源维度是防止遗漏的核心。只按个人经验罗列风险，容易集中在最熟悉的领域，比如进度和人力，而忽略合规、外部环境和干系人。建议每次识别时按以下清单逐项扫描：
- WBS/阶段：每个工作包和每个阶段交接处是否存在输入不齐、验收标准不清、返工可能。
- 干系人：关键决策人、客户、供应商、协作团队是否存在期望不一致、响应延迟或人员变动。
- 外部环境：政策、市场、供应商、季节或场地等外部条件是否可能变化。
- 资源与依赖：关键人员、设备、预算和前后置任务是否存在单点依赖。
- 合规与安全：数据、隐私、合同、资质和安全要求是否可能不满足。
扫描完成后合并去重，同一风险只保留一条记录，把不同来源写进“识别来源”列，避免同一问题重复登记导致台账虚胖。
必填与选填字段的划分
模板要轻量可用，又要保住关键信息。建议把字段分为必填和选填两档，项目初期先保证必填项完整，随着风险等级升高再补齐选填项。
| 类别 | 字段 | 说明 |
|---|---|---|
| 必填 | 风险编号、识别来源、风险描述、影响领域、责任人、当前状态 | 这六项保证风险可被引用、可追溯、可分派和可跟踪 |
| 选填 | 量化影响值、关联任务编号、历史相似风险、备注 | 用于高等级风险或需要跨项目复盘时补充 |
| 按阶段调整 | 概率、影响程度、风险等级、应对策略、应对动作、目标日期、复核日期 | 启动阶段可先填概率与影响程度；进入执行后补齐应对动作和目标日期 |
按项目阶段调整必填项的原则是：越接近执行，越要求应对动作和目标日期可检查；项目早期允许风险描述较粗，但识别来源和影响领域必须写清，否则后续无法判断覆盖是否完整。对于高等级风险，建议把选填的量化影响值和关联任务编号一并补齐，便于在例会上直接对照任务进展。
完整填写示例
下面用一条已填风险示范字段之间的对应关系，示例为演示情景，不代表真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 风险编号 | R-007 |
| 识别来源 | WBS/阶段：系统集成阶段；资源与依赖：第三方接口供应商 |
| 风险描述 | 第三方支付接口在联调阶段若仍未提供测试环境，将导致集成测试延期，进而压缩验收测试时间 |
| 成因与触发条件 | 成因：供应商排期靠后且合同未约定环境交付时间；触发条件：联调开始前一周仍未收到环境地址和账号 |
| 影响领域 | 进度、质量、干系人 |
| 概率 | 中 |
| 影响程度 | 高 |
| 风险等级 | 高 |
| 责任人 | 集成负责人 |
| 应对策略 | 减轻 |
| 应对动作 | 本周内书面确认环境交付日期；准备模拟接口用于提前联调；在合同中补充环境交付条款 |
| 目标日期 | 联调开始前十个工作日 |
| 当前状态 | 跟踪中 |
| 复核日期 | 下次项目周会 |
| 备注 | 关联任务：集成测试计划；历史相似风险：R-003 |
这条示例体现了来源维度的用法：风险同时从 WBS 阶段和资源依赖两个方向扫描出来，合并为一条记录，避免在两张清单里各登记一次。描述写成“事件+条件+后果”，触发条件写成可观察的信号，责任人和应对动作都能在周会上直接检查。
模板的调整与维护方法
模板需要随项目类型裁剪，但核心字段保持稳定，才能跨项目汇总和复盘。调整时可按以下规则执行：
- 按项目类型增删来源维度行。研发项目可强化资源与依赖、合规与安全；交付型项目可强化外部环境和干系人；来源维度可以增减，风险描述、影响领域、责任人、状态等核心字段不建议删。
- 识别会议的节奏与参与角色。建议在项目启动、阶段交接和重大变更时各开一次识别会，参与角色覆盖项目经理、技术负责人、采购或供应商接口人、合规或安全接口人，避免只由项目经理一人填写。
- 风险状态流转与关闭条件。状态按待评估、跟踪中、已缓解、已关闭推进；关闭需满足触发条件不再出现或应对动作已完成并经责任人确认，已发生的阻塞事项转入问题管理流程，不留在风险表中。
- 定期复核与模板版本更新。复核日期与项目例会对齐，每次复核更新概率、影响程度和状态；项目结束后汇总高频来源维度，作为下一版模板的调整依据，并在模板中记录版本号和修改说明。
- 避免机械照抄。先按来源维度逐项扫描，再合并去重，最后逐条补全字段；对每个来源维度标注“已扫描”，比填满表格更能说明识别是否完整。
当风险条目需要在多人之间分派、跟踪和复核时，可以把模板中的字段对应到协作工具的工作项上。以 ONES 为例，采用瀑布管理方式的项目可以用项目计划建立 WBS，按目标、交付物或阶段分解工作，并为任务设置前后置依赖和里程碑；设置计划和里程碑基线后，可以对比计划与执行的偏差，为风险识别提供触发信号。风险条目本身可以在任务或文档中登记，责任人、状态和复核日期随工作项流转，模板则通过 ONES Wiki 的页面模板库维护为制式化文档，并与项目任务关联，保证每次识别使用同一套字段口径。这样模板负责识别维度，工具负责登记、分派和复核，两者配合才能让风险台账长期可用。
常见问题
项目刚启动、信息还不完整时，风险描述写不细怎么办？
启动阶段允许风险描述较粗，但“识别来源”和“影响领域”两项要写清，否则后续无法判断扫描是否覆盖完整。可以先写清事件和可能后果，把触发条件留到阶段评审时补充。随着项目推进，再逐步补齐概率、影响程度和应对动作。判断标准是：这条记录能否让责任人在下次例会上说清要观察什么信号。
来源维度扫描后，同一风险出现在多个分组里怎么处理？
合并为一条记录，把多个来源写进“识别来源”列，例如同时标注 WBS 阶段和资源依赖。合并后重新检查风险描述是否仍然准确，影响领域是否需要增加。这样既保留扫描的完整性，又避免同一问题重复登记导致台账虚胖。合并去重应放在逐项扫描之后、补全字段之前进行。
风险条目应该登记在文档里还是协作工具里？
两种方式可以配合使用。模板负责识别维度和字段口径，适合在识别会和工作坊中使用；需要多人分派、跟踪和复核时，把字段对应到协作工具的工作项上更便于流转。以 ONES 为例，采用瀑布管理方式的项目可以用项目计划建立 WBS，为任务设置前后置依赖和里程碑，设置计划和里程碑基线后对比计划与执行偏差，为风险识别提供触发信号；模板可通过 ONES Wiki 的页面模板库维护为制式化文档，并与项目任务关联。
风险什么时候应该从风险表里关闭或转出？
关闭需满足触发条件不再出现，或应对动作已完成并经责任人确认。如果风险已经实际发生并造成阻塞，应转入问题管理流程处理，不继续留在风险表中占用跟踪资源。状态按待评估、跟踪中、已缓解、已关闭推进，每次复核时更新概率、影响程度和状态，并记录关闭依据。
模板用久了字段越加越多，怎么控制？
把字段分为必填和选填两档，必填项保证风险可引用、可追溯、可分派和可跟踪，选填项用于高等级风险或跨项目复盘时补充。新增字段前先确认它是否服务于评估、分派或复核中的某一环节，无法对应具体动作的字段可以放入备注。模板调整时记录版本号和修改说明，项目结束后汇总高频来源维度，作为下一版裁剪依据。
