İhtiyacı ekran listesinden önce tanımlayın
Yeni bir uygulama talebi çoğu zaman istenen ekranlarla anlatılır. Önce o ekranların hangi işi kolaylaştıracağını konuşmak daha yararlıdır. Bugün işi kim başlatıyor, hangi bilgi bekleniyor, nerede yeniden veri giriliyor ve tamamlandığı nasıl anlaşılıyor? Süreci bir gerçek örnek üzerinden izleyin; kullanılan dosyaları ve sistemleri belirleyin. İlk çıktınız kısa bir ihtiyaç notu olsun: sorun, kullanıcılar, beklenen değişim, kapsam sınırı ve karar sahibi. Henüz çözülemeyen soruları da aynı yerde tutun. Her bilinmeyeni başlangıçta kapatmak gerekmeyebilir; ancak takvimi veya bütçeyi etkileyebilecek bir varsayımın doğrulanmış bilgi gibi görünmemesi gerekir.
Kabulü baştan konuşun, sorumluları isimlendirin
Çalışıyor ifadesi farklı kişiler için farklı anlamlara gelebilir. Kullanıcının tamamlaması gereken işleri ve her işte beklenen sonucu örneklerle yazın. Eksik bilgi, yetkisiz kullanıcı ve iptal edilen işlem gibi durumları da dahil edin. İş birimi gereksinimi ve sonucu değerlendirirken teknik ekip bağlantıları, erişimi ve işletim koşullarını doğrulasın. Proje sorumlusu kararları takip etsin; belirsiz bir konuyu yalnızca toplantı tutanağına bırakmasın. Kabul ölçütlerinin sahibi ve değişikliği onaylayacak kişi belli olsun. Kullanıcı testine ayrılacak zamanla gereken örnek veriyi de planlayın. Böylece teslim tarihi yaklaştığında ilk kez karşılaşılan bir kabul süreci oluşmaz.
Çalışan bir bütünü küçük kapsamla gösterin
Projeyi yalnızca teknik parçalara bölmek, ilerlemeyi kullanıcıdan gizleyebilir. Bunun yerine küçük ama baştan sona çalışan bir senaryo seçin: kayıt gelir, yetkili kişi inceler, sonuç ilgili sisteme döner. Bu ilk teslim bütün kapsamı çözmek zorunda değildir; bağlantıların ve iş kuralının birlikte çalıştığını göstermelidir. Gösterimde hangi adımların gerçek, hangilerinin geçici olduğunu açıkça belirtin. Her değerlendirmeden sonra kabul edilen işi, bulunan sorunu ve kapsam değişikliği talebini ayrı kaydedin. Yeni bir istek geldiğinde mevcut işin içine sessizce eklemek yerine etkisini konuşun. Öncelik ve teslim sırası, süreç sahibinin anlayabileceği bir iş listesinde güncel kalsın.
Test sonucunu karar verilebilir hale getirin
Testin sonunda yalnızca tamamlandı yazan bir liste bırakmayın. Denenen senaryo, kullanılan veri, beklenen sonuç, gözlenen sonuç ve açık konu kısa biçimde kaydedilsin. Hatanın işi durdurup durdurmadığını ve geçici bir çalışma yolu bulunup bulunmadığını iş sahibiyle değerlendirin. Teknik doğrulama ile kullanıcı kabulü farklı sorulara yanıt verir; ikisine de yer ayırın. Yetki, rapor tutarlılığı, tarayıcı veya cihaz kullanımı gibi ilgili koşulları örneklere ekleyin. Düzeltmeden sonra yalnızca değişen ekranı değil, etkilenen iş adımlarını da kontrol edin. Canlıya çıkış kararı verilirken hangi açık işlerin kabul edildiği ve kimin takip edeceği görünür olmalıdır.
Devreye almayı ayrı bir çalışma olarak yönetin
Canlıya geçiş, yazılımı sunucuya koymaktan daha geniştir. Kullanıcı erişimleri, aktarılacak veriler, mevcut işlemlerin durumu, bildirimler ve destek düzeni birlikte hazır olmalıdır. Geçiş planında sıra, sorumlu, kontrol noktası ve durdurma koşulu yer alsın. Geri dönüş gerekiyorsa bunun yalnızca uygulama sürümünü değil, o sırada oluşan veriyi nasıl etkileyeceğini de değerlendirin. GOV.UK hizmet rehberi, sınırlı kullanıcıyla öğrenmeyi ve canlı kullanımın işletim ihtiyaçlarını önceden hazırlamayı vurgular. Kurumsal projede de kapsamı kontrollü açmak yararlı olabilir. İlk gerçek işlemleri kimlerin izleyeceğini ve beklenmeyen durumda kimin karar vereceğini planlayın; duyuru yapmak bu hazırlığın yerine geçmez.
Teslimden sonra işi sahipsiz bırakmayın
Bilgi aktarımının amacı ekibin günlük işi sürdürebilmesidir. Kurulum ve işletim notları, erişimlerin sahibi, kaynak kodun konumu, bilinen sınırlamalar ve destek yolu bu nedenle birlikte teslim edilmelidir. Belgeleri yalnızca göndermek yerine ekiple bir çalışma yapın: örnek bir sorunu bulabiliyor, doğru kişiye yönlendirebiliyor ve olağan bakım adımını uygulayabiliyorlar mı? Destek süresiyle kapsamını açıkça kaydedin. Canlı kullanımda ortaya çıkan yeni ihtiyaçları da düzeltme işiyle karıştırmadan değerlendirin. GOV.UK rehberinde canlı hizmetin sürekli iyileştirilmesi ayrı bir sorumluluk olarak ele alınır. Projenin sonunda beklediğimiz çıktı da sadece çalışan yazılım değil, onu sahiplenecek kişiler ve sürdürülebilir bir çalışma düzenidir.
