Mobil uygulama yaptırmak isteyen işletmeler genellikle önce ekranları ve özellikleri konuşur. Oysa ilk karar, uygulamanın kullanıcının hangi işini mevcut seçeneklerden daha kolay çözeceğidir. Bir randevu uygulaması için bu iş uygun saati bulup güvenle rezervasyon yapmak olabilir. Bu ana akış netleşmeden özellik listesi büyüdükçe geliştirme süresi ve maliyet artar.
1. Problemi ve kullanıcıyı tanımlayın
Uygulamayı kim kullanacak, bugün aynı ihtiyacı nasıl karşılıyor ve en çok hangi adımda zorlanıyor? Beş ila on gerçek kullanıcı görüşmesi yapın. Sadece “böyle bir uygulama kullanır mısın?” diye sormayın; son kez bu işi nasıl yaptığını anlatmasını isteyin. Sorun sık yaşanmıyorsa veya web üzerinden zaten kolayca çözülüyorsa mağaza uygulaması ilk seçenek olmayabilir.
2. İlk sürümün sınırını çizin
MVP, kullanıcının ana işi baştan sona tamamlayabildiği en küçük üründür. Randevu örneğinde arama, uygun saat, talep ve onay yeterli olabilir. Sohbet, sadakat puanı ve gelişmiş raporlama gibi fikirleri ayrı listeye alın. İlk sürüme her şeyi koymak yerine hangi varsayımı test edeceğinizi yazın: İnsanlar gerçekten rezervasyon yapıyor mu ve tekrar geliyor mu?
3. Tasarım ve altyapıyı birlikte planlayın
Ekran akışını çizip kullanıcıya deneyin. Sonra hesap yönetimi, veri saklama, bildirim, yönetim paneli ve dış servis ihtiyaçlarını belirleyin. Arayüz ile veri/iş mantığını birbirinden ayıran bir mimari, yeni özellikleri ve bakım işlerini kolaylaştırır. Hangi verinin kim tarafından görüleceğini de tasarım aşamasında kararlaştırın. Teknoloji seçimini yalnızca moda olduğu için yapmayın; hedef cihazlar, ekip becerisi ve bakım yükü önemlidir.
4. Test ederek yayınlayın
Geliştirme sırasında yalnızca mutlu yolu değil; bağlantı kesintisi, yanlış giriş, tekrarlanan ödeme, boş sonuç ve eski cihaz senaryolarını sınayın. Sınırlı bir kullanıcı grubuyla ilk sürümü deneyin. Uygulama mağazasına çıkmadan gizlilik metinleri, ekran görüntüleri, destek kanalı ve gerekli hesapları hazırlayın. Yayından sonra çökme kayıtlarını, ilk başarılı göreve ulaşma oranını ve geri dönüşleri izleyin.
Bütçeyi nasıl düşünmeli? Tek bir “mobil uygulama fiyatı” yoktur. Kapsam, tasarım, backend, entegrasyon, güvenlik, test ve sonraki bakım ayrı iş kalemleridir. Teklif alırken teslim edilecek ekranlar kadar kaynak kodu, hesapların sahipliği, hata düzeltme süresi ve yayın sonrası destek kapsamını da yazılı isteyin. İyi ilk sürüm, en kalabalık özellik listesiyle değil, çözdüğü sorunu gerçek kullanıcıda kanıtlamasıyla değerlendirilir.
Kaynak: Android Developers, Guide to app architecture; Firebase, Release Monitoring.