Có một khoảnh khắc rất quen trong công việc: vài phút trước buổi planning, trước khi nhấn nút deploy, trước một vòng phỏng vấn quan trọng, hoặc trước kỳ review promotion. Trong đầu mình thường tự động dựng lên phiên bản đẹp: project chạy ổn, hệ thống chịu tải tốt, interviewer gật đầu, manager nhìn thấy impact, và mọi thứ đi theo đúng kế hoạch.
Sự lạc quan đó không xấu. Nó cho mình năng lượng để bắt đầu. Nhưng nếu đó là câu chuyện duy nhất mình cho phép mình nhìn thấy, những điểm yếu trong kế hoạch sẽ ở yên trong bóng tối. Mình sẽ chuẩn bị cho một thế giới lý tưởng, trong khi thực tế thường vận hành bằng một logic lạnh hơn: thứ gì có thể sai, nếu bị bỏ quên đủ lâu, thường sẽ tìm được cách sai vào đúng lúc mình ít muốn nhất.
Pre-mortem bắt đầu từ một tư thế khác. Thay vì hỏi: “Làm sao để chuyện này thành công?”, nó hỏi: “Giả sử chuyện này đã thất bại rồi. Lý do có khả năng nhất là gì?” Không phải để dọa nhau, không phải để làm căn phòng nặng nề hơn, và cũng không phải để thưởng cho người hay nghi ngờ nhất. Mục tiêu là kéo một phần tiếc nuối của tương lai về hiện tại, khi mình vẫn còn thời gian sửa.
Khái niệm này thường được gắn với nhà tâm lý học Gary Klein, người đã viết về phương pháp này trên Harvard Business Review và trong phần giới thiệu về Pre-mortem Method of Risk Assessment. Nói ngắn gọn: sau khi một kế hoạch được trình bày, cả nhóm tưởng tượng kế hoạch đó đã thất bại, liệt kê các nguyên nhân hợp lý, rồi dùng chính danh sách đó để gia cố kế hoạch trước khi thực hiện. Nếu post-mortem giúp mình học sau khi chuyện đã xảy ra, pre-mortem giúp mình học trước khi cái giá xuất hiện.
Vì sao “tưởng tượng thất bại” lại làm kế hoạch khỏe hơn
Pre-mortem hiệu quả trước hết vì nó hợp pháp hóa việc nói ra điều mọi người thường ngại nói. Trong nhiều cuộc họp, không ai muốn trở thành người “dội gáo nước lạnh” khi cả nhóm đang hào hứng. Rủi ro vì vậy thường được nói nhẹ đi, nói vòng, hoặc không nói. Một buổi pre-mortem đổi luật chơi: tìm điểm yếu không còn là phá mood; đó là nhiệm vụ.
Nó cũng khớp với cách bộ não giải thích sự kiện. Dự đoán một rủi ro mơ hồ trong tương lai rất khó. Nhưng giải thích một sự kiện đã “xảy ra” trong tưởng tượng lại dễ hơn. Khi câu hỏi chuyển từ “có gì có thể sai?” sang “dự án đã chết rồi, vì sao nó chết?”, người ta bỗng nhớ ra dependency bị bỏ quên, rollback plan chưa có, owner chưa rõ, stakeholder chưa được align, câu chuyện interview chưa được luyện, hoặc mục tiêu cá nhân đang dựa quá nhiều vào cảm hứng.
Điểm quan trọng là: pre-mortem không phải bi quan. Bi quan nói: “Chuyện này sẽ hỏng, nên khỏi làm.” Pre-mortem nói: “Chuyện này đáng làm, nên mình phải bảo vệ nó khỏi những lỗi có thể nhìn thấy trước.” Đó là sự lạc quan có kỷ luật.
Trong kỹ thuật: từ dòng code nhỏ đến hệ thống lớn
Trong engineering, pre-mortem bắt đầu từ những câu hỏi nhỏ. Trước khi viết một function, mình có thể hỏi: “Nếu đoạn code này gây bug production, assumption nào của mình có khả năng sai nhất?” Có thể input không bao giờ rỗng trong test data, nhưng ngoài đời thì có. Có thể API bên thứ ba trả về đúng gần hết tài liệu, trừ một field thỉnh thoảng đổi type. Có thể retry loop tưởng là an toàn nhưng lại retry quá mạnh, biến một outage tạm thời thành cơn bão traffic.
Đó không chỉ là chuyện thêm vài lớp try/catch. Defensive Programming không phải sợ lỗi; nó là sự tôn trọng thực tế. Một pre-mortem tốt hỏi sâu hơn vào đường đi của hệ thống: nếu API thanh toán chậm năm phút vào giờ cao điểm, hệ thống của mình degrade gracefully hay treo thread, làm cạn connection pool, rồi kéo database xuống cùng? Nếu cache key phổ biến hết hạn cùng lúc, mình có cache stampede không? Nếu job xử lý nền bị backlog, người dùng thấy trạng thái gì?
Ở tầng architecture, câu hỏi lớn hơn: “Ngày mai CCU tăng gấp 10 lần và platform sập hoàn toàn. Bottleneck nằm ở đâu?” Database? Queue? Đồng bộ dữ liệu? Một synchronous call bị giấu trong hot path? Hay ngược lại, hệ thống không chết vì tải mà chết vì quá phức tạp: quá nhiều abstraction, service, config layer và event khiến lúc incident xảy ra, việc trace bug còn mệt hơn chính bug.
Những câu hỏi này không dễ chịu, nhưng chúng kéo team từ thế chữa cháy sang thế quy hoạch. Pre-mortem không đảm bảo hệ thống hoàn hảo. Nó giúp team chọn nơi cần đặt guardrail: timeout, circuit breaker, idempotency key, monitoring, rollback plan, load test, feature flag, runbook, hoặc đôi khi là một thiết kế bớt thông minh nhưng dễ vận hành hơn.
| Bối cảnh | Câu hỏi pre-mortem | Thường lộ ra điều gì |
|---|---|---|
| Code change | “PR này gây bug production. Assumption nào đã sai?” | Thiếu edge case, validation mỏng, test yếu, coupling ẩn. |
| System design | “Traffic tăng 10x và platform sập. Bottleneck ở đâu?” | DB pressure, queue behavior, cache stampede, dependency đồng bộ. |
| Migration | “Migration phải rollback lúc nửa đêm. Mình đã thiếu gì?” | Data shape lệch, rollback chưa đủ, backfill chậm, observability yếu. |
| Promotion | “Kỳ review kết thúc và mình không được promote. Khoảng trống thật là gì?” | Impact chưa rõ, stakeholder chưa tin, thiếu người kế nhiệm, scope chưa đủ lớn. |
| Interview | “Bước ra khỏi phòng phỏng vấn, mình biết đã tạch. Phần nào làm lộ điểm yếu?” | System design nông, behavioral story yếu, ownership không rõ, tradeoff chưa sắc. |
| Mục tiêu cá nhân | “Một tháng nữa mình bỏ cuộc. Điều gì làm kế hoạch quá khó để tiếp tục?” | Mục tiêu quá lớn, friction cao, không có restart rule, chỉ dựa vào motivation. |
Trong sự nghiệp: promotion, phỏng vấn và phần việc không ai nhìn thấy
Pre-mortem cũng rất hữu ích ngoài kỹ thuật. Nhiều hành trình nghề nghiệp không thất bại ở khoảnh khắc cuối. Chúng yếu đi từ nhiều tháng trước đó: kỳ vọng không rõ, bằng chứng impact chưa đủ, stakeholder chưa thật sự tin, hoặc công việc có giá trị nhưng không ai ngoài mình hiểu.
Một câu hỏi promotion pre-mortem rất đáng viết ra là: “Sáu tháng nữa, kỳ review kết thúc và mình không được lên level. Lý do thật sự là gì?” Câu trả lời có thể là kỹ thuật, nhưng thường không chỉ là kỹ thuật. Có thể mình làm rất nhiều task nhưng chưa nối được chúng với business impact. Có thể mình là người xử lý việc khẩn cấp rất tốt, nhưng chưa nâng được cách cả team vận hành. Có thể mình vẫn là bottleneck của quá nhiều việc hằng ngày, nên không ai thấy mình đang hoạt động ở scope lớn hơn. Có thể mình làm tốt, nhưng chưa kể được câu chuyện đó bằng bằng chứng đủ rõ.
Viết những điều này xuống có thể hơi khó chịu, nhưng nó tử tế hơn việc phát hiện quá muộn. Khi rủi ro đã có tên, bước tiếp theo không phải lo lắng. Nó là tích lũy âm thầm: làm rõ expectation với manager, chọn một project có impact nhìn thấy được, ghi lại quyết định và kết quả, giúp một người khác kế nhiệm phần việc vận hành của mình, xin feedback trước kỳ review chính thức, và xây bằng chứng khi vẫn còn thời gian.
Với phỏng vấn vị trí mới, đặc biệt là Senior, Lead hoặc Architect, câu hỏi tương tự cũng rất mạnh: “Nếu mình bước ra khỏi phòng phỏng vấn và biết là không qua, vì sao?” Có thể phần system design của mình quá chăm vào implementation mà thiếu tradeoff. Có thể incident story nghe giống một câu chuyện người hùng, nhưng không cho thấy mình học được gì. Có thể mình dùng chữ “team em” quá nhiều đến mức interviewer không rõ phần mình thật sự sở hữu. Có thể mình ôn thuật toán nhưng chưa chuẩn bị cho phần leadership judgment mà role mới cần.
Pre-mortem biến việc chuẩn bị phỏng vấn từ học lan man thành sửa đúng chỗ. Mình có thể luyện lại câu chuyện yếu, vẽ lại system design với constraint rõ hơn, chuẩn bị ví dụ hành vi theo cấu trúc cụ thể, và tập giải thích tradeoff một cách bình tĩnh. Mục tiêu không phải học thuộc một phiên bản hoàn hảo của bản thân. Mục tiêu là bỏ bớt những bất ngờ có thể tránh được, để cuộc trò chuyện thật sự có không gian diễn ra.
Trong đời sống: thiết kế quanh những lý do mình thường bỏ cuộc
Nhiều kế hoạch cá nhân không hỏng vì ngày đầu tiên tệ. Chúng hỏng vì kế hoạch đó chỉ phù hợp với một phiên bản của mình có năng lượng vô hạn, không bị gián đoạn, không mệt và luôn có motivation. Học một kỹ năng mới, chạy bộ, viết đều hơn, đọc sách, tiết kiệm tiền, làm side project — tất cả đều dễ tưởng tượng và khó giữ nhịp.
Trước khi bắt đầu, thử một pre-mortem nhỏ: “Một tháng nữa mình bỏ giữa chừng. Chuyện gì đã xảy ra?” Câu trả lời thường không kịch tính. Bài học quá dài. Phòng gym quá xa. Side project không có milestone nhỏ. Một tuần bận làm vỡ nhịp, rồi không có cách quay lại. Mục tiêu được thiết kế cho cảm hứng, không được thiết kế cho đời sống thật.
Khi lý do thất bại đã rõ, kế hoạch có thể mềm hơn nhưng bền hơn. Mười lăm phút mỗi ngày tốt hơn một kế hoạch hai tiếng đầy khí thế nhưng sập ngay vào thứ Ba. Một checklist nhỏ tốt hơn một lời hứa mơ hồ về việc “sẽ kỷ luật hơn”. Một restart rule tốt hơn cảm giác xấu hổ. Với người này, public commitment có ích; với người khác, một routine riêng tư lại hợp hơn. Điểm chính không phải biến mình thành người hoàn hảo. Điểm chính là thiết kế một con đường tôn trọng cuộc sống thật của mình.
Một pre-mortem 15 phút có thể làm như thế nào
Không cần biến nó thành một nghi thức phức tạp. Với nhiều tình huống, mười lăm phút tập trung là đủ.
- Gọi tên kế hoạch. Càng cụ thể càng tốt: deploy release này, chuẩn bị interview này, xin promotion kỳ này, hoàn thành milestone này của side project.
- Nhảy tới tương lai. Viết một câu: “Ba tháng nữa, kế hoạch này thất bại.”
- Liệt kê nguyên nhân trong im lặng trước. Im lặng giúp tránh việc tiếng nói tự tin đầu tiên định hình suy nghĩ của cả nhóm.
- Gom nhóm nguyên nhân. Thường chúng sẽ rơi vào vài cụm: con người, quy trình, kỹ thuật, giao tiếp, thời điểm, năng lượng, incentive.
- Chọn rủi ro lớn nhất. Không cần xử lý mọi thứ. Chọn vài rủi ro vừa có khả năng xảy ra, vừa có cái giá đáng kể.
- Thiết kế mitigation và tín hiệu cảnh báo. Mình làm gì ngay bây giờ, ai chịu trách nhiệm, và dấu hiệu sớm nào cho biết đã đến lúc can thiệp?
Bước cuối cùng là điểm phân biệt giữa lo lắng và chuẩn bị. Một danh sách rủi ro không có hành động sẽ trở thành tiếng ồn trong đầu. Một danh sách rủi ro có owner, mitigation và early signal thì trở thành công cụ điều hướng.
“Nếu chuyện này hỏng trong tương lai, điều gì hôm nay mình sẽ ước là mình đã nhìn ra sớm hơn?” Câu hỏi đó dùng được cho code review, architecture, stakeholder alignment, phỏng vấn, promotion planning và gần như mọi mục tiêu cá nhân đáng bảo vệ.
Giá trị lặng lẽ của việc nhìn trước
Những thay đổi lớn hiếm khi đến từ một khoảnh khắc kịch tính duy nhất. Chúng thường là kết quả của một quá trình tích lũy âm thầm: một test được thêm trước incident, một design note được viết trước handover, một cuộc nói chuyện với stakeholder được thực hiện trước kỳ review, một thói quen nhỏ được giữ trước khi cơ hội xuất hiện. Pre-mortem giúp mình chọn đúng thứ cần tích lũy.
Nó không làm mình trở nên bất bại. Không kế hoạch nào nhìn thấy hết mọi khả năng. Nhưng rất nhiều thất bại không thật sự bí ẩn. Chúng đã từng là những tín hiệu nhỏ trước khi trở thành cái giá lớn. Nghệ thuật nằm ở chỗ để những tín hiệu đó lên tiếng khi chúng còn đủ nhỏ để xử lý.
Những điều đọng lại
- Pre-mortem là cách tưởng tượng thất bại trước khi bắt đầu, để sửa kế hoạch khi vẫn còn thời gian.
- Nó không phải bi quan. Nó là lạc quan có bộ lọc rủi ro: mình bảo vệ kế hoạch vì muốn nó thành công.
- Trong phần mềm, pre-mortem làm lộ assumption ẩn về dependency, scale, observability, rollback và over-engineering.
- Trong sự nghiệp, nó giúp nhìn sớm khoảng trống về impact, stakeholder trust, bằng chứng, succession và cách kể câu chuyện phỏng vấn.
- Trong đời sống, nó giúp thiết kế mục tiêu quanh đời sống thật, thay vì chỉ dựa vào motivation.
- Đầu ra tốt không phải một danh sách nỗi sợ. Đầu ra tốt là vài mitigation rõ, có owner, và có tín hiệu cảnh báo sớm.
Trước lần deploy tiếp theo, trước một cuộc nói chuyện promotion, trước vòng phỏng vấn mới, hoặc trước một mục tiêu cá nhân bạn thật sự muốn giữ, hãy thử dành mười lăm phút rất thành thật cho pre-mortem. Tưởng tượng nó đã hỏng, lắng nghe lý do, rồi quay lại hiện tại với một hai điều có thể sửa ngay. Nếu bạn từng dùng cách nghĩ này trong công việc hoặc đời sống, mình rất muốn nghe nó đã giúp bạn nhìn thấy điều gì trước khi mọi thứ trở nên khẩn cấp.