Yazılım Projeleri Neden Başarısız Olur? 8 Neden + Çözüm

Yazılım projeleri çoğunlukla teknoloji yüzünden değil, karar süreçleri yüzünden çöker. Standish Group'un CHAOS verilerine göre projelerin yalnızca %31'i hedeflenen süre, bütçe ve kapsamla tamamlanıyor; %19'u hiç kullanılmadan rafa kalkıyor. En sık görülen tetikleyici: belirsiz kapsam ve eksik gereksinim toplama.

Bu oranlar yirmi yıldır neredeyse hiç kıpırdamadı. Araçlar gelişti, ekipler çevik yöntemlere geçti, bulut altyapısı ucuzladı — ama aynı hatalar tekrarlanıyor. Bu rehber, bir yazılım projesinin hangi noktalarda rayından çıktığını, hangi erken sinyalleri verdiğini ve yarıda kalmış bir projeyi nasıl kurtarabileceğinizi anlatıyor. Rakamları ajans bloglarından değil, birincil araştırmalardan aldık.

İçindekiler

• Rakamlarla Yazılım Projesi Başarısızlığı
• Neden 1: Kapsam Baştan Netleşmiyor
• Neden 2: Gereksinimler Sahadan Değil Masadan Toplanıyor
• Neden 3: Yanlış Firma ve Eksik Sözleşme
• Neden 4: Projenin Tamamı Tek Faza Sıkıştırılıyor
• Neden 5: Karar Verecek Kişi Belli Değil
• Neden 6: Test ve Kabul Kriteri Yok
• Neden 7: Veri Göçü Son Haftaya Bırakılıyor
• Neden 8: Yayın Günü Bitiş Sanılıyor
• Yarıda Kalan Projeyi Devralmak
• Projeyi Rayında Tutan 7 Kontrol Noktası
• Sıkça Sorulan Sorular

Rakamlarla Yazılım Projesi Başarısızlığı

Başarısızlık kelimesi tek bir şeyi anlatmıyor. Araştırmalar üç ayrı sonucu ayırıyor: hedefine ulaşan proje, geciken veya kapsamı budanan proje, bir de hiç teslim edilmeyen proje. Bu ayrımı bilmek işinize yarar, çünkü sizin projeniz muhtemelen ortadaki kategoriye düşecek. Ortadaki kategori de en az iptal kadar pahalıdır: para harcanır, zaman geçer, sonuçta elinizde beklediğinizin yarısı kalır.

KOBİ ölçeğinde "challenged" yani zorlanmış proje şöyle görünür: altı ay yerine on ayda teslim, planlanan 14 modülden 9'u, bütçenin üzerine bir ek sözleşme. Kimse buna başarısızlık demez, kimse de başarı diye kutlamaz. Oysa bu senaryonun maliyeti, iptal edilen bir projeye yakındır — çünkü ödediğiniz parayı da harcadığınız zamanı da geri alamazsınız.

PM World Journal'da Ocak 2026'da yayımlanan karşılaştırmalı çalışma, Standish Group'un CHAOS verilerini on yıllık perspektifte inceledi. Tablo şaşırtıcı derecede durağan (PM World Journal).

Ortalamalar aldatıcı. Oxford Üniversitesi'nden Bent Flyvbjerg ve Alexander Budzier 1.471 bilişim projesini inceledi ve ortalama bütçe aşımını %27 buldu. Ama dağılımın kuyruğu çok daha sert: her altı projeden biri ortalama %200 bütçe aşımı ve yaklaşık %70 takvim aşımı yaşıyor (Flyvbjerg ve Budzier, Harvard Business Review). Aynı ekibin daha geniş çalışması, bilişim projelerinin 10 projeden 8'inde ilk maliyet tahmininden %10'dan fazla saptığını gösteriyor.

Yani asıl risk "biraz sarkar" değil. Asıl risk, altı projeden birinin bütçeyi üçe katlamasıdır. Bu kuyruk, şirketleri de batırabiliyor: aynı araştırma Kmart'ın 1,4 milyar dolarlık modernizasyon hamlesini ve İngiltere'deki Auto Windscreens'in iflasını bu kategoride örnekliyor. Project Management Institute'un hesabına göre ise kötü proje performansı yüzünden harcanan her doların %9,9'u boşa gidiyor — her 1 milyar dolarlık yatırımda 99 milyon dolar (PMI Pulse of the Profession 2018).

PMI aynı araştırmada başarısız projelerin sorumlularına "birincil nedenler neydi?" sorusunu sordu. Katılımcılar en fazla üç madde seçti.

Listenin ilk sekiz maddesinin hiçbiri teknoloji seçimiyle ilgili değil. Hepsi kapsam, hedef, iletişim ve yönetim başlıklarına giriyor. Yazılım projesi başarısızlığı, büyük ölçüde yönetim disiplini sorunudur.

Türkiye tarafında resmi tablo da bu riskin neden büyüdüğünü açıklıyor. TÜİK'in 2025 Girişimlerde Bilişim Teknolojileri Kullanım Araştırması'na göre ERP kullanan girişimlerin oranı genelde %28,3; 10-49 çalışanlı şirketlerde ise yalnızca %23,6. CRM tarafında oranlar daha da düşük: genel %12, küçük ölçekte %9,9 (TÜİK verileri). Çoğu KOBİ, kurumsal yazılımla ilk kez tanışıyor. İlk yazılım projesi ise her zaman en kırılgan projedir, çünkü şirkette süreci yönetmiş kimse yoktur.

Bir not daha: başarısız projelerin raporlarında teknoloji seçimi sık sık suçlanır. "Yanlış framework seçtik", "o veritabanı bize uymadı" cümleleri rahatlatıcıdır, çünkü sorumluluğu araca yıkar. Oysa birincil araştırmaların hiçbirinde teknoloji ilk sıralarda görünmüyor. Aşağıdaki sekiz neden, bu araştırmalarda tekrar tekrar öne çıkan maddelerin pratik karşılığıdır — her birinin altında, sahada işe yarayan bir çözüm adımı var.

Neden 1: Kapsam Baştan Netleşmiyor

Kapsam genişlemesi (scope creep), projenin onay ve belge olmadan büyümesidir. PMI'ın 2018 araştırması, son 12 ayda tamamlanan projelerin %52'sinde kapsam genişlemesi tespit etti; beş yıl önceki oran %43'tü. Aynı araştırmada PMI'ın "şampiyon" diye sınıfladığı yüksek performanslı kurumlar %33'te kalırken, düşük performanslı kurumlar %69'a tırmanıyor.

Kapsam genişlemesi tek bir büyük kararla gelmez. "Şunu da ekleyelim, zaten yarım saatlik iş" cümlesiyle gelir. Her biri masum görünen on beş talep, üç ayda projeyi yeni bir projeye dönüştürür. Üstelik bu taleplerin hiçbiri takvime ve bütçeye yazılmaz. Proje bittiğinde kimse ilk planı hatırlamaz; herkes gecikmeyi geliştirme ekibine yazar.

Burada ikinci bir tuzak da var: geliştirme ekibinin kendi eklediği süslemeler. Kimsenin istemediği gelişmiş bir arayüz, kimsenin açmayacağı bir rapor ekranı — literatürde bunun adı "gold plating". Sonuç aynı: harcanan gün, teslim edilmeyen değer.

Kapsam genişlemesinin en pahalı biçimi "küçük" entegrasyon talepleridir. Muhasebe programına bağlanma, kargo firması API'si, e-fatura aktarımı — her biri tek satırlık bir cümleyle istenir, haftalarca sürer. Entegrasyonları ilk kapsam belgesine yazmayan projeler takvimi neredeyse her zaman aşar.

Çözüm: Projeye başlamadan önce iki liste yazın. Birincisi teslim edilecek işler, ikincisi bu fazda yapılmayacak işler. İkinci liste birincisinden daha değerlidir. Sonrasında her yeni talep için tek bir soruyu cevaplayın: bu talep hangi teslimatı erteliyor ve maliyeti ne? Kapsamı yazıya dökmek için web tasarım brief'i rehberimizdeki soru setini yazılım projesi brief'i olarak da kullanabilirsiniz.

Neden 2: Gereksinimler Sahadan Değil Masadan Toplanıyor

PMI'ın başarısız projelerle ilgili anketinde ilk üç tetikleyici şöyle sıralandı: kurumun önceliklerinin değişmesi %39, proje hedeflerinin değişmesi %37, hatalı gereksinim toplama %35. Teknoloji seçimi bu listede yok. Sorun, yazılımın yanlış kodlanması değil; yanlış şeyin kodlanması.

Akademik literatür de aynı yere bakıyor. Akademik Bilişim konferansında sunulan bir çalışma, başarısızlığın başlıca sebepleri arasında "kullanıcı gereksinimlerini tam olarak anlayamama" ve "proje kapsamının eksik ya da yanlış tanımlanması" maddelerini ilk iki sıraya koyuyor (Akademik Bilişim bildirisi). Aynı çalışma gerçekçi olmayan teslim tarihini ve projeye uygun yetkinlikte ekip kuramamayı da listeye ekliyor.

Pratikte şu oluyor: gereksinimleri genel müdür ve IT sorumlusu anlatıyor, yazılımı ise depo görevlisi ve saha ekibi kullanacak. Sistem teslim edildiğinde depo görevlisi eski Excel dosyasına geri dönüyor. Yazılım çalışıyor, kimse kullanmıyor. Yazılım projesi teknik olarak "başarılı", ticari olarak sıfır.

İkinci sık hata, müşterinin ne istediğini tam bilmediğini kabul etmemek. Çoğu şirket süreci yazılı tanımlamadan projeye girer. Analiz aşaması bu yüzden masraf değil, sigortadır.

Gereksinim toplamanın ölçülebilir çıktısı da olmalı. "Sipariş girişi kolaylaşacak" bir hedef değil, bir dilektir. "Bir siparişi girme süresi 4 dakikadan 1 dakikaya inecek" ise ölçülebilir hedeftir ve testini yazabilirsiniz.

Çözüm: Her modül için sahadaki gerçek kullanıcıyla en az bir saatlik görüşme yapın. Kullanıcının mevcut yöntemini izleyin, anlatmasını beklemeyin. Sonra her ekran için "bu ekranı kim, günde kaç kez, hangi cihazdan açacak?" sorusunu yazılı cevaplayın. Cevabı olmayan ekranı da listeden çıkarın.

Neden 3: Yanlış Firma ve Eksik Sözleşme

Teklif karşılaştırmasını yalnızca fiyat üzerinden yapan şirketler, farkı sonradan iki kez ödüyor. Düşük teklif genelde dar kapsamdan, deneyimsiz ekipten veya eksik test bütçesinden gelir. Sözleşmede kabul kriteri yoksa "bitti" tanımı tartışmaya açık kalır ve her teslim yeni bir pazarlık turuna dönüşür.

En pahalı eksiklik ise kaynak kod devri. Kod sizin adınıza bir depoda durmuyorsa, firmayla yolunuzu ayırdığınız gün yazılım projesini de kaybediyorsunuz. Yeni ekip sıfırdan başlamak zorunda kalır ve ödediğiniz bütçe tamamen silinir. Bu madde sözleşmede tek satırla çözülür; eksik olduğunda ise aylarla ödenir.

Üçüncü bir detay da ekip şeffaflığıdır. Teklifi veren kıdemli ekip ile kodu yazan ekip aynı olmayabilir. Sözleşmeye "projede çalışacak ekibin rolleri ve kıdemi" maddesini yazdıran şirketler bu sürprizi baştan kapatır.

Dördüncü bir risk de firmanın ölçeğiyle ilgili. Tek kişilik bir ekip hızlı ve ucuz görünür, ama o kişi hastalandığında proje durur. Birden fazla geliştiricinin koda hâkim olduğunu baştan sorun.

Çözüm: Sözleşmeye dört maddeyi yazdırın: teslimat listesi, kabul kriterleri, değişiklik talebi süreci ve kaynak kod sahipliğinin devri. Firma seçiminde hangi kriterleri ölçeceğinizi yazılım firması seçim rehberimizde madde madde bulabilirsiniz; kod devrinin hukuki tarafını ise kaynak kod teslimi yazımız ele alıyor.

Neden 4: Projenin Tamamı Tek Faza Sıkıştırılıyor

Büyük proje, büyük risktir. Flyvbjerg ve Budzier'in verisinde projelerin ortalama bütçesi 167 milyon dolar, en büyüğü 33 milyar dolar. Ölçek büyüdükçe kuyruk riski de büyüyor. Aynı mantık KOBİ ölçeğinde de çalışır: 18 aylık tek parça bir yazılım projesi, 3 aylık altı fazdan çok daha kırılgandır.

Tek fazlı yaklaşımın en can sıkıcı yanı geri bildirim gecikmesidir. Hatalı bir varsayımı 14. ayda öğrenirseniz, o varsayıma dayanan 14 aylık işi de yeniden yazarsınız. Üç ayda bir çalışan bir sürüm teslim ederseniz, aynı hatayı 3. ayda öğrenirsiniz ve sadece üç ayı riske atarsınız.

Uzun projelerde ikinci bir sorun daha birikiyor: teknoloji ve iş ihtiyacı proje süresince değişiyor. PMI'ın araştırmasında başarısızlık nedenlerinin başında "kurumun önceliklerinin değişmesi" çıkması tesadüf değil. 18 ayda şirketin gündemi de değişir.

Fazlı planın bir yan faydası da bütçe kontrolüdür. Her faz sonunda devam kararını yeniden verirsiniz. İlk faz beklentiyi karşılamazsa, 18 aylık bütçenin tamamını değil altıda birini riske atmış olursunuz.

Çözüm: İlk fazı, işin para kazandıran veya en çok zaman kaybettiren tek sürecine odaklayın. Gerisini sonraki fazlara bırakın. Bu yaklaşımın adımlarını MVP rehberimizde anlattık. Fazlı planın bütçeye nasıl yansıdığını görmek için web sitesi fiyat hesaplayıcıyı farklı kapsam senaryolarıyla deneyebilirsiniz.

Neden 5: Karar Verecek Kişi Belli Değil

PMI'ın listesinde yetersiz iletişim %29, yetersiz sponsor desteği %26 paya sahip. Bu iki madde aynı kökten geliyor: yazılım projesinin sahibi yok. Haftalık toplantıya her hafta başka bir yönetici katılır, önceki hafta verilen karar yeniden tartışılır, ekip aynı ekranı üçüncü kez tasarlar.

Karar sahipliği dağıldığında geliştirme ekibi bekler. Bekleyen ekip ya tahminle ilerler ya da başka projeye kayar. İkisi de projeye zarar verir. Dahası, kötü haber yukarı çıkmaz: sorunlar aylarca ekip içinde kalır.

Birleşik Krallık'ta Birmingham Belediyesi'nin Oracle projesi bunun kamuya açık örneği. Sorunlar belediyenin karar organlarına yaklaşık 13 ay boyunca taşınmadı. Başlangıç bütçesi 19 milyon sterlin olan proje için öngörülen toplam maliyet 216,5 milyon sterline çıktı ve 2023/24 için beklenen 69 milyon sterlinlik tasarruf tamamen silindi (The Register).

Karar sahibinin yanında bir de "süreç sahibi" gerekir: yazılımı günlük kullanacak ekibin içinden, soruları cevaplayacak kişi. Bu iki rolü aynı kişiye yüklemek çoğu KOBİ projesinde tıkanma yaratır.

Çözüm: Tek bir karar sahibi atayın ve yetkisini yazılı tanımlayın. Haftalık 30 dakikalık sabit bir toplantı kurun. Kararları toplantı sonunda maddeler hâlinde yazıp paylaşın; sözlü mutabakat üç hafta sonra buhar olur. Kötü haberi erken getiren ekibi de ödüllendirin, cezalandırmayın.

Neden 6: Test ve Kabul Kriteri Yok

Yazılım hatası ne kadar geç bulunursa o kadar pahalıya kapanır. NIST'in Research Triangle Institute ile hazırladığı çalışmaya göre hataların tespiti ve düzeltilmesi, geliştirme maliyetinin yaklaşık %80'ini oluşturuyor; hataların yarıdan fazlası ise süreçte geç aşamalarda ortaya çıkıyor (NIST raporu). Aynı çalışma yetersiz test altyapısının ABD ekonomisine yıllık maliyetini 59,5 milyar dolar olarak hesapladı.

Faturanın büyüklüğü başka bir ölçümde de karşımıza çıkıyor. CISQ'nun 2022 raporu, ABD'de düşük yazılım kalitesinin yıllık maliyetini 2,41 trilyon dolar, birikmiş teknik borcu ise yaklaşık 1,52 trilyon dolar olarak hesapladı (CISQ). Teknik borç, bugün hızlı gitmek için aldığınız kısayolun yarın faiziyle geri dönmesidir.

Kabul kriteri olmayan projede test de yapılamaz. "Sipariş ekranı çalışıyor mu?" sorusunun ölçülebilir karşılığı yoksa, teslim tartışmaya dönüşür. Üstelik testi yalnızca geliştiriciye bırakan şirketler kendi iş kurallarını hiç doğrulamamış olur.

Testin bir de regresyon tarafı var. Yeni özellik eklendikçe eski ekranlar sessizce bozulur. Her faz sonunda temel iş akışlarını baştan sona tekrar denemek, bu sessiz bozulmaları yakalamanın en ucuz yoludur.

Çözüm: Her özellik için tek cümlelik kabul kriteri yazın: "Depo görevlisi barkodu okuttuğunda stok 2 saniye içinde düşer." Kullanıcı kabul testini gerçek veriyle, gerçek kullanıcıyla ve yayından en az iki hafta önce yapın. Hata listesini de önem sırasına göre ikiye ayırın: yayını engelleyenler ve engellemeyenler.

Neden 7: Veri Göçü Son Haftaya Bırakılıyor

Yazılım projelerinin sessiz katili veri göçüdür. Eski sistemin tolere ettiği eksik kayıtları yeni sistem reddeder. Mükerrer müşteri kartları, boş vergi numaraları, farklı birimlerle girilmiş stok miktarları — hepsi göç gününde yüzeye çıkar. Ekip o gün yazılım geliştirmeyi bırakıp veri temizliğine başlar ve takvim bir ay kayar.

Birmingham örneğinde ilk kurulumdaki özelleştirmeler banka mutabakat sürecini bozdu. Belediye 18 ay boyunca denetlenebilir hesap üretemedi; sonunda sistemi "kutudan çıktığı gibi" yeniden kurdular. Aşırı özelleştirme, göç riskini her zaman büyütür. Hazır bir ürünü aşırı özelleştirmek yerine özel yazılım yazmak çoğu durumda daha öngörülebilir bir yoldur.

Veri göçünde ikinci risk, "hangi veri taşınacak?" sorusunun cevapsız kalmasıdır. On yıllık tüm geçmişi taşımak hem maliyetli hem risklidir. Çoğu şirket için son iki yılın hareket verisi ve tüm cari kartlar yeterli olur; gerisi arşiv olarak eski sistemde kalabilir.

Çözüm: Veri temizliğini projenin ilk ayında başlatın ve eski sistem üzerinde yürütün. En az iki prova göçü planlayın: biri geliştirme ortamına, biri canlıya geçişten bir hafta önce. Göç sonrası ilk hafta için eski sisteme dönüş planınızı da yazılı tutun. Mevcut sistemden geçiş yapıyorsanız eski yazılım yenileme yazımızdaki kademeli geçiş yöntemleri işinizi kolaylaştırır.

Neden 8: Yayın Günü Bitiş Sanılıyor

Yayın, yazılım projesinin sonu değil ortasıdır. Eğitim vermezseniz kullanıcı eski alışkanlığına döner. Sahiplenilmeyen yazılım, hiç yazılmamış yazılımla aynı sonucu verir: süreç yine Excel'de yürür. Üç ay sonra yönetim "yazılım tutmadı" der, oysa yazılım hiç denenmemiştir.

Yapay zekâ projelerinde tablo daha da sert. RAND'ın 2024 raporu, bazı tahminlere göre AI projelerinin %80'inden fazlasının başarısız olduğunu ve bunun AI içermeyen bilişim projelerinin iki katı olduğunu aktarıyor. Rapor 65 veri bilimci ve mühendisle görüşme yaptı; en sık kök neden, çözülecek problemin yanlış anlaşılması çıktı (RAND). Üretken yapay zekâ pilotlarının %70-85'i ise kavram kanıtı aşamasını geçemiyor.

Benimsenmeyi hızlandıran en basit araç, şirket içinden bir "süper kullanıcı" yetiştirmektir. Ekip, yazılım firmasına sormaktan çekindiği soruyu yanındaki meslektaşına sorar. Bu rolü yayından önce belirleyin.

Çözüm: Yayın planına üç kalemi ekleyin: rol bazlı eğitim, ilk 30 günlük destek penceresi ve benimsenme ölçümü. Haftalık aktif kullanıcı sayısını ve hedef sürecin ne kadarının sistemde yürüdüğünü takip edin. İkinci ay hâlâ %50'nin altındaysa sorun yazılımda değil, iş akışındadır. Bakım ve destek kapsamının sözleşmede nasıl tanımlandığını yazılım bakım sözleşmesi yazımız açıklıyor.

Sekiz nedenin ortak özelliği şudur: hepsi proje başlamadan ya da ilk aylarda görülebilir. Hiçbiri son haftada ortaya çıkan bir teknik sürpriz değil. Erken fark eden şirket düzeltir, geç fark eden şirket öder. Aşağıdaki iki bölüm, zaten rayından çıkmış bir proje için ne yapabileceğinizi ve bir sonraki projede aynı yere düşmemek için neyi takip etmeniz gerektiğini anlatıyor.

Yarıda Kalan Projeyi Devralmak

Yarıda kalmış bir yazılım projesi her zaman çöp değildir. Devralma kararını üç soru belirler: kaynak kod elinizde mi, veri modeli sağlam mı, kalan iş yeniden yazımdan ucuz mu? Üçüne de "evet" diyebiliyorsanız devam etmek genelde daha hızlı ve daha ucuzdur.

Devralma sürecini şu sırayla yürütüyoruz:

1. Kod ve altyapı envanteri. Depo erişimi, kullanılan kütüphaneler, sunucu yapılandırması ve dış servis anahtarları tek listede toplanır.
2. Teknik değerlendirme raporu. Mimari, veri modeli, test kapsamı ve güvenlik açıkları ayrı ayrı puanlanır. Bu rapor 5-10 iş günü sürer.
3. Karar tablosu. Üç seçenek fiyat ve süre ile yan yana durur: devam etmek, kısmen yeniden yazmak, baştan kurmak.
4. Veri kurtarma planı. Mevcut veritabanı yeni yapıya taşınabiliyorsa, önceki aylarda girilen veri kaybolmaz.
5. Kısa ilk faz. Devralma sonrası ilk teslim 4-6 haftayı aşmamalı. Güven, çalışan bir sürümle geri gelir.

Teknik değerlendirme raporu, devam kararı vermeseniz bile elinizde kalır. Yeni firma ile görüşürken en güçlü kozunuz bu rapordur, çünkü artık neyi satın aldığınızı biliyorsunuz. Web yazılım hizmetlerimiz kapsamında devraldığımız projelerde ilk adım her zaman bu rapordur; hesaplanmamış riskle kod yazmaya başlamıyoruz.

Devralma sırasında dokümantasyon eksikliği en büyük yavaşlatıcıdır. Çoğu yarıda kalmış projede yazılı mimari belgesi yoktur; bilgi eski geliştiricinin kafasındadır. Bu yüzden devralma sözleşmesine kısa bir "bilgi aktarım görüşmesi" maddesi koymaya çalışın. İki saatlik bir görüşme, haftalarca kod okumaktan daha çok kazandırır.

Devralma teklifini alırken de dikkatli olun. "Baştan yazalım" cevabı bazen doğrudur, ama her zaman en kârlı cevaptır. Bu yüzden teknik değerlendirme raporunu, işi yapacak firmadan bağımsız bir gözle okumak önemlidir.

Devralmada en sık yapılan hata, eski ekibi suçlayıp her şeyi silmektir. Çalışan modülleri korumak, projenin moralini ve bütçesini birlikte kurtarır.

Projeyi Rayında Tutan 7 Kontrol Noktası

Aşağıdaki yedi maddeyi her ayın başında gözden geçirin. Hepsine "evet" diyemiyorsanız, yazılım projeniz sinyal veriyor.

1. Kapsam yazılı mı? Teslimat listesi ve kapsam dışı listesi aynı belgede duruyor mu?
2. Son 30 günde çalışan bir sürüm gördünüz mü? Ekran görüntüsü değil, tıklanabilir sürüm.
3. Değişiklik talepleri fiyat ve süre ile kayda geçiyor mu?
4. Karar sahibi tek kişi mi ve toplantılara katılıyor mu?
5. Kabul kriterleri her özellik için yazılı mı?
6. Veri göçü provası yapıldı mı?
7. Kaynak koda bugün erişebiliyor musunuz?

Bu listeyi yazılım firmanıza da gönderin. İyi bir ekip, maddelerin çoğunu zaten takip ettiğini gösterir ve eksikleri kendisi işaretler. Savunmaya geçen, "bizde böyle yapılmaz" diyen bir ekip ise ilk uyarı sinyalinizdir.

Yedinci madde en kritiğidir. Diğer altısı bozulsa bile kod elinizdeyse projeyi kurtarırsınız. Kod elinizde değilse, kalan altı madde mükemmel olsa da pazarlık gücünüz sıfırdır.

Temsili bir örnek: Bursa'da 40 çalışanlı bir üretim firması, sipariş ve sevkiyat takibi için 9 aylık bir yazılım projesi başlatıyor. Gereksinimleri yalnızca yönetim toplantılarında konuştukları için sahadaki vardiya şefinin kullandığı etiket düzenini kimse sormuyor. Yayından sonra şefler etiketleri elle yazmaya devam ediyor, sistem yarım veriyle doluyor. Çözüm teknik değil: iki haftalık saha gözlemi, etiket ekranının yeniden tasarımı ve vardiya başına 45 dakikalık eğitim. Üç hafta sonra veri bütünlüğü yerine oturuyor.

Sıkça Sorulan Sorular

Yazılım projelerinin yüzde kaçı başarısız olur?

Standish Group'un CHAOS verilerine göre bilişim projelerinin yaklaşık %19'u tamamen iptal ediliyor veya hiç kullanılmıyor. Projelerin %50'si gecikme, bütçe aşımı ya da kapsam budaması yaşıyor. Hedeflenen süre, bütçe ve kapsamla tamamlanan proje oranı ise %31 seviyesinde kalıyor.

Yazılım projesi başarısızlığının en sık nedeni nedir?

PMI'ın araştırmasında başarısız projelerin %39'unda kurumun öncelikleri değişmiş, %37'sinde proje hedefleri kaymış, %35'inde gereksinimler hatalı toplanmıştı. Üç maddenin ortak kökü aynı: proje başlarken "ne" ve "neden" sorularının yazılı cevabı yok. Teknoloji seçimi bu listede ilk sıralarda bile değil.

Kapsam genişlemesini nasıl engelleyebilirim?

Kapsam dışı işleri yazılı listeleyin ve her yeni talebi fiyat-süre etkisiyle birlikte kayda geçirin. PMI verisinde yüksek performanslı kurumlarda genişleme oranı %33, düşük performanslılarda %69. Fark, araçtan değil yazılı değişiklik sürecinden geliyor.

Yarıda kalan yazılım projesi kurtarılabilir mi?

Kaynak kod ve veritabanı elinizdeyse çoğu proje kurtulur. Karar için 5-10 iş günlük teknik değerlendirme raporu yeterlidir; rapor devam, kısmi yeniden yazım ve sıfırdan kurulum seçeneklerini fiyatla karşılaştırır. Kod erişiminiz yoksa genellikle yeniden yazım daha ekonomiktir.

Bütçeyi aşmamak için ne yapmalıyım?

Projeyi 3 aylık fazlara bölün ve her fazı çalışan bir sürümle kapatın. Oxford araştırmasında ortalama bütçe aşımı %27 olsa da altı projeden biri %200 aşıyor; bu kuyruk riski uzun ve tek fazlı projelerde yoğunlaşıyor. Fazlı planda hatayı erken bulur, erken düzeltirsiniz.

Sözleşmede hangi maddeler mutlaka olmalı?

Dört madde zorunludur: teslimat listesi, özellik başına kabul kriterleri, değişiklik talebi süreci ve kaynak kod sahipliğinin devri. Bakım kapsamı, yanıt süreleri, projede çalışacak ekibin kıdemi ve proje sonrası destek koşulları da ayrı başlık olarak yer almalıdır.

Yapay zekâ projeleri daha mı çok başarısız oluyor?

Evet. RAND'ın 2024 raporu, bazı tahminlere göre AI projelerinin %80'inden fazlasının başarısız olduğunu ve bu oranın AI içermeyen bilişim projelerinin iki katı olduğunu aktarıyor. En sık kök neden teknoloji değil, çözülecek problemin yanlış tanımlanması. Üretken yapay zekâ pilotlarının %70-85'i de kavram kanıtı aşamasını geçemiyor.

Analiz aşamasına bütçe ayırmak şart mı?

Şart. Analiz, projenin en ucuz sigortasıdır: yanlış varsayımı belgede düzeltmek bir gün, kodda düzeltmek bir ay sürer. Toplam bütçenin %10-15'ini analiz ve kapsam çalışmasına ayıran yazılım projeleri, takvim tahminlerini belirgin biçimde daha iyi tutuyor.

Yazılım projelerinde başarısızlığın büyük kısmı kod yazılmadan önce belirlenir. Kapsamı yazıya dökmek, gerçek kullanıcıyla konuşmak, kabul kriteri tanımlamak ve kod sahipliğini sözleşmeye geçirmek — bu dördü projenizi istatistiklerin iyi tarafına taşır. Hiçbiri teknik beceri değil, disiplin işidir.

Son bir hatırlatma: istatistikler kaderinizi belirlemiyor. PMI'ın aynı araştırmasında değer teslim yetkinliği olgun kurumların projelerinin %64'ü zamanında, %67'si bütçesinde tamamlanıyor; olgunluğu düşük kurumlarda bu oranlar %36 ve %43'e iniyor. Fark, bütçeden ya da teknolojiden değil, süreç disiplininden geliyor.

Elinizde yarıda kalmış bir yazılım projesi varsa ya da yeni bir projeye başlamadan önce kapsamı doğru kurmak istiyorsanız, mevcut durumu birlikte değerlendirelim. Bize ulaşın ve projenizin teknik değerlendirme raporunu çıkaralım.