Pre-mortem & Delivery Risk

Pre-mortem là gì, và vì sao nó hơn một bảng rủi ro

Pre-mortem là một buổi họp diễn ra trước khi bắt đầu xây, với một giả định cố ý: "Hôm nay là sáu tháng sau. Dự án đã thất bại. Hãy viết ra vì sao."

Nghe như một trò chơi chữ, nhưng nó thay đổi hẳn chất lượng câu trả lời. Khi bạn hỏi "có rủi ro gì không?", mọi người đang ở trong tâm thế bảo vệ kế hoạch — nêu rủi ro nghe như nghi ngờ đồng nghiệp hoặc nghi ngờ sếp. Khi bạn nói "nó đã thất bại", việc tìm lý do trở thành bài toán cần giải, và người im lặng nhất phòng thường có câu trả lời đúng nhất.

Bảng rủi ro không sai — nó chỉ là nơi lưu trữ. Pre-mortem là cách lấp đầy nó bằng những thứ đáng lưu. Sau buổi họp, kết quả vẫn nên đi vào bảng rủi ro của dự án; khác biệt là nội dung trong đó giờ đến từ cả đội, đủ cụ thể để hành động.

Khi nào nên chạy: khi đã có hướng giải pháp đủ rõ để hình dung nó thất bại thế nào, nhưng chưa cam kết nguồn lực lớn. Thường là ngay sau solution review, trước kickoff kỹ thuật. Với dự án outsourcing, chạy trước khi ký phạm vi với khách — sau khi ký, nhiều rủi ro đã thành ràng buộc hợp đồng.

Cách chạy một buổi pre-mortem 60–90 phút

Người dự: đội làm (PM, design, tech lead, một hai engineer, QA), cộng một hai người ngoài đội nhìn thấy phần khác của bức tranh — support, sales, vận hành, pháp chế. Không quá 10 người; đông hơn thì chia nhóm.

Câu gợi ý khi phòng im lặng:

• "Khách hàng dùng thử và không quay lại — chuyện gì đã xảy ra?"
• "Chúng ta ra mắt đúng hạn, nhưng sếp tổng nói đây không phải thứ anh ấy muốn — vì sao?"
• "Đội khác làm chúng ta trễ — đội nào, và chuyện gì?"
• "Tính năng chạy tốt nhưng công ty lỗ trên mỗi giao dịch — vì sao?"
• "Chúng ta phải tắt tính năng sau ba ngày — chuyện gì xảy ra trong ba ngày đó?"
• "Điều gì mà ai cũng biết nhưng không ai nói trong các cuộc họp?"

Câu cuối thường mở ra những rủi ro thật nhất. Để nó có tác dụng, người điều phối — thường là PM — phải là người đầu tiên nêu một rủi ro về chính phần việc của mình, chẳng hạn "yêu cầu tôi viết có thể đã hiểu sai khách hàng". Nếu người dẫn bảo vệ kế hoạch của mình, cả phòng sẽ làm theo.

Bảy kiểu thất bại của một lần ra mắt

Khi gom nhóm, dùng bảy loại dưới đây làm khung. Nếu sau buổi viết riêng có loại nào hoàn toàn trống, hãy hỏi riêng về loại đó — một loại trống thường là điểm mù của đội, không phải dấu hiệu an toàn.

Bốn loại đầu là bốn rủi ro sản phẩm kinh điển; ba loại sau là nơi phần lớn các lần ra mắt ở công ty Việt Nam thật sự hỏng — không phải vì ý tưởng sai, mà vì đối tác trễ, vì không ai biết tính năng tồn tại, hoặc vì nó không chạy trên điện thoại của khách.

Chấm điểm, giao chủ, và phân biệt biện pháp với tripwire

Chấm khả năng × tác động, mỗi trục 1–3. Đừng dùng thang 1–10 — không ai phân biệt được 6 và 7, và tranh luận về nó tốn hết thời gian còn lại. Nhóm có điểm 6 hoặc 9 là phải có chủ. Nhóm 3–4 ghi lại để xem lại ở mốc tiếp theo. Nhóm 1–2 ghi nhận và bỏ qua.

Với mỗi rủi ro được giữ lại, có hai loại phản ứng, và một kế hoạch tốt thường cần cả hai:

Tripwire là phần bị bỏ qua nhiều nhất và có giá trị nhất. Nó biến một cuộc tranh luận lúc khủng hoảng thành một quyết định đã đưa ra lúc bình tĩnh. Khi ngày 15/3 đến và đối tác chưa giao, không ai phải họp để bàn có nên lùi hay không — việc đó đã được quyết. Một tripwire tốt có ba phần: chỉ số hoặc sự kiện, ngưỡng hoặc ngày, và hành động.

Chủ của rủi ro không nhất thiết là người sửa nó. Chủ là người theo dõi tín hiệu và lên tiếng khi tripwire bật. Với rủi ro phụ thuộc đối tác, chủ thường là PM; với rủi ro hiệu năng, là tech lead.

Ví dụ đầy đủ — pre-mortem cho tính năng chấm công bằng khuôn mặt

Bối cảnh (giả định): một công ty SaaS nhân sự ở TP.HCM, khách là các chuỗi bán lẻ và nhà máy 300–3.000 nhân viên, chuẩn bị xây chấm công bằng nhận diện khuôn mặt trên máy tính bảng đặt ở cửa ca. Mục tiêu: 20 khách đang dùng chấm công vân tay chuyển sang trong 2 quý. Buổi pre-mortem có 8 người, 75 phút, ra 61 lý do, gom thành 11 nhóm.

PRE-MORTEM — Chấm công khuôn mặt — 75 phút, 8 người
Giả định: "Tháng 9, chỉ 3 trên 20 khách chuyển sang. Dự án bị coi là thất bại."

Nhóm (số phiếu)                         | K | T | Điểm | Loại
1. Nhận diện sai lúc đông người đổi ca   | 3 | 3 | 9    | Chất lượng
2. Công nhân phản đối vì lo bị giám sát  | 2 | 3 | 6    | Giá trị / tiếp cận
3. Thiếu đồng ý xử lý dữ liệu sinh trắc  | 2 | 3 | 6    | Kinh doanh (pháp lý)
4. Wifi nhà máy yếu, máy mất kết nối     | 3 | 2 | 6    | Chất lượng
5. Nhà cung cấp máy tính bảng giao trễ   | 2 | 2 | 4    | Phụ thuộc
6. HR khách không biết cấu hình          | 2 | 2 | 4    | Khả dụng

1. Nhận diện sai lúc đổi ca — Chủ: Tech lead
   Biện pháp: thử thực địa 2 tuần ở 1 nhà máy, ca 6 giờ sáng, 400 người.
   Tripwire: tỉ lệ phải chấm lại > 3% ở thử thực địa => chưa mở bán,
             bổ sung chế độ quét mã QR dự phòng.
2. Công nhân phản đối — Chủ: PM + CS lead
   Biện pháp: bộ tài liệu giải thích cho công nhân; ảnh chỉ lưu dạng mã
             hoá, không lưu ảnh gốc; khách được chọn bật theo từng xưởng.
   Tripwire: > 5% nhân viên một xưởng từ chối đăng ký => dừng mở rộng
             ở khách đó, họp với công đoàn.
3. Đồng ý dữ liệu sinh trắc — Chủ: PM
   Biện pháp: pháp chế duyệt luồng đồng ý và điều khoản trước sprint 2.
   Tripwire: chưa có văn bản duyệt trước ngày 30/4 => không ra beta.
4. Wifi yếu — Chủ: Tech lead
   Biện pháp: chế độ ngoại tuyến, đồng bộ khi có mạng.
5, 6: xem lại ở mốc beta.
Ngày xem lại: sau thử thực địa (tuần 6).

Điều đáng chú ý: rủi ro số 2 và số 3 không đến từ đội kỹ thuật. Chúng đến từ CS lead và một bạn sales từng làm ở nhà máy — hai người sẽ không lên tiếng nếu buổi họp là "rà rủi ro kỹ thuật". Và rủi ro số 2, nếu không được nêu, có thể giết dự án ngay cả khi công nghệ chạy hoàn hảo.

Cược lớn: chia theo mốc, và khi đã thất bại thì triage thế nào

Với một cược lớn — sáu tháng trở lên, nhiều đội — đừng xin cam kết một lần. Chia thành các mốc, mỗi mốc được thiết kế để giết rủi ro lớn nhất còn lại bằng chi phí thấp nhất, và mỗi mốc kết thúc bằng một quyết định đi tiếp, đổi hướng hay dừng.

Điều này cũng giúp nói chuyện với lãnh đạo: thay vì xin "sáu tháng cho tính năng X", bạn xin "ba tuần để biết khách có muốn X không". Câu thứ hai dễ được đồng ý hơn nhiều, và nếu câu trả lời là không, công ty mất ba tuần thay vì sáu tháng.

Khi đã ra mắt mà kết quả không như mong đợi, phản xạ thường là "thêm tính năng" hoặc "chạy thêm quảng cáo". Trước khi làm gì, xác định nó hỏng ở loại nào — vì mỗi loại có cách chữa khác hẳn nhau:

Lỗi thường gặp

Luyện kỹ năng này trong tuần này

• Chạy một pre-mortem 30 phút bản rút gọn cho việc sắp làm trong tháng tới: 5 phút bối cảnh, 7 phút viết riêng, 10 phút gom nhóm, 8 phút giao chủ cho 2 rủi ro lớn nhất.
• Lấy bảng rủi ro hiện tại của dự án bạn và xếp từng dòng vào bảy loại. Loại nào trống? Hỏi riêng một người ngoài đội về loại đó.
• Viết ba tripwire cho dự án đang chạy, mỗi cái đủ ba phần. Gửi cho tech lead và sếp, hỏi họ có đồng ý với hành động trong đó không — tốt nhất là đồng ý bây giờ.
• Chọn một lần ra mắt không như mong đợi gần đây và chẩn đoán bằng bảng triage. Nó hỏng ở loại nào? Đội đã chữa đúng loại chưa?
• Lần tới khi có người nói "chắc không sao đâu", hỏi lại: "Nếu sáu tháng sau nó hỏng, lý do có khả năng nhất là gì?"