Vì sao số dòng code là thước đo năng suất tồi?

Vì nó đo lượng viết ra chứ không đo giá trị. Giải pháp tốt thường ngắn hơn, và xóa code thừa là một đóng góp. Khi biến số này thành mục tiêu, người ta sẽ làm nó tăng, kể cả bằng code cồng kềnh, đúng như luật Goodhart mô tả. Nó còn tăng vọt khi dùng AI nhưng không phản ánh giá trị thêm.

Nên đo năng suất kỹ thuật bằng gì?

Dùng bộ chỉ số theo nhóm, không theo cá nhân. DORA có bốn chỉ số: tần suất triển khai, thời gian từ commit đến chạy thật, tỷ lệ thay đổi gây lỗi và thời gian khôi phục. Khung SPACE của Microsoft và GitHub (2021) thêm sự hài lòng, giao tiếp và dòng chảy công việc, với nguyên tắc không chỉ số đơn lẻ nào đủ. Hãy ghép chỉ số tốc độ với chỉ số chất lượng.

AI làm thay đổi việc đo năng suất thế nào?

AI làm các chỉ số hoạt động tăng nhanh mà chưa chắc giá trị tăng theo. Dữ liệu Faros AI (2025) ghi nhận nhóm dùng AI nhiều gộp thêm khoảng 98% thay đổi, kích thước mỗi thay đổi tăng khoảng 154% và thời gian duyệt tăng khoảng 91%. Đây là dữ liệu của một hãng bán công cụ đo lường, nên cần đọc thận trọng, nhưng nó cho thấy số hoạt động và số giao hàng có thể tách khỏi nhau.

Làm sao nói chuyện với quản lý đang muốn đo bằng số dòng code?

Bắt đầu bằng điều họ cần: biết nhóm có giao hàng đều và an toàn không. Đề nghị thay bằng hai hoặc ba chỉ số kết quả như thời gian giao hàng và tỷ lệ lỗi sau phát hành, dùng theo xu hướng của nhóm. Kể chuyện âm 2000 dòng hoặc một ví dụ trong chính dự án của bạn để minh họa.

Tư duy sản phẩm

Đừng đo năng suất bằng số dòng code

Số dòng code là số dễ đếm nhất và dễ gây hiểu lầm nhất, nhất là khi AI viết cả nghìn dòng trong vài giây. Bài này giải thích vì sao, kể chuyện âm 2000 dòng, và đưa bộ chỉ số thay thế theo nhóm, kèm cách dùng không gây hại.

Nhu Duy Thin (Thinnd)29/10/2026, 16:409 phút đọc

#năng suất
#chỉ số
#DORA
#SPACE
#AI
#quản lý kỹ thuật

Bản trình chiếu

Bấm vào slide rồi dùng phím mũi tên để chuyển trang. Phím L đổi ngôn ngữ, phím F để toàn màn hình.

Mở toàn màn hình

Dành cho lập trình viên, trưởng nhóm và người quản lý sản phẩm. Từ kỹ thuật nào cũng có giải thích ngắn.

Số liệu lấy từ nguồn công khai ở cuối bài, nhiều nguồn do hãng công nghệ công bố nên cần đọc thận trọng. Nhân vật "Hùng" và "nhóm Mận" là ví dụ minh họa dựng lại cho dễ hình dung, không phải người thật.

Tóm tắt nhanh#

Số dòng code đo lượng viết ra, không đo giá trị giao ra. Giải pháp tốt thường ngắn hơn, và xóa code thừa là một đóng góp.
Khi một số trở thành mục tiêu thì nó bị bóp méo (luật Goodhart). Người ta sẽ làm số đó đẹp, kể cả bằng cách làm sản phẩm tệ hơn.
Thời AI nó càng vô nghĩa: AI viết hàng nghìn dòng trong vài giây, nên số dòng tăng mà giá trị chưa chắc tăng.
Hãy đo theo nhóm và theo kết quả: thời gian giao hàng, tỷ lệ thay đổi gây lỗi, thời gian chờ duyệt, công việc làm lại, sự hài lòng.
Dùng chỉ số theo xu hướng, ghép tốc độ với chất lượng, và không xếp hạng cá nhân bằng chúng.

Từ khó, nói dễ#

Thuật ngữ	Nói dễ hiểu
LOC (lines of code)	Số dòng code.
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, vì người ta làm sao cho số đẹp.
DORA	Bộ bốn chỉ số về giao hàng phần mềm của một chương trình nghiên cứu lâu năm.
SPACE	Khung năm chiều về năng suất do nhà nghiên cứu Microsoft và GitHub đề xuất (2021).
Thời gian giao hàng (lead time)	Từ lúc commit đến lúc chạy thật cho người dùng.
Tỷ lệ thay đổi gây lỗi	Trong các lần phát hành, bao nhiêu phần cần sửa gấp hoặc hoàn tác.
Công việc làm lại (rework)	Phần code vừa viết đã phải sửa hoặc bỏ trong thời gian ngắn.

1. Chuyện âm 2000 dòng#

Đầu năm 1982, nhóm làm máy Lisa của Apple có quản lý muốn đo năng suất kỹ sư bằng số dòng code viết mỗi tuần, và mỗi người phải điền một mẫu. Theo Andy Hertzfeld kể lại trên folklore.org, Bill Atkinson khi đó đang tối ưu phần xử lý vùng của thư viện đồ họa QuickDraw. Ông thay bằng một thuật toán đơn giản hơn, làm các thao tác vùng nhanh hơn khoảng sáu lần, và như một hệ quả, bớt đi khoảng 2000 dòng code.

Đến mục điền mẫu, ông ghi -2000. Theo lời kể, ít tuần sau người ta thôi yêu cầu ông điền mẫu.

Đây là một giai thoại, kể lại qua nhiều nguồn, nên đừng coi từng chi tiết là chính xác. Nhưng ý của nó vẫn đứng vững: công việc giỏi nhất của tuần đó làm cho số dòng giảm đi.

2. Vì sao số dòng code sai#

Có ba lý do đơn giản.

Nó đo chữ, không đo kết quả. Người dùng không trả tiền cho dòng code. Họ trả cho việc giải quyết vấn đề của họ.
Ít hơn thường là tốt hơn. Code ít hơn nghĩa là ít chỗ lỗi, ít thứ phải đọc, ít thứ phải bảo trì.
Dễ bị chơi. Khi số dòng là mục tiêu, cách rẻ nhất để tăng nó là viết dài, tách nhỏ vô nghĩa, hoặc chép dán.

Trường hợp cuối là luật Goodhart: khi một chỉ số trở thành mục tiêu thì nó thôi là chỉ số tốt. Số dòng code, số commit và điểm story là những ví dụ kinh điển.

3. Ví dụ minh họa: nhóm Mận và bảng xếp hạng#

Ví dụ minh họa, nhân vật dựng lại.

Nhóm Mận bốn người. Quản lý bắt đầu treo bảng "số dòng code mỗi tuần" lên kênh chung, với ý tốt là tạo động lực.

Tuần 1. Hùng viết 900 dòng. Lan chỉ 120 dòng vì dành cả tuần gỡ một lỗi khó khiến khách hàng phàn nàn.
Tuần 3. Lan thấy tên mình ở cuối bảng. Cô dừng việc dọn code cũ và quay sang viết thêm tính năng nhỏ.
Tuần 6. Hùng dùng AI sinh 3000 dòng, trong đó nhiều đoạn chép lại nhau. Bảng đẹp lên, nhưng thời gian duyệt tăng gấp đôi và hai lỗi lọt vào phát hành.
Tuần 8. Nhóm hiểu bảng không nói điều quản lý cần biết, nhưng ai cũng đã thay đổi hành vi.

Điều đáng nói là hành vi thay đổi nhanh hơn việc phát hiện ra thước đo sai.

4. Thời AI, vấn đề nặng hơn#

AI làm việc tạo ra code rẻ, nên mọi thước đo dựa trên lượng code đều phình ra.

Dữ liệu Faros AI (7/2025, hơn 10.000 lập trình viên ở 1.255 nhóm) ghi nhận nhóm dùng AI nhiều gộp thêm khoảng 98% thay đổi, mỗi thay đổi lớn hơn khoảng 154%, và thời gian duyệt mỗi thay đổi tăng khoảng 91%. Đây là dữ liệu của hãng bán công cụ đo lường, là tương quan, và mình mới đọc bản tóm tắt.
Nghiên cứu của METR (7/2025) trên 16 lập trình viên giàu kinh nghiệm thấy họ chậm hơn khoảng 19% khi dùng công cụ AI đầu 2025, dù tin mình nhanh hơn khoảng 20%. Mẫu nhỏ và công cụ đã đổi, nhưng nó cho thấy cảm giác về tốc độ và tốc độ thật có thể lệch nhau.

Hai điều này gợi ý: số hoạt động (dòng, commit, PR) và số giao hàng có thể tách rời. Đo hoạt động trong thời AI giống đo tốc độ xe bằng số vòng quay bánh, trong khi xe đang trượt.

5. Nên đo gì thay thế#

Hai khung được dùng nhiều, và cả hai đều nhấn mạnh nhóm và nhiều chiều.

DORA, bốn chỉ số về giao hàng

Chỉ số	Câu hỏi nó trả lời
Tần suất triển khai	Nhóm phát hành bao lâu một lần?
Thời gian giao hàng	Từ commit đến người dùng mất bao lâu?
Tỷ lệ thay đổi gây lỗi	Bao nhiêu lần phát hành gây sự cố?
Thời gian khôi phục	Khi hỏng, mất bao lâu để sửa?

SPACE (2021) coi năng suất có năm chiều: sự hài lòng và sức khỏe, hiệu quả công việc, hoạt động, giao tiếp và hợp tác, và hiệu suất và dòng chảy. Lập luận cốt lõi của nó là không có chỉ số đơn lẻ nào đủ, và tối ưu một chiều thường làm tụt chiều khác.

Cả hai dùng để nhìn nhóm và hệ thống. Dùng chúng để chấm điểm cá nhân là hiểu sai mục đích, vì phần lớn biến thiên đến từ quy trình và công cụ chứ không từ từng người.

6. Bảng chỉ số khởi đầu cho nhóm nhỏ#

Bắt đầu với năm chỉ số, ghi ra mỗi tuần hoặc mỗi tháng, xem xu hướng.

Chỉ số	Cách đo	Cảnh báo khi
Thời gian giao hàng	Ngày từ mở việc đến chạy thật	Dài ra liên tục
Tỷ lệ thay đổi gây lỗi	Số lần phải sửa gấp trên số lần phát hành	Tăng khi tốc độ tăng
Thời gian chờ duyệt	Giờ từ mở PR đến được duyệt	Tăng khi dùng AI nhiều
Công việc làm lại	Phần code bị sửa lại trong 2 tuần	Tăng cùng số dòng
Sự hài lòng của nhóm	Khảo sát 3 câu mỗi tháng	Giảm dần

Ghép đôi. Mỗi chỉ số tốc độ phải đi cùng một chỉ số chất lượng. Thời gian giao hàng ngắn mà tỷ lệ lỗi tăng không phải tiến bộ.

7. Cách dùng để không gây hại#

Đo nhóm, không xếp hạng người. Dùng để hỏi "hệ thống của ta vướng ở đâu", không để hỏi "ai kém nhất".
Xem xu hướng, không đặt chỉ tiêu cứng. Chỉ tiêu cứng sinh ra trò chơi.
Công khai cách đo và lý do. Người trong nhóm cần hiểu số liệu dùng để làm gì.
Hỏi người trước khi tin số. Một cuộc trò chuyện 15 phút thường rõ hơn một bảng.
Xem lại thước đo mỗi quý. Thước đo cũng cần được bảo trì như code.

8. Nói chuyện với quản lý#

Nếu người quản lý muốn dùng số dòng code, hãy bắt đầu từ nhu cầu của họ, không phải từ phản bác:

"Anh muốn biết nhóm có giao hàng đều và an toàn, phải không?"
"Em đề nghị hai chỉ số: thời gian giao hàng và tỷ lệ lỗi sau phát hành. Ta theo dõi xu hướng ba tháng."
"Em có một câu chuyện ngắn về một kỹ sư viết âm 2000 dòng. Anh nghĩ chuyện đó nói điều gì?"

Mục tiêu là đổi câu hỏi, không đổi người.

9. Nhìn cân bằng#

Số dòng code không hoàn toàn vô dụng. Nó cho biết quy mô một thay đổi và giúp quyết định cách duyệt (thay đổi 3000 dòng cần chia nhỏ). Dùng để cảnh báo, không để chấm điểm.
Chỉ số khác cũng bị chơi. Số commit, điểm story, thậm chí thời gian giao hàng đều có thể bị bóp méo. Không chỉ số nào thoát luật Goodhart, chỉ là đỡ hơn.
Đo lường vẫn cần. Không đo gì cũng là một lựa chọn tồi. Chỉ là phải chọn đúng thứ và đúng cách dùng.
Dữ liệu còn hạn chế. Phần lớn tài liệu về đo năng suất là bài viết của hãng công cụ hoặc blog. Mình chưa tìm thấy dữ liệu độc lập cho thấy một chỉ số đơn lẻ nào dự đoán tốt năng suất.

10. Kết luận#

Số dòng code đếm được dễ, nên được dùng nhiều. Nhưng nó đo thứ không quan trọng, và thời AI nó đo thứ gần như miễn phí. Hãy đo kết quả của nhóm: giao nhanh, giao an toàn, ít làm lại, và nhóm vẫn muốn làm việc cùng nhau.

Việc nhỏ làm ngay: chọn hai chỉ số kết quả từ bảng ở mục 6, ghi lại số liệu bốn tuần qua, và trình bày xu hướng trong buổi họp tới.

Nguồn tham khảo#

Câu hỏi thường gặp

Vì sao số dòng code là thước đo năng suất tồi?: Vì nó đo lượng viết ra chứ không đo giá trị. Giải pháp tốt thường ngắn hơn, và xóa code thừa là một đóng góp. Khi biến số này thành mục tiêu, người ta sẽ làm nó tăng, kể cả bằng code cồng kềnh, đúng như luật Goodhart mô tả. Nó còn tăng vọt khi dùng AI nhưng không phản ánh giá trị thêm.
Nên đo năng suất kỹ thuật bằng gì?: Dùng bộ chỉ số theo nhóm, không theo cá nhân. DORA có bốn chỉ số: tần suất triển khai, thời gian từ commit đến chạy thật, tỷ lệ thay đổi gây lỗi và thời gian khôi phục. Khung SPACE của Microsoft và GitHub (2021) thêm sự hài lòng, giao tiếp và dòng chảy công việc, với nguyên tắc không chỉ số đơn lẻ nào đủ. Hãy ghép chỉ số tốc độ với chỉ số chất lượng.
AI làm thay đổi việc đo năng suất thế nào?: AI làm các chỉ số hoạt động tăng nhanh mà chưa chắc giá trị tăng theo. Dữ liệu Faros AI (2025) ghi nhận nhóm dùng AI nhiều gộp thêm khoảng 98% thay đổi, kích thước mỗi thay đổi tăng khoảng 154% và thời gian duyệt tăng khoảng 91%. Đây là dữ liệu của một hãng bán công cụ đo lường, nên cần đọc thận trọng, nhưng nó cho thấy số hoạt động và số giao hàng có thể tách khỏi nhau.
Làm sao nói chuyện với quản lý đang muốn đo bằng số dòng code?: Bắt đầu bằng điều họ cần: biết nhóm có giao hàng đều và an toàn không. Đề nghị thay bằng hai hoặc ba chỉ số kết quả như thời gian giao hàng và tỷ lệ lỗi sau phát hành, dùng theo xu hướng của nhóm. Kể chuyện âm 2000 dòng hoặc một ví dụ trong chính dự án của bạn để minh họa.