Proje sınırlarını ve değişiklik kararlarını açık hale getirerek kapsam kaymasını önleyin. Sonucu, dahil edilen teslimatları, hariç tutulanları ve kabul koşullarını tanımlayın. Yeni bir talep geldiğinde kabul etmeden önce değerini ve efor, bağımlılık, maliyet ve zaman üzerindeki etkisini kaydedin. Değişiklik normaldir; incelenmeden genişleme sorun yaratır.
Bir ekip kapsamını kontrol ederken esnek de olabilir. Her yeni fikri reddetmek artık geçerli olmayan bir planı korur. Her talebi kabul etmek ise başka bir sorunu gizler: Proje yavaşça değişir ama özgün teslim tarihi ve kapasite varsayımları aynı kalır.
Kapsam kayması hakkındaki PMI konferans bildirisi, yetkilendirilmiş proje değişikliğiyle uygun yetkilendirme veya sonuç değerlendirmesi olmadan eklenen işi ayırır. Aşağıdaki pratikler bu ayrımı küçük işbirlikçi ekipler için uygular.
İnsanların tanıyabileceği bir sınır tanımlayın
Yararlı bir kapsam açıklaması dört soruya yanıt verir: Hangi sonucu elde etmek istiyoruz? Ne üreteceğiz? Neyi bilerek dışarıda bırakacağız? Kararlaştırılan işin kabul edilebilir olduğunu hangi kanıt gösterecek?
“Raporlama panosu oluştur” farklı beklentilere açıktır. Daha net bir ifade şöyledir: “Destek liderlerine mevcut bilet verilerinden çözümlenmemiş eskalasyonların haftalık görünümünü sun. Kuyruk yaşını ve sahipliği göster. Tahmin, faturalama verisi ve gerçek zamanlı uyarıları kapsam dışında bırak. Kabul için adlandırılmış bir lider örnek kayıtları kaynaklarla karşılaştırmalı.”
Ek ayrıntı belirsizliği ortadan kaldırmaz, talebin kapsama girip girmediğine karar vermek için ortak bir temel sağlar. Sınırı, insanların proje kararlarını zaten gözden geçirdiği yerde saklayın. Kimsenin bulamadığı kapsam belgesi etkili bir kontrol değildir.
Kalite beklentilerini isteğe bağlı eklerden ayırın. Kararlaştırılan kabulü engelleyen kusur otomatik olarak yeni bir özellik değildir. Tersine, ilgisiz bir özelliğe “küçük düzeltme” demek onu ilk anlaşmanın parçası yapmaz.
Hafif bir değişiklik talebi kullanın
Küçük bir ekibin her açıklama için komiteye ihtiyacı yoktur. Ancak bir talep taahhütleri değiştiriyorsa karar görünür olmalıdır. Kısa bir kayıt kullanın:
| Alan | Kaydedilecekler |
|---|---|
| Talep | Önerilen en küçük somut değişiklik |
| Gerekçe | Kullanıcı sorunu, yükümlülük veya yeni kanıt |
| Kapsam ilişkisi | Açıklama, düzeltme, değiştirme veya ekleme |
| Sonuçlar | İş, bağımlılık, maliyet, risk ve zamanlama |
| Ödün | Nelerin duracağı, küçüleceği, erteleneceği veya ek kapasite alacağı |
| Karar | Kabul et, araştır, ertele veya reddet |
| Yetki | Kararı verebilecek kişi |
| Güncellenmiş temel plan | Değişen taahhüdün kaydedildiği yer |
Kararla orantılı tahmin isteyin. Yarım günlük metin değişikliği ayrıntılı iş gerekçesi gerektirmemelidir. Yeni veri kaynağı entegrasyonu, görünür arayüzü küçük olsa bile daha fazla inceleme ister.
Paylaşılan atölye panosu, grubun talep ve ödünleri netleştirmesine yardımcı olabilir. Yetkili kapsam, takvim ve mali taahhütleri kurumunuzun bu amaçla kullandığı sistemlerde tutun.
Örnek: bir ek grafik entegrasyona dönüşüyor
Yukarıdaki destek panosunu geliştiren varsayımsal bir ekip düşünün. Bir paydaş, etkilenen müşteri hesaplarının değerini gösteren “bir ek grafik” ister. Grafiğin kendisi basit görünür ancak veriler farklı kimliklere ve erişim kısıtlarına sahip ayrı bir faturalama sistemindedir.
Ekip talebi kozmetik iyileştirme değil, ekleme olarak sınıflandırır. Entegrasyon işini, veri erişimi onayını, mutabakatı ve süregelen bakım sorumluluğunu belirler. Ayrıca özgün destek sonucunun bu grafiği gerçekten gerektirip gerektirmediğini kontrol eder.
Karar verici üç seçeneği görür: özgün kapsamı koruyup grafiği ertelemek, daha düşük değerli teslimatı entegrasyonla değiştirmek veya kaynakları ve zamanı artırmak. Ekip ertelemeyi seçer ve destek liderleri ilk raporu kullandıktan sonra gözden geçirme noktası kaydeder.
Örnek açıklama amaçlıdır; ertelemenin her zaman en iyi olduğunu iddia etmez. Önemli olan, ekipten görünmeyen işi üstlenmesini istemek yerine grubun gerçek seçimi görmesidir.
Değişikliği kimin kabul edebileceğini netleştirin
Yetkinin parçalı olması sık karşılaşılan bir hatadır. Satış bir özellik vaat eder, paydaş değişiklik ister ve geliştirici yardımcı olmak için uygular. Birleşik etkiyi kimse görmez. Sonuç, bütçe, teslim tarihi ve teknik yaklaşım değişikliklerini kimin onaylayabileceğini belirleyin.
Scrum’da Scrum Guide, öğrenme ortaya çıktıkça Product Owner ile kapsamın açıklığa kavuşturulup yeniden müzakere edilmesine izin verirken Sprint Goal’ü korur. Bu, Sprint Backlog’u koşulsuz bir özellik sözleşmesi saymak veya herhangi bir paydaşın doğrudan iş eklemesine izin vermek değildir.
Diğer teslimat yaklaşımlarında uygun hesap verebilir proje rolünü kullanın. İlke aynıdır: işi yapanların karara açık bir yolu, karar vericinin de dürüst sonuç bilgisi olmalıdır. “Lütfen bunu da yapın” sessiz bir taahhüt yerine ödün görüşmesini başlatmalıdır.
Sonunda suçlamak yerine erken işaretleri izleyin
Büyüyen kabul koşullarını, görünür iş listesi dışındaki tekrar işleri, yeni inceleyicileri veya bağımlılıklar artarken sabit kalan teslim tarihini izleyin. Bunların hiçbiri tek başına kapsam kaymasını kanıtlamaz; neyin değiştiğini ve planın bunu yansıtıp yansıtmadığını inceleme işaretidir.
Normal planlama sırasında kabul edilen değişiklikleri kısaca gözden geçirin. Mevcut kapsamı önceki sürümüyle karşılaştırın. Ekip işin neden eklendiğini açıklayamıyorsa daha fazla rapor yaratmadan önce karar izini onarın.
Değişikliklerin nasıl ele alındığını incelemek için bir agile retrospektifi kullanın: Hangi talepler karar sürecini atlattı? Hangi tahminler koordinasyonu hesaba katmadı? Hangi hariç tutmalar yanlış anlaşıldı? Gizli genişlemeyi kolaylaştıran sisteme odaklanıp tek bir iyileştirme seçin.
Başarıyı reddedilen taleplerin sayısıyla ölçmeyin. Değerli değişikliği reddeden ekip yanlış şeyi tam zamanında teslim edebilir. Kabul edilen değişikliklerin görünür gerekçesi, gerçekçi ödünleri ve güncel taahhütleri olup olmadığına bakın.
Sık sorulan sorular
Kapsam kayması ile değişen gereksinimler aynı şey mi?
Hayır. Gereksinimler meşru öğrenme ve açık kararlarla değişebilir. Kapsam kayması, uygun anlaşmayı atlayan veya sonuçları ele almayan genişlemeyi anlatır. Fark, değişikliğin nasıl değerlendirildiği ve plana katıldığıdır.
Küçük bir paydaş talebine nasıl hayır deriz?
Önce değerini ve gerçek sonuçlarını anlayın. Ödün seçeneklerini açıklayın: başka bir işi değiştirerek kabul etme, erteleme, araştırma veya zaman ve kapasiteyi değiştirme. Bağımlılıkları kontrol etmeden talebin küçük olduğunu varsaymayın.
Çevik ekip değişiklik kontrolü kullanabilir mi?
Evet, rutin uyarlamayı engellemek yerine destekliyorsa. Ürün kararlarını, ekip planlamasını ve taahhütleri açık tutun. Küçük değişiklik için hafifçe kaydedilmiş görüşme çoğu kez yeterlidir; önemli taahhütler uygun yetki gerektirir.