Ngừng đo năng suất nhà phát triển. Hãy đo vận tốc quyết định.

Chỉ số nguy hiểm nhất trong kỹ thuật phần mềm hiện nay không phải là một chỉ số tệ. Nó là một chỉ số gây xao nhãng.

Chúng ta vẫn đo năng suất nhà phát triển theo cách của năm 2015: commit, pull request, story point, cycle time. Không chỉ số nào trong số này cho bạn biết tổ chức kỹ thuật của mình có đang ra quyết định đúng hay không. Và trong kỷ nguyên AI, chất lượng quyết định mới là chỉ số duy nhất đáng kể.

Vì sao các chỉ số truyền thống thất bại

AI đã nén chi phí viết code xuống gần bằng không. Một đội đưa ra quyết định kiến trúc sai giờ có thể xuất xưởng hệ thống sai nhanh gấp đôi. Họ có thể tạo thêm nhiều bài kiểm thử cho sự trừu tượng sai. Họ có thể xây thêm nhiều tính năng trên nền móng sai.

Quan điểm truyền thống về năng suất cho rằng nhiều đầu ra hơn nghĩa là nhiều giá trị hơn. Giả định đó đã vỡ. Khi code rẻ, những quyết định tệ lại đắt đỏ — và các chỉ số đo đầu ra sẽ không bao giờ bắt được chúng.

Vận tốc quyết định thực sự nghĩa là gì

Vận tốc quyết định không phải là ra quyết định nhanh hơn. Nó là hội tụ nhanh hơn vào quyết định đúng, với ít lần đảo ngược tốn kém hơn.

Tôi đo nó qua bốn tín hiệu:

1. Tốc độ quyết định: Mất bao lâu để đưa ra một quyết định có thể đảo ngược? (Nên là vài giờ, không phải vài ngày.)

1. Chất lượng quyết định: Có bao nhiêu quyết định bị đảo ngược trong vòng 90 ngày, và cái giá của việc đảo ngược là gì?

1. Phân bổ quyết định: Có bao nhiêu người trong tổ chức được trao quyền ra quyết định kỹ thuật mà không cần leo thang?

1. Tích lũy quyết định: Các quyết định hôm nay đang khiến các quyết định ngày mai dễ dàng hơn hay khó khăn hơn?

Điều gì thay đổi khi bạn đo lường điều này

Khi bạn bắt đầu đo vận tốc quyết định, một số điều sẽ thay đổi:

• Các buổi đánh giá kiến trúc trở nên nhanh hơn vì thông tin nền tảng được thiết lập trước khi con người tranh luận

• Các mô hình leo thang trở nên hiển hiện — bạn thấy chính xác nơi các quyết định bị tắc nghẽn và vì sao

• Chi phí đảo ngược trở nên rõ ràng — các đội bắt đầu đo cái giá của quyết định sai, điều này thay đổi cách họ đánh giá rủi ro

• Ranh giới quyền hạn trở nên rõ ràng — bạn có thể thấy quyết định nào được đưa ra ở cấp nào và sự phân bổ đó có lành mạnh hay không

Bảng điều khiển thay thế các chỉ số sprint

Tôi không quan tâm đội của tôi đã hoàn thành bao nhiêu story point trong sprint vừa rồi. Tôi quan tâm đến:

• Mất bao lâu để quyết định kiến trúc cho dịch vụ mới?

• Quyết định đó có bị đảo ngược không, và nếu có, cái giá là gì?

• Có bao nhiêu quyết định kỹ thuật được đưa ra mà không có sự tham gia của lãnh đạo kỹ thuật?

• Thời gian trung bình từ "chúng ta gặp vấn đề" đến "chúng ta có kế hoạch giải quyết nó" là bao lâu?

Đây mới là các chỉ số dự đoán kết quả kỹ thuật. Commit chẳng dự đoán được gì.

Phần khó nhất

Đo vận tốc quyết định đòi hỏi lòng tin. Nó đòi hỏi thừa nhận rằng một số quyết định đã sai và học hỏi công khai từ chúng. Hầu hết văn hóa kỹ thuật trừng phạt các quyết định sai. Đo vận tốc quyết định đòi hỏi điều ngược lại: đưa các lần đảo ngược ra như dữ liệu, không phải như thất bại.

Những đội làm tốt điều này tạo ra một văn hóa mà "tôi đã sai" là tín hiệu cho thấy hệ thống ra quyết định đang hoạt động. Những đội không làm vậy sẽ tiếp tục tối ưu cho tốc độ đầu ra, trong khi đối thủ của họ tối ưu cho tốc độ học hỏi.

Bắt đầu từ đây

Chọn một quyết định kỹ thuật gần đây không thành công. Hãy tự hỏi: chúng ta mất bao lâu để nhận ra nó sai? Điều gì có thể khiến vấn đề lộ ra sớm hơn? Chúng ta đã không đo tín hiệu nào?

Khoảng trống đó chính là nơi vận tốc quyết định của bạn trú ngụ.

Bạn muốn ở trong một đội xuất xưởng nhanh nhưng thường xuyên đảo ngược, hay một đội xuất xưởng có chủ đích và học hỏi tiến lên?

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.