IT proje başarısızlıklarının yapısal nedenleri: Tekrarlanan yönetsel cehalet ve bunun maliyeti

• Özet genel bakış:
  • Temel konu: IT proje başarısızlıkları teknik zorluklardan değil, yöneticilerin 'kasıtlı cehaletinden' ve geçmiş başarısızlıklardan ders çıkarmayı reddeden kibirden kaynaklanıyor.
  • Başlıca sayılar: Son 20 yılda küresel IT harcamaları 3 katına çıkarak 5,6 trilyon dolara ulaştı, ancak başarı oranı yerinde saydı; bütçelerin %75'i yalnızca legacy sistemlerin bakımına harcanıyor.
  • Temel örnekler: Kanada'nın Phoenix sistemi vakasındaki kapsamlı yönetim zafiyeti ile Birleşik Krallık'taki Horizon olayındaki etik dışı örtbas, birer 'hata (Blunder)' değil, 'idari kötülük (Administrative Evil)' örneği.

---

1. Giriş: Devasa yatırımlara rağmen iyileşmeyen başarısızlık oranı

• Yatırıma karşı verimlilikte durgunluk:
  • 2005'ten bu yana dünya genelindeki IT harcamaları 1,7 trilyon dolardan 2025 itibarıyla 5,6 trilyon dolara çıkarak üç kattan fazla arttı.
  • Ancak bu devasa harcamalara rağmen yazılım projelerinin başarı oranında son 20 yılda belirgin bir iyileşme görülmedi.
• Yapay zeka fantezilerine karşı uyarı:
  • Pek çok yönetici, yapay zeka araçlarının ya da kodlama yardımcılarının (Copilot) büyük ölçekli projeleri başarıya ulaştıracağını düşünüyor, ancak yazar buna şüpheyle yaklaşıyor.
  • Yapay zeka, sistem mühendisliğinin karmaşıklığını, finansal trade-off'ları ve her şeyden önce proje içindeki 'örgütsel siyaset (Organizational Politics)' sorununu çözemiyor.
• Evrensel başarısızlık olgusu:
  • Yazılım başarısızlıkları ülke, şirket ölçeği, kâr amacı güdüp gütmeme fark etmeksizin ayrım gözetmeden ortaya çıkıyor; bunun nedeni basit teknik hatalar değil, 'insan hayal gücünün eksikliği' ve 'gerçekçi olmayan hedefler'.

2. Ana bölüm: Başarısızlık türleri ve nedenlerinin derinlemesine analizi

2.1. Tekrarlanan 'hata (Blunder)' ve öğrenmeyi reddetme

• Başarısızlık ile hata arasındaki ayrım:
  • Teknik sınırları zorlayarak yaşanan ve 'yaratıcı yıkım (Creative Destruction)' niteliği taşıyan başarısızlıklar memnuniyetle karşılanmalı.
  • Ancak IT başarısızlıklarının çoğu, onlarca yıldır belgelenmiş nedenlerin (risk yönetimi eksikliği, karmaşıklığın hafife alınması vb.) tekrarlandığı 'aptalca hatalardan (Blunder)' ibaret.
• Yönetim kibrinin etkisi:
  • Proje yöneticileri kendi projelerinin "özel ve benzersiz" olduğunu savunarak geçmiş başarısızlık örneklerini ya da verileri görmezden gelme eğiliminde.
  • Bu, basit bir cehalet değil; risk işaretlerine bilinçli olarak sırt çeviren 'kasıtlı cehalet (Willful Ignorance)' durumu.
• Legacy sistem tuzağı:
  • ABD'deki kurumlar yalnızca legacy sistemlerin bakımına yılda 520 milyar dolardan fazla harcıyor; bu da toplam IT bütçesinin %70 ila %75'ine karşılık geliyor.
  • Değiştirme girişiminin başarısız olmasından korkulduğu için modernizasyon, sistem fiziksel olarak çökene (ör. Louisiana Motorlu Taşıtlar Kurumu ana bilgisayarı) ya da maliyet etkinliği tamamen ortadan kalkana kadar erteleniyor.

2.2. Başlıca başarısızlık vakalarının ayrıntıları ve etkileri

• Kanada Phoenix payroll sistemi:
  • İlk yanlış hesap: Hazır bir çözüm olan PeopleSoft alınırken 80.000 maaş kuralı ve 105 sendika-toplu sözleşme düzenlemesinin özelleştirilmesi hedeflendi.
  • Bütçe kesintisinin bedeli: Proje, satıcının önerdiği bütçenin %60'ından azıyla yürütülmeye çalışıldığı için temel maaş işlevleri çıkarıldı, testler azaltıldı ve zorunlu pilot test atlandı.
  • Sonuç: 2016'da devreye alındıktan hemen sonra çöktü. Çalışan maaşlarının yanlış ödenmesi ciddi mali sıkıntılara yol açtı ve bazı çalışan intiharlarının nedenlerinden biri olarak gösterildi.
  • Maliyet: Başlangıç bütçesi 310 milyon Kanada dolarıydı, ancak toparlama ve çözüm maliyeti bugün 5,1 milyar Kanada dolarını (yaklaşık 3,6 milyar ABD doları) aştı.
• Birleşik Krallık Post Office Horizon skandalı:
  • Teknik kusur: Fujitsu tarafından sağlanan sistemdeki middleware hatası parasal uyumsuzluk kayıtlarına yol açtı.
  • Kurumsal örtbas: Yönetim yazılım kusurunu bilmesine rağmen bunu gizledi ve bunun yerine 3.500 postane müdürünü zimmete para geçirme ve hırsızlıkla suçladı. 900 kişi mahkûm edilip hapse atıldı.
  • Toplumsal maliyet: Mağdurlar arasında iflas, boşanma, hapis ve intihar vakaları yaşandı. Bu olay, Birleşik Krallık tarihinin en kötü IT başarısızlığı ve adli skandallarından biri olarak kayda geçti.

2.3. Otomatik karar alma ve 'idari kötülük'

• Algoritmaların şiddeti:
  • ABD'nin Michigan eyaletindeki MiDAS (işsizlik yardımı dolandırıcılığı tespiti) ve Avustralya'nın Robodebt (sosyal yardım dolandırıcılığı tespiti) sistemleri, insan denetimi olmadan yalnızca algoritmalara dayanarak karar verdi.
  • On binlerce masum vatandaşı suçlu durumuna düşürdüler, ancak bürokratlar sistem hatası kanıtlandıktan sonra bile tazminatı reddetti ya da sorumluluktan kaçındı.
• Yapay zeka benimsemenin riski:
  • Bu tür 'idari kötülük (Administrative Evil)', yapay zeka kamu altyapısına daha derin biçimde yerleştikçe ağırlaşacak.
  • AB 'açıklama talep etme hakkı'nı uygulamaya aldı, ancak küresel ölçekte şeffaflık ve algoritmalar için hesap verebilirliğin netleştirilmesi acil bir ihtiyaç.

3. Sonuç: Çözümler ve IT topluluğunun görevi

• Yöntemler (Agile/DevOps) sihirli anahtar değil:
  • Agile projelerde başarısızlık oranının %65'e kadar çıkabildiğini gösteren raporlarda da görüldüğü gibi, yöntemin kendisi başarıyı garanti etmiyor. Tutarlı liderlik ve kurumsal disiplin olmadan hiçbir yeni metodoloji başarılı olamıyor.
• Dürüst risk değerlendirmesi ve etik sorumluluk:
  • Proje başlamadan önce "Neyi biliyoruz, neyi bilmiyoruz?" sorusuna dürüstçe bakan bir boşluk analizi (Gap Analysis) yapılmalı.
  • 'İnsan merkezli yapay zeka (Human-centered AI)' kavramı tüm IT projelerine genişletilmeli; sistem arızalarının son kullanıcıya vereceği duygusal ve finansal zarar, maliyet-fayda analizine dahil edilmeli.
• Yöneticilerin tutumunu değiştirme çağrısı:
  • Yazılım doğası gereği kırılgan (Fragile) ve karmaşıktır. Yöneticiler, yalnızca bütçeyi elinde tutan güç sahipleri olarak değil, başarısızlık durumunda sorumluluk taşıyan aktörler olarak da yazılım geliştirmeye saygı duymalı ve destek vermeli.
  • Tekrarlanan hataları durdurmak, IT sektörünün bu 'krizden (Crisis)' çıkmasının tek yolu.

[baeba]

Hacker News yorum tepkilerinin özeti

1. Kademeli dağıtım ve ölçeklendirme stratejisi eksikliği (Start Small)

• 'Big bang' yaklaşımının kaçınılmaz başarısızlığı: Ulusal ölçekte bir projeyi tek seferde devreye almak intihar niteliğindedir. Küçük birimlerden (köy → şehir → ülke) başlayıp sırayla doğrulama yaparak büyütme stratejisi şarttır.
• Ürün ile sistem arasındaki fark: WhatsApp gibi tekil bir ürünün aksine, karmaşık kurumsal sistemler en baştan devasa ölçeği kaldırmak zorunda olduğundan yaklaşım farklı olmalıdır.
• Temel çözüm: "Küçük başla, doğruladıktan sonra işlev ekle" ilkesi göz ardı ediliyor.

2. Yönetimin yetersizliği ve sorumluluktan kaçışı (Management Issues)

• Sorumluluksuz güç yapısı: Proje başarısız olduğunda geliştiriciler fazla mesaiyle toparlamaya çalışırken, karar verici yöneticilerin sorumluluk almaması hatta bonus alması gibi çelişkili yapı eleştiriliyor.
• Teknik anlayış eksikliği: Teknik zorluğu yok sayan gerçek dışı takvim dayatmaları ve 'kötü haber' duymayı reddeden yukarıdan aşağı kültür, sorun çözümünü engelliyor.
• Siyasi karar alma: Çözümler çoğu zaman teknik uygunluktan çok şirket içi siyaset veya dış vendor ilişkileri (ör. geri ödeme/komisyonlar) üzerinden belirleniyor.

3. Kontrol edilemeyen gereksinimler ve karmaşıklık (Complexity & Scope Creep)

• Süreç sadeleştirmesinin önce gelmemesi: Phoenix Project örneğinde olduğu gibi 80 bin maaş kuralını düzenlemeden aynen dijitalleştirmeye çalışmak temel nedenlerden biri. Dağınık bir offline süreç, yalnızca dağınık bir dijital sistem üretir.
• Sık gereksinim değişiklikleri: Proje sırasında yönetimin ya da müşterinin değişken talepleri yüzünden iş kapsamının genişlemesi (Scope Creep), projeyi bataklığa sürüklüyor.

4. Geliştirici kültürü ve yanlış teşvikler (Developer Culture)

• Özgeçmiş odaklı geliştirme (RDD): Projenin başarısından çok kendi iş değişikliğine fayda sağlayacak en yeni moda teknolojileri (framework'ler) zorla kullanarak teknik borcu artırıyorlar.
• Öğrenme kopukluğu: 2-3 yıllık döngülerle sık iş değiştirme (job hopping) kültürü yüzünden geliştiriciler, kendi yazdıkları kodun uzun vadeli başarısızlığını görme ve bundan ders çıkarma fırsatını kaçırıyor.
• Yeniden icat takıntısı: Kanıtlanmış mevcut çözümleri kullanmak yerine, kişisel tatmin uğruna kodu sıfırdan yeniden yazma gibi verimsiz bir pratik yaygın.

5. Yazılım mühendisliğinin kendine özgü doğası (Engineering Nature)

• Fiziksel kısıtların olmaması: Mimarlık/donanımın aksine yazılımda fiziksel kısıtlar yoktur; bu da sonsuz karmaşıklığa izin vererek kontrol kaybına yol açar.
• Geçmişten öğrenmeme: Diğer mühendislik alanları başarısızlıkları (ör. köprü çökmesi) titizlikle analiz edip ders çıkarırken, yazılım sektörü "bu kez farklı" diyerek geçmiş hataları tekrarlayan bir 'YOLO' tarzı geliştirme sergiliyor.