Kapsam Kayması Nasıl Önlenir: Kök Nedenden Çözüme

Kocaeli'de orta ölçekli bir üretim firmasının IT yöneticisi, tedarik takip sistemi için üç aylık bir teslim tarihi belirlemişti. Beşinci ayın sonunda proje hâlâ bitmemişti, çünkü başlangıçta tek sayfa olan "raporlama modülü" talebi yol boyunca on iki farklı rapor türüne, üç rol bazlı yetkilendirme kademesine ve iki dış sisteme entegrasyona dönüşmüştü. Kimse tek bir büyük hata yapmamıştı. Küçük "bir de şunu ekleyelim" talepleri birikmişti.

Bu durumun adı kapsam kaymasıdır: projenin başında kararlaştırılan iş kapsamının, resmi bir değişiklik süreci işletilmeden adım adım büyümesi. Biz SUNS Tech olarak takip ettiğimiz projelerde bu sorun hemen fark edilmez. Her tekil ekleme tek başına makul görünür, ama toplamda bütçeyi ve takvimi devirir.

Belirti her zaman takvimde değil, önce iletişimde görülür

Kapsam kayması yaşayan projelerde ilk işaret genelde gecikmiş teslim tarihi değildir. Daha önce gelir: toplantı notlarında "bu arada şunu da ekleyelim" ifadesinin sıklaşması, geliştirici ile müşteri arasındaki yazışmaların proje yöneticisini atlaması, ya da sprint planlarının her hafta yeniden açılması. Tedarik takip sisteminde bu belirti, operasyon ekibinin geliştiricilerle doğrudan WhatsApp üzerinden konuşup yeni rapor talepleri iletmesiydi. Proje yöneticisi bu taleplerin çoğundan haftalar sonra haberdar oluyordu.

Bu erken belirtiyi gözden kaçırmanın bedeli, fark edildiğinde çözümün çok daha pahalı olmasıdır. Üç haftalık bir ek iş, fark edilmeden dört aya yayılırsa hem geliştirme ekibinin odağı dağılır hem de test süreci baştan kurgulanmak zorunda kalır.

Kök neden genelde kötü niyet değil, belirsiz kabul kriterleridir

Tedarik takip projesinde kapsam dokümanında "sistem stok hareketlerini raporlayacaktır" yazıyordu. Bu cümle teknik ekip için "günlük stok giriş-çıkış özeti" anlamına gelirken, operasyon müdürü için "tedarikçi bazlı, tarih aralıklı, Excel'e aktarılabilir, yetki seviyesine göre filtrelenmiş" bir rapor seti anlamına geliyordu. Her iki taraf da kendi okumasında haklıydı. Doküman bu farkı kapatacak netlikte yazılmamıştı.

Kapsam kaymasının asıl kaynağı burada ortaya çıkar: kabul kriterleri ölçülebilir ve test edilebilir şekilde yazılmadığında, her iki taraf kendi zihnindeki versiyonu doğru kabul eder. Sözleşmede "raporlama modülü" gibi genel bir başlık varsa, bu başlığın altına eklenecek her şey teknik olarak "zaten kapsamdaydı" savunulabilir hale gelir.

Belirsizliğin büyüdüğü üç nokta

Deneyimlerimizde kapsam belirsizliği özellikle şu üç alanda yoğunlaşıyor:

• İş kurallarının vaka bazlı tanımlanması: "İade durumunda stok geri eklenir" cümlesi, kısmi iade, hasarlı ürün iadesi ve tedarikçiye geri gönderim senaryolarını kapsıyor mu, belirsiz kalır.

• Arayüz detaylarının sözlü bırakılması: "Kullanıcı dostu bir panel" ifadesi mobil uyumluluk ve filtreleme sayısı gibi somut gereksinimleri atlar.

• Entegrasyon sınırlarının tanımsız olması: "Muhasebe programıyla entegre çalışır" cümlesi, hangi verinin hangi yönde, ne sıklıkla aktığını söylemez.

Bu üç alan özellikle entegrasyon projelerinde sık yapılan hatalarla da örtüşüyor; kapsam belirsizliği ve entegrasyon hataları genelde aynı kaynaktan, yani yazılı olmayan varsayımlardan besleniyor.

Ek toplantılar ve sözlü onaylar sorunu çözmedi, geciktirdi

Proje ekibi ilk fark ettiğinde yaptığı şey, haftalık durum toplantılarını sıklaştırmaktı. Bu kısa vadede rahatlatıcı görünse de kapsam kaymasını çözmedi; sadece tartışmayı kayıt altına almadan tekrar tekrar yapılan bir forma dönüştürdü. Sözlü "tamam, bunu da ekleyelim" onayları kimin ne zaman ne istediğine dair bir iz bırakmadığı için, proje sonunda kapsam anlaşmazlığı yaşandığında elde hiçbir referans doküman kalmadı.

Bir diğer yaygın yanlış inanış, kapsam kaymasının çözümünün "müşteriye hayır demek" olduğudur. Gerçekte sorun hayır deme cesareti değil, hangi taleplerin ek iş olduğunu gösterecek bir referans noktasının bulunmamasıdır. Referans doküman olmadan her hayır, müşteri gözünde keyfi bir reddediş gibi görünür ve ilişkiyi geriyor.

İşleyen çözüm, değişiklik talebini resmi bir sürece bağlamaktır

Tedarik takip projesinde işe yarayan adım, kapsam dokümanını yeniden yazıp her madde için kabul kriterini ölçülebilir hale getirmekti: "Stok raporu tedarikçi, tarih aralığı ve ürün kategorisi filtresiyle Excel formatında dışa aktarılabilir" gibi somut ifadeler kullanıldı. Bundan sonra gelen her yeni talep, bu dokümanla karşılaştırılarak kapsam dahilinde mi değil mi diye sınıflandırıldı.

Kapsamın dışında kalan her talep için basit bir değişiklik talebi formu devreye girdi: talebin tanımı, tahmini ek süre, ek maliyet ve hangi başka işin bu nedenle geciktiği tek sayfada yazılıyor, müşteri tarafı onaylamadan geliştirme başlamıyordu. Bu adım kapsam kaymasını durdurmadı ama görünür ve maliyetli hale getirdi. Müşteri artık her talebin bir bedeli olduğunu somut olarak görüyordu.

Değişiklik talebi formunda bulunması gereken dört kalem

1. Talebin net tanımı ve hangi mevcut özelliği değiştirdiği

2. Tahmini ek geliştirme ve test süresi

3. Ek maliyet veya mevcut bütçeden hangi kalemden kısılacağı

4. Onaylayan kişinin adı ve onay tarihi

Bu dört kalem eksik olduğunda form bir bürokrasi kağıdına dönüşür, dolu olduğunda ise gerçek bir karar aracına. Biz SUNS Tech olarak yazılım danışmanlığı projelerinde bu formu proje başlangıcında müşteriyle birlikte tasarlıyoruz, çünkü formun kendisi de sonradan tartışma konusu olabiliyor. Bu yaklaşımı kurumsal yazılımda bakım ve destek süreçlerini kurgularken de aynı şekilde uyguluyoruz; proje bittikten sonra gelen talepler için de benzer bir değerlendirme mantığı işliyor.

Çözümün maliyeti var ve her projeye aynı oranda uymaz

Kapsam kontrolünü sıkılaştırmak bedelsiz değildir. Her değişiklik talebini resmi forma bağlamak, küçük ve gerçekten acil düzeltmeler için bile birkaç günlük bir onay gecikmesi yaratabilir. Tek kişilik bir işletme için geliştirilen basit bir web sitesinde bu süreç gereksiz ağır kalır; burada sözlü onay ve kısa bir e-posta teyidi yeterli olabilir.

Kurumsal ölçekli, birden fazla departmanın talep ürettiği projelerde ise bu resmi süreç olmadan bütçe kontrolü mümkün değildir. Denge şu: daha sıkı kapsam kontrolü seçtiğinizde hız ve esneklikten bir miktar vazgeçersiniz; daha gevşek bir süreç seçtiğinizde ise bütçe ve takvim öngörülebilirliğini riske atarsınız. Doğru denge, projenin paydaş sayısına ve bütçenin ne kadar sıkı izlenmesi gerektiğine göre değişir.

Sözleşme aşamasında atılan bir adım sonraki altı ayı belirler

Tedarik takip projesinde geriye dönüp bakıldığında, en ucuz önlemin sözleşme öncesi kabul kriterlerini yazılı ve ölçülebilir hale getirmek olduğu görüldü. Bu adım proje başlamadan bir iki hafta sürse de, sonradan kapsam anlaşmazlığı nedeniyle kaybedilen bir iki aylık süreyle kıyaslandığında küçük bir yatırımdır. Biz web tasarım ve geliştirme projelerinde de aynı mantığı uyguluyoruz: wireframe ve kabul kriterleri netleşmeden kodlamaya başlamak ilk bakışta hız kazandırır ama orta vadede en pahalı kısayoldur.

Kurum içi satın alma veya proje yönetimi ekibi için pratik kontrol noktası şudur: sözleşme veya teklif dokümanında her ana madde için "bu özelliğin tamamlandığını nasıl test ederiz" sorusuna yazılı bir cevap olmalı. Bu cevap yoksa, o madde ilerleyen aylarda kapsam tartışmasının merkezi olmaya adaydır. Aynı mantık SaaS ürünü geliştirirken de geçerli; sıfırdan SaaS ürünü kurarken de mimari kararlar netleşmeden önce kapsamın yazılı hale gelmesi gerekiyor.

Benzer kapsam yönetimi yaklaşımlarını uyguladığımız projelerin bir kısmını portfolyomuzda inceleyebilirsiniz.

Projenizin kapsamını netleştirmek ve gerçekçi bir takvime bağlamak için proje detaylarınızı iletip fiyat teklifi alabilirsiniz; kapsam netleştiği an takvim ve maliyet öngörüsü de netleşir.