Kapsam kaymasının gerçek maliyeti: neden asla “sadece bir özellik daha” değildir

Kapsam kayması nadiren dramatiktir. Kimse bir anda 20 yeni özellik istemez. Bir “sadece bir alan daha”, bir “Excel'e aktarım da olsun”, bir “bir de kullanıcı düzenleyebilsin” — tek tek bakınca minicik. Toplandığında mimari kararları bozar ve teslim tarihini haftalarca kaydırır. Sorun değişikliğin kendisi değil — fiyat etiketinin hiçbir zaman uygulanmamasıdır.

Kimsenin görmediği domino

Düzenlenebilir yeni bir alan sadece bir alan değildir. Doğrulama, denetim kaydı, yetkiler, UI durumu, API mutation, iyimser güncelleme, hata yönetimi, test, migration. Alan başka bir modüle dokunuyorsa (örneğin faturalama) temas noktaları katlanır. 30 dakikalık bir ince ayar 2 günlük işe dönüşür. Bir sprintte üç kez mi? 6 gün kaybettiniz — sprintin yarısı.

Değişiklik talebi protokolü — her seferinde yazılı

• 1. Her yeni talep yazılı olarak belgelenir (e-posta veya Nortinia Consulting App proje notu); sözlü talep yok hükmündedir
• 2. Tahmin: saat, etkilenen modüller, test ihtiyacı — müşteri resmin tamamını görmelidir
• 3. Açık ödünleşim: bu girerse ne kayar? — sadece ekleyemezsiniz, bir şeyden vazgeçilmelidir
• 4. Fiyat ve teslim tarihi: imzalı yeni bir sprint değişikliği anlaşması (dijital imza yeterli)
• 5. Ancak bundan sonra çalışırız — “sonra hallederiz” = garantili zarar

Değişiklik talebi protokolü bürokrasi değil — tek öğrenme fırsatıdır. Bir müşteri her hafta 3 yeni talep gönderiyorsa ilk tahmin yanlıştı: bir sonraki sözleşmede 1,5 kat tampon koyarız. Değişiklikler seyrekse kapsam belirleme iyiydi, bununla övünün. Protokol bir ölçüm aracıdır.

“Hayır” kelimesi düşmanlık değildir. “Şimdi değil” ifadesi profesyonel iletişimdir. Çoğu zaman tek bir “ama o zaman başka bir şey kayar” yeterlidir.