Vì sao hỏi "có rủi ro gì không" không ra câu trả lời thật
Trong một cuộc họp kế hoạch, câu hỏi "có rủi ro gì không?" thường nhận được những câu trả lời an toàn: "có thể trễ", "thiếu người". Lý do không phải vì đội không biết rủi ro, mà vì nói ra một rủi ro cụ thể nghe như nghi ngờ đồng nghiệp hoặc nghi ngờ kế hoạch sếp đã duyệt.
Pre-mortem đổi câu hỏi: "Hôm nay là ba tháng sau ngày ra mắt. Lần ra mắt đã thất bại. Hãy viết ra vì sao." Khi thất bại được coi là đã xảy ra, việc tìm lý do không còn là phản đối, mà là giải một bài toán. Người im lặng nhất phòng thường có câu trả lời đúng nhất.
Hướng dẫn chi tiết: Chạy buổi pre-mortem. Kỹ năng liên quan: Pre-mortem & Delivery Risk.
Buổi pre-mortem của Sạp Số
Linh mời 9 người: Quân, Hà, hai kỹ sư, designer, Thảo, Tuấn, Phong, và một nhân viên thị trường hay đi tiệm. Buổi họp 75 phút:
| Phút | Bước | Ở Sạp Số |
|---|---|---|
| 0–10 | Đặt bối cảnh | Linh đọc mục tiêu, phạm vi, câu giả định thất bại |
| 10–20 | Viết riêng, im lặng | 9 người viết được 61 lý do |
| 20–40 | Đọc và gom nhóm | Gom thành 14 nhóm |
| 40–50 | Chấm điểm | Khả năng × tác động, mỗi trục 1–3 |
| 50–70 | Biện pháp, tripwire, chủ | Cho 5 nhóm điểm cao nhất |
| 70–75 | Chốt | Đọc lại chủ và ngày xem lại |
Bảy kiểu thất bại
Dùng bảy loại dưới đây làm khung khi gom nhóm. Loại nào trống sau phần viết riêng là điểm mù cần hỏi thêm, không phải dấu hiệu an toàn.
| Loại | Câu hỏi | Rủi ro tìm được ở Sạp Số |
|---|---|---|
| Giá trị | Người dùng có thật sự cần không? | Chủ tiệm không tin gợi ý, vẫn chọn tay từng món |
| Khả dụng | Họ có hiểu và dùng được không? | Chủ tiệm lớn tuổi không nhận ra giỏ đã được điền sẵn, bấm đặt mà không xem |
| Khả thi | Đội có xây được trong thời gian này không? | Dữ liệu lịch sử của tiệm mới quá ít để gợi ý |
| Kinh doanh | Công ty có lời, có vận hành nổi không? | Đơn lớn hơn nhưng tăng tỉ lệ trả hàng, phí bị trừ lại |
| Tiếp cận | Người dùng có biết và có lý do thử không? | Thông báo trong app bị bỏ qua; nhân viên thị trường không giới thiệu |
| Phụ thuộc | Đội, đối tác nào có thể làm trễ? | Nhà phân phối không xử lý kịp đơn dồn sáng thứ Hai |
| Chất lượng | Nó có hỏng ở quy mô thật, thiết bị thật không? | Ứng dụng chậm trên máy Android cũ khi tải giỏ 40 món |
Chấm điểm và chọn
Dùng thang 1–3 cho cả khả năng và tác động. Thang 1–10 khiến cả phòng tranh luận giữa 6 và 7 thay vì bàn biện pháp. Nhóm có điểm tích 6 hoặc 9 là nhóm phải xử lý.
| Rủi ro | Khả năng | Tác động | Điểm |
|---|---|---|---|
| Nhà phân phối không kịp xử lý đơn sáng thứ Hai | 3 | 3 | 9 |
| Chủ tiệm bấm đặt mà không xem giỏ, đặt nhầm | 2 | 3 | 6 |
| Chậm trên máy cũ | 2 | 3 | 6 |
| Không ai biết tính năng | 3 | 2 | 6 |
| Tiệm mới thiếu dữ liệu | 3 | 1 | 3 |
Biện pháp và tripwire là hai thứ khác nhau
Đây là chỗ nhiều buổi pre-mortem dừng quá sớm. Biện pháp là việc làm trước để giảm khả năng hoặc tác động. Tripwire là tín hiệu trong lúc chạy báo rằng rủi ro đang thành sự thật, kèm hành động đã quyết sẵn.
Một tripwire tốt có ba phần: chỉ số hoặc sự kiện, ngưỡng, và hành động đã quyết trước. Quyết hành động trước là điểm mấu chốt: khi tripwire bật, đội không họp để bàn, mà làm.
| Rủi ro | Biện pháp (trước) | Tripwire (trong lúc chạy) | Chủ |
|---|---|---|---|
| Nhà phân phối quá tải | Báo trước lượng đơn dự kiến; có người trực; rollout không bắt đầu vào thứ Hai | Đơn chờ xác nhận quá 2 giờ vượt 5% -> dừng nấc rollout, gọi nhà phân phối | Tuấn |
| Đặt nhầm do không xem giỏ | Màn xác nhận hiện tổng tiền to, rõ; cho huỷ trong 15 phút | Tỉ lệ huỷ trong 15 phút vượt 4% -> tắt nút "đặt cả giỏ", giữ phần gợi ý | Linh |
| Chậm trên máy cũ | Giới hạn giỏ gợi ý 25 món; test trên 6 dòng máy | Thời gian tải giỏ p90 vượt 4 giây -> dừng nấc, loại nhóm máy chậm khỏi rollout | Quân |
| Không ai biết | Kịch bản cho nhân viên thị trường; thông báo theo lịch | Sau 7 ngày ở 100%, dưới 15% tiệm mở giỏ gợi ý -> tăng kênh trực tiếp | Mai |
Sau buổi họp
- Đưa năm rủi ro chính vào trang kickoff và checklist.
- Mỗi tripwire cần một nơi để nhìn — thường là một biểu đồ trên dashboard ra mắt (bài 7) và một cảnh báo tự động.
- Xem lại danh sách rủi ro mỗi tuần trong lúc phát triển; rủi ro đổi khi kế hoạch đổi.
Làm ngay
Với tính năng bạn sắp ra mắt, tự chạy một pre-mortem 20 phút một mình: viết ít nhất một lý do thất bại cho mỗi loại trong bảy loại. Chấm 1–3 cho khả năng và tác động. Với ba rủi ro điểm cao nhất, viết một biện pháp và một tripwire đủ ba phần. Gửi cho tech lead và hỏi: "Anh có đồng ý với ngưỡng và hành động này không?" Câu trả lời sẽ cho bạn biết ngưỡng nào đang được đặt bằng cảm tính.