Khi sự phê duyệt không phải là một lựa chọn dựa trên đầy đủ thông tin

Kịch bản dẫn nhập (Setup)

Một bên liên quan (stakeholder) nói "Đồng ý" ở cuối bài trình bày về sự đánh đổi (tradeoff presentation) có vẻ như đã hiểu rõ sự đánh đổi đó. Bài trình bày rất đầy đủ, chính xác về mặt kỹ thuật, và cả phòng họp đều cảm thấy có sự đồng thuận. Chính cảm giác đó là một cái bẫy.

Phân tích Đợt rà soát Tiền sản xuất (Pre-production review) từ Góc nhìn của CTO

Kiến trúc sư đã trình bày sự đánh đổi trong chiến lược ngữ cảnh (context-strategy tradeoff) bằng các thuật ngữ kỹ thuật. Giám đốc Công nghệ (CTO) đã đặt một câu hỏi về chi phí, Kiến trúc sư trả lời chính xác, và CTO phê duyệt.

Sáu tuần sau, mức chi phí cho mỗi lượt gọi cao hơn đã xuất hiện trên hóa đơn vận hành thực tế (production invoice). Dưới đây là đoạn trao đổi, theo sau là ghi chú của CTO khi nhận được hóa đơn. Nó chỉ ra chính xác nơi bài trình bày đã trả lời sai phiên bản của câu hỏi.

Đoạn trao đổi được tái hiện lại + Diễn biến tiếp theo:

• Kiến trúc sư (Architect): "Chúng tôi đề xuất sử dụng cửa sổ ngữ cảnh lớn hơn, để toàn bộ tài liệu chính sách nằm trong tầm nhìn trên mỗi lượt gọi. Điều này giúp thiết kế đơn giản hơn và tránh phải thêm một tầng truy xuất (retrieval layer)."

• CTO: "Chi phí cho mỗi lượt gọi trông như thế nào?"

• Kiến trúc sư (Architect): "Khoảng 4 cent cho mỗi tương tác ở phân cấp mô hình chúng ta đang dùng. Nếu tài liệu chính sách là tĩnh qua các lượt gọi, cơ chế lưu tạm prompt (prompt caching) có thể kéo phần chi phí đầu vào đó xuống đáng kể."

• CTO: "Được rồi, phê duyệt. Hãy giữ mọi thứ đơn giản."

[6 tuần sau, trên hóa đơn production] Ghi chú của CTO gửi cho đội ngũ quản lý tài khoản:

"Tôi đã phê duyệt một HƯỚNG ĐI, chứ không phải một CON SỐ. Không một ai nói với tôi rằng 4 cent nhân với lưu lượng lượt gọi của chúng ta lại trở thành một dòng chi phí lên tới 5 chữ số mỗi tháng. Nếu tài liệu là tĩnh, tại sao chúng ta lại không sử dụng prompt caching? Và nếu đằng nào chúng ta cũng xây dựng hệ thống xung quanh phương án full-context, tôi cần phải biết việc tháo gỡ (unwinding) quyết định đó sẽ tốn bao nhiêu chi phí một khi hệ thống đã phụ thuộc vào nó."

Vấn đề cốt lõi: Chi phí Đảo ngược Quyết định chưa bao giờ xuất hiện trong Cuộc trò chuyện

Bài trình bày đã nêu tên những gì bản thiết kế đạt được (sự đơn giản), và nó đã trả lời chính xác chi phí cho mỗi lượt gọi theo đúng câu hỏi được đặt ra.

Tuy nhiên, những gì nó chưa bao giờ nhận diện là yếu tố thứ ba: Điều gì sẽ xảy ra với doanh nghiệp khi lựa chọn này chạm tới lưu lượng production và buộc phải đảo ngược (reversed) sau khi hệ thống đã được xây dựng xung quanh nó?

• CTO đã phê duyệt một con số tính trên mỗi lượt gọi, chứ không phải một hóa đơn hàng tháng, và càng không phải chi phí tháo gỡ một quyết định sau này.

• Hai phần của sự đánh đổi đã được truyền thông và hiểu rõ ràng. Phần thứ ba thì không, và nó lại chính là phần chịu tải (load-bearing).

Tại sao điều này lại gây ra sự cố?

Một bài trình bày chính xác vẫn có thể trả lời sai câu hỏi.

Một bên liên quan phê duyệt một khuyến nghị mà không hiểu rõ chi phí đảo ngược (reversal cost) thì không phải là đã đưa ra một lựa chọn dựa trên đầy đủ thông tin (informed choice). CTO đã nghe thấy một con số trên mỗi lượt gọi cùng một lập luận về sự đơn giản, và đã đưa ra câu trả lời "Đồng ý" một cách rất hợp lý.

Bài học cốt lõi: Yếu tố chi phí đảo ngược chính là nhân tố duy nhất có thể làm thay đổi quyết định. Hãy gọi tên đầy đủ cả 3 yếu tố trong mọi lần trình bày, và đặc biệt phải xướng tên chi phí đảo ngược khi bản thiết kế mang lại cảm giác có vẻ đơn giản hơn một cách rõ ràng.