RAID日志怎么做？把风险、假设、问题和依赖分开跟进

RAID日志把项目里的四类事项放在一起跟进：风险是可能发生的不利事件，假设是计划暂时采用但尚未验证的条件，问题是已经存在的障碍，依赖是后续工作需要的前置成果。它的价值不是多做一张表，而是让团队说清“现在知道什么、还在等什么、下一步由谁确认”。

例如，“人员资料应该齐全”“资料还有缺项”“等IT交付资料”“可能赶不上联调”有关联，却不是同一种状态。用Boardmix 项目看板整理时，可以让各条记录保留自己的编号，再把它们与共同的处理任务连接，避免同一件事在四张表里各催一次。

RAID四类记录怎样区分

RAID有不同的缩写用法；有的团队把A用作Actions（行动），把D用作Decisions（决策）。下面采用Risks、Assumptions、Issues、Dependencies，即风险、假设、问题、依赖。团队开始使用前应先在日志顶部写明口径，行动和决策另设关联记录，不能把同一列交给不同成员各自解释。

风险与问题的分界在于事件是否已经发生；依赖则不是“坏消息”的同义词。一个按时交付、质量合格的前置成果仍是依赖，只是没有出现阻塞。假设也不是默认正确的事实：它允许团队先往前规划，同时把需要验证的条件公开。

项目只有少量明确任务时，用普通任务表就够了。需要跨角色交付、采用较多未确认条件，或者周会上反复争论“这是风险还是已经出事”时，再引入RAID。可以参考Atlassian对RAID日志的说明了解这一框架的常见用法，但表格应根据实际项目精简。

一个设备预约试点，怎样写出四类不同记录

下面是构造案例：团队准备让20名员工试用内部设备预约系统，其中一项验收是按部门检查预约权限。计划第3个工作日中午拿到完整人员资料，再开始这部分联调。工作日编号仅用于说明前后关系，正式项目应换成明确日期和时点。

第1个工作日，团队暂时认为已有人员资料包含部门信息，于是建立假设A-01；同时与IT约定交付，建立依赖D-01。第2个工作日查看20名试点人员的资料，发现4人缺少部门字段。这时要保留原假设的验证结果，并登记当前问题及未来可能受到的影响。

四条记录描述同一组资料，但各自回答不同问题。A-01解释原计划为什么这样安排，D-01明确双方交付约定，I-01负责当前缺项的处理，R-01提醒团队未来联调可能受影响。实际补齐资料的动作只需在I-01关联的任务中维护一次，其他记录引用它的进展。

“先测其余16人”也不等于整体验收通过。是否允许分段联调、它能覆盖哪些用例、剩余4人何时补测，需要由相关负责人确认。RAID记录帮助暴露这个决策，不代替决策本身。

假设失效或风险发生时，保留原记录再关联后续

不要把A-01的类型直接改成I，然后删除原来的判断。这样虽然少了一行，下次复盘却无法知道计划当时依赖了什么、何时发现不成立。更清楚的做法是保留A-01，更新为“已验证：不成立”，写上证据日期，再链接I-01。

1. 先更新事实。记录第2个工作日的检查结果：20人中4人缺部门字段。证据中采用必要的脱敏标识，不把员工个人资料直接公开到共享画布。
2. 区分当前障碍与未来影响。I-01处理已经确认的缺项；R-01跟踪它是否导致第3个工作日的联调安排变化。两者用关联编号连接。
3. 共享一项实际行动。“核对部门并更新资料”写在一个处理任务里，指定负责人和检查时间。其他条目引用该任务，不复制成四份待办。
4. 到了约定时间再更新状态。资料提前补齐并验收，D-01可记交付完成，I-01记已解决，R-01按实际影响记解除。若联调确已因此延后，R-01记已发生，并关联延误处理记录。

风险预警信号出现，不一定表示风险事件已经发生。比如“负责人尚未回复”可以触发升级或备选安排，但只有达到原记录中的事件条件，才把风险记为已发生。详细的概率、影响和应对设计，可以另在项目风险登记册中维护，RAID只保留需要在周会上共同跟进的摘要和链接。

并非所有假设被否定都会形成问题。如果团队在需要该条件之前就发现差异，并及时改变方案，记录验证结果和决策即可。也不要为每条依赖都自动生成一条风险；只有存在值得跟进的不确定性和具体影响时，才另外登记。

日志字段要少，但必须能支持下一次跟进

四类条目可以共享一组基础字段：编号、类型、描述、负责人、当前状态、下次检查时间、下一动作、证据位置和关联编号。不要只写“处理中”，还应让未参会的人看出正在处理什么、何时会有新结果。

I-01｜人员部门字段缺项
事实：第2个工作日核对20人资料，4人缺部门字段。
影响：这4人的部门权限用例暂时无法验证。
负责人：人事数据负责人；接收方：IT与开发。
下一动作：核对4人的部门归属并交给IT更新。
检查时间：第3个工作日中午交付前的约定检查点。
解决条件：字段补齐，开发按已确认口径复核可用。
关联：A-01、D-01、R-01；证据：受控位置中的字段检查记录。

“负责人”是负责推进记录的人，不一定是完成所有动作的人。依赖尤其需要两端：提供方说“已发送”，接收方却发现不能使用，交付仍未完成。约定接收人和完成条件，往往比给依赖涂上红色更有帮助。

状态也不必强行统一。假设适合“待验证、成立、不成立”；问题适合“待处理、处理中、待验证、已解决”；依赖适合“待交付、已交付待验收、已接受”；风险则按团队的风险管理口径记录监控、接受、发生或解除。状态名称可以简化，含义必须清楚。

周会按变化和决策复核，不逐行念完整日志

会前请负责人更新有变化的条目，会议集中处理四组内容：已经发生的新问题、即将到达验证时点的假设、接近需要日期的依赖，以及信号发生变化的风险。已关闭且没有新情况的记录可以留在历史区。

每条活跃记录只需讨论三个问题：事实比上次有什么变化，下一步由谁在何时完成，是否需要超出当前负责人的决策权限。对I-01，如果大家只是重复“还缺4人”，却没有核对者和反馈时点，周会没有推动它前进。

需要升级时，带上具体请求，例如“请确认能否先开展16人的联调，以及剩余4人的补测安排”，而不是只向上汇报一个红灯。会议结束后，把决定写回相关编号；若接受延期，应同步项目计划和受影响人员，不能仅把RAID颜色改绿。

日志数量不等于项目健康度。新增记录多，可能是团队更早暴露了未知；关闭记录多，也可能只是把问题移走。更有用的是检查关键条目是否有负责人、是否按期验证、下一步是否真正改变了事实。

在Boardmix中把四类条目与共同动作连起来

先建立四个区域，分别标R、A、I、D，再把同一项目的记录作为卡片放进去。卡片正面只保留编号、关键描述、负责人和检查时间；详细证据放在符合团队访问要求的位置，用说明或链接定位。

设备预约案例可以把I-01放在中心，把A-01、D-01、R-01围绕它布置。连线上写明含义：A-01的核验发现I-01，I-01阻碍D-01完整交付，I-01未解决可能引发R-01。三条关系表达的是不同事实，不需要画成必须顺序经过四个状态的流程。

在旁边放一个共同动作区：核对部门归属、更新资料、开发复核。各条记录通过编号引用同一动作，负责人员在会议中根据实际进展更新。这样既能讨论关系，也不会把资料核对误画成软件已经自动执行的检查。

最后把已完成记录移入历史区，保留原编号、结果和关联。下次有人问“为什么联调时间改了”，可以沿着A-01的验证、I-01的处理和相关决定找到答案，而不必重新翻找每个人的聊天记录。