İki mobil uygulama teklifi aynı ekran sayısını yazsa bile aynı ürünü teslim etmeyebilir. Birinde yalnızca arayüz ve test paketi, diğerinde çalışan servis bağlantıları, mağaza başvurusu ve bakım bulunabilir. Teklifleri karşılaştırmadan önce uygulamanın ilk sürümünde kimin hangi işi yapacağını ve teslimi hangi senaryolarla kabul edeceğinizi belirleyin.
İlk sürümde kullanıcı hangi işi bitirecek?
Özellik listesinden önce kullanıcı yolculuğunu yazın: kişi uygulamaya nasıl giriyor, temel işlemi nasıl tamamlıyor, hata aldığında nasıl devam ediyor? İlk sürüm için zorunlu akışları ve sonraya bırakılabilecek fikirleri ayırın. Her akışın başlangıcını, bitişini ve yönetim tarafında oluşturduğu kaydı tarif edin.
Teklifte iOS, Android veya ikisinin birden kapsamda olduğu; telefon ve tablet desteği; dil seçenekleri; çevrimdışı kullanım gerekip gerekmediği açıkça yazmalı. Tasarım onayı, çalışan uygulama ve mağazada yayımlanma ayrı teslim aşamaları olarak görünmeli.
- İlk sürümde tamamlanacak üç temel kullanıcı akışı hangileri?
- Hangi ekranlar tasarlanacak, hangileri mevcut bir sistemden beslenecek?
- Kapsam dışı kalan özellikler ve sonraki sürüm kararları nerede kaydedilecek?
Uygulama hangi sistemlere bağlanacak?
Giriş, ödeme, bildirim, harita, CRM veya yönetim paneli bağlantılarını tek kelimelik “entegrasyon” kalemi altında bırakmayın. Her bağlantı için veri kaynağını, kullanılacak hesabı, gerekli API erişimini ve geliştirme ortamını belirtin. Var olan bir servis yoksa bunun ayrıca geliştirilip geliştirilmeyeceği teklifte görünmeli.
Örnek bir akışta bağlantı kesilirse, kullanıcı aynı işlemi tekrar denerse veya eski uygulama sürümü servise bağlanırsa ne olacağını konuşun. Bu koşullar için beklenen uygulama mesajını ve sunucu tarafındaki kaydı kabul ölçütüne ekleyin.
Tasarım ve teknik seçim nasıl değerlendirilmeli?
Teklifte ekran çizimleri ile etkileşimli akışın ne zaman onaylanacağı, gerçek içerik ve farklı ekran boyutlarıyla nasıl deneneceği yer almalı. Geliştirme yaklaşımı seçilirken yalnız teknoloji adını değil, ihtiyaç duyulan cihaz özelliklerini, mevcut ekibin bakım kapasitesini ve güncelleme yöntemini değerlendirin.
Kaynak kodu, tasarım dosyaları, kullanılan kütüphaneler, dış servisler ve derleme adımları teslim listesinde ayrı kalemler olmalı. Böylece sonraki geliştirmenin hangi dosya ve hesaplara bağlı olduğu proje bitmeden anlaşılır.
Test için hangi kanıtları isteyeceksiniz?
Her temel akışın başarılı ve hatalı durumunu örnek verilerle deneyin: yeni kullanıcı, yanlış giriş, eksik bağlantı, izin verilmemiş bildirim ve tekrar edilen işlem gibi. Test edilen cihazları ve işletim sistemi sürümlerini, bulunan sorunları ve yeniden test sonucunu kaydedin. Bir ekran görüntüsü, çalışan akışın kanıtı değildir.
Apple, TestFlight üzerinden beta sürümleri test kullanıcılarına dağıtmayı ve geri bildirim toplamayı destekliyor. Google Play Console da iç ve kapalı test kanalları sunuyor. Teklifte test paketini kimin hazırlayacağı, test kullanıcılarını kimin davet edeceği ve geri bildirimin hangi sürümde düzeltileceği yazmalı.
Mağaza hesapları ve yayın sorumluluğu kimde?
App Store Connect ve Play Console hesaplarının hangi işletmeye ait olacağını, ajansa hangi yetkilerin verileceğini ve iş sonunda erişimlerin nasıl gözden geçirileceğini başta belirleyin. Her iki platform ekip üyelerine rol ve izin tanımlamaya izin verir. Bu, yayın işini yürütmek için hesap sahipliğini belirsiz bırakmayı gerektirmez.
Mağaza açıklaması, ekran görüntüleri, yaş veya içerik beyanları, gizlilik bilgileri ve inceleme için gereken test erişimi kimin işi? Apple, uygulama gizliliği açıklamalarının uygulama ve üçüncü taraf kodlarının veri kullanımını yansıtmasını istiyor; Google Play de Veri güvenliği bölümünde veri toplama ve paylaşma beyanları istiyor. Bu bilgileri teknik ekiple işletme birlikte doğrulamalı.
Apple başvurusunda gerekli bilgiler ve doğru sürüm paketi hazırlandıktan sonra uygulama incelemeye gönderiliyor. Google Play tarafında test ve üretim kanalları ile bazı yeni bireysel geliştirici hesaplarına özel üretime erişim koşulları var. Teklif, mağaza onayını kesin tarih veya garanti olarak sunmamalı; başvuru, olası düzeltme ve yeniden gönderim sorumlusunu göstermeli.
Teslim ve yayın sonrası destek nerede bitiyor?
Kabul listesinde çalışan test sürümü, kararlaştırılmış kullanıcı akışları, kaynak ve tasarım dosyaları, mağaza kayıtları, hesap erişimleri, açık hata listesi ve kısa işletim notu bulunsun. Yayında görülen sürüm ile kabul edilen test sürümünün aynı kapsamı taşıdığını ayrıca kontrol edin.
Yayın sonrası hata düzeltme süresi, yeni işletim sistemi sürümlerine uyum, üçüncü taraf servis değişiklikleri ve yeni özellik istekleri için ayrı sorumluluklar tanımlayın. Böylece ilk teslimin sınırı ile sonraki bakım işi tekliflerde karşılaştırılabilir hâle gelir.
Konuyla ilgili kısa cevaplar
Mobil uygulama teklifi mağazada yayını da kapsar mı?
Kendiliğinden kapsamaz. Hesap hazırlığı, mağaza içerikleri, başvuru ve inceleme sonrası düzeltmelerin hangilerinin dahil olduğunu yazılı isteyin.
iOS ve Android için tek bir test yeterli mi?
Hayır. Kapsamdaki iki platformda da temel akışları ve kararlaştırılmış cihaz koşullarını ayrı ayrı doğrulayın.
Uygulama ne zaman teslim edilmiş sayılır?
Kararlaştırılan akışlar kabul testinden geçtiğinde, kod ve hesap erişimleri devredildiğinde, açık sorunlar ve yayın sonrası sorumluluklar kayda alındığında.