Mobil Uygulama Geliştirme

Hayır. Mobil uygulama yaptırmak, kullanıcının aynı işi tekrar tekrar yapacağı durumlarda anlam kazanır: sipariş, rezervasyon, üyelik, takip, sadakat programı ya da saha ekibinin kullandığı iç araçlar. Bildirim göndermek, çevrimdışı çalışmak ya da kamera ve konum gibi cihaz özelliklerini kullanmak gerekiyorsa uygulama doğru araçtır.

Karar verirken şu soruyu sorarız: kullanıcının bu uygulamayı telefonunda tutması için bir nedeni var mı? Çok seyrek yapılan bir işlem için uygulama indirilmez; sık açılan bir araç içinse uygulama, tarayıcıdan daha rahat bir deneyim sunar.

Amaç yalnızca tanıtım ve bilgi vermekse iyi kurulmuş bir web sitesi daha hızlı ve daha ekonomik bir çözümdür. Keşif görüşmesinde bunu açıkça söyleriz; ihtiyacınız olmayan bir uygulamayı size önermeyiz. Kimi zaman doğru yanıt ikisinin birleşimidir: tanıtım ve içerik web sitesinde, tekrar eden işlem uygulamada.

Müşteri projelerinin yanında kendi ürünlerimizi de geliştiriyoruz. Seyahat uygulamamız Valiz ve film-dizi takip uygulamamız İZ, App Store'da yayında. iOS uygulama geliştirme sürecini fikirden mağaza yayınına kadar kendi ürünlerimizde yaşadık. Bu deneyim bize bir uygulama geliştirme ajansı olarak sunum dosyalarında görünmeyen işleri öğretti: mağaza inceleme süreci, gizlilik beyanları, sürüm notları, kullanıcı geri bildirimi ve yayından sonra gelen güncelleme ihtiyacı.

Bir uygulamanın işi mağazaya girdiği gün bitmez, o gün başlar. İşletim sistemleri güncellenir, kullanıcılar eksik bulduklarını yorumlara yazar, ölçümler hangi ekranın terk edildiğini gösterir. Projeleri bu yüzden ilk sürümle sınırlı düşünmüyor, bakım ve sürüm yönetimini baştan plana koyuyoruz.

Kendi ürününü yayınlayan bir ekip, verdiği kararların sonucunu da kendisi yaşar. Bu yüzden müşteri projelerinde yalnızca istenen ekranları değil, yayın sonrasını da düşünürüz: kullanıcı ilk açılışta ne görecek, hangi izin ne zaman istenecek, bir sonraki sürümde ne eklenecek?

İlk sürümü bilerek dar tutarız. Fikrin özünü taşıyan temel akışı eksiksiz çalıştırmak, yarım kalmış çok sayıda özellikten daha değerlidir; geri kalan özellikler gerçek kullanıcı davranışı görüldükten sonra sıraya alınır.

Tasarım aşamasında tıklanabilir bir prototip hazırlarız; geliştirme başlamadan önce akışı dener, eksik ya da gereksiz adımları o aşamada görürsünüz. Bu, sonradan yapılacak değişikliklerin maliyetini düşürür. İlk sürümle birlikte şunlar teslim edilir:

• Kullanıcı akışları ve tıklanabilir prototip
• Markanıza özel arayüz tasarımı
• Üzerinde anlaşılan platformlar için geliştirilmiş ve test edilmiş uygulama
• Gerekli entegrasyonlar: API, bildirim, ödeme, analitik ve ihtiyaç varsa yapay zekâ özellikleri
• Mağaza sayfası hazırlığı: ekran görüntüleri, açıklama metinleri ve gizlilik bilgileri
• Mağaza başvurusu ve yayın sürecinin yönetimi

Mobil uygulama maliyeti için tek bir rakam vermek yanıltıcı olur; birkaç ekranlı bir araç ile üyelik ve ödeme içeren bir platform aynı iş değildir. Teklifi keşif aşamasından sonra, kapsam yazılı hale geldiğinde veririz.

Maliyeti en çok etkileyen karar çoğu zaman kapsamın kendisidir. Bu yüzden keşif aşamasında özellikleri 'ilk sürümde olmalı' ve 'sonraya kalabilir' diye ayırır, bütçenizi önce uygulamanın asıl işini yapan bölüme yönlendiririz. Başlıca etkenler şunlardır:

• Ekran sayısı ve akışların karmaşıklığı
• Platform: yalnızca iOS, yalnızca Android ya da ikisi birden
• Sunucu tarafı ihtiyacı: üyelik, veri tabanı, yönetim paneli
• Entegrasyonlar: ödeme, harita, bildirim, yapay zekâ ve üçüncü taraf servisler
• Tasarımın özgünlük düzeyi ve animasyonlar
• Yayın sonrası bakım ve güncelleme kapsamı

Mağaza onayını ve onay süresini biz belirlemiyoruz; Apple ve Google her başvuruyu kendi kurallarına göre inceler ve değişiklik isteyebilir. Kuralları gözeterek geliştirir, ret riskini azaltırız, ama sonucu garanti edemeyiz.

İndirme sayısı ya da gelir sözü de vermiyoruz. İyi bir uygulama kendiliğinden kullanıcı bulmaz; tanıtım, mağaza sayfası optimizasyonu ve reklam ayrı bir çalışmadır. Bunu proje başında konuşur, yayın sonrası için gerçekçi bir plan yapmanıza yardımcı oluruz.

Süre için de aynı açıklık geçerlidir: takvimi keşif sonrasında veririz ve kapsam değişirse takvimin de değişeceğini baştan söyleriz. Geliştirme boyunca ilerlemeyi çalışan sürüm üzerinden görmenizi sağlarız; böylece sürprizler teslim gününe kalmaz.