Nguyễn Thu Hà, PMP
Tình huống này minh hoạ gần như hoàn hảo định luật Goodhart: khi một thước đo trở thành mục tiêu, nó không còn là thước đo tốt nữa. Con người rất giỏi tối ưu đúng thứ được thưởng — vấn đề là thứ được thưởng không phải thứ ta thực sự muốn.
Vì sao các KPI trên hỏng:
- Số lỗi đóng đo hoạt động, không đo kết quả (chất lượng khách hàng cảm nhận).
- Số lỗi tìm thấy đặt QA và dev vào thế đối đầu, khuyến khích "ghi càng nhiều càng tốt".
- Velocity theo Agile Alliance là thước đo sau sự việc dùng để lập kế hoạch của chính đội đó; không có ý nghĩa ở cấp cá nhân và không so sánh được giữa các đội. Dùng nó làm chỉ số thành tích gần như chắc chắn dẫn đến lạm phát điểm.
Theo PMBOK 7 – lĩnh vực hiệu suất Measurement: thước đo hiệu quả nên gắn với mục tiêu và giá trị, cân bằng giữa chỉ số dẫn trước (leading) và chỉ số theo sau (lagging), và cần cảnh giác với các bẫy đo lường như hiệu ứng Hawthorne (đo làm thay đổi hành vi), chỉ số "phù phiếm" (vanity metric), thiên kiến xác nhận.
Gợi ý thiết kế lại:
- Đo ở cấp đội, không ở cấp cá nhân, để khuyến khích cộng tác.
- Dùng một rổ chỉ số cân bằng, ví dụ: số lỗi khách hàng phát hiện sau phát hành (theo mức độ nghiêm trọng), thời gian từ khi phát hiện đến khi khắc phục lỗi nghiêm trọng, tỷ lệ lỗi tái mở, mức hài lòng của khách hàng. Một chỉ số đơn lẻ dễ bị "lách"; một rổ chỉ số kéo nhau về cân bằng.
- Tách đo lường để học hỏi khỏi đo lường để thưởng phạt. Dùng số liệu để đội tự cải tiến; khen thưởng dựa trên kết quả chung và đánh giá định tính.
- Cùng đội thiết kế chỉ số và hỏi trước: "nếu muốn làm đẹp số này mà không cải thiện thật, người ta sẽ làm gì?" — đây là bài kiểm tra Goodhart nhanh.
- Rà soát chỉ số định kỳ và sẵn sàng bỏ chỉ số đã bị "ăn mòn".
Với PM, bài học là: trước khi đưa một con số lên báo cáo, hãy nghĩ nó sẽ thay đổi hành vi của ai và theo hướng nào.
Nguồn: