Rủi ro vs Issue: RAID log cứu dự án

Có một artifact phân biệt giữa dự án sống sót và dự án không - đó là risk log. Lý do rất đơn giản: rủi ro nào được lộ ra giấy thì sẽ được giảm thiểu, còn rủi ro nằm trong đầu ai đó thì sẽ bị bỏ quên. Chương này giới thiệu format RAID log, nhịp tuần để giữ nó luôn trung thực, và một template bạn có thể đem vào repo ngay hôm nay.

Khi nào risk log thật sự bắt đầu mang lại giá trị?

Có ba dấu hiệu chính.

Dự án dài hơn 4 tuần. Dưới mức đó, bạn vẫn có thể giữ toàn bộ rủi ro trong đầu. Vượt qua đó, trí nhớ bắt đầu suy giảm và một số rủi ro sẽ rơi rụng trong im lặng.

Dự án phụ thuộc vào bên ngoài. Vendor, các team khác, review pháp lý, review bảo mật, handover sang ops - mỗi đầu mối là một nguồn rủi ro mà bạn không kiểm soát. Cái log là cách duy nhất để nhìn thấy hết tất cả cùng lúc.

Dự án có deadline cứng từ bên ngoài. Một ngày ra mắt cố định nghĩa là rủi ro phải có kế hoạch dự phòng, chứ không chỉ giảm thiểu kiểu best-effort. Cái log buộc cả team phải ngồi xuống thảo luận về phương án dự phòng.

Nếu không dấu hiệu nào ở trên đúng (ví dụ một tool nội bộ làm trong 1 tuần và bạn kiểm soát đầu cuối), thì tổng kết bằng trí nhớ là đủ. Phần lớn dự án không-nhỏ thường chạm vào ít nhất hai trong ba dấu hiệu trên.

Cái giá của việc không có risk log là gì?

Có ba kiểu lỗi thường gặp.

Bị bất ngờ bởi những vấn đề lẽ ra phải thấy trước. Mỗi postmortem của một dự án thất bại đều có câu "đáng lẽ phải nhìn thấy chuyện này từ trước". Risk log chính là artifact giúp bạn nhìn thấy trước và viết ra ở chỗ ai đó có thể hành động.

Giảm thiểu được làm quá muộn. Ngay cả khi rủi ro được phát hiện, nếu không có log thì việc theo dõi diễn ra không chính thức và phương án giảm thiểu sẽ trượt. Đến lúc có người nói "thật sự phải fix vấn đề vendor đó", thì SDK của vendor đã ship hỏng từ lâu rồi.

Không có dấu vết giấy tờ ở retrospective. Khi dự án trễ ngày, lãnh đạo sẽ hỏi "lẽ ra có thể làm gì khác?". Nếu có risk log, bạn có bằng chứng. Nếu không, mọi postmortem sẽ biến thành cuộc tranh luận về việc lẽ ra ai phải biết trước.

RAID log tối thiểu trông thế nào?

Với một team 5 người, chỉ cần một bảng markdown duy nhất cho mỗi dự án:

# RAID Log Dự án — {{ Tên dự án }}

Cập nhật cuối: 2026-06-03 bởi {{ Tên PM }}

## Rủi ro (có thể xảy ra)

| ID | Mô tả | XS | TĐ | Điểm | Owner | Giảm thiểu | Trạng thái |
|----|-------|----|----|------|-------|------------|------------|
| R1 | Vendor SDK v3 có thể trượt từ tháng 6 sang tháng 8 | dễ | lớn | 16 | TL | Build adapter trên v2; review 15/6 | Mở |
| R2 | Cửa sổ upgrade Postgres trùng ngày launch | có thể | nặng | 15 | EM | Đàm phán cửa sổ với infra; hạn 10/6 | Mở |
| R3 | Designer nghỉ thai sản tuần launch | chắc chắn | nhẹ | 5 | PM | Ghi handover trước; designer #2 thay | Đã giảm thiểu |

## Giả định (coi là đúng)

| ID | Mô tả | Đã verify | Owner |
|----|-------|-----------|-------|
| A1 | Webhook Stripe retry idempotent phía ta | chưa | TL |
| A2 | Team customer success xử lý support tier-1 sau launch | đã xác nhận | PM |

## Issue (đang xảy ra)

| ID | Mô tả | Mức | Owner | Hành động kế | Mở từ |
|----|-------|-----|-------|--------------|-------|
| I1 | Env staging down từ thứ Ba; chặn QA | cao | EM | Ticket infra #4421 | 2026-06-01 |

## Dependency (ngoài tầm kiểm soát)

| ID | Mô tả | Bên cấp | Hạn | Trạng thái |
|----|-------|---------|-----|------------|
| D1 | Spec API auth service v4 | Team Platform | 2026-06-08 | Đúng tiến độ |
| D2 | Asset thương hiệu cho trang launch | Marketing | 2026-06-12 | Có rủi ro |

Template được giữ ngắn gọn có chủ ý. Quan trọng nhất là kỷ luật viết ra một thứ gì đó, chứ không phải làm cho format hoàn hảo. Mười phút mỗi tuần luôn tốt hơn một cái log bóng bẩy mà chẳng ai cập nhật.

RAID log ở quy mô đa team trông thế nào?

Có ba thay đổi khi dự án vượt qua biên giới của một team:

flowchart TB
    Team1[RAID Team A] --> Combined[RAID cấp dự án<br/>top 5 rủi ro tổng hợp]
    Team2[RAID Team B] --> Combined
    Team3[RAID Team C] --> Combined
    Combined --> Exec[Status lãnh đạo<br/>chỉ top 3]
    Combined --> Review[Review dự án tuần]

Mỗi team sở hữu RAID log riêng của mình; project lead tổng hợp top 5 rủi ro xuyên các team thành một log ở cấp dự án. Chỉ top 3 rủi ro cấp dự án (điểm từ 15 trở lên) mới được đẩy lên status report của lãnh đạo - vì lãnh đạo không thể hành động được trên 30 rủi ro nhỏ cùng lúc. Chương status report sẽ lo phần format tổng hợp này.

Nhịp tuần giữ cho log luôn trung thực ra sao?

Có bốn checkpoint, được sắp vào cùng slot lịch mỗi tuần:

1. Cập nhật từ owner. Mỗi owner rủi ro dành 30 giây để nói về thay đổi trạng thái, tiến độ giảm thiểu, hoặc đơn giản là "vẫn mở, không đổi".
2. Rủi ro mới. Ai cũng có thể nêu một rủi ro mới trong 60 giây. PM chấm điểm ngay tại chỗ.
3. Chuyển cấp. Các rủi ro đã trở thành issue trong tuần sẽ được chuyển cột; những rủi ro đã giảm thiểu thành công sẽ được đánh dấu đóng.
4. Review top 5. Năm rủi ro điểm cao nhất, mỗi cái một phút - phương án giảm thiểu có chạy không, có cần escalate không.

Tổng thời gian: 15 phút. Nếu cuộc họp kéo dài hơn, hoặc là log đã lỗi thời, hoặc là dự án có quá nhiều rủi ro - cả hai đều là tín hiệu cần chú ý.

RAID log có thể tự tạo ra những lỗi nào?

• Log biến thành sách trên kệ. Được tạo ra lúc kickoff rồi không bao giờ cập nhật. Cách phòng: duy trì nhịp tuần và để PM chịu trách nhiệm về tính mới mẻ của log; mỗi rủi ro có ngày "cập nhật cuối"; entry nào cũ hơn 14 ngày sẽ bị flag.
• Rủi ro lẫn với lo lắng. "Tôi lo về vấn đề scale" không phải là một rủi ro; "throughput write của Postgres sẽ vượt 5K/s vào Q3 dựa trên đà tăng trưởng" mới là rủi ro. Dùng kỹ thuật ước lượng để gắn con số cho rủi ro.
• Có giảm thiểu nhưng không có owner. "Nên fix test flaky" mà không gán cho ai cụ thể thì sẽ chẳng có gì xảy ra. Mỗi rủi ro phải có đúng một owner.
• Lạm phát điểm. Mọi rủi ro đều bị đánh "xác suất cao, tác động cao" vì owner muốn được chú ý. Cách phòng: ép phân phối kiểu chuông - trên toàn bộ rủi ro đang mở, chỉ khoảng ~20% nên có điểm từ 15 trở lên.

Khi nào RAID log là quá liều?

Có hai trường hợp.

Task nội bộ kéo dài 2 tuần. Một sprint fix bug hay refactor nhỏ không cần đến log chính thức. Engineer senior chỉ cần nhắc rủi ro trong daily standup là đủ.

Dự án thực sự ổn định. Các công việc bảo trì dài hạn, nơi cùng một vài rủi ro xoay vòng đều đặn (cert hết hạn, cập nhật dependency, dọn test flaky). Hãy ghi chúng vào runbook của team, chứ không phải vào RAID log của dự án.

RAID log chỉ thật sự đáng đầu tư công sức ở mức dự án - khi có scope giới hạn, deadline cứng, và nhiều unknown. Dưới mức đó, các artifact nhẹ hơn vẫn chạy được.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: stakeholder và comms - cách truyền tải các rủi ro được theo dõi ở đây tới những người không tham dự cuộc review hàng tuần. Sau đó, scope và đánh đổi sẽ cho thấy cách phản ứng khi một rủi ro buộc bạn phải đổi scope.