Khi Tài liệu Kết quả Đo lường Sai thứ

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

Một bản triển khai đã hoạt động tốt trong đợt triển khai kiểm soát (controlled rollout) sẽ có dữ liệu đứng đằng sau hỗ trợ. Một Kiến trúc sư khi khép lại dự án sẽ có đầy đủ mọi thứ họ cần để viết tài liệu kết quả (outcome document). Việc viết nó thật nhanh từ các chỉ số kỹ thuật đã có sẵn mang lại cảm giác là một nước đi đúng đắn, và dự án kết thúc trước khi bất kỳ ai kịp nhận ra những gì tài liệu đó không thể trả lời.

Một câu chuyện thực tế: Tài liệu kết quả không thể sống sót qua câu hỏi đầu tiên của CFO

Một Kiến trúc sư đã tạo ra tài liệu kết quả khách hàng bằng cách sử dụng các chỉ số dễ trích xuất nhất từ stack khả năng quan sát (observability stack): lưu lượng yêu cầu, độ trễ trung bình, và tỷ lệ lỗi.

Nhà tài trợ dự án của phía khách hàng (customer sponsor) đã mang nó tới Giám đốc Tài chính (CFO) của họ để bào chữa cho việc mở rộng quy mô bản triển khai. Câu hỏi đầu tiên của CFO là bản triển khai đã tiết kiệm hoặc tạo ra được những gì dưới góc độ kinh doanh, và tài liệu đã không thể trả lời được.

Hai trường thông tin lẽ ra đã làm cho tài liệu trở nên hữu dụng thì chưa bao giờ được điền vào. Dưới đây là cách kịch bản đó diễn ra:

• Nhà tài trợ mở đầu bằng tài liệu đúng như cách nó được viết: "Đây là bản triển khai. 40.000 yêu cầu một tháng, độ trễ trung bình dưới 2 giây, tỷ lệ lỗi dưới 0,5%."

• CFO: "Điều đó chỉ nói cho tôi biết là hệ thống ĐANG CHẠY. Nó đã làm được gì cho chúng ta? Thời gian xử lý bồi thường (claim processing time) trước đây là bao nhiêu, và hiện tại là bao nhiêu? Bởi vì ĐÓ mới là con số bào chữa cho việc chi tiêu thêm tiền."

Nhà tài trợ không có bất kỳ bằng chứng nào để chỉ ra. Tài liệu đã đo lường rằng hệ thống hoạt động, nhưng nó không đo lường những gì hệ thống đã thay đổi.

Vấn đề cốt lõi: Tài liệu thu thập các chỉ số kỹ thuật mà bỏ qua Kết quả Kinh doanh

Lưu lượng (volume), độ trễ (latency), và tỷ lệ lỗi (error rate) là các chỉ số thực tế và đáng theo dõi, nhưng không có chỉ số nào trong số đó là một kết quả kinh doanh (business outcome).

Các trường thông tin lẽ ra sẽ làm cho tài liệu trở nên hữu dụng cho cuộc trò chuyện với CFO bao gồm:

1. Sự so sánh Trước-và-Sau (before-and-after) trên chỉ số kinh doanh mà use case nhắm tới (thời gian xử lý bồi thường).

2. Cơ chế kiểm soát (control) giúp sự so sánh đó có thể kiểm toán được.

Nếu không có con số "Trước đó", sẽ không có câu chuyện nào để kể. Nếu không có cơ chế kiểm soát, con số "Sau đó" chỉ đơn thuần là một lời khẳng định suông. Tài liệu đã hoàn chỉnh như một bản ghi kỹ thuật và hoàn toàn vô dụng như một lập luận cho việc mở rộng quy mô.

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

Các chỉ số dễ trích xuất hiếm khi là những chỉ số giúp bào chữa cho chi phí.

Stack khả năng quan sát thu thập các chỉ số kỹ thuật của bạn một cách tự động, nhưng nếu không tân chúng vào dữ liệu kinh doanh thực tế, bạn sẽ chỉ còn lại các dashboard trông có vẻ nhiều thông tin nhưng không mang lại ý nghĩa kinh doanh nào.

Bài học cốt lõi: Tài liệu kết quả tồn tại cho một người đọc khác — nhà tài trợ, người bắt buộc phải bào chữa cho bản triển khai lên cấp trên.

Hãy thu thập chỉ số "Trước đó" ngay từ khi bắt đầu, gọi tên cơ chế kiểm soát giúp sự so sánh có thể kiểm toán được, và bổ sung ghi chú về khả năng tái sử dụng (reuse note), để tài liệu có thể thực hiện một nhiệm vụ duy nhất mà một dashboard kỹ thuật không bao giờ làm được.