Giá trị của team dev
Đo lường năng suất và giá trị của một team dev như thế nào?
Một vài suy nghĩ rút ra sau gần 2 năm xây dựng một team kỹ sư từ con số 0, và hiện tại đang chứng kiến tổ chức bị ảnh hưởng sau quyết định tái cấu trúc như nhiều công ty tech khác giai đoạn 2023-2026.
Layoff everywhere
Liên tiếp các năm gần đây, việc layoff đã đi từ một điều gây shock, dần trở nên bình thường đặc biệt trong ngành tech. Thậm chí những đợt layoff gần đây không hề còn liên quan đến việc tuyển dụng dư lúc Covid hoặc do kinh doanh thua lỗ nữa.
Toàn bộ các thông điệp layoff gần đây đều nói về việc tái cấu trúc mang tính nền tảng và đều có liên quan AI.
Xôi thịt: Chi phí thật sự của một team kỹ sư là bao nhiêu?
Mức lương trung bình của một software engineer tại Tokyo dao động khoảng ¥7–9M/năm (Glassdoor & TokyoDev 2025). Tính đủ chi phí BHXH, thưởng, thiết bị, văn phòng, và overhead-cost thì tổng chi phí thực cho một kỹ sư rơi vào khoảng ¥11M/năm. Như vậy một team 8 người tại Tokyo tiêu tốn khoảng ¥88M/năm — tức tầm gần ¥350.000 (60M VND) cho mỗi ngày làm việc.
Ba tuần để làm một tính năng phục vụ 2% người dùng? Ở mặt bằng chi phí như vậy, quyết định đó có thể tương đương vài triệu yên chi phí cơ hội.
Ở phía Việt Nam chi phí trên sẽ thấp hơn đáng kể, nhưng phép toán tỷ lệ vẫn vậy.
Câu hỏi đặt ra vẫn giống nhau: sprint đó có tạo ra giá trị gấp 3–5 lần con số đó không? Đa phần các lãnh đạo kỹ thuật sẽ không phải trả lời câu hỏi này.
Tư duy đầu tư: Hòa vốn thôi là chưa đủ
Tại sao phải tạo ra giá trị 3-5 lần chi phí?
Vì một điểm khá tàn khốc: Hòa vốn (break-even) không phải là ngưỡng hoà thật sự. Tỷ lệ thất bại của các dự án là khoảng 50–70%, mỗi tính năng thành công phải gánh chi phí cho cả những tính năng thất bại và cả chi phí bảo trì dài hạn của hệ thống. Do đó ngưỡng thực tế để một team tồn tại với giá trị tốt sẽ rơi vào tầm 3–5 lần chi phí cho team đó.
Đây là lúc chúng ta nhận ra tại sao nhiều big tech đang hành động tàn nhẫn đến vậy. Họ không chỉ cắt giảm vì khó khăn, thực ra họ đang áp dụng tư duy đầu tư vào đội ngũ kỹ thuật, và nhiều team đang không vượt qua ngưỡng 3x.
Cạm bẫy đo lường và sự huyễn hoặc
Một trong những cạm bẫy lớn nhất chính là sự không phân biệt rõ giữa “chỉ số hoạt động” và “chỉ số tài chính”. Velocity, số ticket đóng, số feature ship có thể chỉ là những chỉ số ảo giác. Đơn giản là vì chúng có thể tăng đều trong khi team đang xây sai thứ.
NPS tăng? Good đấy. Nhưng churn rate trong nhóm khách hàng pay nhiều cũng đang tăng thì sao?
Tại sao các tổ chức (kỹ sư) lại chọn cột bên trái? Vì nó dễ đo, dễ báo cáo, và dễ trông có vẻ đang làm tốt. Còn đo lường về mặt tài chính sẽ có thể tạo ra những insight không hề dễ chịu (và dễ kiểm soát) cho team kỹ thuật.
Thời kỳ tiền rẻ đã qua
Đây là phần khiến mình suy nghĩ nhiều nhất.
Từ khoảng 2010 đến 2021, FED giữ lãi suất mức thấp, mô hình SaaS bùng nổ, tăng trưởng doanh thu che lấp mọi sai lầm về ưu tiên sản phẩm. Headcount tăng liên tục được xem như dấu hiệu thành công của các tổ chức kỹ sư. Hơn một thập kỷ đó đã hình thành tư duy của cả một thế hệ lãnh đạo công nghệ thăng tiến trong môi trường chưa bao giờ phải đi chứng minh tỷ suất hoàn vốn.
Khi FED bắt đầu tăng lãi suất trở lại vào 2022, tiền bắt đầu không còn rẻ nữa. Tuy vậy hành vi trên không tự điều chỉnh ngay, vì hành vi đó chưa bao giờ được kết nối với logic tài chính ngay từ đầu.
Đó cũng chính là lý do làn sóng layoff 2023–2026 không dừng lại. Đó ko chỉ là “điều chỉnh nhỏ” mà là quá trình tái thiết lập kỷ luật tài chính mà ngành tech đã quên suốt một thập kỷ.
Khi “tài sản” hóa ra là “tiêu sản”
Theo tư duy cũ, một codebase khổng lồ tích lũy qua nhiều năm là tài sản quý giá, là “con hào kinh tế” (moat) tạo lợi thế an toàn với đối thủ. Tuy nhiên, mỗi dòng code cũng thêm một gánh nặng bảo trì. Mỗi kỹ sư thêm vào để duy trì nó cũng tăng thêm chi phí phối hợp. Lúc này, quy mô hệ thống trở thành lực cản quán tính thay vì lợi thế cạnh tranh.
Sự xuất hiện của GenAI khiến thực tế này không thể bị phớt lờ nữa. Giá trị của việc viết code cũng như đội ngũ lập trình đã bị giảm mạnh, thậm chí tốc độ giảm ngày càng nhanh hơn, tỉ lệ nghịch với độ thông minh của các model AI mới.
Kỷ nguyên A2A
Khi AI bắt đầu được sử dụng trong phát triển phần mềm, có nhiều phàn nàn về code do AI sinh ra rối lắm, tốn effort để đọc hiểu và bảo trì. Chỗ này thực ra chỉ đúng trong thế giới mà con người phải đọc và bảo trì code đó. Trong kỷ nguyên A2A (agent-to-agent), 10 AI agents quét qua một codebase lộn xộn (được tạo bởi người hoặc AI) vẫn đạt được hiệu quả trong khi nhanh và rẻ hơn nhiều so với một team human.
Đây là điều mình đã thử nghiệm trong một dự án migration hệ thống kiến trúc microservices. Team triển khai quy trình Agentic SDLC trong đó phần tạo plan sẽ sử dụng AI agent model tiên tiến nhất để quét qua code base, đánh giá hiện trạng và xây dựng plan chi tiết, con người sẽ focus vào review intent thay vì trực tiếp soi lại toàn bộ codebase. Gánh nặng “legacy understanding” giảm đi không phải vì kỹ sư hiểu code tốt hơn, mà vì AI agent có thể quét và tổng hợp ngữ cảnh ở tốc độ mà con người không bao giờ làm được.
Ngoài ra, chất lượng code tạo bởi AI tốt hay không không phải chỉ do bản thân AI model, mà gần đây phần lớn chính là ở cách chúng ta xây dựng framework Agentic SDLC như thế nào để sử dụng các AI agent một cách hiệu quả nhất.
Thoát ra khỏi sự mơ hồ
Đúc kết, đặc biệt dành cho các manager tại các công ty product:
Biết chính xác team bạn tiêu tốn bao nhiêu mỗi ngày. Không phải con số salary trên bảng lương, mà tổng chi phí thực: lương, BH, khấu hao, quản lý, overhead. Và hãy dùng con số 3x của chi phí này khi đánh giá việc team đang và sẽ làm.
Tách bạch rõ ràng giữa “work that feels productive” và “work that generates return”. Refactoring, cải thiện tooling, giảm tech debt — tất cả đều cần thiết. Nhưng chúng là chi phí duy trì, không phải đầu tư tăng trưởng. Đảm bảo ít nhất 60–70% effort của team hướng tới value creation trực tiếp.
Đầu tư vào AI tooling ngay bây giờ. Team nào bắt đầu tích hợp AI agents vào workflow sớm sẽ có lợi thế kép: giảm chi phí phát triển VÀ tích lũy kinh nghiệm sử dụng — thứ mà đối thủ không thể mua bằng tiền. Đừng chờ “công cụ hoàn hảo” mà hãy bắt đầu với những gì có sẵn, lặp lại, cải tiến.
Xây dựng văn hóa “High agency” — nơi mỗi thành viên hiểu context kinh tế của công việc mình làm. Khi một engineer biết rằng mỗi ngày team tiêu tốn $X, họ sẽ tự nhiên đặt câu hỏi về giá trị của công việc/task đang làm. Sự minh bạch không tạo ra áp lực tiêu cực mà tạo ra ownership thực sự.