Vaka: Bir İstanbul Yazılım Şirketinde Kapsam Kayması Krizi

Aşağıdaki vaka, gerçek bir ERP projesinden esinlenerek kurgulanmıştır; kişi ve şirket adları temsilidir. Amaç, kapsam kaymasının nasıl sinsice büyüdüğünü ve hangi noktalarda müdahale edilebileceğini görmektir.

Sahne: Levent'te bir yazılım şirketi

Maslak'ta 40 kişilik bir yazılım şirketi olan Vega Yazılım, orta ölçekli bir tekstil firmasına özel ERP sistemi geliştiriyor. Proje kapsamı imzalanan sözleşmede net: stok yönetimi, satış modülü ve temel raporlama. Takvim 4 ay, bütçe sabit fiyatla anlaşılmış.

1. Adım: İlk 'küçük' istekler

Proje başladıktan üç hafta sonra müşteri tarafındaki operasyon müdürü, haftalık durum toplantısında rastgele bir cümle kuruyor: "Bu arada, sevkiyat modülüne barkod okuma da eklenebilir mi, çok küçük bir şey." Proje yöneticisi (PY) bunu not alıyor ama resmi bir değişiklik talebi formu doldurtmuyor; "nasılsa küçük" diye düşünüp geliştirici ekibine sözlü iletiyor.

İki hafta sonra başka bir "küçük" istek geliyor: renk bazlı stok filtreleme. Sonra bir tanesi daha: e-posta bildirimleri. Her biri tek başına 1-2 günlük iş gibi görünüyor, kimse alarm çalmıyor.

2. Adım: Ekipte sessiz kalma kültürü

Kıdemli geliştirici Elif, üçüncü haftadan itibaren mesai saatlerinin uzadığını fark ediyor. Sprint planlamasında bunu dile getirmek istiyor ama ekip lideri değişikliklere "müşteri memnuniyeti" gerekçesiyle onay verdiği için, itiraz etmenin "takım oyuncusu olmamak" gibi algılanacağından çekiniyor. Junior geliştiriciler zaten soru sormaktan kaçınıyor. Sonuç: yükün büyüdüğünü gören herkes susuyor.

3. Adım: Proje yöneticisinin geç müdahalesi

Sekizinci haftada PY, geliştirme takviminin gerisinde kaldıklarını fark ediyor ancak nedenini net göremiyor çünkü kapsan değişiklikleri sistematik kayıt altına alınmamış. Bu noktada devreye girip geriye dönük bir kapsam denetimi yapıyor: sözleşmedeki orijinal WBS ile şu anki geliştirilen özellik listesini karşılaştırıyor. Ortaya çıkan tablo şoke edici: 6 adet onaysız ek özellik, toplam tahmini 3 haftalık ek iş yükü, bütçede karşılığı olmayan kaynak kullanımı.

4. Adım: Zor sunum — yönetim kuruluna gidiş

PY, durumu şirket ortaklarına taşımak zorunda kalıyor. Sunumda üç seçenek sunuyor:

• Seçenek A: Ek özellikleri kapsamdan çıkarıp orijinal takvime dönmek
• Seçenek B: Ek bütçe ve süre talep ederek tüm istekleri resmi sözleşmeye dahil etmek
• Seçenek C: Ek özellikleri bir sonraki faza (Faz 2) ertelemek, mevcut fazı orijinal kapsamla tamamlamak

Yönetim kurulu, müşteri ilişkisini korumak için Seçenek C'yi seçiyor: müşteriye durum şeffafça anlatılıyor, ek istekler ayrı bir teklif olarak Faz 2'ye planlanıyor, mevcut proje 3 hafta gecikmeyle ama orijinal kapsamda tamamlanıyor.

Krizden çıkarılan dersler

• Her değişiklik talebi, ne kadar küçük görünürse görünsün, yazılı forma dökülmeli ve etkisi (süre, bütçe, kaynak) değerlendirilmeli.
• Ekip içinde "iş yükü arttı" demenin güvenli olduğu bir kültür kurulmalı; bunun için PY düzenli, açık uçlu sorularla ("bu hafta neyle zorlandın?") ekibi dinlemeli.
• Kapsam denetimi bir kerelik değil, düzenli (örneğin her sprint sonunda) yapılan bir aktivite olmalı.
• Zor haberi geciktirmek durumu daha da zorlaştırır; erken ve şeffaf iletişim, güveni korur.

Tartışma Soruları

• Kendi projenizde şu anda "küçük" diye nitelenen ama kayıt altına alınmamış bir istek var mı? Şimdi bir Değişiklik Talep Formu doldurmayı düşünür müsünüz?
• Ekibinizde iş yükünün arttığını fark ettiğinizde bunu dile getirmek sizin için ne kadar kolay? Bunu kolaylaştırmak için ne yapılabilir?
• Vega Yazılım'ın yönetim kuruluna sunduğu üç seçenekten (A, B, C) siz hangisini seçerdiniz? Neden?