- Chi tiêu CNTT trên toàn cầu đã tăng hơn gấp ba kể từ năm 2005, nhưng tỷ lệ thành công của các dự án phần mềm quy mô lớn gần như không cải thiện
- Các thất bại về quản trị, tổ chức và đạo đức lặp lại ở hệ thống trả lương Phoenix của Canada, Post Office Horizon của Anh, cùng các hệ thống phúc lợi và hành chính tại Mỹ và Australia
- Công cụ AI hay copilot không thể giải quyết những vấn đề này; sự thiếu tưởng tượng của con người, mục tiêu phi thực tế và thất bại trong quản trị rủi ro vẫn là nguyên nhân chính
- Chi phí duy trì hệ thống legacy chiếm 70–75% ngân sách CNTT, và ngay cả việc áp dụng Agile·DevOps cũng có tỷ lệ thất bại cao nếu thiếu thay đổi về lãnh đạo tổ chức và văn hóa
- Những sai lầm quản lý lặp đi lặp lại và sự né tránh trách nhiệm làm gia tăng chi phí xã hội, trong khi minh bạch, đạo đức và thiết kế hệ thống lấy con người làm trung tâm được nêu ra như các nhiệm vụ thiết yếu
Vấn đề dai dẳng của thất bại phần mềm
- Trong 20 năm qua, chi tiêu CNTT đã tăng từ 1,7 nghìn tỷ USD lên 5,6 nghìn tỷ USD nhưng tỷ lệ thành công của phần mềm vẫn dậm chân tại chỗ
- Thất bại xảy ra bất kể quốc gia, ngành hay loại hình tổ chức
- Chi phí xã hội và kinh tế của các thất bại tiếp tục tăng lên
- Chỉ ra rõ giới hạn của AI trong việc giải quyết vấn đề quản trị
- AI khó có thể kiểm soát những xung đột lợi ích phức tạp và các yếu tố chính trị trong các dự án quy mô lớn
- Các dự án CNTT vốn đã có nhiều quyết định phi lý, nên thiếu các trường hợp đủ tốt để AI học hỏi
- Nguyên nhân thất bại gồm sự thiếu tưởng tượng của con người, mục tiêu không rõ ràng, thất bại trong quản lý độ phức tạp và thiếu kiểm soát rủi ro
- Cùng những yếu tố đó lặp lại suốt nhiều thập kỷ, tạo nên hiện tượng “failure déjà vu”
Hệ thống trả lương Phoenix của Canada
- Hệ thống Phoenix trị giá 310 triệu CAD đưa vào vận hành năm 2016 đã thất bại khi cố gắng hợp nhất 80.000 quy tắc trả lương và 105 thỏa ước công đoàn
- Vì cắt giảm ngân sách, dự án đã thúc ép quy trình bằng cách rút gọn kiểm thử và pilot, loại bỏ các chức năng cốt lõi
- Kết quả là trong 9 năm, 70% trong số 430.000 nhân viên đã gặp lỗi lương
- Tính đến tháng 3/2025, còn 349.000 lỗi chưa được xử lý, hơn một nửa bị chậm trên 1 năm
- Thậm chí đã ghi nhận các trường hợp nhân viên tự tử
- Tổng chi phí đã vượt 5,1 tỷ CAD, và cơ quan kiểm toán đánh giá đây là “một thất bại khó hiểu trong quản lý và giám sát dự án”
Hệ thống Post Office Horizon của Anh
- Hệ thống POS Horizon của Fujitsu triển khai từ năm 1999 đã che giấu lỗi nội bộ, khiến 3.500 trưởng điểm bưu cục bị truy tố vì kế toán sai và gian lận
- 900 người bị kết tội, 236 người bị bỏ tù, hơn 13 người tự tử
- Thất bại về công nghệ, quản lý, pháp lý và đạo đức cùng lúc tác động
- Middleware đầy lỗi, mở rộng phạm vi ngoài kiểm soát, thiếu kiểm thử, thiếu nhân lực
- Ban lãnh đạo thù địch với người nêu vấn đề, che giấu bằng chứng và cố gắng bưng bít có hệ thống
- Các nỗ lực thay thế vào năm 2016 và 2021 cũng thất bại, và Horizon vẫn đang được sử dụng
- Ngân sách cho hệ thống mới là 410 triệu bảng Anh, dự kiến quyết định vào tháng 7/2026
Các ví dụ thất bại lớn khác
- Minnesota MNLARS: bắt đầu năm 2016, hủy năm 2019, chi phí 100 triệu USD
- Modernising Business Registers của Australia: ngân sách từ 480 triệu AUD tăng lên 2,8 tỷ AUD, bị hủy năm 2022
- Hệ thống đăng ký xe của Louisiana: mainframe 50 năm tuổi liên tục gặp sự cố, khiến bang phải tuyên bố tình trạng khẩn cấp năm 2025
- Jaguar Land Rover: cuộc tấn công mạng năm 2025 khiến hoạt động toàn cầu ngừng trệ hơn một tháng, thiệt hại 1,2–1,9 tỷ USD
- Lidl ERP: ERP dựa trên SAP trị giá 500 triệu euro thất bại, sau đó quay lại hệ thống tự phát triển (2017)
- Boeing 737 Max: lỗi thiết kế MCAS làm 346 người thiệt mạng, tổng chi phí ước tính 74 tỷ USD
- Nâng cấp F-35 Block 4: chậm tiến độ 5 năm, chi phí tăng từ 10,5 tỷ USD lên 16,5 tỷ USD
Chi phí kinh tế của thất bại
- Tại Mỹ, chi phí thất bại phần mềm năm 2022 là 1,81 nghìn tỷ USD, trong đó thất bại phát triển là 260 tỷ USD
- Tổng số này lớn hơn cả ngân sách quốc phòng (778 tỷ USD)
- Chi phí duy trì hệ thống legacy là 520 tỷ USD mỗi năm, chiếm 70–75% ngân sách CNTT
- Vì chi phí thay thế quá cao và rủi ro thất bại lớn nên việc thay thế thường bị trì hoãn
- Báo cáo NTT DATA 2024: 80% tổ chức cho biết công nghệ cũ đang cản trở đổi mới
- Phần lớn lãnh đạo nhận thức rằng hạ tầng legacy đang cản trở khả năng phản ứng với thị trường
Giới hạn của Agile·DevOps
- Dù phương thức phát triển lặp và tăng dần đã lan rộng, tỷ lệ thất bại vẫn còn nguyên
- Một số báo cáo nêu tỷ lệ thất bại của dự án Agile là 65%, DevOps lên tới 90%
- Để triển khai thành công cần có lãnh đạo, kỷ luật tổ chức, đào tạo và thay đổi văn hóa
- Nhưng phần lớn tổ chức không thể duy trì điều đó
Sai lầm quản lý lặp lại và sự thiếu học hỏi
- Các nhà quản lý dự án CNTT thường nói “dự án của chúng tôi khác” và bỏ qua bài học từ các thất bại trước đó
- Chính phủ Canada đã lặp lại bài học thất bại của hệ thống trả lương đầu tiên năm 1995 trong dự án Phoenix
- Phần lớn thất bại bắt nguồn từ những sai sót quản lý tầm thường hơn là các nỗ lực đổi mới táo bạo
- Nó gần với “phá hủy tài chính” hơn là “phá hủy sáng tạo”
- Các ví dụ thất bại của hệ thống hành chính dựa trên AI
- MiDAS về trợ cấp thất nghiệp của Mỹ và Centrelink Robodebt của Australia đã dùng thuật toán sai để truy tố oan hàng trăm nghìn người
- Chính phủ tỏ ra thiếu tích cực trong việc thừa nhận lỗi và bồi thường
Sự cần thiết của trách nhiệm, đạo đức và minh bạch
- Các quyết định thiếu minh bạch trong những hệ thống có AI nhúng làm dấy lên lo ngại xâm phạm quyền công dân
- EU đã bảo đảm bằng pháp luật ‘quyền được giải thích đối với quyết định của thuật toán’
- Càng ngày càng có nhiều ý kiến cho rằng cần xác lập minh bạch và trách nhiệm của hệ thống tự động như một quyền con người trên toàn cầu
- Có thảo luận về luật trách nhiệm phần mềm và chế độ cấp phép hành nghề chuyên gia, nhưng khả năng hiện thực hóa là thấp
- Giải pháp thực tế hơn là tăng cường sự trung thực, tư duy hoài nghi và phán đoán đạo đức của giới điều hành
- Cần nhận diện rõ rủi ro và cảnh giác với những lời hứa phóng đại từ nhà cung cấp
- Nhấn mạnh áp dụng nguyên tắc thiết kế lấy con người làm trung tâm cho mọi hệ thống CNTT, bao gồm cả AI
Kết luận: Đã đến lúc dừng lặp lại sai lầm
- Phát triển phần mềm vốn dĩ phức tạp và mong manh, và lỗi nhỏ cũng có thể dẫn đến hậu quả lớn
- Để dự án thành công, nguồn lực đầy đủ, lãnh đạo và trách nhiệm giải trình là điều thiết yếu
- Cần tính đến cả thiệt hại cảm xúc và kinh tế đối với người dùng khi ước tính chi phí
- Hơn 50 năm sau “khủng hoảng phần mềm” năm 1968, chúng ta vẫn lặp lại cùng một sai lầm
- “Hãy mắc những sai lầm mới.”
> “Ai cũng có thể mắc sai lầm, nhưng chỉ kẻ ngốc mới cố chấp bám lấy sai lầm của mình” - nhà hùng biện La Mã Cicero
5 bình luận
Ý kiến trên Hacker News
Tôi thấy giải pháp được đưa ra ở phần cuối bài vẫn còn khá thiếu thuyết phục
Theo tôi, giải pháp thực sự là bắt đầu nhỏ và kiểm chứng trong môi trường vận hành thực tế
Ví dụ, nếu muốn xây dựng một hệ thống trả lương toàn quốc, trước tiên nên thử nghiệm ở một thị trấn nhỏ khoảng 50 người, sửa lỗi rồi mới dần mở rộng ra các thành phố lớn hơn
Không tồn tại quy trình phát triển phần mềm nào có thể bỏ qua việc giải quyết vấn đề ở quy mô nhỏ mà nhảy thẳng lên quy mô toàn quốc
Lượng giao dịch thấp nên nếu có vấn đề vẫn có thể điều chỉnh thủ công, đồng thời tránh được các quy định PCI
Nhờ thử theo cách đó trước khi triển khai ra cửa hàng thật, chúng tôi vẫn kịp deadline mà không gặp sự cố lớn nào
Nếu ngay từ đầu đã triển khai ở cửa hàng phục vụ khách, hẳn đã xảy ra hỗn loạn lớn vì lỗi tính thuế hoặc vấn đề hiệu năng
Mở rộng dần dần sẽ tích lũy technical debt, rồi đến lúc không ai còn chắc chắn về phần cốt lõi của codebase và rơi vào nỗi sợ rewrite
Ngay cả với một sản phẩm đơn giản như WhatsApp, thiết kế kỹ thuật vẫn phải tính đến khả năng mở rộng quy mô lớn ngay từ đầu
Với những hệ thống nhỏ và thành công, kiểu người này dễ xuất hiện hơn, từ đó có thể xây dựng lòng tin từ cả người dùng lẫn lập trình viên để tăng trưởng dần dần
Vì các dự án lớn có xác suất thất bại cao, nên theo Nguyên tắc phòng ngừa (Precautionary Principle), ta phải bắt đầu từ quy mô nhỏ
Với bất kỳ dự án nào, vòng lặp này cũng là nền tảng
Hãy bắt đầu nhỏ, rồi mô-đun hóa sau đó mở rộng. Trường hợp megafactory của Tesla đặc biệt gây ấn tượng
Điều tôi rút ra khi nghiên cứu lịch sử công nghệ là: ngành hardware học từ những thành công và thất bại trong quá khứ, còn ngành phần mềm thì không
Phần lớn lập trình viên không học bằng cách mổ xẻ các hệ thống cũ, nên mỗi thế hệ lại phải trải qua cùng một vấn đề thêm lần nữa
Trong retro, câu hỏi lúc nào cũng chỉ là “lần sau developer cần làm khác đi điều gì?”, còn manager thì không phải chịu trách nhiệm gì
Kết cục là cùng một vấn đề lặp lại mãi, và gánh nặng lại bị đẩy cho phía developer
Các thế hệ trước giải quyết vấn đề ở phần đáy của stack, còn bây giờ người ta chỉ muốn giải quyết ở phần trên
Hệ quả là tòa tháp abstraction cứ cao dần, tài nguyên tiêu tốn nhiều hơn nhưng chức năng thì không khác bao nhiêu
Giờ chúng ta còn đang bước vào thời kỳ chồng thêm một lớp phần mềm nữa lên trên các mô hình AI
Cả kinh nghiệm lẫn tính cách đều quan trọng, và cái tôi thấp cùng tư duy tập trung vào giải quyết vấn đề là điều bắt buộc
Đa số mọi người đều đánh giá thấp độ phức tạp của dự án
Thời học cao học, tôi từng dành một tuần chỉ để đọc source code của TinyOS và nắm cấu trúc của nó; trải nghiệm đó giúp tôi rất nhiều
Khả năng nhanh chóng hiểu một codebase xa lạ là cực kỳ hữu ích
Nếu các ngôn ngữ hay framework mới cứ định kỳ xuất hiện, doanh nghiệp sẽ có thể tiếp tục tuyển nhân sự mới lương thấp
Tôi nghĩ đó cũng là một trong các lý do khiến phần mềm không được đối xử như những ngành kỹ thuật khác
Về căn bản, đây không phải vấn đề của lập trình mà là vấn đề quản lý bất tài
Trong đa số dự án, yêu cầu nghiệp vụ không được xác định rõ ràng, nên mọi thứ đều được triển khai dựa trên phỏng đoán
Thất bại của các dự án CNTT công quy mô lớn sẽ dễ hiểu hơn nếu nhìn vào cấu trúc hợp đồng và incentive
Vấn đề là mô hình phụ thuộc vào tư vấn tính phí theo giờ hơn là năng lực thực sự
Với các dự án thành công, yếu tố cốt lõi không phải công nghệ mà là sự đồng bộ giữa các tổ chức (alignment) và năng lực (competence)
Tôi nghĩ phân biệt tuổi tác ở Silicon Valley mới là một vấn đề thật sự
Kinh nghiệm bị xem nhẹ, và những bài học trong quá khứ hoàn toàn không được phản ánh
Ngành hardware đã theo đuổi đổi mới mà vẫn biết tôn trọng di sản
Theo góc nhìn đó, người đã học từ thất bại trong quá khứ sẽ không còn dám thử điều mới nữa
Cuối cùng thì các dự án phần mềm thất bại là do sự thất bại của con người
Quan trọng hơn quy trình hay công cụ hoàn hảo là những con người có động lực và tinh thần trách nhiệm
Cần phải có hệ quả pháp lý (Consequences) thì con người mới làm việc tử tế
Giống như trong xây dựng công trình vật lý, mỗi giai đoạn nên có kiểm chứng độc lập và trách nhiệm rõ ràng
Vì vậy trên thực tế, vẫn phải tiến hành với một mức độ rủi ro nhất định
Những dự án thành công thường là nhờ một vài cá nhân có trí tuệ cảm xúc và năng lực lãnh đạo
Cuối cùng, software engineering vẫn là vấn đề con người
Nhưng ngành này vẫn đang chìm trong né tránh trách nhiệm và chạy theo trào lưu
Những vấn đề này không chỉ riêng phần mềm
Các dự án hạ tầng lớn như Auburn Dam, Columbia River Crossing, Big Dig cũng nổi tiếng vì đội vốn
Nếu ngân sách ban đầu phi thực tế, thì đó có thể chỉ là chi phí đã được điều chỉnh về đúng thực tế
Vì vậy cách tiếp cận bắt đầu từ dự án nhỏ rồi mở rộng dần là rất quan trọng
Tôi không phải developer hay PM, nhưng vẫn tò mò về những trường hợp thành công ở quy mô lớn
Vì tôi làm trong bệnh viện, nên nếu là case thành công liên quan đến healthcare thì càng tốt
Tôi đã đọc The Phoenix Project và phần nào hiểu được tư duy Agile và DevOps, nhưng vẫn khó áp dụng vào công việc thực tế
Tôi muốn gieo những hạt giống thành công từ các dự án nhỏ
Chúng bắt đầu từ sự phản tỉnh trước độ phức tạp của Multics, rồi Ken Thompson tự viết Unix chỉ trong 3 tuần
Tham khảo bài viết này
Conway’s Law, rủi ro phụ thuộc nhân sự cốt lõi, quyền sở hữu rõ ràng, văn hóa testing cũng đều rất quan trọng
Trên hết là phải có dũng khí để nói “không”
Cũng có những trường hợp như healthcare.gov, ban đầu thất bại nhưng sau đó được cải thiện
Trước khi đổ lỗi cho cộng đồng IT, cần nhìn vào văn hóa doanh nghiệp chạy theo lợi ích ngắn hạn
Bảo mật và độ ổn định luôn là mục bị cắt ngân sách đầu tiên
Ban lãnh đạo thất bại vẫn rời đi với golden parachute, còn trách nhiệm thì để lại cho developer
Chính phủ cũng không trừng phạt thích đáng các sự cố bảo mật do doanh nghiệp làm cẩu thả
Rốt cuộc, thực tế đầy mỉa mai kiểu “cứ để AI, consultant, outsourcing giải quyết” lại tiếp tục lặp lại
Đổ hàng nghìn tỷ won vào AI cũng sẽ không cải thiện được tình hình, thậm chí còn làm mọi thứ tệ hơn
Xã hội phương Tây vốn đã bất ổn và đang nghiêng về cực hữu
Cuộc khủng hoảng tiếp theo có thể không chỉ là sụp đổ tài chính mà còn dẫn tới đổ vỡ xã hội
Nhân loại cần tiến lên bằng sự thấu hiểu thay vì khủng hoảng
Nếu quy trình tốt, nó khuếch đại kết quả; nếu quy trình tệ, nó sẽ tăng tốc các vấn đề
Cuối cùng hướng đi vẫn vậy, chỉ là tốc độ nhanh hơn mà thôi
Nếu ngần ấy thời gian mà vẫn chưa sửa được, thì có lẽ đây không phải vấn đề về kỹ thuật phát triển hay nguyên tắc phát triển, mà là vấn đề ở phía vận hành tiếp nhận nó chăng...
Vụ bê bối Bưu điện Anh cũng đã được dựng thành phim.
Cho đến nay các nạn nhân vẫn chưa được bồi thường, nên vụ việc vẫn đang tiếp diễn.
Ví dụ gần đây trong nước mà tôi nhớ tới là vụ thất bại của dự án xây dựng hệ thống điện toán thế hệ mới của Quỹ Bảo lãnh Tín dụng Gyeonggi.
https://v.daum.net/v/20251111165048155
Ở các nước khác cũng triển khai những dự án SI khổng lồ như vậy sao