Yazılım projesi neden gecikir? Sekiz sebep ve her birinin önlemi

Yazılım projeleri çoğu zaman kod yazılırken değil, kararlar arasında gecikir: belirsiz kapsam, haftalarca bekleyen geri bildirim, takvimi sizin elinizde olmayan entegrasyonlar, taşınırken temizlenmesi gereken veri, ilk sürüm çıkmadan eklenen yeni istekler, unutulan yönetim ve rapor ekranları, sona bırakılan testler ve tek bir geliştiriciye bağımlılık. Bu sekiz sebebin hepsinin önceden alınabilecek bir önlemi var. Aşağıda her birini, erken işaretini ve önlemini anlatıyoruz.

Gecikme kod yazarken değil, kararlar arasında birikir

Bir proje geciktiğinde ilk akla gelen şey, geliştiricilerin yavaş çalıştığıdır. Gerçekte gecikmenin büyük kısmı, kimsenin klavyeye dokunmadığı anlarda birikir: bir sorunun cevabını beklerken, bir test ortamının açılmasını beklerken, bir toplantının ertelenmesini beklerken. Bu bekleme süreleri tek tek küçük görünür ama üst üste eklendiğinde haftalara dönüşür.

Bu yüzden gecikmeyi önlemek, büyük ölçüde iki tarafın da bekleme süresini kısaltmak demektir. Aşağıdaki sebeplerin yarısından fazlası, yazılımı yaptıran şirketin tarafında çözülebilecek türdendir. Bu bir suçlama değil; tersine, kontrolün önemli bir kısmının sizde olduğu anlamına gelir.

Tedarikçi tarafında da bir sorumluluk var: süreyi uzatabilecek riskleri baştan, yazılı olarak söylemek. İyi bir teklif yalnızca bir bitiş tarihi vermez; o tarihi neyin kaydırabileceğini de üç beş madde halinde sayar. “Kargo firmasının test ortamı onayı”, “eski verinin temizliği”, “onay akışının kurallarının netleşmesi” gibi. Bu liste, gecikme yaşandığında kimin neyi beklediğini tartışmak yerine, en baştan hangi riskin kimin elinde olduğunu konuşmayı sağlar. Teklifinizde böyle bir liste yoksa, isteyin. Projenin ortasında ortaya çıkan her risk, baştan konuşulmuş olandan daha pahalıdır; hem süre hem de iki taraf arasındaki güven açısından.

Kapsam ve kararlar

1. Belirsiz kapsam

“Sipariş takibi yapılacak” bir kapsam değil, bir başlıktır. Kabul kriterleri yazılmadan başlayan bir projede her ekran bir tartışmaya dönüşür, çünkü “bitti” kelimesinin herkes için anlamı farklıdır.

Önlem: İşe başlamadan önce kapsamı, kimin hangi adımı yapıp hangi sonucu göreceğini anlatan kabul kriterleriyle yazın. Açıkça kapsam dışı bırakılanları da listeleyin. Bu adım kısa bir keşif çalışması gerektirir ama projenin geri kalanında kaybedilecek zamanı ortadan kaldırır.

2. Yavaş kararlar

Prototip gönderilir, geri bildirim iki hafta sonra gelir. Bir alanın zorunlu olup olmadığı sorulur, cevap üç departmanın onayını bekler. Gecikmeleri en çok uzatan şey, deneyimimize göre, tam olarak budur.

Önlem: Sizin tarafınızda kararı verebilecek tek bir kişi belirleyin ve bu kişinin haftada belli bir zamanı projeye ayırmasını sağlayın. Açık kararları bir listede tutun; her birinin bir sahibi ve bir tarihi olsun.

3. Değişiklik talepleri

İlk sürüm çıkmadan yeni istekler eklemek, projeyi en sessiz biçimde uzatan alışkanlıktır. Her istek tek başına küçüktür; toplamı ise ilk sürümü haftalarca öteler.

Önlem: Yeni istekleri reddetmeyin, ama bir “sonraki faz” listesine yazın. İlk sürüme girmesi gerçekten şartsa, sürenin ve fiyatın ne kadar etkileneceğini işe başlamadan önce yazılı olarak öğrenin ve buna göre karar verin. Bunun ne kadar etkili olduğunu görmek için MVP nedir yazısında anlattığımız dilimleme mantığına bakabilirsiniz.

Dış bağımlılıklar

4. Entegrasyonlar

Banka, kargo, ödeme sağlayıcısı, e-fatura entegratörü ya da muhasebe programı. Her entegrasyon, size hiçbir şey borçlu olmayan bir şirketin takvimine bağlıdır. Test ortamı gecikebilir, dokümantasyon eksik olabilir, onay süreci haftalar alabilir.

Önlem: Entegrasyonları kapsamın en başında listeleyin ve her biri için test ortamı başvurusunu ilk hafta yapın. Mümkünse entegrasyonu ilk sürümün kritik yolundan çıkarın: önce dışa aktarma ya da elle aktarımla çalışan bir akış, entegrasyon hazır olduğunda otomatik bağlantı.

5. Veri kalitesi

Yıllar içinde elle düzeltilmiş Excel dosyaları, aynı müşterinin farklı yazımları, eksik kodlar. Veri göçü genelde projenin sonuna bırakılır ve orada sürpriz çıkarır.

Önlem: Verinin gerçek halini, temizlenmiş şablonunu değil, ilk görüşmeye getirin. Deneme aktarımını projenin ortasında yapın, sonunda değil. Temizliğin kimin işi olduğunu baştan yazın.

Unutulan ve sona bırakılan işler

6. Yönetim paneli ve raporlar

Kullanıcı ekranları üzerinde haftalarca çalışılır; ama kullanıcı tanımlamak, yetki değiştirmek, bir kaydı düzeltmek ya da ay sonu raporunu almak için gereken ekranlar kimsenin aklına gelmez. Bunlar sonda fark edildiğinde, ilk sürüm “neredeyse hazır” halde haftalarca bekler.

Önlem: Kapsamı yazarken yalnızca işi yapan kullanıcıyı değil, sistemi yöneten kişiyi ve rakamlara bakan yöneticiyi de düşünün. Hangi raporlara her hafta gerçekten bakıldığını yazın; geri kalanını dışa aktarmaya bırakın.

7. Sona bırakılan test

Bütün özellikler bittikten sonra test etmeye başlamak, bütün hataların aynı anda ortaya çıkması demektir. Hataların bir kısmı küçük, bir kısmı ise temel bir yanlış anlaşılmanın işaretidir ve o noktada düzeltmek pahalıdır.

Önlem: Haftalık ya da iki haftalık aralıklarla çalışan bir sürüm isteyin ve sizin tarafınızda o sürümü gerçek bir işle deneyecek bir kullanıcı belirleyin. Haftada bir saat yeterlidir. Erken bulunan hata ucuzdur.

Tek geliştiriciye bağımlılık

Projeyi tek bir kişinin bildiği, kodun onun bilgisayarında durduğu, dokümanın onun kafasında olduğu bir düzen, o kişi hastalandığında, izne çıktığında ya da ayrıldığında projeyi durdurur. Bu durum küçük ekiplerde ve serbest çalışanlarla yürütülen işlerde çok yaygındır ve genelde ancak bir şey ters gittiğinde fark edilir.

Önlem: Kodun ilk günden sizin hesabınızdaki bir depoda tutulmasını, kurulum ve işletim dokümanının proje boyunca güncellenmesini ve en azından kritik kısımların ikinci bir kişi tarafından gözden geçirilmesini isteyin. Bu konuların sözleşmede nasıl yazılacağını yazılım sözleşmesi ve kaynak kod sahipliği yazısında ele aldık. Depo ve hesaplar sizdeyse, en kötü durumda bile başka bir ekip işi devralabilir.

Teklif aşamasında şu soruyu sormak da faydalı: projede çalışan kişi iki hafta ulaşılamaz olursa ne olur? Cevap “olmaz” ya da “başka biri bakar” gibi belirsiz bir cümleyse, o başka birinin kim olduğunu, projeyi ne kadar bildiğini ve koda erişimi olup olmadığını sorun. Net bir cevap, riskin gerçekten düşünüldüğünü gösterir.

Gecikmeyi erken fark etmenin işaretleri

Gecikmeler nadiren bir gecede ortaya çıkar; genelde haftalar öncesinden işaret verir. Aşağıdaki tablo, her sebebin erken işaretini ve ilk yapılacak şeyi özetliyor:

Bir işaret daha var: durum raporlarının somut teslimler yerine yüzdelerle konuşması. “Yüzde seksen tamamlandı” cümlesi, kalan yüzde yirminin ne kadar süreceği hakkında hiçbir şey söylemez. Çalışan ve tıklanabilen bir sürüm, herhangi bir yüzdeden daha güvenilir bir ilerleme ölçüsüdür.

Kesin bir tarihiniz varsa

Bazı projelerin gerçekten kaçırılamayacak bir tarihi vardır: bir sezon başlangıcı, bir denetim, biten bir sözleşme, açılacak bir şube. Bu durumda tarihi ilk görüşmede, nedeniyle birlikte söyleyin. Bir tarihe yetişmenin en güvenilir yolu genelde daha fazla kişi eklemek ya da daha uzun çalışmak değil, kapsamı kesmektir: o tarihte mutlaka olması gereken üç dört işi belirleyip gerisini sonraki faza bırakmak. Tedarikçiniz tarihin gerçekçi olmadığını düşünüyorsa bunu baştan söylemesi, projenin ortasında “biraz kaydı” demesinden çok daha değerlidir.

Nereden başlamalı?

Yeni bir projeye başlıyorsanız, yukarıdaki tabloyu bir kontrol listesi olarak kullanın ve her satır için “bizde bu nasıl işleyecek?” sorusunu baştan cevaplayın. Süren bir projede gecikme yaşıyorsanız, önce açık kararları listeleyin ve kapsamı yeniden kesin; çoğu zaman bu iki adım, eklenecek her geliştiriciden daha fazla zaman kazandırır. Süreyi kısaltan ve uzatan etkenlerin daha ayrıntılı bir listesini yazılım yaptırma rehberimizde bulabilirsiniz.

Özel iş yazılımı projelerimizi bu riskleri baştan yazıya dökerek ve her hafta çalışan bir sürüm göstererek yürütüyoruz. Planladığınız ya da takılmış bir projeyi konuşmak isterseniz iletişim sayfamızdan bir görüşme ayarlayabilirsiniz.