Yazılım projesinde kapsam kayması: nasıl fark edilir, nasıl durdurulur?

"8 haftalık proje demiştik, 5 aydır devam ediyor."

Bu cümlenin arkasında genelde kötü niyet yok. Ne müşteri kandırıyor ne ajans oyalıyor. Olan şey şu: proje fark edilmeden büyüdü.

Kapsam kayması tek bir büyük kararla olmuyor. On beş küçük "bu da olsun" ile oluyor ve her biri tek başına makul.

Nasıl başlıyor#

Tipik seyir:

• 2. hafta: "Bu ekrana bir filtre daha eklesek?" — makul, yarım gün.
• 4. hafta: "Rapor Excel'e de aktarılsa iyi olur." — makul, bir gün.
• 6. hafta: "Bir de mobilden girilebilse." — bu artık yarım gün değil.
• 8. hafta: "Muhasebeye de bağlansın, elle girmeyelim." — bu ayrı bir proje.

Hiçbir adımda "hayır" denmemiş, hiçbir adımda takvim yeniden hesaplanmamış. Sekizinci haftada proje ilk konuşulanın iki katı büyüklükte ve takvim hâlâ eski takvim.

Erken işaretler#

Kaymanın belirtileri, takvim kaçmadan önce görülüyor:

• "Küçük bir şey" ile başlayan talepler artıyor. Cümlenin kendisi bir uyarı.
• Toplantılarda yeni ekran adları geçiyor. Kapsam dokümanında olmayan isimler.
• "Nasıl olsa buradayken" cümlesi. Ekstra işi mevcut işin içine gizliyor.
• Test edilecek liste büyüyor ama teslim tarihi değişmiyor. Matematiksel olarak mümkün değil.
• Kimse kapsam dokümanına bakmıyor. Doküman varsa ama referans alınmıyorsa yok sayılır.

Kök sebep: kapsamın yazılı olmaması#

Projelerin çoğu kapsam yazılı olmadığı için kayıyor. "Bir yönetim paneli olacak" cümlesi bir kapsam değil.

Kapsam şunları içermeli:

• Ekran listesi — hangi ekranlar, her birinde ne yapılıyor
• Kullanıcı rolleri — kim neyi görüyor, kim neyi değiştirebiliyor
• Entegrasyonlar — hangi sisteme, hangi yönde, hangi veri
• Kapsam DIŞI olanlar — en önemli bölüm
• Kabul kriterleri — proje ne olduğunda "bitti" sayılıyor

Dördüncü madde en çok atlanan ve en çok işe yarayan. "Mobil uygulama bu projeye dahil değildir", "çok dillilik kapsam dışıdır" gibi cümleler, altı hafta sonra çıkacak tartışmayı bugünden bitiriyor.

Değişiklik yasak değil, sessiz olması yasak#

Kapsam kaymasının çözümü "hiçbir şeyi değiştirmemek" değil — proje ilerledikçe daha iyi fikirler çıkması normal ve iyi.

Sorun, değişikliğin görünmez olması. Çözüm basit bir düzen:

Her yeni talep için üç satır:

1. Ne isteniyor?
2. Ek süre ne kadar?
3. Ek maliyet ne kadar? (veya: kapsamdan ne çıkarılacak?)

Üçüncü seçenek özellikle işe yarıyor: "Bunu ekleyebiliriz, karşılığında X ekranını ikinci faza alalım." Böylece takvim korunuyor ve karar müşterinin oluyor.

Bu üç satır yazılı olsun — e-posta yeter. Sözlü onaylanan değişiklikler, üç ay sonra kimsenin hatırlamadığı değişikliklerdir.

Ajans tarafının sorumluluğu#

Kapsam kayması yalnızca müşteri kaynaklı değil. Ajans tarafında da kaynakları var:

• Baştan yeterince soru sormamak. Analiz aşamasını kısa tutup "yaparken netleşir" demek.
• Hayır diyememek. Müşteriyi memnun etmek için her talebi kabul etmek, projeyi geciktirerek daha büyük memnuniyetsizlik üretiyor.
• Etkiyi anlatmamak. "Tamam ekleriz" demek kolay; "ekleriz ama teslim 10 gün kayar" demek gerekiyor.
• Ara teslim yapmamak. Müşteri çalışan bir şey görmezse hayal etmeye devam ediyor ve hayal büyüyor.

Son madde en etkilisi. İki haftada bir çalışan bir parça göstermek, kapsamı yazılı tutmaktan bile daha çok işe yarıyor — çünkü beklenti somutlaşıyor.

Müşteri tarafının sorumluluğu#

• Kapsam dokümanını okuyun ve onaylayın. İmzalanan ama okunmayan doküman koruma sağlamıyor.
• Talepleri biriktirin. Aklınıza gelen her şeyi anlık iletmek yerine haftalık toplayın; çoğu kendiliğinden eleniyor.
• Karar verecek kişiyi netleştirin. Üç kişiden üç farklı yön gelirse proje yalpalıyor.
• Geri bildirimi zamanında verin. Test için gönderilen sürüm iki hafta bekliyorsa gecikme kapsamdan değil.

Faz mantığı#

Büyük projelerde en güvenli yapı, işi fazlara bölmek:

• Faz 1: İşin durduğu tek süreç, en sade hâliyle
• Faz 2: Kullanım verisiyle ortaya çıkan gerçek ihtiyaçlar
• Faz 3: Entegrasyonlar ve otomasyon

Bu yapının avantajı: Faz 1 kullanılmaya başladığında Faz 2 listesinin yarısının gereksiz olduğu görülüyor. Kullanmadan hayal edilen ihtiyaçlarla, kullandıktan sonra fark edilen ihtiyaçlar aynı liste değil.

Takvim gerçekçi miydi#

Bazen sorun kayma değil, baştan iyimser takvim. Bir tahmin verilirken şunlar hesaba katılmalı:

• Analiz ve tasarım onay süreleri (müşteri tarafında bekleme dahil)
• Test ve düzeltme turu (genelde geliştirmenin %25–30'u)
• Veri taşıma ve temizlik
• Eğitim ve devreye alma

Bunlar sayılmadan verilen "8 hafta", gerçekte 8 haftalık geliştirme + belirsiz süre demek.

Proje kaydıysa ne yapmalı#

Zaten kaymışsa geriye dönük suçlama işe yaramıyor. Yapılacak:

1. Bugünkü gerçek kapsamı yazın. Neye dönüştüğünü ikisi de görsün.
2. Kalan işi listeleyin ve önceliklendirin.
3. Yayına almak için gerekli minimumu belirleyin.
4. Gerisini Faz 2'ye alın ve tarih verin.

Çoğu tıkanmış proje bu dört adımla 3–4 hafta içinde yayına çıkabiliyor. Çünkü kalan işin büyük kısmı "olsa iyi olur" kategorisinde.

Projenizin kapsamını yazılı hâle getirip gerçekçi bir takvim çıkaralım — projenizi anlatın.