Bir mobil uygulama ne kadar sürer sorusunun cevabını çoğu yazı “üç ila altı ay” diyerek geçiştirir, oysa bu cümle bir işletme sahibine neredeyse hiçbir şey anlatmaz. Biz bu yazıda takvimi hafta hafta açıyoruz, üç farklı büyüklükteki uygulamanın gerçek aritmetiğini gösteriyoruz ve ardından lansmanları asıl geciktiren tarafa geçiyoruz: Apple ile Google'ın, uygulamanız indirilebilir hale gelmeden önce sizden istediği hesaplar, formlar, hukuki sayfalar ve inceleme kuralları.
Kısa cevap, hafta cinsinden
Üç aralık veriyoruz ve üçü de gerçek projelerden çıkıyor. Beş ila sekiz ekranı olan, tek tip kullanıcı girişi bulunan ve ödeme almayan küçük bir uygulama 5 ila 8 haftada biter. Üyelik, ödeme, bildirim ve içeriği yöneteceğiniz bir yönetim paneli içeren standart bir işletme uygulaması 12 ila 16 hafta ister. Canlı takip, mesajlaşma ve dış sistem bağlantıları olan çok rollü bir platform ise 6 ila 9 aya yayılır.
Bu süreyi belirleyen şey ekibin ne kadar hızlı çalıştığı değil, uygulamanın kapsamıdır. Yani tarihi öne çekmenin tek gerçek yolu, uygulamanın içindekileri azaltmaktır, çünkü aynı işi daha az zamanda yapmanın bir yolu yoktur ama daha az iş yapmanın vardır.
Bize gelen müşterilerin çoğu “basit bir uygulama” diye tarif ettikleri şeyle aslında ortadaki basamağı tarif ediyor, çünkü üyelik sistemi, ödeme altyapısı ve bildirim gönderimi tek bir iş değil, birbirinden bağımsız üç ayrı iştir. Üçü birden isteniyorsa proje kendiliğinden standart sınıfa geçer.
Bu aralıkların hepsi tek bir varsayıma dayanıyor: kararların zamanında gelmesi. Pratikte en sık çöken varsayım da tam olarak budur, nedenini birazdan rakamlarla göstereceğiz.
Küçük, standart ve büyük uygulama neye göre ayrılır
Fikrinizi hiçbir teknik bilgiye ihtiyaç duymadan sınıflandırabilirsiniz. Üç şeyi sayın: kaç ekran var, kaç farklı tipte kullanıcı giriş yapıyor ve dışarıdaki kaç sisteme bağlanmanız gerekiyor. Ekran derken kullanıcının gördüğü her ayrı sayfayı kastediyoruz, yani giriş, liste, detay, sepet, profil gibi.
Somut bir örnek üzerinden gidelim: hastaların randevu aldığı, doktorların kendi takvimini gördüğü, hatırlatma bildirimi gönderen ve online ödeme kabul eden bir klinik uygulaması. Bu iş kağıt üzerinde sade görünür, ama saydığınızda 18 ila 22 ekran ve iki ayrı kullanıcı rolü çıkar, dolayısıyla küçük değil standart bir projedir ve doğrudan 12 ila 16 haftalık aralığa oturur.
Bir de şu var: personelin içerikleri, fiyatları ve randevuları yönettiği yönetim paneli, aslında birinci ürünün içine gizlenmiş ikinci bir üründür. Kendi ekranları, kendi yetki kuralları ve kendi testleri vardır, bu yüzden takvime tipik olarak 2 ila 3 hafta ekler. Tam kapsamlı bir işin nelerden oluştuğunu kalem kalem görmek isterseniz mobil uygulama geliştirme hizmetimizin içeriğine bakabilirsiniz.
Bir projenin beş aşaması ve her birinin gerçek zaman maliyeti
Bir uygulama beş aşamada kurulur: keşif ve yazılı şartname, arayüz tasarımı, geliştirme, test ve düzeltme, en sonda da mağaza hazırlığı ile inceleme. Standart 14 haftalık bir projede bu aşamalar aşağıdaki gibi dağılır.
Keşif aşamasında ne yapıldığı çoğu zaman yanlış anlaşılır, çünkü burada toplantı yapılmaz, karar yazılır. Her ekran listelenir, her kural cümleye dökülür, “kullanıcı ödemeyi yarıda bırakırsa ne olacak” türünden sorular tek tek cevaplanır. Bunu iki haftada yapmamızın nedeni basit: dokuzuncu haftada karar icat etmek, aynı kararı en baştan yazmanın kabaca beş katına mal olur.
Tasarımın geliştirme başlamadan bitmesi de tarihi koruyan asıl unsurdur, çünkü bir ekranı çizim aşamasında değiştirmek birkaç saat sürerken, kodlandıktan sonra değiştirmek yaklaşık üç katı zaman ister. Ekran çizimlerini onaylarken acele etmeyin, asıl tasarrufu tam olarak orada yaparsınız.
Saatler nereye gidiyor, kodlama neden işin yarısından azı
Toplam eforu böldüğümüzde ortaya çıkan tablo çoğu kişiyi şaşırtıyor: yaklaşık yüzde 45 geliştirme, yüzde 18 test ve düzeltme, yüzde 15 tasarım, yüzde 12 ödeme ya da kargo gibi dış sistemlere bağlanma ve yüzde 10 mağaza uyumluluğu ile gönderim evrakı. Yani kod yazmak, işin yarısından bile azıdır.
Test kısmını gündelik dille anlatalım: aynı uygulamanın hem ekranı çatlamış eski bir Android telefonda hem de en yeni iPhone'da düzgün çalışması gerekir. Arada onlarca cihaz ve işletim sistemi sürümü kombinasyonu vardır ve her biri ayrı ayrı denenir. Bu yüzden test haftalarını kısmak, kulağa hoş gelen ama pahalıya patlayan bir tasarruftur. Lansman günü yaşanan tek bir çökme, kazandığınız iki haftaya karşılık kötü yorumlar, iade talepleri ve yeniden kazanılması gereken bir güven bırakır.
Apple ve Google yayına almadan önce ne istiyor
Önce hesaplar. Apple Developer Program üyeliği yılda 99 ABD doları, Google Play Console kaydı ise tek seferlik 25 ABD dolarıdır. İkisi de şirket adına açılmalıdır, bir çalışanın kişisel hesabına değil, çünkü o kişi ayrıldığı gün uygulamanın sahipliği tartışmalı hale gelir ve bunu sonradan düzeltmek haftalar alır.
Şirket hesabı açarken D-U-N-S numarası denen uluslararası işletme kimlik numarası istenir ve buna belge kontrolü eşlik eder. Bu doğrulama tipik olarak 3 ila 14 gün sürer, üstelik tamamen sizin dışınızdaki bir kurumun hızına bağlıdır, bu yüzden projenin birinci gününde başlatılması gerekir.
Ardından evraklar geliyor. Kendi web sitenizde yayında duran bir gizlilik politikası, uygulamanın gerçekte topladığı verilerle birebir örtüşen bir veri ve gizlilik formu, bir yaş sınırı beyanı ve çalışan bir destek iletişim kanalı şarttır. Formu doldururken tahminle ilerlemeyin, uygulamanın hangi veriyi neden sakladığını teknik ekibinizle satır satır teyit edin. Siber güvenlik tarafındaki ekibimiz bu noktada devreye girer ve beyanınızın uygulamanın gerçek davranışıyla uyuştuğundan emin olur.
Bir de insanları en çok yakalayan kurallar var. Kullanıcı uygulamanın içinden hesap açabiliyorsa, her iki mağaza da hesabı yine uygulama içinden silebilme imkanını zorunlu tutar. Google veya Facebook ile giriş sunuyorsanız Apple genellikle kendi giriş yöntemini de sunmanızı bekler. Avrupa'da satış yapıyorsanız tacir iletişim bilgilerinizi beyan edip yayınlamanız gerekir, aksi halde uygulamanız Avrupa mağazalarında reddedilmez bile, sadece hiç görünmez.
Mağaza sayfası, kimsenin bütçesine koymadığı iş
Gönderimden önce hazır olması gereken görsel ve metin listesi şudur: 1024 piksel kare uygulama simgesi, zorunlu her telefon ve tablet boyutu için ekran görüntüleri, her boyut için en fazla on adet, Google Play tarafında 1024 x 500 piksellik bir öne çıkan görsel, yaklaşık 80 karakterlik kısa açıklama, 4000 karaktere kadar uzun açıklama ve kendi sitenizde barındırılan gizlilik politikası.
Bunların hepsini düzgün yazmak ve çekmek 3 ila 5 iş günü alır. Üstelik uygulamayı satan şey ajansın cümleleri değil sizin kelimelerinizdir, bu yüzden bu işi lansmandan önceki son cumaya bırakmayın.
Bir de inceleme hesabı meselesi var. Uygulamanızda giriş varsa, Apple ve Google'a çalışan bir test kullanıcısı ile şifresini vermek zorundasınız. Eksik veya süresi dolmuş bir test hesabı, ret sebeplerinin en yaygınlarından biridir ve tamamen önlenebilir bir hatadır. İyi haber şu ki mağaza metinleri sonradan düzenlenebiliyor, dolayısıyla ilk listelemenin iyi olması yeterli, kusursuz olması gerekmiyor.
İnceleme ne kadar sürer ve uygulamalar neden reddedilir
Pratikte gördüğümüz süreler şöyle: Apple gönderimlerinin çoğu 24 ila 48 saat içinde cevaplanır, ancak yeni bir hesaptan gönderilen ilk uygulama çoğu zaman 2 ila 5 gün alır. Google Play tarafında yeni bir hesabın ilk yayını 7 güne kadar uzayabilir, sonraki güncellemeler ise genelde saatler içinde geçer.
İnsanları hazırlıksız yakalayan bir kural daha var. Yeni açılmış kişisel bir Google Play hesabının halka açık yayına geçebilmesi için, önce en az 12 test kullanıcısının 14 gün boyunca kesintisiz kayıtlı kaldığı kapalı bir test yürütmesi gerekir. Tek başına bu şart lansmanı iki hafta öteler ve hiçbir geliştirme takvimi bu iki haftayı içermez, bu yüzden hesap tipini projenin ilk günü konuşmak gerekir.
Dürüst olalım: Linkysoft olarak deneyimimizde ilk gönderimlerin kabaca üçte biri en az bir notla geri dönüyor. Bu bir felaket değil, sürecin normal bir adımıdır, çünkü düzelt ve yeniden gönder döngüsü tipik olarak 2 ila 5 gün sürer. Gelen notlar da hemen her zaman aynı beş başlıkta toplanır:
- İncelemeyi yapan kişinin cihazında yaşanan bir çökme.
- Eksik ya da süresi dolmuş bir inceleme test hesabı.
- Uygulamanın gerçek davranışıyla örtüşmeyen gizlilik cevapları.
- Hesabı uygulama içinden silmenin bir yolunun bulunmaması.
- Dijital içerik satışının mağaza dışında tahsil edilmesi.
En sık gördüğümüz gecikmeler ve her birinin bedeli
Sıralamanın başında ödeme kuruluşu ve üye iş yeri onayı var, çünkü bu tamamen bankanın ve ödeme sağlayıcısının takvimine bağlıdır. Hemen ardından geliştirme sırasında eklenen yeni istekler geliyor, sonra müşteriden beklenen fotoğraf ve metinler, geliştirici hesabının kimlik doğrulaması ve en sonda bir mağaza reddi ile yeniden gönderim döngüsü.
Beklemenin maliyetini aritmetikle anlatmak istiyoruz, çünkü böylesi çok daha çabuk yerine oturuyor. Üç kişilik bir ekip bir hafta boyunca cevap bekliyorsa, bu 15 iş günü ödenmiş kapasitenin hiçbir şey üretmemesi demektir. Cevapsız kalan tek bir soru, çoğu projede kalemi en pahalı satırdır.
Kapsam eklemelerinin biriken etkisi de aynı mantıkla işler. “Küçük bir ekleme” dediğiniz her özellik, tasarımı, kodu, testi ve etrafındaki ekranların yeniden kontrolü sayıldığında 1,5 ila 3 iş gününe mal olur. Beş tane küçük ekleme, kimse fark etmeden takvime iki hafta ekler ve bu iki hafta sonradan kimsenin hatırlamadığı bir yerden gelir.
Tek kod tabanı mı, iki ayrı uygulama mı
Çapraz platform, tek bir kod setinden hem iPhone hem de Android uygulaması üretmek demektir. İki uygulamayı ayrı ayrı yazmaya kıyasla geliştirme haftalarının tipik olarak yüzde 25 ila 35 kadarını kazandırır, üstelik bu kazanç yayından sonra da sürer, çünkü her düzeltme iki kez değil bir kez yazılır.
Yerel geliştirmenin, yani her iki telefon için ayrı ayrı kod yazmanın bu ek süreye değdiği durumlar da var: yoğun kamera veya video işleme, sürekli arka plan konum takibi, cihazın derin donanım özelliklerini kullanan işler ve oyunlar. Bunların dışında, yani randevu, sipariş, üyelik, teslimat ve şirket içi iş uygulamalarının neredeyse tamamında doğru cevap çapraz platformdur, Linkysoft olarak da uzun yolu satmak yerine bunu açıkça söylüyoruz.
Şunu da net söyleyelim: bu yazıdaki mağaza şartlarının hiçbiri teknoloji seçimine göre değişmez. Hangi yolu seçerseniz seçin uyumluluk işi aynıdır, dolayısıyla teknoloji tercihi mağaza tarafındaki takvimi asla kısaltmaz.
Daha küçük bir lansmanın gerçekten doğru karar olduğu durumlar
Bazen en iyi tavsiye, uygulamayı şimdilik ertelemektir. Eğer fikir esas olarak bilgi göstermek ve randevu ya da sipariş almaksa, mobil uyumlu hızlı bir web sitesi her telefona aylar değil günler içinde ulaşır ve hiçbir mağaza onayına ihtiyaç duymaz. Web tasarım ve geliştirme tarafında bunu sık sık ilk adım olarak öneriyoruz, çünkü müşterinin parasını korumak bizim işimizin bir parçası.
İkinci seçenek uygulamayı küçültmektir. 22 ekranlık bir ilk sürümü 9 ekrana indirip 15 hafta yerine 7 haftada yayına çıkabilir, geri kalanını gerçek kullanıcılar hangi bölümleri kullandığını gösterdikten sonra ekleyebilirsiniz. Bunun asıl faydası hız değil bilgidir, çünkü tahmin üzerine özellik inşa etmek yerine gerçek davranış verisi toplamaya başlarsınız. Benzer kararların nasıl sonuçlandığını vaka çalışmalarımızda adım adım görebilirsiniz.
Lansman tarihinizi korumak için bugün başlayabilecekleriniz
Aşağıdakilerin hepsi sizin elinizde ve hiçbiri tek satır kod yazılmasını beklemez:
- Her iki mağaza hesabını da bugün şirket adına açın, kimlik doğrulaması arka planda ilerlesin.
- Web sitenize bir gizlilik politikası ve bir destek sayfası koyun, ikisi de gönderim anında yayında olmalı.
- Bir gün içinde nihai kararı verebilecek tek bir yetkili belirleyin, komite değil.
- İçeriği erkenden toplayın: gerçek fotoğraflar, gerçek ürün ve hizmet açıklamaları, fiyat ve şartların tam metni.
Ödeme sağlayıcısı ve banka evraklarını da birinci haftada başlatın, çünkü onay süreci kimsenin kontrolünde değildir ve yaygın olarak 1 ila 3 hafta sürer. Bir lansman tarihinin en çok bu tür dış onaylar yüzünden kaydığını görüyoruz, oysa hepsi projenin ilk gününde başlatılabilecek işlerdir.
Lansmandan sonra: ilk doksan gün ve yıllık takvim
İlk 30 günde 2 ila 4 küçük güncelleme çıkarmayı bekleyin. Bu, işin kötü gittiğinin değil sağlıklı gittiğinin işaretidir, çünkü gerçek kullanıcılar hiçbir test ekibinin bulamayacağı şeyleri her zaman bulur ve bunları ilk haftalarda bulmaları en iyi senaryodur.
Sonrasında yıllık bir ritim başlar. Her sonbaharda yeni telefon işletim sistemleri çıkar ve her iki mağaza da yılda bir kez uygulamanızın uyumlu olması gereken asgari sürümü yükseltir. Bir yıl boyunca hiç dokunulmayan bir uygulama, bir noktadan sonra ciddi bir yeniden çalışma yapılmadan güncellenemez hale gelir, bu yüzden bakımı erteleyen her karar bileşik faizle geri döner.
Bütçe için basit bir kural verelim: her yıl, geliştirme maliyetinin kabaca yüzde 15 ila 20 kadarını bakım, barındırma, mağaza ücretleri ve küçük iyileştirmeler için ayırın. Kendi fikriniz için gerçekçi bir tarih çıkarmamızı isterseniz ekranları ve rolleri birlikte sayalım, Linkysoft ekibi size hafta hafta bir plan hazırlasın, bunun için tek yapmanız gereken bize ulaşmak.
