Kỹ năng khó nhất trong công nghệ doanh nghiệp không phải là kỹ thuật, mà là đưa ra quyết định với dữ liệu không đầy đủ.

Mỗi ngày trong công nghệ doanh nghiệp, người ta đòi hỏi sự chắc chắn trước khi hành động.

"Đưa tôi thêm dữ liệu." "Hãy chạy thêm một phân tích nữa." "Chúng ta cần chắc chắn trước khi cam kết."

Chính tôi cũng từng mắc lỗi này. Sự trì hoãn mang lại một cảm giác dễ chịu — nó có vẻ nghiêm túc, có vẻ trách nhiệm. Nhưng đây là điều tôi học được sau hai thập kỷ xây dựng hệ thống và vận hành:

Yêu cầu sự chắc chắn gần như luôn là một yêu cầu ngụy trang để tránh đưa ra quyết định.

Và những hệ thống chiến thắng không phải là hệ thống có nhiều dữ liệu nhất, mà là những hệ thống đã học cách hành động dứt khoát trong sự mơ hồ.

Cái bẫy dữ liệu

Chúng ta đã nội hóa ý tưởng rằng nhiều dữ liệu hơn đồng nghĩa với quyết định tốt hơn. Và đôi khi đúng là như vậy. Nhưng thường thì, nhiều dữ liệu hơn chỉ tạo ra nhiều nhiễu hơn.

Tôi đã chứng kiến các đội dành hàng tuần để thu thập thêm các điểm dữ liệu, xây dựng dashboard, chạy hồi quy — tất cả chỉ để né tránh sự thật rằng quyết định đó vốn sẽ không bao giờ trở nên rõ ràng. Dữ liệu bổ sung không làm giảm sự bất định, mà chỉ khiến sự bất định trông phức tạp hơn.

Kỹ năng thực sự không phải là thu thập dữ liệu, mà là biết:

Dữ liệu nào thực sự quan trọng cho quyết định này Bạn cần bao nhiêu tự tin để hành động (không phải 100%, không bao giờ 100%) Điều bạn sẵn sàng sai

Hầu hết các đội tối ưu cho điều đầu tiên và bỏ qua hai điều còn lại. Đó chính là nơi sự tê liệt tồn tại.

Kiến trúc của sự mơ hồ

Những hệ thống tôi xây dựng tồn tại lâu nhất không phải là hệ thống có kiến trúc thanh lịch nhất, mà là những hệ thống được thiết kế để vận hành trong điều kiện bất định.

Điều đó có nghĩa là:

Các phương án dự phòng chế độ suy giảm — hệ thống làm gì khi một nguồn dữ liệu ngừng hoạt động? Không phải "nó sập", mà là nó mặc định chuyển về trạng thái nào?

Các cổng quyết định thừa nhận sự bất định — không phải "nếu X thì Y", mà là "nếu chúng ta có độ tin cậy cao vào X, hãy làm Y; nếu ở mức trung bình, hãy leo thang; nếu thấp, hãy quay về mặc định an toàn."

Các vòng phản hồi khép lại nhanh — bạn càng biết nhanh một quyết định có đúng hay không, thì càng ít thời gian phải bỏ ra để phân tích trước khi quyết định.

Đây là cách bạn xây dựng các hệ thống vận hành trơn tru. Không phải bằng cách loại bỏ sự mơ hồ, mà bằng cách thiết kế cho nó.

Điều này có ý nghĩa gì với các nhà lãnh đạo

Khả năng chịu đựng sự mơ hồ bắt đầu từ cấp cao nhất. Nếu bạn, với tư cách là lãnh đạo, đòi hỏi sự chắc chắn trước khi phê duyệt một quyết định, thì đội của bạn sẽ dành năng lượng để tạo ra sự chắc chắn thay vì giải quyết vấn đề.

Họ sẽ đưa cho bạn khoảng tin cậy mà bạn muốn nghe, thay vì khoảng phản ánh thực tế.

Phương án thay thế khó hơn nhưng trung thực hơn:

"Tôi không biết liệu điều này có hiệu quả không. Nhưng tôi biết cách chúng ta sẽ tìm ra, tốc độ chúng ta có thể điều chỉnh hướng đi, và giới hạn của phần rủi ro là ở đâu."

Đó mới là một kế hoạch thực sự. Còn câu "đưa tôi thêm dữ liệu" chỉ là sự trì hoãn được ngụy trang thành sự chuyên cần.

Sự thật khó chịu

Không có lượng dữ liệu nào có thể loại bỏ sự bất định trong các hệ thống phức tạp. Thế giới thay đổi quá nhanh. Các biến số quá đan xen. Tương lai không nằm gọn trong một bảng tính.

Những tổ chức xử lý tốt điều này không phải là những tổ chức có dashboard tốt nhất hay đội dữ liệu lớn nhất, mà là những tổ chức đã rèn luyện khả năng đưa ra quyết định với những gì mình có — và điều chỉnh nhanh khi sai.

Dấu hỏi không bao giờ biến mất. Bạn chỉ học cách tin vào các công cụ đo lường của mình dù sao đi nữa.

Nghĩ rằng lập luận này phù hợp với sự kiện của bạn? Hãy kể cho tôi về khán phòng — lịch trình có chọn lọc.