Vì sao xây dựng phần mềm vẫn luôn khó — góc nhìn từ một nhà quản lý kỹ thuật

Có một câu hỏi mà giới kỹ thuật viên chúng ta nghe hoài mà chưa bao giờ trả lời trọn vẹn: nếu viết code chỉ là gõ những từ có nghĩa cố định, và chúng ta biết rõ mình muốn gì nhờ bản đặc tả, thì tại sao mọi thứ cứ ngày càng phức tạp?

Minh họa về quá trình phát triển phần mềm

Bài viết dưới đây là chia sẻ của một engineering manager sau một cuộc thi hackathon đầy cảm xúc — và cũng là lời giải thích dễ hiểu nhất cho những người làm kinh doanh về bản chất của công việc xây dựng phần mềm.

1 giờ chiều, ngày cuối cùng của hackathon

Chỉ còn 5 tiếng nữa là hết giờ. Hai tiếng trước đó, cả nhóm không tiến được một bước nào. Tác giả thú nhận đã nguyền rủa cái ngày Lovable ra đời.

Cứ sửa xong vấn đề này thì vấn đề khác lại xuất hiện, ứng dụng gần như không dùng được. Khởi đầu thì đầy hứa hẹn: nhóm gồm hai kỹ sư và ba chuyên viên tuyển dụng cùng xây dựng HoneyCrew — một hệ thống giới thiệu ứng viên thông minh, gửi bản tóm tắt hàng tuần cho nhân viên với danh sách ứng viên tiềm năng từ mạng lưới của họ. Họ chọn Lovable với mong muốn nhóm tuyển dụng sau này có thể tự bảo trì sản phẩm.

Ngày đầu tiên, mọi thứ diễn ra như bay. Nhóm hoàn thành 90% dự án: thu thập dữ liệu, chấm điểm, tích hợp Slack, trang quản trị — gần như sẵn sàng.

Sang ngày thứ hai và cũng là ngày cuối, nhóm chỉ định chỉnh vài thứ nhỏ. Thế rồi mọi thứ… đổ vỡ hoàn toàn. Lỗi tràn lan, hệ thống chậm chạp, ai cũng căng thẳng. Những chuyên viên tuyển dụng trong nhóm không hiểu chuyện gì đang xảy ra.

Chứng dị ứng với "công việc hạ tầng"

Tác giả kể về một vị lãnh đạo cấp cao cũ, người thường nói mình bị "dị ứng" với hai chữ tái cấu trúc (refactor) và công việc hạ tầng (infra work). Ông ấy không hiểu vì sao đội kỹ thuật không thể làm đúng ngay từ đầu, và vì sao lúc nào cũng chậm.

Sau khi LLM xuất hiện, tình hình còn tệ hơn. Ông liên tục hỏi: "Sao không giao việc này cho ChatGPT luôn đi? Vấn đề nằm ở đâu?"

Thành thật mà nói, ông ấy ít nhất còn hỏi thẳng mặt chúng tôi. Tôi biết nhiều lãnh đạo phi kỹ thuật khác chỉ nghĩ kỹ sư luôn phóng đại và làm việc quá chậm.

Một người bạn đồng nghiệp từng đặt câu hỏi đầy thách thức: "Cậu viết code, mà code thì chỉ là các từ trong một ngôn ngữ tôi không hiểu, với ý nghĩa cố định đúng không? Cậu biết mình muốn viết gì, vì có bản đặc tả trong tay. Vậy tại sao nó lúc nào cũng phức tạp hơn?"

Phép so sánh với việc xây nhà

Tác giả thừa nhận đã loay hoay tìm cách giải thích, cho đến khi suýt mua một căn nhà.

Vào tháng 10 năm ngoái, vợ chồng anh xem một căn nhà gần nhà bố mẹ vợ. Vị trí tốt, hàng xóm dễ chịu, có khu vườn đúng ý, giá lại rất phải chăng. Nhà nhỏ và đã 30 năm tuổi, nhưng giá rẻ để lại dư ra một khoản để sửa sang.

Họ hỏi một nhà thầu: "Cải tạo và mở rộng thêm 2 phòng thì tốn bao nhiêu?"

Câu trả lời khiến anh không thể ngừng cười: "Tôi không khuyên anh làm vậy. Nhà quá cũ rồi. Phá đi xây mới còn đơn giản và rẻ hơn nhiều."

Anh nhận xét: người thầu đó có thể trở thành một kỹ sư phần mềm cừ khôi.

Từ đó, phép so sánh với việc xây nhà được tác giả dùng thường xuyên khi nói về phần mềm. Xây nhà là công việc đã có hàng nghìn năm lịch sử, vậy mà mỗi căn nhà mới vẫn gặp những vấn đề khác nhau. Và vì ai cũng đang sống trong một căn nhà, nên câu chuyện trở nên dễ đồng cảm.

Tại sao không thể sửa nhanh cho xong?

Mái nhà bị dột. Bạn có hai lựa chọn: đặt một cái xô hứng nước, hoặc tìm tận gốc nguyên nhân. Nếu là nhà của chính bạn, bạn sẽ làm gì?

Đặt xô có thể chấp nhận được trong vài ngày, nhưng bạn phải liên tục đổ nước, và nguy cơ vấn đề thật sự trở nên nghiêm trọng hơn vẫn luôn thường trực.

Tại sao không chỉ giải quyết đúng trường hợp cụ thể này, bỏ qua hết "hạ tầng"? Hãy tưởng tượng bạn xây nhà cho gia đình. Ngân sách chỉ đủ cho tầng một, nhưng gia đình đông người và bạn biết vài năm nữa sẽ cần thêm tầng hai. Việc chuẩn bị kết cấu hạ tầng để đỡ được tầng hai rẻ hơn nhiều nếu làm ngay từ đầu, so với khi bạn thực sự muốn xây tầng hai.

Minh họa về hạ tầng và kiến trúc phần mềm

Ngôi nhà không bao giờ hoàn thiện

Quay lại 1 giờ chiều ngày cuối hackathon, khi mọi thứ đều như đổ vỡ. Nhóm không còn lựa chọn nào khác. Họ dừng cơn cuồng vibe coding, cẩn thận đi qua từng khu vực một cho đến khi có được luồng demo đơn giản hoạt động được.

Hiểu, lập kế hoạch, triển khai. Chậm hơn nhiều so với tốc độ ngày đầu, nhưng ít nhất họ cũng có một luồng demo chạy được.

Đây chính là cách phần mềm tốt được xây dựng, nhưng người ta rất dễ quên điều đó khi cứ lao về phía trước. Và khác với một căn nhà, bạn không bao giờ thực sự xây xong phần mềm — bạn phải liên tục cập nhật trang thiết bị trong khi người dùng đã sống trong đó.

Những điều đáng chú ý trong tuần

• Đừng trở thành nút thắt khi review code. Một góc nhìn thực tế và thú vị về cách xử lý sự mệt mỏi khi review code — gợi ý là không phải review nhanh hơn, cũng không phải giao hết cho AI agent.
• "Truyền cảm hứng" thực sự nghĩa là gì. Bạn không phải Viggo Mortensen đang hiệu triệu binh sĩ đánh Sauron. Bạn là một engineering manager trong ngành công nghệ.
• Người lao động ngành công nghệ cảm thấy thế nào trong năm 2026. Một khảo sát rất đáng chú ý: những nhân viên có người quản lý cực kỳ hiệu quả báo cáo mức độ yêu thích công việc cao hơn khoảng 65% và mức độ kiệt sức thấp hơn đáng kể so với những người có người quản lý kém hiệu quả.

Thế nhưng chỉ 25,5% nhân viên công nghệ đánh giá người quản lý của họ là hiệu quả cao, trong khi 36,5% đánh giá người quản lý của họ là kém hiệu quả.

Minh họa về quản lý kỹ thuật và đội ngũ