- Phần lớn các tổ chức kỹ thuật đang vận hành mà không nắm được bằng số liệu chi phí và giá trị tạo ra ở cấp độ nhóm, dẫn đến kém hiệu quả về tài chính
- Chi phí hằng năm của một nhóm 8 người vào khoảng 1,04 triệu € (87 nghìn €/tháng, 4.000 €/ngày), nên mọi quyết định như phát triển tính năng hay trì hoãn cải tiến đều có tác động tiền tệ rõ ràng
- Cả nhóm nền tảng nội bộ lẫn nhóm sản phẩm hướng tới khách hàng đều có thể tính được điểm hòa vốn và ngưỡng tạo ra giá trị gấp 3~5 lần, nhưng rất ít tổ chức thực sự theo dõi điều này
- Môi trường lãi suất thấp và văn hóa tăng trưởng trong 20 năm qua đã làm suy yếu kỷ luật tài chính, biến các tổ chức quy mô lớn và codebase phức tạp thành nợ phải trả thay vì tài sản
- Sự xuất hiện của LLM đang phơi bày những kém hiệu quả mang tính cấu trúc này, và các tổ chức đo lường định lượng chi phí, giá trị và lợi nhuận theo từng nhóm sẽ giành được lợi thế cạnh tranh dài hạn
Kinh tế học của các nhóm phần mềm: Vì sao phần lớn tổ chức kỹ thuật đang ‘bịt mắt’ về mặt tài chính
- Phân tích bằng số liệu cấu trúc chi phí phát triển phần mềm và tính hợp lý kinh tế ở cấp độ nhóm, cho thấy phần lớn tổ chức đang vận hành mà không nhận thức được dữ liệu này
- Với một nhóm 8 người, chi phí vào khoảng 1,04 triệu €/năm (87 nghìn €/tháng), tương đương khoảng €4.000 mỗi ngày
- Cả nhóm nền tảng nội bộ lẫn nhóm sản phẩm hướng tới khách hàng đều có thể tính được lượng giá trị cần tạo ra để vượt điểm hòa vốn (break-even), nhưng hầu như không có tổ chức nào thực sự theo dõi việc này
- Môi trường lãi suất thấp và văn hóa tăng trưởng trong 20 năm qua đã làm suy yếu kỷ luật tài chính, khiến nhiều nơi nhầm tưởng các tổ chức kỹ thuật lớn và codebase phức tạp là “tài sản”
- Sự xuất hiện của LLM (mô hình ngôn ngữ lớn) đang phơi bày những kém hiệu quả mang tính cấu trúc này, và các tổ chức đo lường rõ ràng chi phí và giá trị tạo ra của từng nhóm sẽ có được lợi thế cạnh tranh
Cấu trúc chi phí thực tế của một nhóm
- Theo mặt bằng Tây Âu, tổng chi phí hằng năm cho mỗi kỹ sư phần mềm là 120.000~150.000 €, trung bình khoảng 130.000 €
- Bao gồm lương, chi phí an sinh xã hội, lương hưu, thiết bị, chi phí quản lý, không gian văn phòng, v.v.
- Tổng chi phí hằng năm của một nhóm 8 người là 1.040.000 €, tương đương 86.667 €/tháng, 4.000 €/ngày
- Ngay cả đa số kỹ sư và quản lý cũng không biết các con số này, nên nhận thức về chi phí không được phản ánh trong quá trình ưu tiên công việc
- Mọi quyết định như phát triển tính năng, trì hoãn cải tiến hay xây lại nền tảng đều đi kèm chi phí tiền tệ rõ ràng
- Ví dụ: phát triển một tính năng trong 3 tuần cho 2% người dùng tương đương một quyết định trị giá khoảng 60.000 €
Tính điểm hòa vốn cho nhóm nền tảng nội bộ
- Giả sử một nhóm nền tảng 8 người hỗ trợ 100 kỹ sư
- Chi phí mỗi tháng là 87.000 €, nên cần tạo ra giá trị tương ứng để bù đắp
- Chi phí mỗi kỹ sư mỗi tháng là 10.800 € (65 €/giờ)
- Với 100 người, cần tiết kiệm 1.340 giờ/tháng (3 giờ/tuần mỗi người) để đạt điểm hòa vốn
- Ngoài việc tiết kiệm thời gian đơn thuần, còn có thể trực tiếp bảo vệ doanh thu thông qua giảm sự cố
- Tuy nhiên, phần lớn các nhóm không đo lường các con số này cũng như không phản ánh chúng trong việc ra quyết định
- Tiêu chuẩn thực tế cho sức khỏe tài chính là tạo ra giá trị gấp 3~5 lần (260 nghìn~430 nghìn €/tháng)
- Cần tính đến chi phí duy trì/thay thế hệ thống và tỷ lệ thất bại (50~70%)
- Không chỉ dừng ở “hòa vốn” mà cần đảm bảo lợi nhuận bền vững
Cùng một logic với nhóm sản phẩm hướng tới khách hàng
- Một nhóm 8 người làm sản phẩm cho khách hàng cũng có cấu trúc chi phí 87.000 €/tháng
- Nếu doanh thu mỗi người dùng là 50 €/tháng, thì để hòa vốn cần tạo ra giá trị tương đương 1.740 người dùng,
còn theo chuẩn 3~5 lần thì cần giá trị tương đương 5.000~8.700 người dùng
- Cải thiện tỷ lệ rời bỏ (churn) là đòn bẩy trực tiếp nhất
- Ví dụ: trong 50.000 người dùng, nếu mỗi tháng 2% rời đi (1.000 người, mất 50.000 €) → loại bỏ nguyên nhân có thể bù đắp phần lớn điểm hòa vốn
- Cải thiện tỷ lệ kích hoạt (activation) cũng rất quan trọng
- Trong 10.000 người dùng mới mỗi tháng, nếu chỉ 30% kích hoạt → cải thiện thêm 5 điểm phần trăm sẽ chuyển đổi thêm 500 người, tạo thêm 25.000 € doanh thu
- Việc tăng tỷ lệ chuyển đổi (conversion) cũng mang lại hiệu quả tương tự
- Trong 20.000 lượt dùng thử, nếu tỷ lệ chuyển đổi tăng từ 4% lên 4,5% thì có thêm 100 người trả phí, tương đương 5.000 € doanh thu tăng thêm
- Những cải thiện nhỏ ở nhiều chỉ số có thể cộng dồn thành tác động tài chính lớn,
nhưng phần lớn các nhóm không đo lường mối liên kết giữa các chỉ số này và kết quả tài chính
Vì sao không đo lường tài chính
- Nhiều nhóm chỉ theo dõi các chỉ số hoạt động hoặc cảm nhận như velocity, số ticket, số tính năng, NPS, CSAT
- Đây không phải là vật thay thế cho chỉ số tài chính mà là một phạm trù hoàn toàn khác
- Ngay cả khi các chỉ số hoạt động cải thiện, kết quả tài chính vẫn có thể xấu đi
- Số tính năng tăng → có thể là những tính năng sai
- Mức độ tương tác tăng → nhưng số người dùng thực sự đóng góp doanh thu có thể giảm
- Những chỉ số này được chọn vì dễ đo lường, dễ báo cáo, dễ “đóng gói” thành thành tích
- Trong khi chỉ số tài chính có thể phơi bày những sự thật khó chịu
- Phần lớn tổ chức không chủ động xây dựng văn hóa đo lường tài chính minh bạch
Bối cảnh của 20 năm qua
- Giai đoạn 2002~2011: lãi suất thấp nhưng nhà đầu tư né rủi ro, nên kỷ luật tài chính vẫn được duy trì
- Giai đoạn 2011~2022: lãi suất bằng 0, khẩu vị rủi ro phục hồi, và logic tăng trưởng SaaS kết hợp với nhau
- Trong 11 năm đó, doanh nghiệp vẫn được tha thứ bằng tốc độ tăng trưởng dù nhân sự tăng mạnh, hiệu quả thấp và ưu tiên sai
- Thế hệ lãnh đạo hình thành trong giai đoạn này đã trưởng thành trong một môi trường không bị yêu cầu chứng minh hiệu quả tài chính
- Vì vậy ngay cả khi chi phí vốn tăng sau năm 2022, hành vi cũng không tự động điều chỉnh
Khoản nợ bị nhầm là “tài sản” của tổ chức kỹ thuật
- Codebase lớn và tổ chức kỹ thuật quy mô lớn từ lâu được xem là tài sản (asset)
- Nhờ tích lũy logic nghiệp vụ, nền tảng công nghệ, năng lực tổ chức, v.v.
- Nhưng trên thực tế, đó lại là cấu trúc nợ phải trả (liability) với gánh nặng bảo trì, chi phí phối hợp và sự chậm trễ trong ra quyết định ngày càng tích tụ
- Độ phức tạp tăng làm năng suất giảm, chi phí tăng và doanh thu đình trệ
- Trước đây, môi trường lãi suất thấp đã che khuất khoản nợ này
-
Thực tế mà LLM phơi bày
- Nhà phát triển Nathan Cavaglione đã dùng agent LLM để sao chép 95% tính năng cốt lõi của Slack chỉ trong 14 ngày
- Slack đã được hàng nghìn kỹ sư phát triển trong hơn 10 năm, với khoản đầu tư trị giá hàng tỷ euro
- Nathan hoàn thành một sản phẩm tương tự trong thời gian ngắn mà không phải gánh độ phức tạp tổ chức, kiến trúc cũ hay chi phí phối hợp
- Điều này cho thấy giả định rằng quy mô, độ phức tạp và lượng code tích lũy của tổ chức lớn là lợi thế cạnh tranh không còn đúng nữa
- Vẫn tồn tại vấn đề về khả năng bảo trì của mã do LLM tạo ra,
nhưng trong môi trường agent-agent, nó vẫn có lợi thế về chi phí và tốc độ so với bảo trì bằng con người
Điều kiện để các tổ chức bứt lên trong tương lai
- Cốt lõi của năng lực cạnh tranh không nằm ở công nghệ mà ở năng lực phân tích
- Tổ chức nào nắm rõ chi phí, giá trị và ngưỡng lợi nhuận của từng nhóm sẽ có ưu thế mang tính cấu trúc
- Những tổ chức như vậy có thể:
- Đưa ra quyết định Build vs Buy dựa trên hiệu quả kinh tế thực tế
- Xác định các nhóm nằm dưới ngưỡng sinh lời
- Định lượng mức thất thoát giá trị do trì hoãn để điều chỉnh ưu tiên
- Hiện nay, phần lớn tổ chức chưa có hạ tầng đo lường, luồng dữ liệu và thói quen cần thiết
- Quá trình xây dựng sẽ khó chịu nhưng là bắt buộc
- Có thể phát hiện rằng một nhóm đã tiêu tốn cả quý cho công việc không có liên kết tài chính
- Trước đây, lãi suất thấp và logic tăng trưởng đã dung thứ cho điều này,
nhưng trong bối cảnh chi phí phát triển giảm mạnh nhờ AI và nhà đầu tư đòi hỏi hiệu quả tài chính, cách làm đó không còn bền vững
- Tổ chức nào có thói quen đặt câu hỏi và đo lường rõ ràng tính kinh tế ở cấp độ nhóm
sẽ tích lũy lợi thế cạnh tranh kép theo thời gian
1 bình luận
Ý kiến Hacker News
Ý chính của bài này là không phải việc lập trình tự thân là phần khó, mà phần thực sự khó là tìm ra cần phải lập trình cái gì
Trên thực tế, phần lớn công việc là khám phá không gian vấn đề bằng cách сначала xây thứ sai, rồi thay thế nó, lặp đi lặp lại nhiều lần
Lập trình thường không phải là đầu ra cuối cùng, mà gần hơn với một phương tiện để làm rõ định nghĩa của vấn đề
Nếu chỉ là ghép các framework với nhau thì có thể dễ, nhưng trong môi trường phải xử lý hệ thống phức tạp, chính việc lập trình mới là phần thực sự khó
Tôi đã nhiều lần thấy những yêu cầu đơn giản bị mở rộng thành hệ thống khổng lồ. Nhưng nếu đầu tư khôn ngoan vào hạ tầng như Google, điều đó cũng có thể trở thành lợi thế cạnh tranh
Nhưng cách tiếp cận này thường trông thiếu hiệu quả, hoặc dễ khiến người khác hiểu nhầm là “người luôn nói sai”
Nhiều lập trình viên tưởng dự án của mình là đặc biệt, nhưng thực ra trong nhiều trường hợp chỉ cần sao chép thiết kế đã được kiểm chứng là đủ
Như bài viết nói, lo ngại rằng khi mã được tạo quá nhanh thì sẽ khó quản lý là hợp lý, nhưng người viết cho rằng điều đó kém quan trọng hơn nếu con người không trực tiếp bảo trì nó
Nhưng tôi nghĩ logic đó cũng có thể áp dụng cho “LLM huấn luyện viên Agile”. LLM đã có thể cung cấp phần lớn insight với chi phí rẻ hơn rất nhiều
Cuối cùng con người có lẽ chỉ cần thư giãn bên hồ bơi
Tôi không đồng ý với nhận định rằng “dù codebase có bẩn đến đâu, cứ thả nhiều agent vào là giải quyết được”
Thực tế có rất nhiều mã trông bên ngoài thì hoàn hảo, nhưng bên trong lại sai về mặt cấu trúc, như một tòa nhà làm bằng foam
Loại mã này theo thời gian sẽ không thể mở rộng được nữa và cuối cùng cứng lại như gạch
Tôi cũng từng có trải nghiệm hai dự án do AI tạo ra thất bại hoàn toàn
Dù thêm nhiều agent hơn cũng không có tiến triển, và phần lớn kết quả tạo ra đều đi sai hướng
Tôi đồng ý với nhận định rằng “phát triển phần mềm là hoạt động thâm dụng vốn”, nhưng bối cảnh mỗi ngành lại khác nhau
Công ty điện lực hay nhà sản xuất có chi phí duy trì hạ tầng vật lý lớn hơn rất nhiều so với IT
Nhưng khi số lượng hợp đồng SaaS ngày càng nhiều, ngày càng nhiều doanh nghiệp bắt đầu cân nhắc liệu thuê lập trình viên LLM có kinh tế hơn không
Tôi đang đọc bài với hứng thú thì lại mất niềm tin ở ví dụ sao chép Slack
Đó là một nhận định hoàn toàn không hiểu gì về quy mô, độ ổn định và tính năng của Slack thực tế
Với sản phẩm doanh nghiệp, hàng trăm chi tiết tính năng như vậy là bắt buộc. Sao chép đơn thuần không phải cạnh tranh
Những bài viết chỉ ném ra một đống con số và biểu đồ trông giống như bài của người muốn thắng tranh luận
Như Rory Sutherland từng nói, “Finance People” ám ảnh với sự chắc chắn và khả năng dự đoán
Nhưng thế giới không đơn giản như vậy
Hơn cả các chi tiết của bài viết, tôi đồng cảm với văn hóa kỹ thuật không suy nghĩ về giá trị so với chi phí
Trong các cuộc họp hay quá trình xử lý sự cố, rất thường xuyên người ta áp dụng các biện pháp quá mức mà không cân nhắc hiệu quả trên chi phí
Technical debt cũng vậy, nếu không biết chi phí thì không thể đưa ra lựa chọn có trách nhiệm
Phép tính đơn giản rằng “đội platform phải chứng minh giá trị bằng lượng thời gian tiết kiệm được” là sai
Đội platform không chỉ tiết kiệm thời gian, mà còn có vai trò giảm rủi ro kinh doanh và đảm bảo các phẩm chất cốt lõi
Đây không chỉ là logic kinh tế đơn thuần mà là vấn đề hạ tầng thiết yếu của tổ chức
Cuối cùng, điều quan trọng là đội ngũ có thực sự quan tâm đến sản phẩm hay không
Chỉ những đội coi bản thân sản phẩm quan trọng hơn sự nghiệp ngắn hạn mới có thể vượt lên trên chỉ số hay kỹ thuật quản lý để tạo ra kết quả thực sự
Nhưng có những dự án ngay từ đầu đã có cấu trúc không thể khiến người ta gắn bó, nên giới hạn năng suất là rất rõ ràng