Đo từ lúc bắt đầu đến khi công việc được nghiệm thu
Muốn biết AI có giúp phát triển phần mềm hiệu quả hơn không, hãy đo đến lúc công việc được kiểm tra và chấp nhận bàn giao. Viết code nhanh hơn chưa chắc giúp hoàn thành sớm hơn nếu đội ngũ phải tốn thêm thời gian kiểm tra, sửa lỗi hoặc chờ xác nhận. Số dòng code hay số gợi ý được dùng chỉ cho thấy một phần công việc.
Bài viết này nói về hiệu quả của việc dùng AI hỗ trợ lập trình, không phải độ chính xác của chatbot hay một sản phẩm AI. Mục tiêu là biết AI giúp được việc nào, phát sinh thêm chi phí gì và cần giữ điều kiện chất lượng nào. Hãy đo để tìm câu trả lời, thay vì cố chứng minh một mức tăng năng suất đặt sẵn.
Chọn công việc tương đương để so sánh trước và sau
Đầu tiên, chọn một loại công việc cụ thể và ghi lại cách làm khi chưa dùng AI. Đây là mức cơ sở để so sánh. Ví dụ, bạn có thể chọn viết kiểm thử cho một quy tắc đã rõ hoặc làm màn hình theo thiết kế đã duyệt. Hai cách làm phải có điểm bắt đầu, điểm kết thúc và tiêu chí hoàn thành giống nhau. So một việc dễ với một việc khó sẽ không cho biết tác động thực sự của AI.
Hãy đặt câu hỏi có thể kiểm tra, chẳng hạn: “AI có giúp chuẩn bị bài kiểm thử nhanh hơn mà vẫn phát hiện được các lỗi cần tìm không?”. Câu hỏi này nêu cả điều muốn cải thiện và chất lượng cần giữ. Ghi thêm kinh nghiệm của người làm, mức độ quen công cụ và thay đổi yêu cầu, vì những yếu tố đó cũng có thể ảnh hưởng kết quả.
Ngoài tốc độ viết code, cần đo thêm điều gì?
- Thời gian bàn giao: từ lúc yêu cầu đủ điều kiện bắt đầu đến khi được chấp nhận, gồm cả thời gian chờ.
- Giờ công: thời gian chuẩn bị yêu cầu cho AI, lập trình, kiểm thử, rà soát code và sửa lại.
- Chất lượng: lỗi được phát hiện trước và sau phát hành, phân theo mức ảnh hưởng và nguyên nhân.
- Khả năng bảo trì: người khác có hiểu, sửa và kiểm thử thay đổi mà không phụ thuộc người tạo code không?
- Chi phí: công cụ, thiết lập, đào tạo và xử lý lại, ngoài phần phát triển trực tiếp.
Không nên dùng riêng một con số để thưởng phạt hoặc kết luận hiệu quả. Ví dụ, số lần đưa code vào hệ thống có thể tăng chỉ vì đội ngũ chia nhỏ công việc. Nhiều gợi ý AI được dùng cũng không có nghĩa chúng đều đúng. Hãy xem chỉ số cùng với độ khó của nhiệm vụ và kết quả kiểm tra chất lượng.
Thử trên phạm vi nhỏ với cùng tiêu chuẩn kiểm tra
Ví dụ giả định: đội ngũ thử AI để viết bài kiểm tra cách các phần của hệ thống phối hợp với nhau. Chọn hai nhóm nhiệm vụ có độ khó tương đương và chốt cùng tiêu chuẩn kiểm tra. Một nhóm làm theo cách hiện tại, nhóm kia dùng AI hỗ trợ. Ghi toàn bộ công sức của cả hai, kể cả thời gian thử rồi bỏ một đề xuất AI không dùng được.
Nếu chỉ thử vài nhiệm vụ hoặc người thực hiện có kinh nghiệm khác nhau, kết quả chỉ có giá trị tham khảo trong phạm vi đó. Có thể lặp lại qua các đợt công việc, ghi rõ điểm khác biệt và giới hạn của phép so sánh. Yêu cầu bảo mật vẫn phải được giữ: không đưa dữ liệu nhạy cảm vào công cụ chỉ để thử nghiệm dễ hơn.
Tính số giờ thực sự tiết kiệm sau khi dùng AI
Công sức tiết kiệm ròng là số giờ thực sự giảm sau khi đã tính phần việc phát sinh do dùng AI. Cách tính: tổng giờ công không dùng AI trừ tổng giờ công có AI, với công việc tương đương và cùng tiêu chí nghiệm thu. Phía dùng AI phải tính cả soạn yêu cầu cho công cụ, lập trình, kiểm thử, rà soát, sửa lỗi và phần thời gian thiết lập, đào tạo liên quan. Mỗi khoảng thời gian chỉ ghi một lần.
- Ghi kết quả riêng cho từng loại việc, như viết kiểm thử hoặc làm giao diện, thay vì gộp tất cả vào một con số.
- Giữ lại các trường hợp AI không giúp ích hoặc làm phát sinh sửa lại.
- Phân biệt thời gian thao tác với thời gian chờ phê duyệt và phụ thuộc bên ngoài.
- Ghi lại việc đổi quy trình hoặc nhân sự trong thời gian thử nghiệm vì chúng cũng có thể làm kết quả thay đổi.
| Khoản ghi nhận | Không dùng AI | Có AI hỗ trợ |
|---|---|---|
| Phạm vi và nghiệm thu | Ghi loại việc, độ khó, điều kiện đạt và kết quả | Dùng cùng điều kiện đạt; ghi phần công việc khác nhau nếu có |
| Chuẩn bị yêu cầu thực hiện | Ghi giờ chuẩn bị thông thường | Ghi giờ viết và sửa yêu cầu gửi cho AI |
| Lập trình và kiểm thử | Ghi giờ thực hiện, chưa gồm rà soát/sửa lại bên dưới | Ghi giờ thực hiện và kiểm tra đầu ra ban đầu |
| Rà soát và sửa lại | Ghi giờ kiểm tra độc lập và khắc phục | Tính cả đề xuất bị bỏ, lần thử thất bại và sửa lại |
| Phần thiết lập và đào tạo tính cho nhóm việc này | Ghi phần chi phí thời gian liên quan nếu có | Ghi tổng giờ chuẩn bị chung và cách chia cho từng nhóm công việc |
| Thời gian chờ | Theo dõi riêng, không cộng vào giờ công | Theo dõi riêng để tính thời gian bàn giao |
| Chất lượng sau nghiệm thu | Ghi lỗi theo mức ảnh hưởng trong cùng kỳ theo dõi | Dùng cùng kỳ theo dõi và cách phân loại |
Ví dụ giả định: tính phần tiết kiệm sau rà soát và sửa lỗi
Các con số sau chỉ minh họa cách tính, không phải kết quả dự án của Genki. Giả sử nhóm công việc không dùng AI cần 20 giờ công. Nhóm tương đương dùng AI cần 6 giờ lập trình và kiểm thử, 2 giờ chuẩn bị yêu cầu cho AI, 3 giờ rà soát, 2 giờ sửa lại và 1 giờ thiết lập, đào tạo được tính cho nhóm công việc này.
Tổng khi dùng AI là 6 + 2 + 3 + 2 + 1 = 14 giờ. Phần tiết kiệm là 20 − 14 = 6 giờ, bằng 30% so với cách làm không dùng AI trong ví dụ. Khoản 1 giờ thiết lập và đào tạo có thể được tính bằng cách chia 10 giờ chuẩn bị chung cho 10 nhóm công việc tương đương. Nếu các nhóm dùng công cụ không đều nhau, cần chọn cách chia phù hợp hơn và ghi rõ.
Không trừ thêm giờ rà soát, sửa lỗi hay đào tạo vì chúng đã nằm trong tổng 14 giờ. Nếu dùng AI mất hơn 20 giờ, nghĩa là công sức tăng chứ không tiết kiệm. Giảm giờ công cũng chưa đồng nghĩa giảm tiền chi: cần tính phí công cụ, ngân sách nhân sự và cách dùng thời gian tiết kiệm được. Tỷ lệ 30% trong ví dụ không phải mức có thể áp dụng cho mọi dự án.
Từ kết quả đo, quyết định nên dùng AI cho việc nào
Kết quả đo cần giúp bạn quyết định việc nào nên tiếp tục dùng AI, việc nào cần điều chỉnh và việc nào chưa đủ dữ liệu để kết luận. Chẳng hạn, AI có thể hữu ích với nhiệm vụ rõ yêu cầu nhưng chưa hiệu quả với quy trình nhiều ngoại lệ. Khi đó, hãy giới hạn phạm vi sử dụng thay vì áp dụng cho mọi việc. Các bước rà soát và phê duyệt vẫn cần phù hợp với rủi ro.
Trước khi thử, hãy thống nhất khi nào phải dừng vì chất lượng hoặc bảo mật không đạt. Nếu quyết định mở rộng, vẫn cần đo lại vì công cụ, con người và hệ thống có thể thay đổi. Báo cáo cuối cùng nên chỉ rõ công việc tiếp tục áp dụng, công việc chưa hiệu quả và thông tin còn thiếu, không hứa một mức tăng năng suất cho tất cả dự án.
Để giữ cùng tiêu chuẩn khi so sánh hai cách làm, dùng checklist chất lượng và nghiệm thu mã nguồn