Mobil uygulama geliştirme süresi, ekran sayısından çok kullanıcı akışlarına, entegrasyonlara ve yayın koşullarına bağlıdır. Kapsamı belli olmayan bir uygulama için tek bir hafta sayısı vermek yanıltıcı olur. Kullanışlı bir takvim, hangi işin hangi karara bağlı olduğunu ve “tamamlandı” sayılması için neyin test edileceğini gösterir.
Bütçe tarafını mobil uygulama maliyet rehberinde ele alıyoruz. Burada amaç, geliştirme süresi ile mağazada yayına çıkma tarihini birbirinden ayırarak plan yapmaktır.
Takvimi beş teslimata bölün
- Kapsam ve kararlar: hedef kullanıcı, ana akış, ilk sürüm dışında kalanlar ve kabul kriterleri.
- Akış ve tasarım: normal kullanımın yanında boş, yükleniyor, izin reddi ve hata durumları.
- Çalışan ürün: veri saklama, servis bağlantıları ve uçtan uca çalışan ana akış.
- Doğrulama: cihaz testleri, güncelleme senaryosu, bağlantı kesintileri ve geri bildirim düzeltmeleri.
- Yayın hazırlığı: mağaza bilgileri, ekran görüntüleri, incelemeye erişim ve yayın sonrası kontrol.
Bu işler tamamen ardışık olmak zorunda değildir. Örneğin mağaza açıklamaları geliştirme sürerken hazırlanabilir. Ancak henüz kararlaştırılmamış hesap modeli üzerine ödeme akışı inşa etmek, sonradan yeniden iş yapma riski yaratır.
Örnek takvim nasıl okunmalı?
Aşağıdaki dağılım bir fiyat veya teslim taahhüdü değildir. Tek platformda çalışan, çevrimdışı metin kaydı ve listeleme sunan; üyelik, ödeme, bulut eşitleme ve AI içermeyen küçük bir prototip için varsayımsal planlama örneğidir. Deneyimli bir geliştirici, hazır tasarım kararları ve düzenli müşteri geri bildirimi varsayılır.
- İlk hafta: akış, veri modeli ve kabul senaryoları.
- İkinci ve üçüncü hafta: kayıt oluşturma, düzenleme, listeleme ve yerel saklama.
- Dördüncü hafta: cihaz testleri, hata düzeltmeleri ve teslim hazırlığı.
Bu dört haftalık örneğe mağaza onayı dahil değildir. Girdi koşulları değiştiğinde süre yeniden hesaplanır. Örneğin cihazlar arası eşitleme eklemek; hesap, çakışma çözümü, ağ hataları ve ek testler doğurur. Takvime yalnız bir ekran eklenmiş olmaz.
Entegrasyonları erken sınayın
Ödeme, harita, kimlik doğrulama veya AI servisi kritikse ilk çalışan denemeyi erkene alın. Gerekli hesap açılabiliyor mu, test ortamı erişilebilir mi, örnek istek beklenen sonucu veriyor mu? Bu soruların son haftada cevaplanması yayını geciktirebilir.
Nurena'nın yapım hikâyesinde analiz öncesinde metni yerel taslak olarak koruma kararını anlatıyoruz. Böyle bir davranış, “analiz ekranı” başlığının altında görünmeyen geliştirme ve test işini somutlaştırır. Buradaki takvim örneği Nurena'nın gerçek geliştirme süresi değildir.
Mağaza incelemesini ayrı bir aşama olarak planlayın
Kodun tamamlanması, uygulamanın mağazada görünmesiyle aynı şey değildir. Apple'ın App Review sayfası incelemeye hazır olma koşullarını açıklar. Google Play, işlemenin birkaç saatten yedi güne kadar sürebileceğini ve istisnalarda daha uzun olabileceğini belirtir. Bu süreyi proje için garanti kabul etmeyin. Google Play yayın ve inceleme rehberi.
Mağaza hesabı erişimini, gerekli test koşullarını ve inceleme ekibinin uygulamayı kullanabilmesini geliştirme başında kontrol edin. Kampanya tarihini, henüz alınmamış mağaza onayına kesin biçimde bağlamayın.
Gecikme riskini görünür kılın
Her haftalık değerlendirmede üç liste tutun: biten işler, karar bekleyen işler ve kapsam değişiklikleri. “Ödeme tamamlandı” yerine test hesabıyla satın alma, iptal ve başarısızlık senaryolarının sonucunu yazın.
Müşteri geri bildirimini kim topluyor ve son kararı kim veriyor, belirleyin. Tasarım, metin ve geliştirme için farklı kişiler çelişen yönlendirmeler yaptığında bekleme süresi de takvimin parçasına dönüşür. Yeni isteklerde etkilenen test ve teslim tarihini birlikte güncelleyin.
Sık sorulan sorular
İki platform süreyi ikiye katlar mı?
Her zaman değil. Paylaşılan kod bazı işleri azaltabilir; cihaz davranışları, izinler ve mağaza süreçleri yine ayrı doğrulama ister. Tek bir çarpan yerine platforma özel işleri listeleyin.
Sabit tarihe yetişmek için ne yapılabilir?
Önce temel kullanıcı sonucunu koruyarak kapsamı daraltın. MVP kapsamı rehberi bu ayrımı yapmanıza yardımcı olur. Testi kaldırmak, kapsamı küçültmekle aynı şey değildir.
Planı çıkarmak için ne hazırlamalıyım?
Ana akış, platform, entegrasyon, içerik ve karar sorumlusunu yazın. Mobil uygulama geliştirme hizmetimiz için görüşürken bu bilgileri proje brief'iyle paylaşabilirsiniz.