Yazılım Tahminleri Neden Sürekli Kayar?

Tahminler beş yaygın sebeple kayar. Üçü meşrudur ve projenin dürüstçe yürütüldüğünü gösterir. İkisi bir şeylerin ters gittiğini gösterir. Fark, genelde sebebin kendisinde değil nasıl anlatıldığında görünür.

Bunlara geçmeden önce kabul edilmesi gereken bir şey var: yazılım tahminleri her yerde, mükemmel mühendisleri olan şirketlerde bile gerçekten kötüdür. İş, önceden bilinemeyecek şeyleri keşfetmeyi içerir. Tahminini hiç değiştirmeyen bir ekip ya ciddi pay bırakıyordur ya da keşifleri size anlatmıyordur.

Önemli noktalar

• Kayan tahmin normaldir: Şüphelenilecek durum hiç kaymayan tahmindir.
• Üç meşru, iki kötü sebep: Keşif, değişen gereksinim ve bölünme; belirsizlik ve yeniden yapım.
• Test, somutluktur: Gerçek bir sebebin adı, tarihi ve sonucu vardır.
• İsabete değil yakınsamaya bakın: Daralan tahmin sağlıklıdır. Sürekli sıfırlanan tahmin değildir.

Üç meşru sebep

Keşif

Bir şey dokümantasyonun, verinin ya da kendi ekibinizin söylediğinden farklı çıkmıştır. Entegrasyon varsaydığınız bir durumu desteklemiyordur, veri kümesi beklenenden kirlidir ya da işinizdeki bir kural hiç yazıya dökülmemiştir.

Gerçek kaymaların en sık sebebi budur ve tahmin yürütmek yerine gerçekten iş yapan bir ekibin işaretidir. Bu sebebin iyi hâli somuttur: "Kargo sağlayıcısının API'si kısmi sevkiyat döndürmüyor, kendimiz modellememiz gerekiyor, yaklaşık bir hafta."

Değişen gereksinim

Biri farklı bir şey istemiştir ya da ilk tarif iki anlama geliyordur ve ekip diğerini kurmuştur. Bu genelde müşterinin taşıyacağı bir maliyettir ve adı konduğu sürece sorun değildir.

Buradaki hata biçimi sessiz emilimdir: değişiklikleri kabul edip tarihi güncellemeyen, sonra tarihi kaçıran ve kendisine ait olmayan sebeplerle beceriksiz görünen bir ekip. Ekibiniz hiç "bu bir değişiklik" demiyorsa, değişiklikleri içine çekip çekmediklerini sorun.

Bölünme

Geliştiriciler üretim sorunlarına, destek eskalasyonlarına ya da başka bir projeye çekilmiştir. Asıl işle ilgili hiçbir şey değişmemiştir; sadece planlanandan az vakit harcanmıştır.

Bu meşrudur ama aynı zamanda düzeltilmesi en kolay olandır ve ayrıca takip edilmeye değer. Sebep iki ay üst üste bölünmeyse sorununuz tahmin değil, ekibin korunmuş zamanının olmamasıdır.

Bir şeylerin ters gittiğini gösteren iki sebep

İş, tahmin edilebilecek kadar hiç anlaşılmamıştır

İşareti, daralmak yerine sıfırlanan bir tahmindir. Tarihe yakınsayan ekip üç hafta der, sonra iki hafta, sonra "perşembe". İşi hiç anlamamış ekip üç hafta der, sonra yine üç hafta, sonra yine üç hafta; her seferinde bugünden itibaren.

Bu bir sahtekârlık değildir. Genelde işin tahmin edilemeyecek kadar büyük olduğu ve hiç parçalanmadığı anlamına gelir. Çaresi, işi günler içinde bitirilebilecek parçalara bölmektir ki bu, ilerlemeyi de ilk kez görünür kılar.

İş bitirilmiyor, yeniden yapılıyor

Aynı alana tekrar tekrar dokunulur. Her tur gerçek bir emektir, dolayısıyla her haftanın raporu doğrudur, ama sistem ilerlemez. Sebepler değişir: tutmayan bir tasarım, sürekli biçim değiştiren bir gereksinim ya da her biri baştan başlayan kişiler arasında dolaşan bir iş.

Birden fazla kez yeniden yazılan ne olduğunu ve nedenini sorun. Gereksinimlerde karşılık gelen bir değişiklik olmadan tekrarlayan yeniden yapım, daha dikkatli bakmanız gereken sebeptir.

Tek soruyla ayırt etmek

Sorun: Sayıyı değiştiren tam olarak neyi öğrendiniz?

Meşru bir sebep, içinde bir ad geçen somut bir cevap üretir. Belirsiz bir sebep ise kategori üretir: karmaşıklık, öngörülemeyen sorunlar, teknik borç. Bu kelimelerin hepsi gerçek şeyleri anlatır, ama bir cevaba giriş yerine cevabın kendisi olarak kullanıldığında, konuşan kişinin de somut bir sebebi olmadığını gösterir.

İkinci faydalı soru, yeni tahminin aynı kapsam için olup olmadığıdır. Çoğu zaman değildir ve kimse bunu söylememiştir; yani iki farklı sayıyı karşılaştırıp ikisi hakkında da yanlış bir sonuca varıyorsunuzdur.

Kayan tarihlerin ne zaman durmuş bir projeye işaret ettiğine dair geniş tablo için projenin gerçekten geride olup olmadığı yazısına bakın.

Ne yapmalı

Tarih yerine aralık isteyin ve kısa ucun gerçekleşmesi için neyin doğru olması gerektiğini sorun. "İki ila dört hafta; sağlayıcının test ortamı belgelendiği gibi çalışırsa iki" cümlesi size tahmini ve riski tek cümlede verir, ekibe de dürüstçe durabileceği bir zemin sağlar.

Sonra tarihi değil kapsamı sabitleyin. Daha küçük bir şeyi zamanında çıkaran proje, her şeyi geç çıkarandan neredeyse her zaman daha değerlidir ve hangi parçaların düşeceği kararı ekibin değil sizindir.