İş uygulaması projesinde ilk sürüm kapsamı nasıl belirlenir?

Özellik listesinden önce tamamlanacak işi seçin

“Mobil uygulama, yönetim ekranı ve raporlama istiyoruz” cümlesi yapılacak işleri sıralar; ilk sürümün hangi sorunu çözmesi gerektiğini henüz anlatmaz. Başlangıç için, bugün aksayan tek bir iş akışını seçip başlangıcını ve bitişini yazın. Bu rehberde bir şirket içi talebin açılması, takip edilmesi ve sonuçlandırılması üzerinden ilerliyoruz. Örnek temsilîdir; bir Ofelya müşteri projesi veya teslim taahhüdü değildir.

Örnek işletmede talepler farklı mesajlarda kalıyor ve çalışanlar son durumu öğrenmek için aynı soruyu tekrar soruyor. İlk sürümün amacı burada “bütün iş süreçlerini dijitalleştirmek” değil, bir talebin hangi aşamada olduğunu takip edebilmektir. Gerçek projenizde önce hangi işin öncelikli olduğunu, o işi yapan kişilerle birlikte belirleyin.

Kullanıcıyı, ihtiyacını ve amacını aynı cümlede birleştirin

GOV.UK Service Manual, kullanıcı hikâyesini kişinin kim olduğu, ne yapmak istediği ve bunun amacı üzerinden kurar. Özellik adını yazmak yerine bu üç parçayı birlikte düşünmek, konuşmayı kullanıcının ihtiyacına bağlar.

Temsilî hikâye şöyle olabilir: “Talep açan çalışan olarak, talebimin güncel aşamasını görmek istiyorum; böylece ilerleme bilgisi için farklı kişilere tekrar mesaj göndermeyeyim.” Aynı akışta talebi ele alan ekip açısından da ihtiyaç yazılır. Bu cümleler ekran tasarımı, cihaz tercihi veya teknik çözüm seçimi değildir. Kullanıcıların bugün ne yaptığını görüşmeden, varsayımı kesin ihtiyaç olarak kaydetmeyin.

• Kim: Bu işi günlük olarak yapan kişi veya ekip hangisi?
• Ne: Kullanıcının tamamlamak istediği eylem nedir?
• Neden: Bu eylem hangi iş ihtiyacına karşılık geliyor?

“Tamamlandı” demek için gözlenebilir sonuçları yazın

Aynı rehber, kabul ölçütlerini kullanıcı ihtiyacının karşılandığını gösteren sonuçlar olarak ele alır. “Takip ekranı yapılacak” gibi genel bir ifade yerine, görüşmede neyin gösterileceğini tarif edin. Aşağıdaki maddeler yalnız örnek akışın işletme açısından değerlendirilmesine yöneliktir; projenin bütün kabul koşullarını kapsamaz.

Bu örnekte talebin hangi aşamalarının bulunacağı ve sonuç notunun neyi açıklayacağı, uygulamayı kullanacak ekiple netleştirilir. “Hızlı”, “kolay” veya “eksiksiz” gibi kişiden kişiye değişebilen sıfatları tek başına kabul ölçütü yapmayın.

• Çalışan yeni talebini kaydettikten sonra kendi talep listesinde bulabiliyor.
• Talep ele alındığında, üzerinde anlaşılan aşama bilgisi talep görünümünde görülebiliyor.
• Tamamlanan talebin sonucu kayda ekleniyor ve çalışan bu sonucu okuyabiliyor.

İlk sürümü baştan sona bir akış olarak sınırlandırın

Temsilî örnekte yalnız talep açmayı tamamlayıp takip ve sonuçlandırmayı belirsiz bırakmak, seçtiğimiz iş ihtiyacının tamamını karşılamaz. İlk sürüm için konuşulan kapsamı üç satırda özetleyebilirsiniz: talebi açma, güncel aşamayı görme, sonucu okuma. Bu üç adımın birlikte ele alınması burada seçtiğimiz örneğe aittir; her iş uygulamasının aynı özelliklerle başlaması gerekmez.

Gelişmiş grafikler, ayrı bir mobil uygulama veya başka sistemlere bağlantılar isteniyorsa her birini ayrıca sorun: Seçtiğimiz akış bunlar olmadan tamamlanabiliyor mu? Gerçek kullanım bunlardan birine bağlıysa onu sırf listeyi kısaltmak için ertelemeyin. Bağlı değilse daha sonraki değerlendirmeye bırakmanın gerekçesini yazın. İlk sürüm sınırı, eksik kalan işleri görünmez kılmak için kullanılmamalıdır.

Önceliğin yanına gerekçeyi ve yeniden bakılacak zamanı ekleyin

GOV.UK’in önceliklendirme rehberi, kararları kullanıcı araştırması ve ekip katkısıyla desteklemeyi; yeni bilgi geldikçe yeniden değerlendirmeyi önerir. Öncelik listesi yalnız yeni özelliklerden oluşmaz: mevcut kullanımın devamı için gereken destek ve iyileştirmeler de değerlendirmeye girer.

Örneğimizde “haftalık grafik” için şu not yazılabilir: “İlk sürüm dışında; şu anki soru tek tek taleplerin durumunu görmek. Ekip ilk kullanım döneminde gerçekten toplu karşılaştırma ihtiyacı bildirirse yeniden değerlendirilecek.” Bu, bütün raporlamanın gereksiz olduğu anlamına gelmez. İhtiyaç, gerekçe ve yeniden değerlendirme koşulu aynı satırda tutulur; sonradan eklenen bir özellik kapsamın geri kalanından bağımsız kabul edilmez.

İlk proje görüşmesine net sınırlar ve açık sorularla gidin

Görüşme öncesi hazırlığınızda seçilen iş akışı, kullanıcı hikâyeleri, gözlenebilir kabul sonuçları ve ilk sürüm dışında bırakılan maddeler birlikte bulunsun. Henüz yanıtlanmayan konuları da listeleyin: hangi ekipler kullanacak, bugün hangi kayıtlarla çalışılıyor, başka bir sistemden bilgi gerekiyor mu? Bu soruların varlığı tek başına süre veya maliyet belirlemez.

Ofelya’nın mobil ve kurumsal iş uygulamaları ile entegrasyon ve süreç otomasyonu hizmetleri için talep oluştururken bu notları proje amacınızla birlikte paylaşabilirsiniz. Görüşme sonucunda kapsam, bağımlılıklar ve teslim beklentileri ayrıca değerlendirilir. Kaynaklardaki genel planlama yaklaşımı burada bir işletme örneğine uyarlanmıştır; belirli bir ürünün teknik tasarımını veya Türkiye’ye özgü bir uygunluk değerlendirmesini sunmaz.