Kapsam Kayması ile Yaşamak: Değişikliği Reddetmek Değil Yönetmek

Kapsam kayması (scope creep), yazılım projelerinde en sık suçlanan ama en az anlaşılan olgudur. Genellikle müşterinin ya da ürün sahibinin bir kusuru gibi anlatılır. Gerçekte ise kayma, öğrenmenin doğal sonucudur: proje ilerledikçe herkes — geliştiriciler dâhil — problemi daha iyi anlar ve ilk plandaki bazı maddelerin yanlış olduğunu görür. Sorun değişikliğin kendisi değil, görünmez olmasıdır.

Kayma nasıl oluşur?

Neredeyse hiçbir proje "bu modülü baştan yazalım" cümlesiyle raydan çıkmaz. Çıkışın tipik yolu şudur: "Bu arada şuraya küçük bir filtre ekleyebilir miyiz?" Tek başına yarım gün. Ancak bu tür istekler haftada iki kez gelir, hiçbiri kaydedilmez ve üç ay sonra takvim üç hafta gecikmiştir. Kimse büyük bir değişiklik istemediği için de gecikmenin sebebi anlaşılamaz; suçlama genellikle "geliştirme yavaş" noktasına gelir.

Bu, tahminlerin şaşmasının en yaygın sebeplerindendir — konuyu farklı bir açıdan ele alan tahmin yazımız bu tabloyu tamamlıyor.

Yanlış çözüm: her şeye hayır demek

Kaymaya karşı en yaygın refleks, kapsamı kilitlemek ve tüm değişiklikleri reddetmektir. Bu, iki sebeple işe yaramaz. Birincisi, ilk günkü plan her zaman eksiktir; değişikliği tamamen engellemek, bile bile yanlış ürünü teslim etmek demektir. İkincisi, resmî kanal kapatıldığında istekler gayriresmî kanallardan sızar — "kayıt açmaya gerek yok, ufak bir şey" cümlesiyle.

Doğru hedef değişikliği durdurmak değil, görünür ve maliyetli kılmaktır.

Anahtar cümle: "neyin yerine?"

Kapsam yönetiminin tamamı tek bir soruya indirgenebilir. Yeni bir istek geldiğinde cevap "hayır" değil, şu olmalıdır: "Yapabiliriz. Bu iki günlük bir iş; hangi maddeyi çıkarıyoruz ya da teslimi iki gün öteliyor muyuz?"

Bu cümlenin gücü, kararı doğru kişiye taşımasıdır. Geliştirici "hayır" dediğinde engelleyici görünür; takası ortaya koyduğunda ise karar, önceliği belirlemesi gereken kişiye geçer. Deneyim şunu gösterir: isteklerin önemli bir kısmı, bedeli somut olarak görüldüğünde sahibi tarafından geri çekilir.

Kayıt tutmak: en basit ve en etkili önlem

Her isteğin — ne kadar küçük olursa olsun — tek bir yere yazılması, kaymayla mücadelenin bel kemiğidir. Kayıt üç şeyi içermelidir: talebin kendisi, kimden geldiği ve tahmini etkisi.

Bu listenin asıl değeri, dönem sonunda ortaya çıkar. "Neden geciktik?" sorusu sorulduğunda cevap, tahmin ya da his değil, on yedi maddelik somut bir listedir. Bu liste tartışmayı kişisellikten çıkarır ve bir sonraki planlamayı gerçekçi kılar.

Kapsam dışını yazın

Sözleşmelerde ve tasarım notlarında en çok atlanan bölüm, yapılmayacakların listesidir. "Raporlama bu fazda yok", "çok dilli destek kapsam dışı", "mobil uygulama ayrı bir iştir" gibi cümleler, ileride yaşanacak tartışmaların büyük kısmını bugünden bitirir. Bu alışkanlık, teknik tasarım notu yazımızda anlattığımız kapsam bölümünün proje ölçeğindeki karşılığıdır.

Sabit fiyat mı, zaman-malzeme mi?

Ticari model, kayma dinamiğini doğrudan belirler. Sabit fiyatlı işlerde tedarikçi değişime direnir, müşteri "zaten anlaşmıştık" der ve ilişki gerginleşir; ürün genellikle ilk günkü yanlış plana sadık kalarak teslim edilir. Zaman-malzeme modelinde ise esneklik vardır ama bütçe belirsizliği müşteriyi tedirgin eder.

Pratikte en iyi sonucu veren yaklaşım ikisinin arasındadır: bütçe sabittir, kapsam değişkendir. Yani "şu bütçeyle, önceliklendirilmiş listenin en üstünden aşağı doğru ilerleriz" denir. Bu model, değişikliği cezalandırmadan bütçeyi korur. Kurumsal ölçekte benzer bir mantık geçişlerde de geçerlidir; büyük patlama göçünden kaçınma yazımız bu kademeli yaklaşımı ele alıyor.

Sağlıklı kayma ile sağlıksız kayma

Her kapsam değişikliği kötü değildir. Kullanıcı testinden gelen ve ürünü gerçekten daha iyi yapan bir değişiklik, plana sadakatten daha değerlidir. Ayırt edici soru şudur: bu istek yeni bir öğrenmeden mi doğdu, yoksa baştan yapılmamış bir analizin geç fark edilmesinden mi?

İkinci durum tekrarlıyorsa problem kapsam yönetiminde değil, proje başlangıcındadır. Bu, projelerin başarısızlık sebeplerinden biridir ve projelerin neden başarısız olduğu yazımızda ayrıntılı ele alınıyor. Ekiplerin ortak çalışma pratikleri için Martin Fowler'ın yazıları da faydalı bir kaynaktır.

Sonuç

Kapsam kayması engellenmesi gereken bir kusur değil, yönetilmesi gereken bir gerçektir. Kaymanın zarar vermesi, isteklerin görünmez kalmasıyla olur: küçük diye kaydedilmeyen, bedeli konuşulmayan, kimsenin sahiplenmediği talepler. Her isteği yazılı hâle getirmek, "hayır" yerine "neyin yerine?" diye sormak ve kapsam dışını açıkça belgelemek, projelerin çoğunda gecikmelerin büyük kısmını ortadan kaldırır. Bu hafta küçük bir deney yapın: gelen her ek isteği, ne kadar küçük olursa olsun tek bir listeye yazın. Hafta sonunda listenin uzunluğu, muhtemelen en çok şaşıracağınız veri olacak.