Yazılım projelerinin başarısızlık oranı, sektörde arka plan gürültüsü haline gelecek kadar uzun süredir bilinen bir problem. Yüzde 60 ile 80 arasında başarısızlık oranı belirten araştırmalar konferanslarda alıntılanıyor, yönetim kitaplarında referans gösteriliyor ve sonra aynı hataları tekrarlamak üzere olan bir sonraki ekip tarafından derhal göz ardı ediliyor. Çarpıcı olan başarısızlık oranının yüksek olması değil. Araçlarda, metodolojilerde ve mevcut yetenekte devasa değişimlere rağmen bunun arkasındaki nedenlerin on yıllardır şaşırtıcı biçimde tutarlı kalması.

Çoğu yazılım projesi kötü kod yüzünden başarısız olmuyor. Tek bir satır kod yazılmadan önce başarısız oluyorlar, projenin en erken, en az teknik aşamasında alınan kararlarda. Bir şeyin yanlış olduğunu birinin fark ettiği zamana gelindiğinde, hasar aylar önce zaten oluşmuştur.

Problem Başından İtibaren Yanlış Tanımlanıyor

En yaygın temel neden, açık bir farkla, en başta düzgün biçimde anlaşılmamış bir probleme çözüm inşa etmek. Bu, gerçek açıklama olamayacak kadar basit gibi görünüyor, ama vaka vaka incelendiğinde geçerliliğini koruyor. Bir ekip, çoğunlukla şeyi inşa eden insanlara ulaşmadan önce birkaç paydaş katmanından süzülmüş bir istek alır ve neye ihtiyaç duyulduğunun doğrulanmış bir anlayışından çok bir yorumuna dayanarak inşa etmeye başlar.

Bir paydaşın ihtiyacı olduğunu söylediği şey ile gerçekten ihtiyacı olan şey arasındaki boşluk genellikle önemlidir ve nadiren erken yakalanır, çünkü yeterince açıklayıcı soru sormak, herkesin hızlı hareket etmek istediği bir süreci yavaşlatıyormuş gibi hissettirir. Bir satış ekibi “daha iyi bir raporlama panosu” ister. Altı ay sonra mühendislik daha fazla grafik ve filtre içeren bir pano gönderir ve satış ekibi daha mutlu olmaz, çünkü gerçekte ihtiyaç duydukları şey müşteri görüşmeleri sırasında belirli üç sayıya daha hızlı erişimdi, daha kapsamlı bir analitik aracı değil. Kimse yalan söylemedi. Kimse yetersiz değildi. Problem tanımı basitçe yanlıştı ve üzerine inşa edilen her şey bu kusuru miras aldı.

Bu tür bir başarısızlık gerçekleşirken neredeyse görünmezdir. Ekip sıkı çalışıyordur, kod derleniyordur, demolar makul görünüyordur. Başarısızlık ancak lansmanda, gerçek kullanım inşa edilen şeyin kimsenin gerçekte sormadığı bir soruyu yanıtladığını ortaya çıkardığında görünür hale gelir.

Kapsam Sessizce Büyür, Ta Ki Yönetilemez Hale Gelene Kadar

Kapsam genişlemesinin (scope creep) açık, kolayca kaçınılabilir bir problem olduğuna dair bir ünü var ve tam da bu yüzden hep gerçekleşiyor. Kimse oturup tek bir bilinçli anda bir projenin kapsamını dramatik biçimde genişletmeye karar vermiyor. Her biri tek başına makul olan bir istek dizisi yoluyla gerçekleşiyor, her biri evet demenin geri itmekten daha kolay hissettirecek kadar küçük.

“Bu küçük özelliği de ekleyebilir miyiz.” “Oradayken bu ilgili şeyi de düzeltebilir miyiz.” “Hukuktan az önce bu yeni gereksinim geldi, sıkıştırabilir miyiz.” Her ekleme tek başına makul. Bu küçük eklemelerden onlarcası boyunca birikimli etki, kimsenin bunun gerçekleşmesi gerektiğine açıkça karar vermeden orijinal zaman çizelgesi ve bütçesinin çok ötesine büyümüş bir proje oluyor. Kapsam genişlemesi doğrudan ele alınacak kadar belirgin hale geldiğinde, proje çoğu zaman bir yön düzeltmesinin yaşayabilir hissettirmesi için çok gerideymiştir, böylece ekipler uyumsuzlukla dürüstçe yüzleşmek yerine gerçekçi olmayan bir planla ilerlemeye devam ederler.

Daha derin mesele, gereksinimlerin değişmesi değil, gereksinimler her zaman değişir, çoğu ekibin yeni bir isteğin kabul edilmeden önce zaman ve karmaşıklık açısından maliyetine değip değmeyeceğini değerlendirecek gerçek bir mekanizmaya sahip olmaması. Bu değerlendirme olmadan varsayılan olarak evet demek, makul bireysel kararların makul olmayan toplu bir sonuca nasıl eklendiğinin yolu.

Teknik Borç Geleceğin Problemi Olarak Ele Alınıyor

Her mühendislik ekibi teknik borç kavramını soyut olarak anlıyor. Çok daha az ekip bu anlayışa gerçekten önemli olduğu zamanda, yani erken, borç birikmeden önce göre hareket ediyor. Son tarih baskısı altında, açıkça daha sonra yeniden ele alınması gerekecek bir kısayol alma cazibesi güçlü ve gerekçe, lansmandan sonra düzeltiriz, o anda mantıklı geliyor.

Problem şu ki “lansmandan sonra” nadiren temizlik için müsait sakin bir dönem olarak gelir. Acil hata düzeltmeleri, erken kullanıcılardan gelen anında özellik istekleri ve momentumu sürdürme baskısının olduğu bir dönem olarak gelir. Orijinal son tarih baskısı altında alınan kısayollar yeniden ele alınmaz. Üzerlerine inşa edilir ve bir sonraki kısayollar kümesi ilk kümenin üzerine katmanlanır ve bir yıl içinde kod tabanı, herhangi bir anlamlı değişikliği orantısız biçimde maliyetli ve riskli hale getirecek kadar yapısal taviz biriktirmiş olur.

Bu birikme etkisi, teknik borcun diğer proje riski türlerinden gerçekten farklı olmasının nedeni. Tanıtıldığı alanla sınırlı kalmıyor. Bir modüldeki bir kısayol, bitişik bir modüldeki bir sonraki kişinin işini zorlaştırır, bu da onların kendi kısayolunu almasını daha olası kılar ve kalıp, bakımı çok uzun süre erteleyen bir binada yapısal ihmalin yayıldığı gibi bir kod tabanı boyunca yayılır.

İletişim Organizasyonel Mesafe Boyunca Çöker

Başarısız projelerde tutarlı biçimde ortaya çıkan bir kalıp, iş problemini anlayan insanlar ile kodu yazan insanlar arasındaki iletişim mesafesi, bu mesafe organizasyonel olsun, coğrafi olsun ya da basitçe iki grup arasında çok fazla yönetim katmanı meselesi olsun. Bilgi her aktarımla bozulur. Nüanslı bir iş gereksinimi bir bilet haline basitleştirilir, bilet gereksinimi başlatan kişiyle hiç doğrudan konuşmamış bir mühendis tarafından yorumlanır ve o zincirin bir yerinde gerçek niyet kaybolur.

Bu, ürün yöneticilerinin, tasarımcıların ve mühendislerin aralarında formel aktarım süreçleriyle ayrı departmanlar olarak çalıştığı daha büyük organizasyonlarda özellikle görünür. Her aktarım bir bilgi kaybı fırsatıdır ve bir gereksinim onu gerçekten uygulayan kişiye ulaştığında, çoğu zaman orijinal olarak neye ihtiyaç duyulduğuyla yalnızca kısmi bir benzerlik taşır. Proje, herhangi biri bireysel işini kötü yaptığı için başarısız olmaz. O işleri birbirine bağlayan sistem her adımda sinyali bozduğu için başarısız olur.

Daha küçük, daha sıkı entegre ekipler bu başarısızlık modelinden kaçınma eğilimindedir, insanlar daha zeki olduğu için değil, iletişim mesafesi daha kısa ve yanlış yorumlama şansları daha az olduğu için.

Kimse İşlerin Yolunda Gitmediğini Söyleyen Kişi Olmak İstemiyor

Belki de proje başarısızlığının en insani nedeni, ve süreç değişiklikleriyle tek başına ele alınması en zor olanı, zorlanan bir projenin içindeki insanların bunu açıkça ve erken söylemekteki isteksizliği. Batık maliyet düşüncesi güçlü. Aylarca yatırım yaptıktan sonra, bir yaklaşımın işe yaramadığını kabul etmek, önceki ayların boşa gittiğini kabul etmek gibi hissettiriyor ve bu, özellikle orijinal planı ve bütçeyi onaylamış liderliğe söylenmesi rahatsız edici bir şey.

Böylece projeler, dürüst bir değerlendirmenin yönde önemli bir değişiklik gerektireceği noktanın ötesine topallayarak ilerler. İnsanlar zaman çizelgelerini ayarlamaya devam eder, sessizce bir sonraki sprintin her şeyin yerine oturacağı sprint olmasını umar. Uyarı işaretleri yapısal problemler olarak değil geçici aksilikler olarak yeniden çerçevelenir. Sorunlar inkar edilemez hale geldiğinde, çoğunlukla lansmandan tam önce ya da tam sonra, yön değiştirmenin maliyeti o kadar büyümüştür ki seçenekler kusurlu bir şeyi göndermek ya da bir yılın kaynağını tüketmiş bir şeyi iptal etmek arasına sıkışır.

Bunu iyi yöneten organizasyonlar, kaygıları erken dile getirmek için süreçlerine açık bir izin inşa etme eğilimindedir, bir seferlik bir retrospektif ritüel olarak değil sürekli, düşük riskli bir alışkanlık olarak. Birinin “bence bu yaklaşım işe yaramıyor” diyebildiği ekipler, ikinci ayda, bu yaklaşımı önerenlere bir saldırı olarak ele alınmadan, problemleri hâlâ ucuza düzeltilebilirken yakalar.

Başarıyı Gerçekte Ne Öngörüyor

Başarılı olan projelere bakıldığında, birkaç kalıp güvenilir biçimde ortaya çıkıyor ve bunların hiçbiri egzotik değil. Başarılı olan ekipler, kod yazmadan önce gerçek problemi anladıklarını doğrulamaya gerçek zaman yatırma eğilimindedir, çoğunlukla süzülmüş gereksinim belgeleri yoluyla değil inşa edilen şeyi kullanacak insanlarla doğrudan konuşma yoluyla. Daha küçük inşa eder ve daha erken gönderirler, kapsamlı bir versiyona aylar yatırmadan önce sınırlı bir versiyon üzerinde gerçek geri bildirim alırlar. Teknik borcu süresiz biçimde ertelenecek bir şey olarak değil aktif biçimde yönetilecek bir şey olarak ele alırlar, onu sessizce birikmesine izin vermek yerine bilinçli biçimde öderler. Ve bir problem fark eden birinin onu kaçınılmaz hale gelmeden önce söyleyebilecek hissedeceği kadar psikolojik güvenlik yaratırlar.

Bunların hiçbiri teknik çözüm değil. Organizasyonel ve kültürel çözümler ve tam da bu yüzden daha iyi araçlar ve framework’ler son birkaç on yılda başarısızlık oranını çok fazla hareket ettirmedi. Araçlar dramatik biçimde gelişti. Projelerin başarısız olmasına neden olan insani ve organizasyonel kalıplar neredeyse o kadar değişmedi, çünkü gerçekte teknolojiyle ilgili değiller.

Projelerimi ve çalışmalarımı incelemek isterseniz: https://hub.barisgunduz.com/