Nguyên nhân mang tính cấu trúc của thất bại dự án IT: sự thiếu hiểu biết trong quản trị lặp đi lặp lại và cái giá phải trả

• Tóm tắt khái quát:
  • Chủ đề cốt lõi: Thất bại của các dự án IT không bắt nguồn từ bài toán kỹ thuật khó, mà từ "sự thiếu hiểu biết có chủ đích" của ban lãnh đạo và sự kiêu ngạo khi từ chối học hỏi từ những thất bại trong quá khứ.
  • Các con số chính: Trong 20 năm qua, chi tiêu IT toàn cầu đã tăng gấp 3 lần (lên 5,6 nghìn tỷ USD) nhưng tỷ lệ thành công vẫn dậm chân tại chỗ, trong khi riêng việc bảo trì hệ thống legacy đã tiêu tốn 75% ngân sách.
  • Các trường hợp tiêu biểu: Sự yếu kém toàn diện trong quản trị của hệ thống Phoenix tại Canada và hành vi che giấu phi đạo đức trong vụ Horizon ở Anh không phải là "sai lầm (Blunder)", mà là "cái ác hành chính (Administrative Evil)".

---

1. Mở đầu: Tỷ lệ thất bại không cải thiện dù đầu tư khổng lồ

• Hiệu quả trì trệ so với mức đầu tư:
  • Từ sau năm 2005, chi tiêu IT toàn cầu đã tăng vọt hơn 3 lần, từ 1,7 nghìn tỷ USD lên 5,6 nghìn tỷ USD vào năm 2025.
  • Tuy nhiên, bất chấp khoản chi phí khổng lồ này, tỷ lệ thành công của các dự án phần mềm không cho thấy cải thiện rõ rệt trong 20 năm qua.
• Cảnh giác với ảo tưởng về AI:
  • Nhiều lãnh đạo kỳ vọng các công cụ AI hay công cụ hỗ trợ lập trình như Copilot sẽ giúp các dự án quy mô lớn thành công, nhưng tác giả tỏ ra hoài nghi về điều đó.
  • AI không thể giải quyết độ phức tạp của system engineering, các đánh đổi tài chính, và trên hết là "chính trị tổ chức (Organizational Politics)" trong dự án.
• Hiện tượng thất bại mang tính phổ quát:
  • Thất bại phần mềm xảy ra không phân biệt quốc gia, quy mô doanh nghiệp hay tính chất lợi nhuận/phi lợi nhuận; đây không đơn thuần là lỗi kỹ thuật mà bắt nguồn từ "sự thiếu trí tưởng tượng của con người" và "các mục tiêu phi thực tế".

2. Nội dung chính: Phân tích sâu về các kiểu thất bại và nguyên nhân

2.1. Những "sai lầm (Blunder)" lặp đi lặp lại và sự từ chối học hỏi

• Phân biệt giữa thất bại và sai lầm:
  • Những thất bại xảy ra khi thách thức giới hạn kỹ thuật, như một dạng "sáng tạo hủy diệt (Creative Destruction)", là điều nên được chào đón.
  • Nhưng phần lớn thất bại trong IT chỉ đơn thuần là "những sai lầm ngớ ngẩn (Blunder)", lặp lại các nguyên nhân đã được ghi nhận suốt nhiều thập kỷ như thiếu quản trị rủi ro hay đánh giá thấp độ phức tạp.
• Sự kiêu ngạo của giới quản lý:
  • Các quản lý dự án thường cho rằng dự án của mình "đặc biệt và duy nhất", nên có xu hướng phớt lờ dữ liệu hay các trường hợp thất bại trước đó.
  • Đây không chỉ là thiếu hiểu biết đơn thuần, mà là "sự thiếu hiểu biết có chủ đích (Willful Ignorance)" khi cố tình làm ngơ trước các tín hiệu rủi ro.
• Cái bẫy của hệ thống legacy:
  • Các tổ chức tại Mỹ chi hơn 520 tỷ USD mỗi năm chỉ để bảo trì hệ thống legacy, tương đương 70~75% tổng ngân sách IT.
  • Vì sợ thất bại khi thay thế, họ trì hoãn hiện đại hóa cho đến khi hệ thống sụp đổ về mặt vật lý (ví dụ: mainframe của Sở xe cơ giới Louisiana) hoặc hoàn toàn không còn hiệu quả về chi phí.

2.2. Chi tiết các vụ thất bại lớn và tác động lan rộng

• Hệ thống trả lương Phoenix của Canada:
  • Đánh giá sai ngay từ đầu: Khi áp dụng giải pháp có sẵn (PeopleSoft), dự án lại cố tùy biến để đáp ứng 80.000 quy tắc trả lương và 105 thỏa ước lao động tập thể.
  • Cái giá của việc cắt giảm ngân sách: Để triển khai dự án với mức ngân sách dưới 60% so với đề xuất của nhà cung cấp, họ đã ép cắt bỏ các chức năng trả lương cốt lõi, giảm kiểm thử và bỏ qua cả thử nghiệm pilot bắt buộc.
  • Kết quả: Hệ thống sụp đổ ngay sau khi vận hành năm 2016. Việc trả lương sai gây ra đau khổ tài chính cho nhân viên, thậm chí bị cho là nguyên nhân dẫn tới tự sát ở một số trường hợp.
  • Chi phí: Ngân sách ban đầu là 310 triệu CAD, nhưng chi phí khắc phục và xử lý hiện đã vượt 5,1 tỷ CAD (khoảng 3,6 tỷ USD).
• Vụ bê bối Horizon của Bưu điện Anh:
  • Lỗi kỹ thuật: Bug middleware trong hệ thống do Fujitsu cung cấp đã gây ra các sai lệch về tiền bạc.
  • Sự che giấu có hệ thống: Dù biết phần mềm có lỗi, ban lãnh đạo vẫn che giấu và thậm chí truy tố 3.500 trưởng bưu cục về tội biển thủ và trộm cắp. 900 người bị kết án và bỏ tù.
  • Cái giá xã hội: Nạn nhân rơi vào phá sản, ly hôn, tù tội và tự sát. Vụ việc được ghi nhận là thất bại IT và thảm họa tư pháp tồi tệ nhất trong lịch sử Anh.

2.3. Ra quyết định tự động và "cái ác hành chính"

• Tính bạo lực của thuật toán:
  • Các hệ thống MiDAS của bang Michigan, Mỹ (phát hiện gian lận trợ cấp thất nghiệp) và Robodebt của Australia (phát hiện gian lận phúc lợi) đã đưa ra phán quyết chỉ dựa vào thuật toán mà không có giám sát của con người.
  • Họ đã đẩy hàng chục nghìn công dân vô tội thành tội phạm, nhưng ngay cả khi lỗi hệ thống đã được chứng minh, giới quan chức vẫn từ chối bồi thường hoặc né tránh trách nhiệm.
• Rủi ro khi đưa AI vào vận hành:
  • Kiểu "cái ác hành chính (Administrative Evil)" này sẽ càng trầm trọng hơn khi AI can thiệp ngày càng sâu vào hạ tầng công cộng.
  • EU đã đưa vào "quyền yêu cầu giải thích", nhưng trên toàn cầu, nhu cầu cấp bách hiện nay là phải xác lập tính minh bạch và trách nhiệm đối với thuật toán.

3. Kết luận: Giải pháp và bài toán cho cộng đồng IT

• Phương pháp luận (Agile/DevOps) không phải chìa khóa vạn năng:
  • Có báo cáo cho thấy tỷ lệ thất bại của các dự án Agile lên tới 65%, cho thấy bản thân phương pháp luận không bảo đảm thành công. Nếu không có lãnh đạo nhất quán và kỷ luật tổ chức, bất kỳ phương pháp mới nào cũng sẽ thất bại.
• Đánh giá rủi ro trung thực và trách nhiệm đạo đức:
  • Trước khi bắt đầu dự án, cần thực hiện phân tích khoảng cách (Gap Analysis) một cách trung thực về "ta biết gì và ta chưa biết gì".
  • Cần mở rộng khái niệm "AI lấy con người làm trung tâm (Human-centered AI)" sang mọi dự án IT, để đưa cả tổn thất cảm xúc và tài chính mà người dùng cuối phải chịu khi hệ thống thất bại vào phân tích chi phí - lợi ích.
• Kêu gọi thay đổi thái độ của lãnh đạo:
  • Phần mềm về bản chất là mong manh (Fragile) và phức tạp. Lãnh đạo không chỉ nên đứng ở vị thế người nắm ngân sách, mà còn phải tôn trọng và hỗ trợ phát triển phần mềm với tư cách là người chịu trách nhiệm khi thất bại xảy ra.
  • Chỉ khi chấm dứt các lỗi lặp đi lặp lại, ngành IT mới có thể thoát khỏi "khủng hoảng (Crisis)".

[baeba]

Tóm tắt phản ứng bình luận trên Hacker News

1. Thiếu chiến lược triển khai và mở rộng dần dần (Start Small)

• Thất bại gần như tất yếu của cách làm 'big bang': Triển khai một dự án quy mô quốc gia chỉ trong một lần là hành động tự sát. Cần chiến lược mở rộng bằng cách kiểm chứng tuần tự từ đơn vị nhỏ (làng → thành phố → quốc gia).
• Khác biệt giữa sản phẩm và hệ thống: Không giống một sản phẩm đơn lẻ như WhatsApp, các hệ thống doanh nghiệp phức tạp phải gánh quy mô rất lớn ngay từ đầu, nên cách tiếp cận phải khác.
• Giải pháp cốt lõi: Nguyên tắc "làm nhỏ trước, kiểm chứng rồi mới thêm chức năng" đang bị phớt lờ.

2. Sự kém năng lực của ban quản lý và né tránh trách nhiệm (Management Issues)

• Cấu trúc quyền lực không đi kèm trách nhiệm: Khi dự án thất bại, lập trình viên phải làm thêm giờ để cứu vãn, còn giới quản lý nắm quyền quyết định thì không chịu trách nhiệm, thậm chí còn nhận thưởng — một cấu trúc đầy mâu thuẫn bị chỉ trích.
• Thiếu hiểu biết kỹ thuật: Việc ép tiến độ phi thực tế, phớt lờ độ khó kỹ thuật, cùng văn hóa cấp trên - cấp dưới từ chối nghe "tin xấu" đã cản trở giải quyết vấn đề.
• Ra quyết định mang tính chính trị: Giải pháp thường được chọn dựa trên chính trị nội bộ hoặc quan hệ với vendor bên ngoài (như rebate) thay vì mức độ phù hợp về mặt kỹ thuật.

3. Yêu cầu mất kiểm soát và độ phức tạp gia tăng (Complexity & Scope Creep)

• Không đơn giản hóa quy trình trước: Như trường hợp trong Phoenix Project, việc cố số hóa nguyên trạng 80.000 quy tắc lương thay vì sắp xếp lại chúng là nguyên nhân gốc rễ. Một quy trình offline hỗn loạn chỉ tạo ra một hệ thống số cũng hỗn loạn.
• Thay đổi yêu cầu liên tục: Việc mở rộng phạm vi công việc (Scope Creep) do thay đổi thất thường từ ban quản lý hoặc khách hàng trong lúc dự án đang chạy khiến dự án sa lầy.

4. Văn hóa lập trình viên và các động lực sai lệch (Developer Culture)

• Phát triển theo CV (RDD): Vì lợi ích nhảy việc của bản thân hơn là thành công của dự án, nhiều người cưỡng ép đưa vào các công nghệ thời thượng mới nhất (framework), làm tăng technical debt.
• Sự đứt gãy trong học hỏi: Văn hóa nhảy việc thường xuyên theo chu kỳ 2–3 năm khiến lập trình viên không có cơ hội chứng kiến thất bại dài hạn của chính đoạn code mình viết và rút ra bài học.
• Ám ảnh phát minh lại từ đầu: Một thói quen kém hiệu quả là viết lại toàn bộ code từ đầu để thỏa mãn cái tôi cá nhân, thay vì tận dụng các giải pháp sẵn có đã được kiểm chứng.

5. Tính đặc thù của kỹ nghệ phần mềm (Engineering Nature)

• Thiếu ràng buộc vật lý: Khác với xây dựng hay phần cứng, phần mềm không có ràng buộc vật lý nên cho phép độ phức tạp tăng gần như vô hạn, từ đó dẫn tới trạng thái mất kiểm soát.
• Không học từ quá khứ: Các ngành kỹ thuật khác phân tích kỹ các thất bại (ví dụ: sập cầu) và để lại bài học, nhưng ngành phần mềm lại hành xử theo kiểu 'YOLO', luôn cho rằng "lần này sẽ khác" và tiếp tục lặp lại sai lầm cũ.