Mở đầu — vì sao bài này quan trọng
Có một câu nói kinh điển trong nghề PM: "Mọi dự án đều có rủi ro. Sự khác biệt giữa team chuyên nghiệp và team nghiệp dư không nằm ở chỗ ai gặp ít rủi ro hơn, mà ở chỗ ai nhìn thấy rủi ro trước khi nó nổ."
Risk Register — tạm dịch là "Sổ đăng ký rủi ro" — chính là công cụ giúp bạn nhìn thấy trước. Nó là một phần nhỏ nhưng cực kỳ quyền lực trong PRD: một bảng liệt kê có hệ thống tất cả những điều có thể đi sai, kèm theo mức độ nghiêm trọng và cách bạn dự định xử lý.
Tại sao bài này quan trọng đến vậy? Vì phần lớn các sự cố lớn khi ship sản phẩm đều không phải là "thiên nga đen" — chúng không phải điều không ai có thể lường trước. Sự thật phũ phàng là: trong 90% các bản post-mortem (báo cáo sau sự cố), bạn sẽ tìm thấy ít nhất một người trong team đã từng nói "tôi lo cái này lắm" nhưng nỗi lo đó không bao giờ được ghi lại, không được gán cho ai, và rồi bị lãng quên cho đến khi nó thành sự thật.
Risk Register biến những nỗi lo mơ hồ "trong đầu mọi người" thành một tài sản có cấu trúc: ai cũng nhìn thấy, ai cũng có thể tranh luận, và quan trọng nhất — mỗi rủi ro đều có một người chịu trách nhiệm theo dõi. Trong bài này, tôi sẽ hướng dẫn bạn xây dựng một Risk Register thực sự hữu ích, chứ không phải loại bảng "viết cho có" mà chẳng ai đọc lại sau ngày approve PRD.
Khái niệm cốt lõi
Risk Register là gì?
Risk Register là danh sách các rủi ro đã được nhận diện, kèm theo đánh giá và biện pháp giảm thiểu (mitigation). Nó trả lời ba câu hỏi:
- Điều gì có thể đi sai? (Risk)
- Nó tệ đến mức nào và khả năng xảy ra ra sao? (Impact × Likelihood)
- Chúng ta sẽ làm gì với nó, và ai phụ trách? (Mitigation + Owner)
Định dạng chuẩn của một dòng rủi ro
Đây là cấu trúc bảng tôi khuyên dùng cho mọi PRD:
| # | Risk | Likelihood | Impact | Score | Mitigation | Owner | Status |
|---|---|---|---|---|---|---|---|
| R1 | Đối tác thanh toán VNPay không kịp tích hợp trước ngày ship | Medium | High | 6 | Chuẩn bị phương án dùng MoMo làm phương thức mặc định nếu VNPay trễ; chốt deadline tích hợp trước launch 2 tuần | Trang (PM) | Open |
- # (ID): Mỗi rủi ro có một mã định danh (R1, R2...). Nghe có vẻ thừa, nhưng khi họp review mà ai đó nói "chúng ta cần bàn lại R3", nó nhanh và rõ hơn nhiều so với đọc cả đoạn mô tả.
- Risk (Mô tả rủi ro): Viết theo công thức "Nếu [điều kiện] thì [hậu quả]". Tránh viết cụt lủn kiểu "API chậm" — hãy viết "Nếu API gợi ý sản phẩm phản hồi chậm hơn 800ms thì tỷ lệ thoát trang checkout sẽ tăng, ảnh hưởng doanh thu".
- Likelihood (Khả năng xảy ra): Thường dùng thang Low / Medium / High, hoặc 1–3 / 1–5. Đừng cầu kỳ tính xác suất phần trăm — định tính là đủ.
- Impact (Mức độ ảnh hưởng): Cũng Low / Medium / High. Hỏi: nếu rủi ro này thành sự thật, nó ảnh hưởng tới doanh thu, người dùng, uy tín, hay tiến độ ở mức nào?
- Score (Điểm ưu tiên): Nhân Likelihood × Impact (ví dụ quy ước Low=1, Medium=2, High=3 thì Medium × High = 6). Điểm này dùng để sắp xếp — rủi ro điểm cao nằm trên cùng, được chú ý trước.
- Mitigation (Biện pháp giảm thiểu): Đây là cột quan trọng nhất và cũng là cột hay bị làm hời hợt nhất. Phải là hành động cụ thể, không phải lời an ủi. "Chúng ta sẽ cẩn thận" không phải mitigation. "Thêm circuit breaker tự ngắt khi API lỗi quá 5% trong 1 phút" mới là mitigation.
- Owner (Người phụ trách): Một cái tên cụ thể. Không phải "team" hay "phòng kỹ thuật". Một rủi ro không có owner là một rủi ro không ai theo dõi.
- Status (Trạng thái): Open / Mitigated / Accepted / Closed. Cho biết rủi ro đang được xử lý đến đâu.
Bốn cách phản ứng với rủi ro
Khi đã liệt kê được rủi ro, bạn có bốn lựa chọn ứng xử — nhớ khung này sẽ giúp bạn quyết định mitigation cho từng dòng:
- Mitigate (Giảm thiểu): Làm gì đó để giảm khả năng hoặc giảm tác hại. Đây là phản ứng phổ biến nhất.
- Avoid (Tránh né): Thay đổi thiết kế để rủi ro không còn tồn tại. Ví dụ: thay vì xử lý dữ liệu thẻ tín dụng trên server của mình (rủi ro bảo mật cao), dùng hẳn cổng thanh toán bên thứ ba để mình không bao giờ chạm vào dữ liệu nhạy cảm.
- Transfer (Chuyển giao): Đẩy rủi ro sang một bên khác, thường qua hợp đồng hoặc bảo hiểm hoặc SLA với nhà cung cấp.
- Accept (Chấp nhận): Với rủi ro nhỏ hoặc chi phí xử lý quá lớn, ta ghi nhận và chấp nhận sống chung. Điều quan trọng: chấp nhận một cách có ý thức và được ghi lại, khác hoàn toàn với việc bỏ qua vì không nhìn thấy.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT ra mắt tính năng "Mua trước trả sau"
Một sàn thương mại điện tử tại Việt Nam (giả định tên Chợ Số) chuẩn bị ra mắt tính năng "Mua trước trả sau" (BNPL) hợp tác với một công ty fintech. PM phụ trách — chị Lan — đưa vào PRD một Risk Register gồm năm dòng. Hai dòng đáng chú ý:
- R2 — Rủi ro pháp lý: "Nếu Ngân hàng Nhà nước siết quy định về tín dụng tiêu dùng giữa chừng dự án thì tính năng có thể phải tạm ngừng." Likelihood: Medium, Impact: High, Score 6. Mitigation: "Làm việc với phòng Pháp chế để rà soát khung pháp lý hiện hành trước khi viết code; thiết kế feature flag để có thể tắt tính năng trong 1 giờ nếu cần." Owner: Lan + trưởng phòng Pháp chế.
- R4 — Rủi ro nợ xấu: "Nếu tỷ lệ người dùng không trả nợ vượt 8% thì đối tác fintech có thể rút khỏi hợp đồng." Likelihood: Low, Impact: High, Score 3. Mitigation: "Giới hạn hạn mức ban đầu ở 2 triệu đồng cho người dùng mới; chạy thử với 5% người dùng trong 1 tháng trước khi mở rộng."
Bài học: Giá trị lớn nhất của Risk Register không phải là ngăn rủi ro xảy ra — nhiều rủi ro nằm ngoài tầm kiểm soát của bạn. Giá trị nằm ở chỗ khi nó xảy ra, bạn đã có sẵn kế hoạch và một cái van để xả áp.
Ví dụ 2 — Startup gọi xe và rủi ro bị bỏ sót vì "không ai dám nói"
Một startup gọi xe ở Đông Nam Á (giả định tên GoNow) làm tính năng tài xế nhận chuyến tự động dựa trên thuật toán. Trong buổi review PRD, mọi người đều gật gù. Risk Register chỉ có ba dòng, toàn rủi ro kỹ thuật quen thuộc: server quá tải, GPS sai lệch, app crash.
Nhưng một kỹ sư trẻ trong góc phòng có linh cảm thuật toán sẽ ưu tiên tài xế ở khu trung tâm và "bỏ rơi" tài xế ngoại thành, gây bất mãn. Cậu không nói ra vì nghĩ "chắc các sếp đã nghĩ tới rồi". Risk Register không có dòng nào về công bằng phân phối chuyến.
Ba tháng sau khi ra mắt, đúng là tài xế ngoại thành biểu tình phản đối vì thu nhập giảm. Một cuộc khủng hoảng truyền thông nổ ra mà lẽ ra hoàn toàn có thể lường trước.
Sau sự cố, GoNow thay đổi quy trình: trong mọi buổi review Risk Register, PM bắt buộc đặt câu hỏi "Ai trong nhóm người dùng/đối tác của chúng ta sẽ thiệt vì tính năng này?" và yêu cầu từng người trong phòng nêu ít nhất một rủi ro họ lo ngại, kể cả người ít nói nhất.
Bài học: Risk Register chỉ tốt bằng quá trình thu thập rủi ro. Một bảng đẹp do mình PM tự nghĩ ra trong 15 phút sẽ luôn thiếu những góc nhìn quan trọng. Hãy biến việc liệt kê rủi ro thành hoạt động tập thể, và chủ động hỏi những người dễ bị bỏ qua tiếng nói.
Ví dụ 3 — Tính năng AI tóm tắt và rủi ro được "chấp nhận có ý thức"
Một công ty SaaS làm phần mềm quản lý công việc (giả định tên TaskFlow) thêm tính năng AI tóm tắt nội dung cuộc họp. PM ghi vào Risk Register:
- R1 — Hallucination (AI bịa thông tin): "Nếu AI tóm tắt sai hoặc bịa ra chi tiết không có thật thì người dùng có thể ra quyết định dựa trên thông tin sai." Likelihood: High, Impact: High, Score 9. Mitigation: "Luôn hiển thị disclaimer 'Bản tóm tắt do AI tạo, vui lòng kiểm tra lại'; cho phép người dùng nhấp vào từng câu để xem đoạn gốc tương ứng." Owner: Minh (PM).
- R3 — Chi phí token vượt ngân sách: "Nếu lượng dùng cao hơn dự kiến 3 lần thì chi phí API có thể vượt ngân sách quý." Likelihood: Medium, Impact: Medium, Score 4. Status: Accepted. Lý do ghi rõ: "Chấp nhận trong giai đoạn beta để học hành vi người dùng; sẽ thêm giới hạn theo gói cước ở phiên bản chính thức."
Bài học: Một rủi ro được ghi là "Accepted" với lý do rõ ràng sẽ bảo vệ bạn và team khi nó xảy ra. Nó chứng minh đây là quyết định có chủ đích, không phải sơ suất — và đó là sự khác biệt giữa một PM được tin tưởng và một PM bị đổ lỗi.
Hướng dẫn từng bước
Đây là quy trình tôi khuyên bạn áp dụng để xây Risk Register cho PRD tiếp theo:
Bước 1 — Brainstorm rủi ro theo từng nhóm. Đừng ngồi nghĩ rủi ro một cách ngẫu nhiên. Hãy đi qua các nhóm có hệ thống để không bỏ sót: rủi ro kỹ thuật (technical), rủi ro tiến độ (timeline), rủi ro phụ thuộc bên ngoài (dependency), rủi ro pháp lý/tuân thủ (legal), rủi ro vận hành (operational), rủi ro với người dùng/đối tác (user trust), và rủi ro kinh doanh (business). Mỗi nhóm tự hỏi "điều gì có thể đi sai ở đây?"
Bước 2 — Thu thập từ nhiều người. Gửi danh sách nháp cho engineer, designer, người làm vận hành, support. Câu hỏi mạnh nhất bạn có thể đặt cho engineer là: "Phần nào của thiết kế này khiến bạn lo lắng nhất khi phải code?" Họ luôn biết những góc khuất mà PM không thấy.
Bước 3 — Đánh giá Likelihood và Impact. Với mỗi rủi ro, gán Low/Medium/High cho cả hai chiều. Đừng tranh cãi quá lâu về việc nó là Medium hay High — mục tiêu là sắp thứ tự ưu tiên tương đối, không phải đo lường chính xác.
Bước 4 — Sắp xếp theo Score và lọc. Tính điểm và sắp giảm dần. Tập trung viết mitigation kỹ cho nhóm điểm cao (6–9). Nhóm điểm thấp (1–3) có thể chỉ cần ghi "Accepted" hoặc một câu mitigation ngắn. Đừng cố viết mitigation hoành tráng cho mọi dòng — sẽ loãng.
Bước 5 — Viết mitigation cụ thể và gán owner. Với mỗi rủi ro ưu tiên cao, viết hành động kiểm chứng được và một cái tên người. Nếu bạn không nghĩ ra owner, đó là dấu hiệu rủi ro này chưa thực sự "thuộc về" ai — cần làm rõ.
Bước 6 — Đánh dấu trạng thái và đưa vào review. Trong buổi review PRD (bài 47), dành riêng vài phút đi qua các rủi ro điểm cao. Đây là lúc lãnh đạo cấp cao đồng ý "chấp nhận" những rủi ro nhất định một cách chính thức.
Bước 7 — Coi nó là tài liệu sống. Đây là bước hầu hết mọi người bỏ qua. Risk Register không phải viết một lần rồi quên. Trong các buổi cập nhật tiến độ, hãy mở lại: rủi ro nào đã được xử lý (chuyển Mitigated)? Rủi ro mới nào xuất hiện? Một bảng được cập nhật là một bảng còn sống.
Lỗi thường gặp & mẹo
Lỗi 1 — Mitigation chung chung vô nghĩa. "Sẽ theo dõi sát", "sẽ cẩn thận", "đảm bảo chất lượng" — đây không phải mitigation, đây là khẩu hiệu. Mẹo: mỗi mitigation phải trả lời được "ai làm gì, khi nào, và làm sao biết nó đã xong?"
Lỗi 2 — Chỉ liệt kê rủi ro kỹ thuật. PM hay quên rủi ro phi kỹ thuật: pháp lý, niềm tin người dùng, vận hành, truyền thông. Như ví dụ GoNow, rủi ro chết người nhất thường nằm ở khía cạnh con người, không phải code. Mẹo: dùng checklist các nhóm rủi ro ở Bước 1 mỗi lần.
Lỗi 3 — Không có owner hoặc owner là "team". Rủi ro không có người sở hữu là rủi ro không được theo dõi. Mẹo: nếu một rủi ro mãi không có owner, hãy hỏi thẳng trong buổi review "ai sẵn sàng theo dõi cái này?"
Lỗi 4 — Bảng viết xong rồi chết. Risk Register bị đóng băng ngay khi PRD được approve. Mẹo: đưa "rà soát Risk Register" thành một mục cố định trong các cuộc họp tiến độ định kỳ.
Lỗi 5 — Liệt kê quá nhiều, làm loãng. Một bảng 40 dòng khiến không ai đọc và làm mờ những rủi ro thực sự quan trọng. Mẹo: giữ 5–10 rủi ro trọng yếu nhất. Những thứ nhỏ nhặt gom vào "Accepted" hoặc bỏ hẳn.
Lỗi 6 — Lẫn lộn rủi ro với câu hỏi mở. "Chúng ta nên dùng màu nào cho nút?" là Open Question, không phải risk. Mẹo: nếu bạn không mô tả được hậu quả tiêu cực của nó, có lẽ nó không phải rủi ro.
Mẹo nâng cao — quy ước "ngưỡng kích hoạt" (trigger): Với những rủi ro quan trọng, ghi thêm điều kiện cụ thể để biết khi nào cần hành động. Ví dụ: "Nếu tỷ lệ lỗi vượt 2% trong 10 phút → kích hoạt mitigation tắt feature flag." Điều này biến mitigation thụ động thành kế hoạch chủ động, ai trực cũng biết phải làm gì.
Bài tập thực hành
Hãy chọn một tính năng bạn đang làm hoặc một tính năng giả định (ví dụ: "thêm đăng nhập bằng sinh trắc học cho app ngân hàng"). Thực hiện:
- Brainstorm tối thiểu 8 rủi ro, mỗi rủi ro thuộc một nhóm khác nhau (kỹ thuật, tiến độ, phụ thuộc, pháp lý, vận hành, niềm tin người dùng, kinh doanh). Viết mỗi rủi ro theo công thức "Nếu... thì...".
- Lập bảng đầy đủ với các cột: #, Risk, Likelihood, Impact, Score, Mitigation, Owner, Status. Gán Likelihood và Impact (Low/Medium/High) và tính điểm.
- Sắp xếp theo Score giảm dần. Với 3 rủi ro điểm cao nhất, viết mitigation thật cụ thể — phải nêu được hành động, người làm, và cách biết đã xong.
- Đánh dấu ít nhất một rủi ro là "Accepted" và viết một câu giải thích vì sao bạn chấp nhận nó.
- Tự kiểm tra: đọc lại cột Mitigation. Có dòng nào chung chung kiểu "sẽ cẩn thận" không? Nếu có, viết lại cho cụ thể. Có dòng nào owner là "team" không? Nếu có, gán một cái tên.
Tóm tắt
- Risk Register là danh sách có cấu trúc các rủi ro đã nhận diện, kèm đánh giá mức độ và biện pháp giảm thiểu — biến những nỗi lo mơ hồ thành tài sản theo dõi được.
- Định dạng chuẩn gồm: #, Risk, Likelihood, Impact, Score, Mitigation, Owner, Status. Score = Likelihood × Impact dùng để sắp ưu tiên.
- Cột Mitigation và Owner là hai cột quyết định giá trị thực: mitigation phải cụ thể, kiểm chứng được; owner phải là một con người, không phải "team".
- Bốn cách ứng xử với rủi ro: Mitigate, Avoid, Transfer, Accept. Một rủi ro được "Accept có ý thức" và ghi lại sẽ bảo vệ team khi nó xảy ra.
- Đừng chỉ liệt kê rủi ro kỹ thuật — những sự cố lớn nhất thường đến từ khía cạnh con người, pháp lý và niềm tin người dùng.
- Thu thập rủi ro là hoạt động tập thể; chủ động hỏi cả những người ít nói nhất trong team.
- Risk Register là tài liệu sống — rà soát và cập nhật trong suốt vòng đời dự án, không phải viết một lần rồi bỏ quên.