Feature Creep: Kapsam Neden Sessizce Şişer
Bir projeye sonradan eklenen her özellik, tek başına bakıldığında makul görünür. Feature creep de tam oradan çıkar: kimse bilerek kötü bir karar vermez, ama kararların toplamı takvimi, bütçeyi ve ürünün kullanılabilirliğini bozar. Eklemeler tek tek mantıklıysa sorun tam olarak nerede başlıyor?
Tek tek masum, toplamda pahalı
Feature creep, kapsam üzerinde anlaşıldıktan sonra sınırın dışına taşan eklemelerin birikmesidir. Scope creep, featuritis, feature bloat: adı değişir, mekanizma aynı kalır. Sonuçları da fazlasıyla tahmin edilebilir. Teslim tarihi kayar, bütçe aşılır, olgun bir yazılım kendi menüsünde kaybolur.
Buraya kadarı zaten herkesin kabul ettiği kısım. Asıl merak edilecek soru şu: madem sonuç bu kadar öngörülebilir, neden aynı hikâye her projede tekrar ediyor? Çünkü maliyet, ekleme anında görünmez. Ekleme anında görünen tek şey, iyi niyetli ve küçük bir istektir.
Bir özelliğin maliyeti yazıldığı gün bitmez
Yeni bir seçenek eklediğinizde iş, o seçeneğin kodu değildir. Birbirinden bağımsız açılıp kapanabilen n tane ayarınız varsa sistemin davranış uzayı 2^n konfigürasyondur; dokuz ayarla 512 olan kombinasyon sayısı, onuncu ayarı eklediğinizde 1024 olur. Kimse bunların hepsini test etmez, zaten mesele de bu. Test edilmeyen kombinasyonlar ortadan kalkmaz, yalnızca görünmez olur ve birkaç sürüm sonra hata kaydı olarak geri döner.
Kapsam tartışmasını genelde tek bir soruyla açarım: bu ayar mevcut ayarlarla kesişiyor mu? Kesişmiyorsa gerçekten ucuzdur, tartışmaya bile değmez. Kesişiyorsa fiyat etiketi geliştirme süresi değildir; ondan sonraki her sürümde ödenecek bakım payıdır ve o payı kimse teklife yazmaz.
"Biri girerse biri çıkar" kuralı nerede tıkanır
Proje yönetiminde en sık verilen tavsiye şudur: yeni bir özellik ancak listeden bir başkası çıkarılırsa girer. Disiplinli görünüyor, ama sessiz bir varsayıma yaslanıyor, o da özelliklerin birbirine denk olduğu. Pratikte takas hemen her zaman aynı yönde işler. Çıkan, savunucusu olmadığı için gözden çıkarılabilen küçük iştir. Giren ise gündeme gelebilecek kadar güçlü bir sponsoru olan büyük iştir. Kalem sayısını sabit tutarsınız, iş yükünü büyütürsünüz.
Kural, kalem üzerinden değil tahmini süre üzerinden işletildiğinde çalışır. Beş günlük bir özellik giriyorsa listeden beş günlük iş çıkacak. Bunu peşinen kabul etmeyen bir müşteri, aslında kapsam değişikliğini değil ek bütçeyi konuşuyordur.
Yazılı kapsam, hatırlamanın yerine geçer
Kapsamın yazılı ve onaylı olması, kimse kimseye güvenmediği için değil, altı ay sonra kimsenin ilk konuşmayı aynı şekilde hatırlamadığı için gerekir. Freelancer tarafında bu daha da keskin: sözleşmede ek isteklerin nasıl ele alınacağı yazmıyorsa, ek istek varsayılan olarak ücretsiz sayılır. Yeni talep geldiğinde verilecek cevap ret değildir. Cevap, talebin süreye ve bütçeye etkisini aynı cümlede söylemektir; karar zaten karşı tarafın.
Peki kapsam hiç mi değişmemeli?
Değişmeli. Kullanıcı görüşmesi sonrası planlanan bir özelliğin işe yaramadığını fark ettiyseniz, o özelliği inatla yapmak kapsamı korumak değil, körlüğü korumaktır. Ayrım şurada: yeni bilgi mi geldi, yoksa yeni bir heves mi? Birincisi kapsamı yeniden kurmak için sağlam bir gerekçedir. İkincisi bir sonraki sürüme yazılır ve orada da beklemeye devam ederse zaten gerçekten gerekli değilmiş demektir.
Kaynaklar