项目风险清单
先当反对者，再把风险变成可跟踪的表
你是被请来挑刺的项目审计，默认这个项目会延期。项目信息：[目标、deadline、人力、依赖方]。输出一张风险表，列为：风险 / 触发信号 / 影响（时间、成本、质量）/ 概率 / 我方能做的缓解动作 / 责任人。要求：1）至少 8 条，覆盖人力、外部依赖、需求变更、技术不确定性；2）按概率×影响排序；3）只写现在还能干预的，已发生的另列；4）缓解动作必须可执行，不要写「加强沟通」。
使用建议
每周只更新「触发信号」那一列，这张表才不会写完就被彻底忘掉。
适合什么场景
- 立项或排期评审前，需要把「会不会延期」变成一张能每周更新的表，而不是会上口头担心。
- 项目已经出现延期迹象，需要把还能干预的和已经发生的分开，避免混在一起讨论。
不适合的场景
- 项目已经取消或进入收尾——风险管理的成本高于收益，这时该做复盘而不是风险表。
- 团队还在探索方向、高度不确定——固定的风险表会压制必要的试错。
示例
输入
目标：11 月底上线企业版 SSO。deadline 11 月 30 日。人力：后端 2 人，其中 1 人 11 月中休假；前端 1 人。依赖：IAM 团队提供接口，法务审 DPA。
你会得到
至少 8 条，覆盖人力、外部依赖、需求变更和技术不确定性，按概率乘影响排序。每条写清触发信号（如 IAM 接口联调失败率超过 10%）、对时间成本质量的影响、缓解动作和责任人；缓解动作要具体到「10 月 30 日前拿到 IAM 沙箱」。已经发生的单列一节，比如 IAM 接口文档晚了一周。
常见误用
- 写「可能延期」「资源不足」这种通用条目——没有触发信号，谁也不知道什么时候该动手。
- 只列风险，不写责任人和缓解动作——表就变成焦虑清单，开会念一遍就结束。
可以这样改
- 加「每条给一个下周就能观察到的量化触发信号」，风险表才真的能每周更新。
- 加「如果只能保 3 条，保哪 3 条、放弃哪条」，适合资源不够时做取舍。