SoDeep IconSoDeep
·
Kỹ thuật Pre-mortem để 'debug' rủi ro trước khi bắt đầu dự án

Kỹ thuật Pre-mortem để 'debug' rủi ro trước khi bắt đầu dự án

@Khắc Kỷ Online · 15 tháng 6, 2026

Thay vì ngồi cầu nguyện cho dự án thành công, hãy thử tưởng tượng nó đã thất bại thảm hại. Kỹ thuật Pre-mortem giống như việc khám nghiệm tử thi cho một kế hoạch vẫn còn đang sống nhăn răng.

Bạn tự đưa mình đến tương lai, nhìn vào đống đổ nát của dự án và đặt câu hỏi: "Cái gì đã giết chết nó?". Có thể là do server sập, hay đơn giản là cả team đã hiểu lầm ý nhau ngay từ đầu.

Cách "debug" ngược này giúp chúng ta tỉnh táo hơn hẳn việc ngồi vẽ ra viễn cảnh màu hồng. Khi đã biết trước những hố đen có thể xuất hiện, bạn chỉ việc thiết lập lại hệ thống để né chúng ra trước khi kịp bước chân vào.

Nhưng ngồi trù ẻo dự án sập như vậy không làm cả team nản lòng sao?

Ngược lại hoàn toàn, đây là cách chúng ta "hack" tâm lý sợ hãi. Khi coi thất bại là một dữ liệu đã xảy ra, bộ não sẽ ngừng lo âu vớ vẩn và chuyển sang chế độ giải quyết vấn đề. Nó biến nỗi sợ mơ hồ thành một danh sách các "bug" cụ thể cần fix.

Quan trọng là bầu không khí: chúng ta không tìm người để đổ lỗi, mà tìm lỗ hổng trong hệ thống. Khi cả team cùng "khám nghiệm tử thi", cái tôi cá nhân bị dẹp sang một bên để nhường chỗ cho sự tỉnh táo của những người thợ sửa máy.

Thay vì lo lắng trong vô vọng, team sẽ cảm thấy tự tin hơn vì đã có sẵn các "bản vá" cho những kịch bản tệ nhất. Đó là sự lạc quan dựa trên thực tế, chứ không phải sự hưng phấn ảo giác.

Ủa, vậy nếu gặp những 'bug' nằm ngoài tầm kiểm soát thì xử lý thế nào?

Trong lập trình, bạn không thể ngăn cá mập cắn cáp quang, nhưng bạn có thể thuê thêm một đường truyền dự phòng. Những "bug" ngoại cảnh đó không phải để sửa, mà để xây dựng các phương án sao lưu (backup).

Nếu rủi ro là thiên tai, ta không cố ngăn bão mà đi gia cố mái nhà. Mục tiêu là biến một cú sốc chí mạng thành một vết trầy xước nhẹ để hệ thống không bị sập nguồn hoàn toàn.

Đừng lãng phí tài nguyên để kiểm soát cái không thể kiểm soát. Hãy tập trung vào việc phản ứng: "Nếu nó xảy ra, ta sẽ làm gì?". Đó là sự chuẩn bị tỉnh táo, không phải lo âu vô ích.

Làm sao để không bị quá tải khi có quá nhiều kịch bản tệ hại?

Hãy dùng bộ lọc "xác suất" và "hậu quả". Đừng lo thiên thạch rơi trúng đầu vì tỉ lệ đó bằng không. Hãy tập trung vào những thứ vừa dễ xảy ra, vừa gây thiệt hại lớn.

Giống như việc ưu tiên vá lốp xe hơn là xây hầm trú ẩn. Một cái làm bạn hỏng việc mỗi ngày, cái kia chỉ tổ tốn kém vô ích.

Chỉ dồn lực cho 3-5 rủi ro "chí mạng". Những thứ còn lại? Chấp nhận buông bỏ. Bạn không bao giờ có thể an toàn tuyệt đối 100%.

Nếu cái rủi ro mình vừa gạt đi lại xảy ra thật thì sao?

Chấp nhận rủi ro giống như việc không mang ô khi tỉ lệ mưa chỉ 5%. Nếu mưa thật, bạn bị ướt—đó là cái giá để đổi lấy sự thảnh thơi thay vì vác đồ cồng kềnh.

Trong kỹ thuật, đây là "chấp nhận lỗi" (fault tolerance). Nếu rủi ro phụ ập đến, bạn tốn công xử lý, nhưng vì lõi chính đã an toàn, hệ thống sẽ không sập.

Đừng xây pháo đài không kẽ hở, hãy xây một con lật đật. Dù va đập ở điểm không ngờ tới, nó vẫn tự đứng dậy vì trọng tâm đã được giữ vững.

Trải nghiệm duyệt thẻ →

Chủ đề liên quan

Sự thôi thúc phải giải thích khi bị người khác hiểu lầmSự bức bối khi phải chờ đợi một cuộc hẹn muộnCơ chế 'quản trị rủi ro' cho những kỳ vọng quá caoCảm giác 'tội lỗi' khi dành thời gian nghỉ ngơiNghịch lý của sự lựa chọn trước thực đơn quá dàiLỗi logic khi nhầm lẫn giữa bận rộn và năng suất