Bir yazılım fikrinin özellik listesi kolayca uzar; ancak her özelliği ilk teslimata koymak projenin ne zaman kullanılacağını belirsizleştirir. İlk sürümün amacı, asıl işi güvenilir biçimde tamamlayan bir akışı gerçek kullanıcıya ulaştırmaktır. Bunun için nelerin yapılacağı kadar nelerin hangi gerekçeyle sonraya bırakılacağını da yazmak gerekir.
Ekran listesiyle değil, tamamlanacak işle başlayın
“Müşteriler, raporlar, takvim ve ayarlar ekranı olsun” demek yeterli kapsam değildir. Bu ekranların hangi işi bitirdiği belli olmalıdır. Örneğin servis işletmesinde müşteri talebinin alınması, uygun personele atanması, işin kapanması ve sonucun müşteriye iletilmesi bir bütün oluşturur.
İlk sürüm bu zinciri tamamlayamıyorsa çok sayıda ekranın hazır olması kullanım değeri üretmeyebilir. Buna karşılık az sayıda ekranla işin baştan sona yapılabilmesi güçlü bir başlangıçtır. Tasarım görüşmesinde menü başlıklarından önce gerçek bir işlemi adım adım canlandırın.
İşin başlangıcını ve bitişini tanımlayın. Talep hangi bilgilerle açılacak? Kim kabul edecek? İşin bittiğini hangi durum gösterecek? Bir sonraki çalışanın ne yapacağını anlamak için telefon açması gerekiyorsa akışta hâlâ eksik bir karar olabilir.
Kullanıcı rollerini ve yetkilerini ayırın
Her kullanıcının her veriyi görmesi veya değiştirmesi gerekmez. Yönetici, saha çalışanı ve müşteri farklı yetkilere sahip olabilir. Yetki kuralları sonradan eklenecek bir süs değildir; veri güvenliği ve günlük kullanımın parçasıdır. İlk sürüm için gerekli rolleri ve temel izinleri baştan belirleyin.
Bir görevli işi tamamlandı olarak işaretleyebiliyor ama fiyat değiştiremiyorsa bu kural açıkça yazılmalıdır. Aynı şekilde müşteri yalnızca kendi kaydını görmelidir. Kontrolü sadece ekranda butonu gizleyerek bırakmayın; geliştirme ekibi sunucu tarafında da yetki doğrulaması yapmalıdır.
Rol listesini gereksiz yere ayrıntılandırmak da yönetimi zorlaştırır. Gerçek sorumlulukları ayıran az sayıda rolle başlayın. İleride farklı şubeler veya ekipler eklenecekse bu ihtiyacı tasarımda bilin; bütün olası organizasyonları ilk günden kurmak zorunda değilsiniz.
Özellikleri üç gruba ayırın
Her talep için “İlk kullanıcı bu olmadan temel işi bitirebilir mi?” sorusunu sorun. Yanıt hayırsa ilk sürüm adayını buldunuz. Yanıt evetse özelliğin hangi sorunu azalttığını ve ne zaman değerlendirileceğini yazın. Herkesin faydalı bulduğu özellik, mutlaka ilk teslimatın şartı değildir.
| Grup | Karar ölçütü | Örnek |
|---|---|---|
| İlk sürümde gerekli | Temel iş tamamlanamıyor veya riskli kalıyor | Talep açma, atama, yetki ve durum takibi |
| Kullanımla doğrulanacak | Faydası var ama ihtiyaç biçimi belirsiz | Yöneticiye özel gelişmiş rapor |
| Sonraki aşama | Başka bir akış veya kanal açıyor | Ayrı bayi portalı ya da yeni pazar entegrasyonu |
Güvenlik, veri yedeği ve hata yönetimini “sonraki aşama” diye otomatik ertelemeyin. Kapsam küçük olabilir; fakat gerçek verilerle çalışacak sistemin temel işletim ihtiyaçları vardır. Dar kapsam ile eksik çalışmayı birbirinden ayırmak gerekir.
Kabul senaryolarını örneklerle yazın
“Rapor çalışacak” yerine beklenen davranışı tanımlayın. Örneğin “Yönetici seçtiği tarihlerde tamamlanan işleri filtreleyip dışa aktarabilecek; iptal edilenler toplamın dışında görünecek.” Bu cümle hem geliştirmenin yönünü belirler hem teslim sırasında neyin kontrol edileceğini anlatır.
Her önemli akış için normal durumun yanında bir hata veya istisna seçin. Aynı talep iki kez gönderilirse ne olur? Yetkisiz kişi bağlantıyı açarsa ne görür? Eksik bilgiyle kayıt oluşturulabilir mi? Geri alınamayan işlemde kullanıcıdan ne beklenir? Bu sorular son gün ortaya çıktığında kapsam tartışmasına dönüşebilir.
Örnek veriler kullanarak bir kabul dosyası hazırlayın. Gerçek kişisel verileri geliştirme ortamına taşımak yerine anonim kayıtlar üretin. Müşterinin, geliştiricinin ve günlük kullanıcının aynı senaryoyu değerlendirmesi yanlış anlaşılmayı azaltır.
Entegrasyonları erken doğrulayın
Muhasebe, ödeme, kargo veya mevcut müşteri sistemiyle bağlantı kurulacaksa gerekli erişimleri ve dokümantasyonu proje başında inceleyin. “Entegrasyon var” sözü, bütün alanların ve işlemlerin erişilebilir olduğunu göstermez. Test hesabı, yetki seviyesi ve veri sınırları sonucu değiştirebilir.
Başka sisteme bağlı işlem başarısız olduğunda kullanıcıya ne olacağını da belirleyin. Kayıt beklemeye mi alınacak, yeniden mi denenecek, operatör mü bilgilendirilecek? Başarılı bağlantı kadar hata durumunun yönetilmesi de işin parçasıdır. Aynı işlemin tekrar gönderilmesi çift kayıt üretmemelidir.
Eski veriler taşınacaksa örnek bir aktarımı erkenden yapın. Eksik telefonlar, mükerrer müşteriler ve farklı tarih biçimleri ancak gerçek dosyada görülebilir. Veri temizliğinin kim tarafından yapılacağını belirlemek teslim takvimini daha gerçekçi kurar.
Takvimi geri bildirim noktalarıyla kurun
Aylar sonra tek bir büyük teslim almak yerine, değerlendirilebilir ara çıktılar planlayın. Önce akış ve ekran taslağı, sonra çalışan temel işlem, ardından entegrasyon ve kabul turu görülebilir. Her aşamada kimin ne kadar sürede geri bildirim vereceği belli olsun.
Yeni istek geldiğinde onu yok saymayın; ilk sürüme etkisini görünür kılın. Eklenen iş hangi teslimi öteliyor veya hangi maliyeti değiştiriyor? Değişiklik kaydında gerekçe, karar veren kişi ve kabul edilen sonuç bulunsun. Böylece kapsam, konuşmalar arasında fark edilmeden büyümez.
Teklifleri değerlendirirken ekran sayısından çok bu çalışma biçimini karşılaştırın. Web projesi fiyatlarını değiştiren unsurlar, kapsam ile bedel arasındaki ilişkiyi okumak için yardımcı bir başlangıçtır.
Yayına çıkmak projenin son adımı değildir
İlk kullanıcıların eğitimi, erişimlerin teslimi, yedekleme düzeni ve sorun bildirim kanalı yayın planında yer almalıdır. Kaynak kod, lisanslar ve sistemden veri çıkarma koşulları da sözleşmede netleşmelidir. Hangi bakımın dahil, hangi geliştirmenin ayrıca ele alınacağı bilinmelidir.
Kariha’nın özel yazılım hizmetinde kapsamı gerçek iş akışı üzerinden değerlendiriyoruz. Fikrinizi uzun bir özellik listesine çevirmeden önce, bugün tamamlamakta zorlandığınız işi bize anlatın; ilk kullanılabilir sürümün sınırlarını birlikte belirleyelim.
