Tại sao Developer Productivity Engineering lại bị đánh giá thấp?

Tôi dành hai tuần để theo dõi thời gian của mình, ghi lại từng giờ làm việc. Những con số thu được đáng thất vọng đến mức tôi phải dừng lại. Phần lớn những gì tôi gọi là "thời gian phát triển" thực chất lại dành cho việc chờ đợi, tìm kiếm, chuyển đổi ngữ cảnh, chạy lại các test không ổn định hoặc đào bới trong tài liệu lỗi thời và các luồng tin nhắn rời rạc.

Điều này không phải là trường hợp cá biệt. Nó rất phổ biến và hầu hết các đội nhóm đã coi đó là điều bình thường. Sự lãng phí vô hình này chính là thứ mà Developer Productivity Engineering (DPE) hướng tới loại bỏ.

Có một lý do sâu xa hơn khiến những vấn đề này tồn tại dai dẳng: những người có quyền hạn tài trợ cho các giải pháp gần như không bao giờ nghe thấy về chúng. Các lập trình viên phát hiện ra các bản build chậm, pipeline không ổn định và tài liệu hỏng ngay lập tức — nhưng nỗi đau đó hiếm khi được truyền tải lên cấp cao hơn. Hầu hết các kỹ sư chỉ đơn giản là xoay sở để vượt qua, vá lỗi cục bộ hoặc chấp nhận sự ma sát như một phần của công việc. Đến khi lãnh đạo nghe về các vấn đề này, nó thường đã ở mức độ khủng hoảng.

Sự lãng phí là có thật

Các lập trình viên mất hàng giờ mỗi tuần để đối phó với sự ma sát thay vì xây dựng sản phẩm. 58% báo cáo mất năm giờ hoặc nhiều hơn mỗi tuần vì sự thiếu hiệu quả như build chậm, công cụ bị lỗi và thiếu hụt kiến thức — một con số tôi quan sát thấy ở hầu hết mọi nơi và khớp với dữ liệu.

62% các lập trình viên cho biết nợ kỹ thuật là sự gây ức chế hàng đầu của họ, trong khi hơn 10% làm việc tại các công ty thiếu CI/CD, kiểm thử tự động hóa hoặc DevOps.

61% các lập trình viên dành ít nhất 30 phút mỗi ngày để tìm kiếm thông tin. Hơn một phần ba bị chặn bởi các "silos" kiến thức, và một tỷ lệ tương tự phải trả lại những câu hỏi mà họ đã từng giải quyết. Mọi người gọi đó là vấn đề tài liệu, nhưng thực tế nó cũng là vấn đề về kiến trúc và đào tạo. Kiến thức và văn hóa nhận được ít sự chú ý, gây thiệt hại nhiều nhất và hiếm khi xuất hiện trên các bảng điều khiển (dashboard).

Với một đội ngũ 50 lập trình viên có mức lương trung bình 150.000 USD (dựa trên chuẩn lương lập trình viên tại Mỹ), việc mất 30 phút mỗi người mỗi ngày sẽ cộng lại thành gần 500.000 USD mỗi năm. Đó là tương đương với việc mất ba kỹ sư toàn thời gian vì sự thiếu hiệu quả.

Sự lãng phí chính là vấn đề mà DPE hướng tới giải quyết. Hầu hết các tổ chức đều đầu tư quá ít vào nó.

Tại sao ít ai cải thiện năng suất lập trình viên?

Đội ngũ sales của bạn được dùng CRM. Không ai yêu cầu họ quản lý giao dịch trên bảng tính. Bộ phận tài chính có phần mềm kế toán phù hợp. Không ai nghi ngờ về lợi nhuận đầu tư (ROI) của việc đó.

Các lập trình viên, thường là nhóm có lương cao nhất và khó thay thế nhất, lại phải xoay sở chấp nhận sự ma sát. Họ đối mặt với các pipeline CI bị hỏng, các dịch vụ không có tài liệu, và dành thời gian tìm kiếm thông tin lẽ ra phải có sẵn ngay.

Đây là phần mà hầu hết các quản lý không thấy: các nhân viên cấp nhân sự (staff) và kỹ sư cấp cao trong đội ngũ của bạn thực chất đang làm công việc DPE. Họ chỉ không gọi tên nó là vậy.

Họ nhận thấy bản build chậm và dành một buổi sáng thứ Bảy để theo dõi lý do tại sao. Họ viết tài liệu hướng dẫn (runbook) mà không ai yêu cầu. Họ thúc đẩy việc di chuyển (migration) mà không ai muốn tập trung vào.

Đây là công việc DPE: vô hình, không được ghi nhận, và lấy đi thời gian khỏi những gì đội nhóm thực sự đo lường. Tôi đã chứng kiến những kỹ sư giỏi bị kiệt sức theo cách này — làm công việc quan trọng nhất trong công ty trong khi nhận được sự ghi nhận bằng không.

Một nửa các quản lý kỹ thuật nói rằng công ty họ đo lường năng suất hoặc trải nghiệm nhà phát triển (DevEx), nhưng chỉ 16% có người được dành riêng để cải thiện chúng.

66% các lập trình viên nói rằng các chỉ số năng suất bỏ qua đóng góp thực sự của họ. Hầu hết dựa vào các thước đo thô sơ: dòng code, story points, tần suất commit. Các kỹ sư có thể "lách luật" các chỉ số này trong vòng một tháng. Mọi người đều biết những con số đó không có thật. Và 60% tổ chức kỹ thuật không theo bất kỳ khung đo lường cụ thể nào, mặc dù 90% đánh giá việc cải thiện năng suất là sáng kiến hàng đầu (trung bình 8,2/10).

Nghiên cứu năm 2025 của DORA, khảo sát gần 5.000 chuyên gia, xác nhận mô hình này: chỉ 40% các đội xuất sắc về cả tốc độ và độ ổn định. Phần còn lại bị kìm hãm bởi sự ma sát trong quy trình và các khoảng trống nền tảng — không phải là sự đánh đổi. Sự thỏa hiệp "tốc độ so với độ ổn định" chỉ là huyền thoại: những đội nhóm tốt nhất làm được cả hai.

Vấn đề cốt lõi là việc đo lường thì dễ, nhưng sửa chữa thì khó. Nếu bạn chỉ theo dõi mà không bao giờ sửa chữa, bạn đang chỉ làm việc do thám. Sự tin tưởng giảm xuống và không có gì được cải thiện.

Developer Productivity Engineering thực chất là gì?

DPE rộng hơn Trải nghiệm Nhà phát triển (Developer Experience - DX). DX là một phần, nhưng không phải là toàn bộ. DPE coi hệ sinh thái của nhà phát triển như một hệ thống với bốn trụ支柱 liên kết:

• Trải nghiệm Nhà phát triển (Developer Experience) — vòng lặp phản hồi, yêu cầu nhận thức, trạng thái dòng chảy (flow state).
• Hạ tầng Kỹ thuật (Engineering Infrastructure) — hệ thống build, CI/CD, tự động hóa test, công cụ nền tảng, di chuyển hệ thống cũ (legacy migration).
• Kiến thức và Văn hóa — cách thông tin lưu chuyển, được ghi lại và tồn tại qua sự thay đổi nhân sự.
• Tăng cường AI — cách công cụ AI đặt lên trên và nhân đôi những gì ba trụ cột kia tạo ra.

Nếu một trụ cột yếu, các trụ cột khác không thể bù đắp. Trải nghiệm nhà phát triển là nơi phần lớn sự ma suất xuất hiện đầu tiên — và cách tư duy hữu ích nhất về DX tập trung vào ba chiều kích bao gồm hầu hết những điều quan trọng: vòng lặp phản hồi, yêu cầu nhận thức, và trạng thái dòng chảy.

• Vòng lặp phản hồi là rõ ràng nhất. Mất bao lâu từ git push đến "có hoạt động không?". Nếu câu trả lời là 20 phút, bạn đã mất mạch tư duy rồi.
• Yêu cầu nhận thức khó nắm bắt hơn. Nó không chỉ là liệu code có khó không; mà là bạn cần nhớ bao nhiêu để thực hiện một thay đổi an toàn. Mọi ranh giới dịch vụ không được tài liệu hóa và mỗi phụ thuộc ẩn thêm một gánh nặng tiềm ẩn. Bạn chỉ nhận ra nó khi một nhân viên mới mất ba tháng để trở nên năng suất.
• Trạng thái dòng chảy là cửa sổ 2-3 giờ khi ai đó thực sự đang giải quyết một vấn đề khó. Môi trường bảo vệ nó thường xuyên đến mức nào?

Ảnh hưởng lớn nhất đến DX không phải là công cụ — mà là các yếu tố văn hóa và tổ chức: quản lý sản phẩm hoạt động như thế nào, quyết định được đưa ra ra sao, và các đội nhóm giao tiếp như thế nào. Công cụ có quan trọng, nhưng tổ chức mới đặt ra trần. Đó là lý do nhiều sáng kiến "cải thiện DX" thất bại: họ mua công cụ mà không giải quyết môi trường mà những công cụ đó hoạt động.

Các hệ thống cũ (legacy) là gánh nặng cho mọi kỹ sư chạm vào chúng. Các mô hình như Strangler Fig và di chuyển tăng dần hoạt động hiệu quả, nhưng chỉ khi ai đó ưu tiên chúng. Ở hầu hết các tổ chức, người đó là một staff engineer đang thuyết phục lãnh đạo, những người không trực tiếp cảm nhận được sự ma sát.

Và sau đó là AI, được xây dựng dựa trên cả ba trụ cột kia. Theo khảo sát của DORA với gần 5.000 chuyên gia, hơn 80% lập trình viên nói rằng AI đã tăng năng suất của họ. Khoảng một phần ba code mới trong các tổ chức được khảo sát giờ đến từ AI.

Nhưng AI chỉ nhân đôi hệ thống mà bạn đang có. Nếu DX của bạn tốt, công cụ AI làm nó tốt hơn nữa. Nếu DX của bạn bị hỏng, AI chỉ làm mọi thứ hỏng nhanh hơn.

Báo cáo DORA 2025 — nghiên cứu toàn diện nhất về AI trong phát triển phần mềm cho đến nay — gọi AI là "một bộ khuếch đại". Nó phóng đại điểm mạnh của các tổ chức hoạt động hiệu quả cao và sự rối loạn chức năng của những tổ chức đang gặp khó khăn. Tại Adidas, các đội với kiến trúc lỏng lẻo và vòng lặp phản hồi nhanh thấy năng suất tăng 20–30% từ AI và tăng 50% "Thời gian Hạnh phúc" (Happy Time). Các đội có vòng lặp phản hồi chậm do kết nối chặt chẽ thấy rất ít hoặc không có lợi ích.

Giải pháp tồn tại — Và Nó Tích Hợp Theo Cấp Số

ROI là Có Thật

Can thiệp	Kết quả	Nguồn
Khung DX Core 4	Tăng 3-12% hiệu quả kỹ thuật	DX (Core 4)
Khung DX Core 4	Tăng 14% thời gian R&D cho phát triển tính năng	DX (Core 4)
DXI nhóm tứ phân vị cao	Mức độ gắn kết nhân viên cao hơn 43%	DX (DXI)
AI + vòng lặp phản hồi nhanh (Adidas)	Tăng năng suất 20-30%, tăng 50% "Thời gian Hạnh phúc"	DORA 2025
AI + đào tạo lập trình viên (Booking.com)	Tăng tới 30% yêu cầu merge (merge requests)	DORA 2025

Một điểm tăng trên Chỉ số Trải nghiệm Nhà phát triển (Developer Experience Index) tiết kiệm 13 phút mỗi lập trình viên mỗi tuần. Trên một đội 200 người, việc cải thiện 5 điểm cộng lại thành 11.000 giờ lập trình mỗi năm. Đó là tương đương với năm kỹ sư toàn thời gian mà không cần tuyển dụng thêm.

Các can thiệp DPE tích hợp theo thời gian. DX tốt hơn có nghĩa là ít thời gian lãng phí vào công cụ hơn và giao hàng nhanh hơn. Nó cũng cải thiện sự hài lòng của khách hàng — và đây là nơi các con số trở nên nghiêm túc.

24,5% lập trình viên hạnh phúc tại nơi làm việc. 47,1% thụ động. 28,4% tích cực không hài lòng. Yếu tố hài lòng hàng đầu là sự tự chủ và tin tưởng.

DPE ánh xạ trực tiếp đến những gì giữ cho các kỹ sư gắn bó — sự tự chủ thông qua công cụ tốt hơn, sự tin tưởng khi bạn loại bỏ các chỉ số giám sát, và chất lượng vì môi trường thực sự hỗ trợ công việc. Trên một đội 50 người, việc ngăn chặn ngay cả một hoặc hai sự ra đi của cấp cao mỗi năm có thể tự chi trả cho một sáng kiến DPE.

Nên bắt đầu từ đâu

Bạn không cần một sáng kiến lớn. Một người tập trung và khoảng 90 ngày có thể tạo ra sự khác biệt. Không có kế hoạch ba bước nào — mỗi tổ chức đều khác nhau.

Lỗi sai chính là coi DPE như một sáng kiến một lần. Nó là một thực hành, giống như xem xét bảo mật hoặc kiểm tra hiệu suất, cần sự chú ý liên tục.

Nhưng bạn vẫn cần một điểm khởi đầu. Xác định ba điểm đau hàng đầu bằng cách hỏi, không phải đoán. Một khảo sát ngắn hoặc một vài cuộc trò chuyện ngắn qua các đội nhóm thường là đủ. Câu trả lời thường khác với giả định của lãnh đạo, và các bản sửa lỗi thường nhỏ hơn dự kiến.

Sửa một vấn đề và đo lường kết quả. Vấn đề là bình thường: việc di chuyển mất nhiều thời gian hơn, thay đổi quy trình gặp sự kháng cự, hoặc các chỉ số không di chuyển như mong đợi. Sử dụng những chiến thắng sớm để tạo uy tín cho cải tiến tiếp theo. Đưa dữ liệu vào.

Nếu bạn là một staff hoặc senior engineer đang đấu tranh để thu hút sự chú ý của lãnh đạo, dữ liệu ở đây dành cho bạn. Bạn có khả năng đã làm công việc DPE từ lâu rồi, ngay cả khi nó vô hình. Bây giờ bạn có một khung và một cái tên cho nó.

Có một điều gì đó trong đội nhóm của bạn khiến bạn muốn đóng máy tính và bỏ đi không? Tôi thực sự tò mò về điều đó.