Đo hiệu quả AI lập trình trong nhóm không nên dựa vào số dòng mã hay tỉ lệ gợi ý được nhận: hai con số đó tăng dễ dàng mà không nói gì về giá trị. Nên theo dõi những thứ nhóm vốn quan tâm: việc đi từ lúc bắt đầu tới lúc lên thật mất bao lâu, bao nhiêu thay đổi gây sự cố, thời gian rà soát, và cảm nhận của chính lập trình viên.
Bài này dành cho trưởng nhóm kỹ thuật cần trả lời câu hỏi của cấp trên hoặc của chính mình: tiền và công sức bỏ vào công cụ AI có đáng không. Bài dựa trên các khung đo đã được dùng rộng rãi trong nghề như bốn chỉ số của chương trình nghiên cứu DORA và khung SPACE, kèm cách áp vào nhóm nhỏ ở Việt Nam mà không cần mua công cụ đo đắt tiền.
Vì sao số dòng mã và tỉ lệ nhận gợi ý đánh lừa
Số dòng mã là thước đo năng suất bị phê phán từ lâu trước khi có AI, vì cùng một việc, người giỏi thường viết ít dòng hơn. Với AI, vấn đề nặng thêm: sinh thêm mã gần như không tốn công, nên số dòng tăng vọt mà giá trị có thể không đổi, thậm chí giảm vì mã nhiều hơn là gánh bảo trì nhiều hơn. Một nhóm được khen vì số dòng tăng gấp đôi có thể đang chất thêm nợ kỹ thuật gấp đôi.
Tỉ lệ gợi ý được nhận, con số nhiều công cụ hiển thị sẵn trên bảng quản trị, cũng dễ hiểu sai. Lập trình viên nhận một gợi ý rồi xoá đi ba dòng sau vẫn được tính là đã nhận. Người hay nhận gợi ý ngắn kiểu đóng ngoặc có tỉ lệ cao mà không tiết kiệm được bao nhiêu. Con số này có ích để xem công cụ có hợp với ngôn ngữ của dự án không, nhưng không đo được giá trị cho sản phẩm.
Có một cái bẫy chung: khi một con số trở thành mục tiêu, người ta tối ưu con số chứ không tối ưu điều nó đại diện. Nếu nhóm biết mình được đánh giá theo mức dùng AI, mức dùng sẽ tăng, bất kể có ích hay không. Vì vậy chỉ số nên đo kết quả của cả nhóm, không đo mức dùng công cụ của từng người.
Bốn chỉ số giao hàng phần mềm và cách đọc khi có AI
Bốn chỉ số dưới đây xuất phát từ chương trình nghiên cứu DORA và được trình bày trong cuốn Accelerate (Forsgren, Humble, Kim, 2018). Chúng đo cả nhóm và cả quy trình, nên khó bị làm đẹp bởi riêng một công cụ.
| Chỉ số | Đo gì | Khi có AI, chú ý điều gì |
|---|---|---|
| Tần suất triển khai | Bao lâu nhóm đưa thay đổi lên môi trường thật một lần | Tăng là tốt nếu tỉ lệ sự cố không tăng theo |
| Thời gian từ ghi nhận tới lên thật | Một thay đổi mất bao lâu từ lúc ghi nhận tới lúc chạy thật | AI rút ngắn phần viết; nếu tổng không giảm, nút thắt nằm ở rà soát hay kiểm thử |
| Tỉ lệ thay đổi gây sự cố | Phần trăm lần triển khai phải sửa gấp hoặc hoàn tác | Chỉ số cảnh báo sớm nhất nếu mã AI viết lọt lỗi |
| Thời gian khôi phục | Khi có sự cố, mất bao lâu để hệ thống chạy lại bình thường | Mã nhóm không hiểu rõ thường làm thời gian này dài ra |
Bạn không cần công cụ chuyên dụng để có số liệu thô. Lịch sử ghi nhận, lịch sử yêu cầu gộp trên nền tảng lưu kho và nhật ký triển khai đủ để tính tay mỗi tháng một lần cho nhóm nhỏ. Điều quan trọng là đo trước khi đưa AI vào ít nhất vài tuần để có mốc so sánh.
Những chỉ số bổ sung riêng cho thời có AI
Thời gian chờ rà soát. Từ lúc mở yêu cầu gộp đến lúc có người rà đầu tiên, và tổng thời gian rà. Nếu AI giúp viết nhanh mà hàng đợi rà phình ra, năng suất chỉ dời chỗ. Đây thường là nút thắt đầu tiên lộ ra.
Cỡ yêu cầu gộp. Số dòng thay đổi trung bình mỗi yêu cầu gộp. Cỡ tăng đều là dấu hiệu AI làm việc lớn quá mà không ai tách, kéo theo rà kém kỹ.
Tỉ lệ yêu cầu gộp phải sửa nhiều vòng. Số yêu cầu gộp cần trên hai vòng góp ý. Tăng có thể do mã AI viết chưa hợp quy ước dự án, gợi ý cập nhật tệp hướng dẫn.
Thay đổi bị sửa lại sớm. Tỉ lệ mã bị sửa hoặc xoá trong vài tuần sau khi gộp. Mã viết vội, kể cả do AI, thường bị viết lại sớm; con số này lấy được từ lịch sử git.
Chi phí công cụ trên mỗi người. Theo mức sử dụng thực tế, so với giờ công ước tính tiết kiệm được. Ghi số theo tháng, không cần chính xác tuyệt đối, chỉ cần đủ để thấy xu hướng.
Đo cảm nhận: phần định tính không được bỏ
Khung SPACE, do một nhóm nhà nghiên cứu trong đó có Nicole Forsgren đề xuất năm 2021, nhấn mạnh rằng năng suất lập trình viên có nhiều chiều: sự hài lòng, kết quả, hoạt động, giao tiếp và cộng tác, hiệu quả và mạch làm việc. Không chiều nào đủ một mình. Với AI, chiều cảm nhận đặc biệt quan trọng vì nhiều tác động không hiện ra trong số liệu: lập trình viên có thấy đỡ mệt với việc nhàm chán không, có thấy mất mạch vì gợi ý nhiễu không, có lo kỹ năng mình mai một không.
Cách đo đơn giản là khảo sát ngắn mỗi tháng, năm câu, ẩn danh, trả lời theo thang năm mức kèm một ô viết tự do. Ví dụ câu hỏi: AI giúp bạn hoàn thành việc nhanh hơn ở loại việc nào; loại việc nào AI làm bạn chậm đi; bạn tự tin thế nào khi giải thích mã có AI tham gia trong yêu cầu gộp của mình; bạn có thấy rà mã của người khác khó hơn không.
Kết quả khảo sát nên được đọc cùng số liệu quy trình. Nếu cảm nhận tốt mà tỉ lệ sự cố tăng, nhóm đang vui với tốc độ mà chưa thấy cái giá. Nếu số liệu tốt mà cảm nhận xấu đi, có thể người rà đang gánh quá tải, và sớm muộn con số cũng xấu theo.
Đọc số liệu một quý: ví dụ giả định
Một nhóm tám người làm phần mềm quản lý kho, đưa trợ lý AI vào từ đầu quý. Mốc trước đó: thời gian trung bình từ ghi nhận tới lên thật khoảng năm ngày, tỉ lệ thay đổi gây sự cố khoảng một phần mười, yêu cầu gộp chờ người rà đầu tiên khoảng nửa ngày. Mọi con số trong ví dụ này là giả định để minh hoạ cách đọc.
Sau tháng đầu, thời gian chờ rà tăng lên gần hai ngày, cỡ yêu cầu gộp trung bình tăng gần gấp đôi, tổng thời gian tới lên thật gần như không đổi. Khảo sát cho thấy người viết hài lòng, người rà mệt. Cách đọc: AI rút ngắn phần viết, nhưng việc dồn sang phần rà. Nhóm áp ngưỡng cỡ yêu cầu gộp và luân phiên người rà chính mỗi ngày.
Sau tháng thứ ba, thời gian chờ rà về lại khoảng nửa ngày, tổng thời gian tới lên thật còn khoảng ba ngày rưỡi, tỉ lệ sự cố giữ nguyên. Một chỉ số xấu đi: mã bị sửa lại trong hai tuần sau gộp tăng ở mô-đun báo cáo. Nhóm phát hiện tác tử hay viết truy vấn không theo lớp truy cập dữ liệu chung, bèn thêm một dòng vào tệp hướng dẫn dự án và một ADR. Kết luận quý gửi cấp trên gồm cả phần tốt lẫn phần đang sửa.
Thiết lập đo lường trong một tháng cho nhóm nhỏ
Không cần hệ thống phức tạp; một bảng tính và lịch nhắc là đủ để bắt đầu:
- Chọn ba đến năm chỉ số: thời gian từ ghi nhận tới lên thật, tỉ lệ thay đổi gây sự cố, thời gian chờ rà soát, cỡ yêu cầu gộp, cộng khảo sát cảm nhận.
- Lấy số liệu bốn đến tám tuần gần nhất từ lịch sử nền tảng lưu kho và nhật ký triển khai làm mốc.
- Thống nhất với nhóm rằng số đo dành cho nhóm, không dùng đánh giá cá nhân. Nói rõ và làm đúng như vậy.
- Mỗi tháng cập nhật bảng, xem cùng nhóm trong buổi nhìn lại, hỏi điều gì giải thích được thay đổi.
- Sau một quý, quyết định: giữ, đổi cách dùng, hay thu hẹp công cụ. Viết quyết định và lý do lại.
Đừng đo quá nhiều. Mười hai chỉ số không ai đọc kém hơn ba chỉ số được bàn mỗi tháng. Và đừng chờ số đẹp mới báo cáo lên trên; báo cáo trung thực một tháng xấu kèm cách xử lý tạo niềm tin hơn chuỗi số đẹp mà không ai giải thích được.
Những cách đo nên tránh
Một số cách đo nghe hợp lý nhưng gây hại cho nhóm:
- Xếp hạng lập trình viên theo mức dùng AI hay số yêu cầu gộp: khuyến khích làm nhiều thay vì làm đúng, và phá văn hoá rà soát.
- So nhóm dùng AI với nhóm không dùng trong cùng thời gian mà không tính khác biệt về loại việc: nhóm làm tính năng mới và nhóm bảo trì hệ thống cũ có nhịp rất khác nhau.
- Tin vào con số "tiết kiệm bao nhiêu giờ" do công cụ tự báo: con số đó thường dựa trên giả định của nhà cung cấp, không phải đo trên nhóm bạn.
- Đo trong hai tuần đầu: giai đoạn làm quen luôn có biến động, kết luận lúc đó dễ sai cả hai chiều.
- Chỉ đo tốc độ, quên chất lượng: thời gian giao việc giảm mà tỉ lệ sự cố tăng là đổi chất lượng lấy tốc độ, không phải năng suất.
Nguyên tắc chung: số đo là để nhóm tự hiểu mình và điều chỉnh, không phải để chứng minh một quyết định mua công cụ là đúng. Nếu bạn bắt đầu đo với kết luận sẵn trong đầu, số liệu nào rồi cũng sẽ được đọc theo kết luận đó.
Câu hỏi thường gặp
Cấp trên muốn một con số duy nhất về hiệu quả AI thì trả lời thế nào?
Đưa thời gian từ ghi nhận tới lên thật đặt cạnh tỉ lệ thay đổi gây sự cố, so trước và sau, kèm một hai câu giải thích. Một cặp số tốc độ và chất lượng nói thật hơn bất kỳ con số đơn lẻ nào, và đủ gọn để báo cáo.
Nhóm năm người có đủ dữ liệu để đo không?
Đủ để thấy xu hướng nếu đo theo tháng và đọc cẩn thận, không đủ để kết luận thống kê chặt. Với nhóm nhỏ, kết hợp số liệu thô với khảo sát và thảo luận trong buổi nhìn lại đáng tin hơn dựa vào riêng con số.
Có nên dùng số liệu của công cụ AI cung cấp không?
Dùng làm tham khảo về mức sử dụng và độ hợp của công cụ với dự án. Không dùng làm thước đo hiệu quả chính, vì nó đo hoạt động trong công cụ chứ không đo kết quả giao hàng của nhóm.
Hiệu quả AI thường lộ ra sau bao lâu?
Thường cần vài tháng để nhóm quen cách giao việc, cập nhật tệp hướng dẫn và điều chỉnh quy trình rà. Tháng đầu có thể chậm hơn. Vì vậy nên đặt mốc đánh giá sau một quý thay vì vài tuần.
Làm sao để nhóm không lo bị đánh giá qua số đo?
Nói rõ từ đầu rằng số đo ở cấp nhóm, không có bảng theo từng người, và giữ đúng lời. Mời nhóm cùng chọn chỉ số và cùng đọc kết quả. Khi nhóm thấy số đo dẫn tới cải tiến quy trình chứ không dẫn tới phê bình, họ sẽ hợp tác.
Có cần đo riêng cho tác tử tự mở yêu cầu gộp không?
Có, nếu nhóm dùng luồng đó. Theo dõi tỉ lệ yêu cầu gộp của tác tử được gộp, thời gian người duyệt bỏ ra cho mỗi cái, và tỉ lệ phải hoàn tác sau khi gộp, để biết loại việc nào đáng giữ cho tác tử.