经得起真实项目考验的 RAID 日志
RAID 日志是你拥有的最廉价的项目控制工具之一，也是最被忽视的工具之一。这个缩写代表风险（Risks）、假设（Assumptions）、问题（Issues）和依赖（Dependencies）。用得好，它就是团队记录下列内容的唯一场所：什么可能损害项目、你在凭什么信念行事、已经出了什么差错、以及你在等别人交付什么。用得差，它不过是有人在启动会上做的一张电子表格，此后再没人打开过。
在 2022 年初，通胀攀升、材料与劳动力短缺、返岗计划一周一变，活的 RAID 日志与死的 RAID 日志之间的差距，就是一支能预见麻烦的团队与一支措手不及的团队之间的差距。下面这份清单，你这周就能用起来。
把四个类别分清楚
最常见的失误是把各列混在一起。有人把风险记成问题，或把依赖塞进假设里，于是日志就失去了锋芒。请保持区分清晰：
风险。 可能发生、一旦发生就会造成损害的事，目前尚未发生。每一项都需要一名负责人、一个发生概率、一个影响程度，以及一项应对措施（规避、降低、转移或接受）。
假设。 你在没有证据的情况下当作真的来对待的事，因为计划依赖于它。「预制件供应商仍能赶上三月的档期」就是一个假设——在 2022 年，还是个相当冒进的假设。一旦假设站不住脚，它就会变成风险或问题。
问题。 已经出了差错、现在就需要行动的事。问题是变成了现实的风险，或是没人预见到的难题。它需要一名负责人和一个目标解决日期。
依赖。 在你能继续推进之前，需要从另一个团队、供应商或审批机构那里获得的东西。记清楚谁欠谁什么、何时交付。
搭建清单
为每一条记录指定唯一一名具名负责人——是某个人，而非一个团队。共同负责等于无人负责。
在每条记录提出时以及每次更新时都标注日期，这样你才能看出哪些内容正在过时。
用全项目统一的同一套简单标尺，按概率和影响对风险评级（一个 1 到 5 的网格就足够了）。
写下应对措施，而不只是评级。「高风险」却没有方案，只是单元格里的一份焦虑。
加一列状态，取值要少：未处理、进行中、已关闭、已上报。忍住别发明出十二种来。
每个项目只保留一份日志，放在一个人人都能访问的地方。三个收件箱里的三份副本，等于零份可靠副本。
让它保持鲜活
RAID 日志要么是一份活文档，要么什么都不是。让它持续呼吸的习惯，是一场简短而周期性的复盘——在每周项目例会开头花十分钟就够了。先过一遍未处理的问题，再看头部风险，然后看任何正在滑期的依赖。把已完成的关掉，让清单保持诚实；把任何已悄然变得脆弱的假设升级为风险，赶在它变成问题之前。
还有两个习惯，把能长久的日志区分开来。其一，按时钟而非凭感觉上报：一开始就约定，任何超过目标日期仍未关闭的问题，或任何没有应对措施的高风险，自动上报指导委员会。其二，写出陌生人也能看懂的记录。六个月后读这份日志的人——也许是在审计中，也许是在你离开之后——应该能在你不在场的情况下读懂来龙去脉。经得起真实项目考验的 RAID 日志，不是最花哨的那个，而是团队信任到愿意在糟糕的周二也去更新它的那个。
如果你希望有人帮你建立能在真实压力下站得住脚的项目控制机制，XNM 的项目集与项目交付咨询服务 可以帮你搭建并将其落地扎根。