Plausible Alternative: Cứu Dự Án Khỏi Khủng Hoảng Ra Sao

Khi kế hoạch A sụp đổ lúc 2 giờ sáng

Bạn đã bao giờ nhận được cuộc gọi lúc nửa đêm thông báo hệ thống production đã chết, và cả đội không biết phải làm gì vì “kế hoạch dự phòng” thực ra chỉ là một slide PowerPoint đẹp mắt? Nếu câu trả lời là có, bạn không hề đơn độc. Đây chính là khoảnh khắc mà khái niệm plausible alternative – phương án thay thế khả thi – chứng minh giá trị thực sự của nó, vượt xa những dòng lý thuyết khô khan trong sách quản trị.

Không giống như một “kế hoạch B” mơ hồ được viết ra cho có, một plausible alternative là phương án đã được kiểm chứng tính khả thi, có nguồn lực được phân bổ sẵn, và quan trọng nhất: đội ngũ biết chính xác phải làm gì khi chuyển sang nó. Hãy cùng đi qua những ví dụ thực tế, nơi ranh giới giữa thảm họa và cứu nguy chỉ nằm ở việc bạn đã chuẩn bị phương án thay thế thực sự khả thi hay chưa.

Plausible alternative thực sự là gì?

Trước khi đi vào ví dụ, cần làm rõ một hiểu lầm phổ biến. Nhiều người đánh đồng “có phương án dự phòng” với “có plausible alternative”. Đây là hai thứ hoàn toàn khác nhau.

Phương án dự phòng thông thường thường là một tài liệu mô tả chung chung: “Nếu nhà cung cấp A gặp sự cố, chúng ta sẽ chuyển sang nhà cung cấp B”. Nhưng nhà cung cấp B đã được onboard chưa? Hợp đồng đã ký? API đã tích hợp? Đội ngũ đã test? Nếu câu trả lời là chưa, đó không phải là plausible alternative. Plausible alternative đòi hỏi ba yếu tố cốt lõi: (1) tính khả thi đã được chứng minh qua thử nghiệm thực tế, (2) nguồn lực được phân bổ và sẵn sàng kích hoạt, (3) quy trình chuyển đổi được định nghĩa rõ ràng và được diễn tập.

Ví dụ thực tế trong quản lý dự án

Trường hợp 1: Nhà cung cấp API ngừng hoạt động

Một công ty fintech tôi từng làm việc phụ thuộc vào một nhà cung cấp dữ liệu ngoại hối duy nhất. Khi nhà cung cấp này thông báo ngừng dịch vụ trong 30 ngày do tái cấu trúc, đội ngũ không hề hoảng loạn. Tại sao?

Họ đã xây dựng một layer abstraction ngay từ đầu, và quan trọng hơn, họ thường xuyên chạy traffic với tỷ lệ 5% qua nhà cung cấp phụ trong suốt 6 tháng trước đó. Khi sự cố xảy ra, việc chuyển đổi hoàn toàn sang nhà cung cấp thứ hai chỉ đơn giản là thay đổi một biến cấu hình từ 0.05 thành 1.0. Toàn bộ quá trình mất chưa đến 15 phút. Không một khách hàng nào nhận ra sự thay đổi.

Bài học: Plausible alternative không chỉ cần tồn tại, nó cần được sử dụng thực tế ở quy mô nhỏ. Traffic shaping và canary deployment không chỉ là công cụ kỹ thuật, chúng là cơ chế kiểm chứng tính khả thi của phương án dự phòng.

Trường hợp 2: Nhân sự chủ chốt đột ngột rời đi

Một dự án ERP quy mô lớn gặp khủng hoảng khi Tech Lead duy nhất xin nghỉ việc với thời gian bàn giao chỉ 2 tuần. Dự án có 40 người, nhưng toàn bộ kiến trúc hệ thống và các quyết định kỹ thuật cốt lõi đều tập trung vào một người.

Dự án suýt sụp đổ. Nhưng cũng một công ty đó, 2 năm sau gặp tình huống tương tự – lần này họ đã chuẩn bị một plausible alternative về nhân sự: mỗi module quan trọng đều có ít nhất hai người hiểu sâu, được yêu cầu viết Architecture Decision Records (ADR) cho mọi quyết định quan trọng, và tổ chức các buổi knowledge transfer định kỳ không phải dưới dạng thuyết trình mà là pair programming thực tế.

Khi Tech Lead thứ hai rời đi, người kế nhiệm mất 3 ngày để nắm bắt thay vì 3 tháng. Dự án chậm tiến độ 1 tuần thay vì 2 tháng như lần trước.

Bài học: Plausible alternative trong nhân sự không phải là “thuê người dự phòng” – điều không ai làm được. Nó là cơ chế phân tán kiến thức một cách có chủ đích và liên tục.

Trường hợp 3: Công nghệ thay đổi giữa chừng

Một startup xây dựng sản phẩm trên nền tảng blockchain Ethereum. Họ dành 8 tháng phát triển smart contract, sẵn sàng launch thì phí gas tăng đột biến 10 lần, khiến mô hình kinh doanh của họ không còn khả thi.

Điều cứu họ không phải là may mắn. Trong quá trình phát triển, CTO đã nhất quyết giữ toàn bộ business logic ngoài chuỗi (off-chain), chỉ dùng blockchain cho settlement cuối cùng. Khi cần pivot sang một blockchain khác có phí thấp hơn, họ chỉ phải viết lại một smart contract mỏng ~300 dòng code, thay vì phải viết lại toàn bộ hệ thống.

Bài học: Plausible alternative về công nghệ không nhất thiết là một lựa chọn thứ hai được xây dựng song song. Đôi khi nó nằm ở kiến trúc – sự tách biệt rạch ròi giữa domain logic và hạ tầng, cho phép thay đổi tầng dưới mà không ảnh hưởng đến tầng trên.

Ví dụ thực tế trong xử lý khủng hoảng

Trường hợp 4: Tấn công ransomware

Một công ty logistics vừa và nhỏ bị tấn công ransomware vào hệ thống quản lý đơn hàng. Tin tặc yêu cầu tiền chuộc, dữ liệu bị mã hóa toàn bộ. Trong khi nhiều công ty khác trong tình huống tương tự phải trả tiền hoặc mất dữ liệu, họ đã khôi phục hoạt động trong vòng 4 giờ.

Bí quyết? Họ không chỉ “backup dữ liệu”. Họ đã diễn tập khôi phục toàn bộ hệ thống mỗi quý một lần, trên một môi trường biệt lập. Phương án thay thế của họ đã được chứng minh là thực sự hoạt động, không chỉ trên giấy. Khi khủng hoảng thực sự xảy ra, đội ngũ đã quen thuộc với quy trình, biết chính xác cần bao nhiêu phút để khôi phục từng hệ thống, và ai chịu trách nhiệm cho từng bước.

Họ còn có một phương án thủ công – xử lý đơn hàng qua bảng tính Excel – được thiết kế sẵn và nhân viên đã được đào tạo. Trong 4 giờ hệ thống chính đang được khôi phục, hoạt động kinh doanh vẫn tiếp tục dù ở chế độ giảm năng suất.

Bài học: Kế hoạch ứng phó sự cố (Incident Response Plan) chỉ thực sự là plausible alternative khi nó được diễn tập thực tế. Một bản kế hoạch đẹp trong thư mục Google Drive không bao giờ là phương án thay thế khả thi.

Trường hợp 5: Khủng hoảng truyền