Trong nhiều dự án, chúng ta thường bắt đầu bằng một bảng “success factors”, rồi dồn toàn lực để chase tiến độ. Nhưng càng mải miết chạy theo timeline, ta càng dễ bỏ quên những nguyên nhân thất bại âm thầm tích tụ: yêu cầu mơ hồ, quyền quyết định lỏng lẻo, phụ thuộc ẩn, môi trường kỹ thuật lệch chuẩn. Inversion đề nghị một góc nhìn khác: thay vì hỏi “Làm sao để thành công?”, hãy hỏi “Điều gì sẽ khiến chúng ta thất bại?” và chủ động dựng lan can ngay từ hôm nay.
Cách làm rất đơn giản. Ở buổi kick-off hoặc đầu mỗi phase/sprint, dành 30–45 phút cho một pre-mortem: giả định dự án đã thất bại và liệt kê những lý do có thể xảy ra. Từ danh sách đó, ta tạo Inversion Canvas gọn trong một trang: xác định các anti-goals (những trạng thái tối kỵ như “Done chỉ là code merge, không có test evidence”), liệt kê các failure modes theo lát cắt con người, phạm vi, quy trình, kỹ thuật, truyền thông; gắn cho mỗi rủi ro một tín hiệu sớm, điểm kích hoạt, biện pháp ứng phó, chủ sở hữu, và ngày hết hạn. Canvas này treo ngay cạnh Sprint Goal để nhắc cả đội rằng đi nhanh thôi chưa đủ — quan trọng là không rơi xuống hố.
Từ đây, ta vận hành dự án như một chuỗi giả thuyết rủi ro cần kiểm chứng. Mỗi rủi ro viết theo cấu trúc Claim–Signal–Trigger–Response–Owner–Expiry. Ví dụ: “Khách hàng sẽ sign-off Test Scenarios trong ≤ 3 ngày (Claim). Nếu quá 3 ngày chưa phản hồi (Signal), đến T+4 sẽ escalate (Trigger). BrSE nhắc lần 1, PM escalate, đồng thời tách scope ‘blocked’ khỏi sprint (Response). BrSE chịu trách nhiệm, PM phê duyệt (Owner). Hết hạn 31/10/2025 (Expiry).” Cách viết này buộc đội ngũ xác định ngưỡng hành động rõ ràng thay vì “theo dõi thêm”.
Để không bị những chiếc đèn “xanh giả” đánh lừa, chúng ta cần leading indicators bên cạnh các chỉ số trễ (lagging) như % hoàn thành. Hãy quan sát tỉ lệ rework, tuổi PR (PR Review Latency), xu hướng Cycle/Lead Time, “tuổi” phản hồi UAT, tốc độ burn-down rủi ro, tỷ lệ gỡ phụ thuộc đúng kế hoạch, defect escape rate sang UAT/Prod, các chỉ số DORA (Change Failure Rate, MTTR), và đặc biệt là bus factor ở các module trọng yếu. Khi những chỉ báo sớm này đổi màu, ta điều chỉnh kế hoạch trước khi timeline sụp đổ.
Song song đó, cần một Inversion Review ngắn 15 phút mỗi tuần: cập nhật ba rủi ro lớn nhất trong hai tuần tới, đóng những rủi ro đã “hết tuổi”, và thêm biện pháp phòng ngừa mới nếu xuất hiện tín hiệu. Vào các điểm rơi quan trọng (migration, cutover, kiến trúc nền), tổ chức một red-team review: một nhóm nhỏ đóng vai “phe phản biện” soi thẳng vào giả định, cấu hình môi trường, dữ liệu test, gate bảo mật, và kịch bản rollback/DR. Nhờ vậy, “điểm mù” tập thể được phơi bày trước khi gây tai nạn.
Một thay đổi văn hóa nhỏ nhưng tác dụng lớn là định nghĩa lại Done và Stop. “Done” không chỉ là code được merge; nó phải đi kèm bằng chứng kiểm thử, kiểm soát bảo mật, và sự chấp thuận phù hợp (ví dụ UAT sign-off). Còn Kill/Stop criteria giúp ta dám dừng khi chất lượng vượt ngưỡng nguy hiểm: “Nếu change failure rate > 40% trong 2 tuần liên tiếp, tạm dừng release để khắc phục chất lượng (test automation + review checklist) rồi mới tiếp tục.” Các anti-metrics như “% task done” hay “tỷ lệ đúng hạn” chỉ có ý nghĩa khi đứng cùng chất lượng và giá trị; nếu không, chúng dễ biến thành thuốc an thần.
Thực thi hằng ngày cần những “lan can” rõ ràng. Đừng bắt đầu bất kỳ công việc nào nếu chưa đạt Definition of Ready; đừng đánh dấu “Done” khi thiếu evidence; đừng “green by default” khi dữ liệu chưa chắc; đừng nhận thêm scope nếu chưa qua change control; và đừng để phụ thuộc “ẩn” — mọi dependency phải có owner, mốc, và phương án dự phòng. Chỉ cần kỷ luật với vài nguyên tắc này, team sẽ bớt “chạy theo” và nhiều hơn ở trạng thái tự phòng vệ.
Nếu muốn kiểm tra nhanh mức độ rủi ro, hãy dùng một bộ câu hỏi nghĩ ngược trong các cuộc họp: nếu dự án thất bại trong 90 ngày tới, lý do số 1 là gì; ta đang đo thứ gì vô nghĩa để tự trấn an; nếu ngày mai key person nghỉ, module nào sụp (bus factor); điều gì khiến khách hàng không sign-off dù mình “đúng hạn”; đâu là phụ thuộc ngoài tầm kiểm soát và buffer đã đủ chưa; quyết định quan trọng nào chưa có owner hoặc chưa có hạn chót; môi trường dev/staging/prod khác nhau ở đâu và rủi ro kéo theo; và nếu buộc dừng/pivot tuần sau, tiêu chí cụ thể là gì. Mỗi câu trả lời sẽ dẫn ta về một failure mode cần thêm tín hiệu sớm và biện pháp ứng phó.
Điểm mấu chốt: Inversion không phải bi quan; đó là kỷ luật nhìn thẳng vào điều có thể kéo dự án xuống vực. Khi cả đội quen hỏi “Điều gì sẽ khiến chúng ta thất bại?” và dựng lan can từ sớm, tiến độ sẽ không còn là cuộc rượt đuổi căng thẳng, mà trở thành hệ quả tự nhiên của một hệ thống minh bạch, an toàn và có khả năng tự điều chỉnh. Bắt đầu ngay hôm nay bằng ba bước nhỏ: pre-mortem đầu sprint, Inversion Canvas một trang, và Inversion Review 15 phút mỗi tuần. Nhỏ gọn, đều đặn, và đủ mạnh để đổi văn hóa từ “chạy theo timeline” sang phòng ngừa thất bại.
Transforming Leadership 