Ngày 7/8, GitHub thêm mục lợi tức đầu tư tiềm năng vào bảng đo tác động của Copilot. Mục này hiển thị các thẻ so sánh theo nhóm mức độ sử dụng, gồm chi phí mỗi lập trình viên mỗi tháng, tỉ lệ chi phí đó trên quỹ lương, và số pull request mở mỗi tháng, kèm một ô chọn mức lương để bạn mô phỏng theo dữ liệu thu nhập của mình.
Đây là cải tiến thật — phần chi phí được tính từ mức tiêu thụ AI credit thực tế chứ không phải giá niêm yết. Nhưng nó cũng thuộc loại bảng đo dễ đẻ ra một slide, và slide làm từ bảng đo thường đánh rơi hết phần lưu ý trên đường đi tới phòng họp.
Các con số thực chất là gì
Trong ba đầu vào thì hai được đo và một do bạn tự đặt, và phân biệt được cái nào là cái nào rất quan trọng.
- Chi phí mỗi lập trình viên mỗi tháng — được đo, tính từ mức tiêu thụ AI credit thực tế của nhóm đó
- Số pull request mỗi tháng — được đo, và là một tín hiệu đầu ra thật
- Mức lương — không được đo. Đây là ô bạn tự chọn, và GitHub nói rõ đó là tham số mô phỏng chứ không phải dữ liệu lương thật
Ai xem được
Chủ sở hữu enterprise, người quản lý thanh toán, chủ sở hữu tổ chức, và bất kỳ ai có vai trò tùy chỉnh mang quyền View Copilot Metrics. Chính sách usage metrics của Copilot phải được bật thì dữ liệu mới đổ về.
Danh sách quyền truy cập đó đáng lưu ý trước khi bạn trình bày các con số: vài người ngồi trong phòng họp có thể tự mở bảng đo lên và kiểm tra bạn đã làm gì với nó.
Thay đổi cách đếm nhóm sẽ tự làm số của bạn nhích lên
GitHub cũng tinh chỉnh cách đếm nhóm mức độ sử dụng, tính cả những người hoạt động trong trọn cửa sổ báo cáo 28 ngày. Hệ quả được nêu rõ là số lượng trong các nhóm sẽ cao lên thấy rõ từ nay về sau.
Với bất cứ ai đang theo dõi xu hướng, đây là dòng quan trọng nhất trong thông báo. Nếu bạn đem bảng đo tháng này so với ảnh chụp màn hình hồi tháng 6 rồi báo cáo phần chênh lệch là mức độ sử dụng đã cải thiện, thì bạn đang báo cáo một thay đổi trong cách đếm của GitHub như thể đó là thay đổi trong hành vi của đội mình.
Hãy đặt lại mốc so sánh. Mọi so sánh trước–sau vắt qua ngày 7/8 đều cần một dòng chú thích, nếu không thì nó sai.
Số pull request là đầu ra, không phải giá trị
Bảng đo so sánh lượng PR giữa các nhóm mức độ sử dụng, và câu chuyện nhân quả thì tự viết ra: nhóm dùng nhiều mở nhiều pull request hơn, vậy Copilot tạo ra khác biệt đó.
Hãy cẩn thận. Mức độ sử dụng không được phân bổ ngẫu nhiên. Những lập trình viên đón công cụ mới nhanh nhất thường cũng là người vốn đã ship nhiều nhất, làm ở những dịch vụ sôi động nhất, và ít bị nghẽn ở hàng chờ rà soát nhất — nên một phần khoảng cách bạn đang nhìn đã tồn tại từ trước khi có Copilot.
Và số PR là thước đo khối lượng. Nó không nói gì về việc những pull request đó có được merge không, có bị revert không, hay đã nằm ba ngày trong hàng chờ rà. Một tính năng khác cũng ra mắt tháng này liên quan trực tiếp ở đây: mức nỗ lực giờ được ghi lại trên pull request, nên độ sâu rà soát cuối cùng cũng ghép được với khối lượng. Số PR tăng đi kèm xu hướng rà soát nhẹ đi là một câu chuyện khác hẳn số PR tăng mà độ sâu rà soát giữ nguyên.
Dùng sao cho đúng
Hãy coi mục ROI là nguồn sinh câu hỏi chứ không phải nguồn cho câu trả lời. Dùng theo cách đó, đây là một trong những thứ hữu ích nhất GitHub làm cho quản lý kỹ thuật trong năm nay.
- Hãy dùng con số chi phí đã được đo — đó là số đáng tin nhất trên trang, và thường cũng là số mà trước đây mọi người vẫn phải đoán
- Đặt ô chọn mức lương ở một con số thật, bảo vệ được, đặt một lần rồi giữ cố định; một giả định trôi nổi làm mọi xu hướng trở nên vô nghĩa
- So sánh giữa các nhóm trong cùng một tháng, thay vì so cùng một nhóm qua nhiều tháng, cho tới khi bạn có mốc sau ngày 7/8
- Ghép số PR với tỉ lệ merge hoặc revert lấy từ nguồn khác trước khi kết luận về đầu ra
- Đừng bao giờ trình bày con số ROI mà bỏ đi lưu ý của chính GitHub: đây là ước tính và một mô hình, không phải sổ sách kế toán