Yazılım projesinde değişiklik talebi; ihtiyaç, etki, karar ve kabul kontrolüyle birlikte yönetilmelidir. Bir mesajda geçen küçük ekleme, veri yapısını veya başka ekranları etkileyebilir. Önce istenen sonucu tanımlayın, sonra süre ve maliyet değerlendirmesine geçin.
Bir kullanıcı yeni filtre ister, yönetici aynı anda raporu değiştirmek ister. Her istek doğrudan geliştirmeye alınırsa ekip hangi sürümün onaylandığını kaybedebilir. Amaç değişiklikleri engellemek değil; neyin neden ve hangi koşulla yapılacağını herkes için görünür tutmaktır.
Hata, iyileştirme ve yeni kapsamı ayırın
Onaylanan davranış çalışmıyorsa hata olabilir. Mevcut işi daha kolay yapmak iyileştirme, yeni kullanıcı veya işlem eklemek kapsam değişikliği olabilir. Kararı yalnızca talebin kısa yazılmış olmasına göre vermeyin. Mevcut kabul ölçütü ve proje kapsamıyla karşılaştırın.
- Hangi kullanıcı hangi işi yapamıyor?
- Şu anda ne oluyor, ne olması bekleniyor?
- Talep hangi ekran ve işlemleri etkiliyor?
- Gerekli tarih için iş gerekçesi nedir?
- Sonucun kabul edildiğine kim karar verecek?
Talebi ekran tarifinden önce sonuçla anlatın
Bir düğme daha ekleyin yerine, bekleyen siparişleri tarihe göre bulamıyorum demek sorunu daha iyi tarif eder. Çözüm yeni düğme, mevcut filtreyi düzenleme veya veri hatasını giderme olabilir. İlk önerilen arayüzü tek seçenek gibi kabul etmeden ihtiyacı anlayın.
Kurgusal örnek: Satış ekibi yalnızca kendisine atanmış açık teklifleri görmek istiyor. Bu istek filtre kadar yetki, rapor ve bildirim davranışını da etkileyebilir. Hangi rollerde geçerli olacağı ve diğer kullanıcıların ne göreceği belirtilmelidir.
Etki analizinde neler sorulmalı?
- Veri alanı veya eski kayıtların dönüşümü gerekiyor mu?
- Yetki ve kişisel veri erişimi değişiyor mu?
- Mobil uygulama, web ve entegrasyon etkileniyor mu?
- Mevcut raporlar ve otomatik işler değişecek mi?
- Geçiş, test ve gerekirse geri dönüş nasıl yapılacak?
Etki analizi, sadece kod yazma süresi değildir. Test, veri hazırlığı ve kullanıcı eğitimi de planın parçası olabilir. Dış servise bağlı işler varsa bunların koşulları ve belirsizlikleri açıkça yazılsın. Kesinleşmemiş süreyi teslim sözü gibi aktarmayın.
Öncelik ve onay kaydı oluşturun
İşin etkisi, aciliyeti ve mevcut planla çakışması birlikte değerlendirilsin. Her talebe acil etiketi koymak sıralamayı anlamsızlaştırır. Karar, kapsam, kabul ölçütü ve planlanan sürüm aynı kayıtta dursun. Süre veya maliyet değişiyorsa yetkili kişinin onayı olmadan geliştirmeye başlanmamalıdır.
Sözlü konuşulan son halle eski ekran tasarımı çelişiyorsa önce tek bir güncel karar kaydı oluşturun. Birden fazla mesajlaşma kanalındaki farklı notların ekip tarafından yorumlanmasına bırakmayın. Sözleşmesel kapsam ve ücret koşulları ilgili taraflarca ayrıca netleştirilmelidir.
Kabul testini talebin başında yazın
Örnekteki teklif filtresi için normal kullanıcı, yetkisiz kullanıcı, boş sonuç ve eski kayıt senaryolarını tanımlayın. Geliştirme tamamlandıktan sonra neye bakılacağını ilk kez konuşmak yerine, beklenen sonucu baştan somutlaştırın. Yeni işlevin eski akışı bozmadığı da kontrol edilmelidir.
Yayın sonrası ilk kontrolün sorumlusu ve sorun başvuru yolu belli olsun. Bakım ve destek kapsamını değişiklik yönetiminden ayrı ama bağlantılı değerlendirin. BE Soft yazılım projeleri için örnek talebinizi mevcut davranışla birlikte paylaşın; etki ve kabul planını birlikte çıkaralım.
Sık sorulan sorular
Kısa bir istek mutlaka küçük iş mi?
Hayır. Veri, yetki ve entegrasyon etkisi görülmeden büyüklüğü yalnızca cümle uzunluğuyla belirlenemez.
Kabul testi geliştirme sonunda mı yazılır?
Beklenen sonuç baştan tanımlanırsa kapsam ve teslim kontrolü daha anlaşılır olur.
