Săn ghost engineer: Cách nhìn ra đóng góp thực sự của lập trình viên

“Ghost engineer”—cứ mười lập trình viên thì có một người gần như không tạo ra công việc hữu ích nào, chỉ diễn rất đạt vai người luôn bận rộn. Nguyên nhân thật sự—làm thêm cho nơi khác, kiệt sức hay đơn giản là lười biếng—có thể bị che giấu khỏi ban quản lý trong một thời gian rất dài. (Nghiên cứu Stanford năm 2024: luồng bài gốc)

Lập trình viên không thích bị bàn đến hiệu suất. Sau một “thời hoàng kim” kéo dài của nghề này, ngành công nghệ dần coi một câu hỏi đơn giản là điều cấm kỵ: kết quả kỹ thuật có xứng đáng với thời gian và tiền bạc đã đầu tư hay không? Nhưng chính lập trình viên cũng bực bội với ghost engineer—và thường thì đội ngũ, chứ không phải ban quản lý, là bên nhận ra vấn đề đầu tiên.

Ở Nga, từ lâu người ta không thích “mách lẻo”. Vì vậy, nhiều người có thể biết có vấn đề nhưng chẳng ai muốn lên tiếng. Tội gì dính vào rắc rối của người khác? Mọi chuyện chỉ vỡ lở khi sự kiên nhẫn của tất cả đã cạn.

Nhưng có lẽ cứ mặc kệ những bóng ma ấy? Công ty cũng đâu thiếu chút tiền đó.

Tiếc là vấn đề nằm ngay ở chỗ ấy…

Khi nói hiệu suất thấp, tôi không có ý nói Alex đang cặm cụi làm việc nhưng hoàn thành ít hơn Ben 10%. Tôi nói đến chuyện khác: trong mỗi buổi stand-up, cả đội lại phải nghe một câu chuyện bi thương mới—đội kia làm chậm, ticket viết mơ hồ, vận may không mỉm cười. Nhưng ngày mai chắc chắn sẽ xong. Xin thề.

Chỉ có điều cái “ngày mai” ấy đã từng là hôm qua, rồi hôm kia—và giờ đã thành thông lệ.

Đội ngũ nhận ra chuyện này rất nhanh. Những người thực sự gánh việc đương nhiên sẽ tự hỏi: tại sao phải làm đến kiệt sức nếu chỉ cần kể chuyện hay mà chẳng phải chịu hậu quả gì?

Nhưng nhận ra vấn đề thôi chưa đủ. Không có số liệu và sự kiện trong tay, cuộc trao đổi nhanh chóng biến thành tranh cãi: đội ngũ nói “Người này làm việc kém”; lập trình viên đáp “Họ không cho tôi làm việc.” Thông thường, chẳng ai bắt đầu điều tra cho đến khi mọi người hết kiên nhẫn và yêu cầu quản lý thay người.

Đó là lúc câu chuyện dài bắt đầu: thu thập dữ kiện, nghe cả hai phía, đưa ra phản hồi, rồi cho người đó thời gian để cải thiện. Theo kinh nghiệm của tôi, kết thúc thường gặp nhất là ghost engineer chuyển sang một nhà tuyển dụng mới—và vô cùng “may mắn”.

Vấn đề không chỉ là một người làm ít hơn. Công ty phải trả giá hai lần: trước hết cho phần việc không bao giờ hoàn thành, sau đó cho thời gian đồng nghiệp và quản lý dùng để kiểm tra lại, lấp chỗ trống và tìm hiểu nguyên nhân. Cuối cùng, không còn là một lập trình viên làm việc kém nữa. Cả đội đều sa sút.

Liệu quản lý có thể phát hiện sớm hơn—nhìn ra bất thường, hỏi thêm bối cảnh và điều tra trước khi đội ngũ hết kiên nhẫn, còn công ty mất thời gian lẫn tiền bạc?

Khi đã có đủ kinh nghiệm, bạn thường có thể nhận ra trước những tình huống như vậy qua một vài kiểu hành vi đặc trưng:

• Mọi thành công đều là công của tôi; mọi thất bại đều là lỗi của bạn.
• Chuẩn bị sẵn lý do cho việc thất bại ngay cả trước khi bắt tay vào làm.
• Lấy việc nói quá nhiều để bù cho năng lực còn thiếu.
• Theo thời gian, đặc biệt là người quản lý bị biến thành “thủ phạm”.
• Khác với người thực sự đang gặp khó khăn, hành vi này không cải thiện ngay cả sau phản hồi thẳng thắn.

Tuy nhiên, nghi ngờ cần có dấu vết kỹ thuật số để chứng minh.

Hãy xem những công cụ phổ biến nhất để đo hiệu suất kỹ thuật và liệu chúng có giúp phát hiện ghost engineer hay không.

Trước khi so sánh, tôi cần nêu rõ xung đột lợi ích hiển nhiên: bạn đang đọc blog chính thức của DevGhost, còn tôi là người sáng lập sản phẩm. Đây là góc nhìn của tác giả, không phải một nghiên cứu độc lập.

Để đánh giá riêng hoạt động phát triển phần mềm—không phải toàn bộ doanh nghiệp hay sản phẩm—tôi dùng một bộ ba đơn giản: tốc độ, chất lượng và khối lượng. Chỉ số DORA cho biết tốc độ; kiểm thử và lỗi cho biết chất lượng. Khối lượng thì khó hơn. Đây là vùng ít được khai phá nhất—và cũng là nơi những bóng ma chúng ta đang tìm thường ẩn náu.

DORA: tốc độ và độ tin cậy khi phát hành

DORA cho thấy một đội đưa thay đổi lên production nhanh và ổn định đến đâu. Mô hình hiện dùng năm chỉ số: thời gian từ commit đến production, tần suất triển khai, tỷ lệ triển khai gây lỗi, thời gian khôi phục và tỷ lệ công việc phát sinh ngoài kế hoạch.

Đó là thước đo tốt cho quy trình delivery, nhưng không đo được đóng góp cá nhân. Nếu một người làm phần việc của ba người còn người khác ẩn sau kết quả chung của đội, DORA sẽ không cho bạn biết.

Các chỉ số này cũng tiện đến tuyệt vời khi dùng làm KPI. Ở một công ty tôi từng làm, chúng tôi đã “vắt sữa” chúng từ năm 2018—thành công tô xanh mọi dashboard trong khi ai cũng vui vẻ. Mô hình DORA hiện tại.

Kiểm thử và lỗi: công việc được làm tốt đến đâu

Các phương pháp đã được xác lập từ lâu và hoạt động tốt trong thực tế. Chất lượng được kiểm soát bằng code review, kiểm thử và phân tích tĩnh; hệ quả được theo dõi qua lỗi và sự cố.

Nhưng những tín hiệu này không nói gì về khối lượng. Một bản vá rất nhỏ nhưng hoàn hảo cũng đủ làm mọi chỉ số chuyển xanh—còn ghost engineer vẫn vô hình.

Jira và story point: đã đóng bao nhiêu ticket

Jira hiển thị ticket đã đóng và story point, nhưng ước tính là do chính đội ngũ đưa ra. Cùng một công việc có thể được chấm 3 điểm hoặc 13 điểm, chia thành 5 ticket hoặc gộp vào 1 ticket.

Story point hữu ích cho việc lập kế hoạch, nhưng không đáng tin khi đo đóng góp cá nhân. Một khi điểm số trở thành mục tiêu, người ta bắt đầu tối ưu điểm thay vì tối ưu công việc.

Chúng cũng rất tiện để làm KPI. Dữ liệu được nhập và ticket được di chuyển chỉ để vượt qua quality gate. Một lượng lớn công việc thủ công vô nghĩa.

Commit và số dòng code: sự thật thiếu bối cảnh

Git không phụ thuộc vào ước tính của đội nên việc đếm commit và dòng code rất hấp dẫn. Nhưng năm commit có thể chỉ là một bản vá nhỏ, còn một squash commit duy nhất có thể chứa cả tuần làm việc.

Định dạng lại, code được sinh tự động, sao chép và di chuyển code đều làm số dòng phình lên, trong khi một bản sửa khó có thể chỉ dài mười dòng.

Swarmia, LinearB và Waydev: toàn bộ hệ thống kỹ thuật ở một nơi

Swarmia, LinearB và Waydev kết hợp Git, công cụ theo dõi issue và CI/CD. Quản lý có thể xem chỉ số DORA, hàng đợi review, lead time của thay đổi và kết quả khảo sát.

Chúng cho ta bức tranh hữu ích về cả hệ thống kỹ thuật—và thường chỉ ra rằng vấn đề nằm ở quy trình chứ không phải một cá nhân. Nhưng đo khối lượng công việc của từng lập trình viên trên một thang đo có thể so sánh không phải câu hỏi trung tâm mà các nền tảng này muốn trả lời. Swarmia, LinearB, Waydev.

GitClear: phần còn lại sau khi loại bỏ nhiễu code

GitClear phân biệt code được thêm, di chuyển và sao chép, loại trừ file được sinh tự động, đồng thời xét xem code mới sau đó có bị viết lại hoặc xóa hay không.

Từ đó, hệ thống tính ra Diff Delta—đơn vị riêng của GitClear cho những thay đổi có ý nghĩa còn lại trong codebase. Code sao chép hoặc nhanh chóng bị bỏ đi có trọng số thấp hơn một thay đổi gọn nhưng tiếp tục hoạt động trên production. Cách Diff Delta hoạt động.

Diff Delta không trả lời cần bao nhiêu công sức để làm ra thay đổi. Nó trả lời có bao nhiêu thay đổi có ý nghĩa còn lại sau nhiễu và việc làm lại. Điểm mạnh nhất của GitClear là đo độ bền và chất lượng của code, cũng như phân tích tác động của AI.

Giờ thì đã gần hơn. Dịch vụ này công bố benchmark, nhưng Diff Delta vẫn là đơn vị riêng: con số 10.000 không nói lên nhiều điều nếu thiếu đối chiếu phù hợp và hiểu biết về phương pháp. Không có một mốc rõ ràng kiểu “100% là bình thường”. Benchmark Diff Delta.

BlueOptima: cùng một câu hỏi ở quy mô doanh nghiệp

Tôi biết BlueOptima từ trải nghiệm thực tế. Tôi bắt đầu làm việc với nền tảng này vào năm 2019. Chính trải nghiệm đó đã truyền cảm hứng để tôi xây sản phẩm riêng.

Thuật toán Coding Effort phân tích từng thay đổi source code bằng một bộ chỉ số tĩnh, có tính đến quy mô, độ phức tạp và mối quan hệ với phần code còn lại. Sau đó, kết quả được biểu diễn bằng số giờ.

Nhờ vậy có thể so sánh lập trình viên giữa các đội và stack công nghệ, kể cả với benchmark toàn cầu. Với tôi, đây là nỗ lực thuyết phục đầu tiên nhằm trả lời không phải “Lập trình viên này viết bao nhiêu dòng?”, mà là “Những thay đổi này đại diện cho bao nhiêu công việc thực chất?” Phương pháp của BlueOptima, benchmark toàn cầu.

Trong trường hợp của tôi, để có các khả năng cấp doanh nghiệp ấy cần một đợt triển khai khá nặng: phải cài agent trong môi trường mạng khép kín, chi phí cao và kết quả cần chuyên gia diễn giải.

Với công ty có hàng nghìn lập trình viên, điều đó có thể hợp lý. Với startup hay đội nhỏ, có lẽ không. Khoảng trống ấy sau này trở thành một trong những lý do DevGhost ra đời.

Cùng một thước đo, không cần mời thầu

Khi xây DevGhost, tôi không cố tạo thêm một nền tảng tất-cả-trong-một nhồi nhét mọi chỉ số kỹ thuật có thể tưởng tượng được.

Tôi muốn có cùng câu trả lời mà BlueOptima đưa ra—bao nhiêu công việc thực chất nằm sau những thay đổi—nhưng ở dạng mà chủ startup hoặc đội nhỏ có thể dùng mà không cần mời thầu, triển khai kéo dài hay cả một nhóm tư vấn.

Nguyên lý rất đơn giản: DevGhost phân tích chính những thay đổi—thứ gì được thêm, xóa và tái cấu trúc, cũng như kết quả đó khó tạo ra và kiểm chứng đến mức nào. Việc định dạng, di chuyển code, thay thế tự động hàng loạt và code được sinh tự động được tách khỏi công việc thực chất.

Kết quả là ước tính công sức theo số giờ tương đương: một lập trình viên tầm trung, hiểu codebase và làm việc không có AI sẽ mất bao lâu để viết cùng lượng code. Đây không phải thời gian thực tế ngồi trước bàn phím, cũng không phải đánh giá chất lượng hay giá trị kinh doanh của code. Nó là thước đo chung để so sánh các thay đổi. Tìm hiểu thêm về phương pháp DevGhost.

Ghost% so sánh ước tính đó với sản lượng kỳ vọng của một lập trình viên tầm trung, đồng thời tính đến phần thời gian người ấy thực sự dành cho phát triển. Kết quả 100% nghĩa là đúng mức chuẩn. Thấp hơn là lý do để tìm hiểu; cao hơn là điều đáng nghiên cứu và có thể biến thành thực hành tốt.

Mốc chuẩn cố ý giả định làm việc không có AI. DevGhost không cố xác định đoạn code cụ thể do người, Copilot hay agent tự trị viết. Nó đánh giá thay đổi cuối cùng: một lập trình viên tầm trung cần bao nhiêu công sức để tạo và kiểm chứng chúng nếu không có AI.

Nhờ vậy, tác động của AI không biến mất bên trong chỉ số mà trở nên hữu hình. Nếu trong một giai đoạn, lập trình viên tạo và kiểm chứng lượng kết quả mà trước đây cần gấp hai hoặc ba lần công sức, Ghost% sẽ phản ánh điều đó. Định dạng, sinh code hàng loạt và các loại nhiễu khác không nên tạo ra hiệu ứng tương tự.

Ai sẽ đánh giá người đánh giá?

Câu hỏi hiển nhiên nhất là: tại sao phải tin một ước tính do máy tạo ra? Câu trả lời ngắn gọn là không nên tin một cách mù quáng.

Đánh giá độ khó của công việc vốn mang tính chủ quan. Chúng tôi đã thử đưa cùng một tập thay đổi cho vài lập trình viên giàu kinh nghiệm ước tính—và nhận về những con số khác nhau rõ rệt. Mỗi người có tốc độ, kinh nghiệm và cảm nhận về độ khó khác nhau.

DevGhost cũng có thể sai. Lợi thế của nó không nằm ở việc nắm giữ chân lý tuyệt đối, mà ở chỗ mọi thay đổi đều được đánh giá bằng cùng một thước đo—không thiên vị, không mệt mỏi, không mang sẵn định kiến về tác giả.

Vì vậy, Ghost% là tín hiệu chứ không phải phán quyết. Kết quả thấp có thể cho thấy đóng góp yếu, nhưng cũng có thể được giải thích bằng trách nhiệm của team lead, công việc kiến trúc, mentoring, sự cố hoặc blocker.

Con số cho biết nơi nào cần đặt câu hỏi. Quản lý vẫn phải đi tìm câu trả lời—nhưng giờ họ có một ý kiến thứ hai độc lập thay vì chỉ dựa vào trực giác.

“Tôi vốn đã biết mọi người trong đội làm việc ra sao”

Một khách hàng của DevGhost là lãnh đạo kỹ thuật tại một công ty AI tăng trưởng nhanh. Ban đầu, anh ấy hoài nghi chính ý tưởng đo hiệu suất kỹ thuật. Quan điểm rất đơn giản: một lãnh đạo kỹ thuật giỏi không cần dashboard cũng biết từng người làm việc ra sao.

Chúng tôi phân tích lịch sử của một repository mà anh ấy rất quen thuộc. Trước đó đã có nghi ngại về ba lập trình viên: ticket của họ tiến triển chậm, nhưng họ làm trên một dịch vụ riêng nên khó so sánh với phần còn lại của đội. DevGhost cho thấy cả ba đều liên tục có kết quả thấp trong khoảng sáu tháng.

Sau đó, khi những lập trình viên này bắt đầu nghỉ việc, mọi người mới biết suốt thời gian ấy họ đồng thời xây sản phẩm riêng. DevGhost không thể biết nguyên nhân. Nó chỉ cho thấy điều mà số commit, pull request và các cuộc trò chuyện hằng ngày trên Slack không thể hiện: khối lượng công việc của họ thấp hơn kỳ vọng rõ rệt.

Nhưng phân tích đó không biến thành danh sách sa thải. Với hai lập trình viên khác, kết quả thấp giúp đưa ra phản hồi cụ thể, tìm hiểu nguyên nhân và cải thiện hiệu suất. Cả hai đều ở lại đội.

Những lập trình viên mà vị lãnh đạo ấy đánh giá cao cũng xuất hiện đúng nơi anh dự đoán. Giờ đây anh không chỉ thấy ai đang vượt kỳ vọng mà còn thấy họ làm được điều đó đều đặn đến đâu.

Dĩ nhiên, một trường hợp không chứng minh phương pháp này chính xác. Điều khiến khách hàng ngạc nhiên là bức tranh tổng thể khớp chặt chẽ với những gì trước đây chỉ được cảm nhận bằng trực giác—và trong vài trường hợp, chỉ trở nên rõ ràng khi nhìn lại.

Nếu một lập trình viên tạo ra kết quả của ba người thì sao?

Săn ghost là phần gây chú ý nhất của câu chuyện. Nhưng nửa trên của biểu đồ có thể hữu ích hơn.

Nếu một lập trình viên liên tục tạo ra sản lượng gấp vài lần mức trung bình, rất đáng tìm hiểu chính xác họ làm điều đó bằng cách nào.

Ngày nay, câu hỏi không còn là lập trình viên có dùng AI hay không—với nhiều người, AI đã là một phần bình thường của công việc. Câu hỏi là họ biến agent thành năng lực delivery bổ sung hiệu quả đến đâu.

Một người chỉ dừng ở autocomplete. Người khác biết cách cung cấp đúng ngữ cảnh cho agent, đặt quy tắc rõ ràng, chạy nhiều tác vụ song song và rà soát kỹ kết quả. Vì vậy, cùng quyền tiếp cận AI có thể tạo ra mức tăng năng suất hoàn toàn khác nhau.

Ghost% cao giúp tìm ra những lập trình viên đã đạt kết quả tốt với sự kết hợp giữa người và agent—và hiểu thực hành nào có thể truyền lại cho cả đội.

Nếu kết quả cao được chất lượng công việc và đánh giá của quản lý xác nhận, lập trình viên ấy xứng đáng được coi trọng, giữ chân và cân nhắc thăng chức. Cách làm của họ cũng nên được nghiên cứu và lan tỏa trong đội.

Đừng biến thước đo thành vũ khí

Mọi chỉ số đều gặp cùng một số phận: sớm muộn cũng có người muốn biến nó thành KPI. Ghost% không phù hợp cho việc đó.

Biến Ghost% thành KPI của đội, mọi người sẽ tối ưu công việc theo chỉ số. Công khai bảng xếp hạng, niềm tin sẽ biến mất. Biến điểm số thành nút sa thải, sai lầm sẽ không thể tránh khỏi.

Tôi sẽ đặt ra bốn nguyên tắc:

• Không kết luận từ một lần đo hoặc một giai đoạn ngắn.
• Tính đến vai trò của người đó, phần thời gian dành cho phát triển và công việc ngoài code.
• Cho lập trình viên xem kết quả và cơ hội giải thích bối cảnh.
• Không dùng Ghost% làm căn cứ duy nhất cho quyết định nhân sự.

Nếu kết quả thấp kéo dài, trước hết quản lý nên tìm hiểu nguyên nhân. Có thể người đó thực sự không đáp ứng được công việc. Cũng có thể họ đang làm kiến trúc, xử lý sự cố giúp người khác hoặc bị quy trình của đội cản trở.

Nếu vấn đề được xác nhận, cần có kế hoạch cải thiện cụ thể và đánh giá lại sau khoảng thời gian đã thống nhất.

Từ chối chỉ số không loại bỏ việc đánh giá con người. Nó chỉ để lại cảm tính, những câu chuyện kể trong stand-up và sở thích cá nhân của quản lý.

Tốc độ, chất lượng và khối lượng cần những công cụ khác nhau. DORA cho thấy thay đổi đi đến production ra sao. Kiểm thử và lỗi cho thấy chất lượng. DevGhost bổ sung ước tính công việc phía sau các thay đổi code.

Không chỉ số nào trong số này nên thay quản lý đưa ra quyết định.

Giá trị của một con số không nằm ở việc tuyên án. Nó nằm ở chỗ giúp cuộc trò chuyện khó khăn bắt đầu sớm hơn—và dựa trên dữ kiện.

Bạn đánh giá khối lượng công việc của lập trình viên như thế nào, và đâu là ranh giới giữa minh bạch hữu ích với giám sát?