Mobil Uygulama Geliştirme Süreci Kaç Aşamadan Oluşur?
Beş aşama vardır: keşif, tasarım, geliştirme, test ve mağaza yayını. Aşamalar sırayla değil, kısmen üst üste ilerler. Toplam takvimi belirleyen şey aşama sayısı değil, her aşamada verilen karar sayısıdır. Mobil uygulama geliştirme süreci kararsızlıkla uzar, kapsamla değil. Bekleyen tek bir onay, iki haftayı yiyebilir.
Aşamaları bir çizgi gibi düşünmek yanıltır. Tasarım bitmeden geliştirme başlar, geliştirme sürerken test yürür. Bu binişme takvimi kısaltır ama tek şartla: kararlar zamanında çıkarsa.
Aşağıdaki sıra bizim yürüttüğümüz düzendir. Süreç boyunca geliştirme ekibi ve sizin tarafınız aynı panoyu görür.
- Keşif — sorun, kullanıcı, ekran envanteri.
- Tasarım — akış, ekranlar ve durum çizimleri.
- Geliştirme — iki haftalık turlar hâlinde yapım.
- Test — turların içinde, ayrı bir blok değil.
- Mağaza yayını — inceleme ve düzeltme payı.
Takvimi Asıl Ne Uzatır?
Kod değil, bekleyen karar. Onay bekleyen bir ekran, iki haftalık turu tek başına boşa çıkarabilir. Bu yüzden ilk oturumda karar verecek kişiyi belirleriz. Yetkisi olmayan bir muhatap, geliştirme sürecinin en pahalı gecikme kaynağıdır.
Keşif ve Kapsam Aşaması Ne Kadar Sürer?
Bu aşama genelde bir ila iki hafta sürer. O sürede sorun tanımı, kullanıcı akışı ve ekran envanteri çıkar. Kısa görünen bu aşama, sonraki aşamaların hepsini kısaltır. Geliştirme süreci boyunca en çok bu belgeye geri döneriz. Atlanırsa tasarım aşaması rahatça iki katına çıkar.
Keşif oturumunda ekran çizmeyiz. Bugün işin nasıl yürüdüğünü, nerede tıkandığını ve kimin hangi kararı verdiğini konuşuruz. Çıktı bir sayfadır: sorun, kullanıcı, kullanım sıklığı, olmazsa olmaz ekranlar ve dış servisler.
Bu sayfayı görüşmeye kendiniz getirdiyseniz aşama üç güne iner. Hangi soruların yanıtlanması gerektiğini uygulama yaptırma soruları yazısında tek tek saymıştık.
Keşfi kısaltmak isteyenler genelde onu tümüyle atlamayı dener. Sonuç hep aynı çıkar: tasarım aşaması, keşifte sorulmayan soruları sormakla geçer. Süreyi geliştirme tarafında kazanmaya çalışmak, en başta kaybetmek demektir.
Keşif Çıktısı Neye Benzer?
Kalın bir şartname değil, tek sayfa. Uzun belgeler okunmadığı için karar hızını düşürür. Tek sayfa herkesin aklında kalır ve mobil uygulama geliştirme süreci boyunca ortak dil olur.
Tasarım Aşamasında Neler Üretilir?
Bu aşama üç çıktı verir: akış şeması, ekran tasarımları ve durum çizimleri. Üçüncüsü çoğu teklifte unutulur ama takvimi en çok o belirler. Boş liste, kopuk bağlantı ve zaman aşımı ekranları burada çizilmezse iş geliştirmeye kayar. Orada çözmek daha uzun sürer. Tasarımın işi ekranı güzelleştirmek değil, kararı önceden vermektir.
Tipik uzunluk iki ila dört haftadır. Ekran sayısı arttıkça değil, durum sayısı arttıkça uzar. On ekranlı ama her ekranı dört hâlli bir ürün, yirmi ekranlı bir katalogdan uzun sürer.
Arayüz kararlarının hangi ilkelere dayandığını arayüz tasarımı ilkeleri yazısında ele aldık. Tasarım bittiğinde geliştirme için çizilmemiş ekran kalmamalı.
Durum çizimlerini atlamak takvimi iki yerden birden vurur. Önce geliştirici tahmin yürütür, sonra siz o tahmini beğenmezsiniz. Sürecin ortasında geliştirme ekibinin ekran tasarlaması, hem yavaş hem tutarsız bir yol açar.
Onay Turları Kaç Kez Döner?
İki tur normaldir, üçüncü tur uyarıdır. Üçten fazla dönüyorsa sorun tasarımda değil, keşifte eksik kalmış bir karardadır. O zaman bir adım geri gideriz.
Geliştirme ve Test Aşaması Nasıl İlerler?
İki hafta uzunluğunda turlar hâlinde ilerler. Her tur sonunda çalışan bir sürüm elinize geçer, yorumunuzu alırız. Test ayrı bir aşama değil, her turun içindedir. Geliştirme süreci bu ritimle yürüdüğünde sürprizler sona değil, ortaya yayılır. Sonda toplanan sürpriz her zaman daha pahalıdır.
Her yineleme sonunda cihazınıza kurulabilen bir sürüm göndeririz. Ekranda görmek, belgede okumaktan farklıdır; yorumlarınız da o zaman keskinleşir. Tipik uzunluk kapsama göre altı ila on altı hafta arasında değişir.
Donanıma yakın çalışma gerekiyorsa takvim genişler. Kamera, sensör ve arka plan konumu gibi ihtiyaçları iOS ve Android tarafında ayrı ayrı ele alırız. Mimari seçimini native mi cross-platform mı yazısında tarttık.
Test Neden Ayrı Bir Blok Değil?
Sona bırakılan test, hataları en pahalı anda toplar. Her turun içine yayıldığında hata çıktığı gün düzelir. Bu düzen mobil uygulama geliştirme süreci içinde en çok zaman kazandıran alışkanlıktır.
Mağaza Yayını Neden Tahmin Edilenden Uzun Sürer?
İnceleme teknik bir sınav değil, kural denetimidir. Apple ve Google; gizlilik metni, izin gerekçeleri ve hesap silme akışına ayrı ayrı bakar. İlk gönderimde ret almak olağandır. Bu yüzden geliştirme süreci takvimine yayın için bir hafta pay koyarız. Payı koymayan ekipler lansman tarihini iki kez erteler.
En Sık Ret Nedenleri Nelerdir?
Yayın denetimi çoğu zaman birkaç gün sürer, ama ret gelirse süre baştan işler. En sık ret nedenleri şaşırtıcı biçimde basittir: eksik gizlilik metni, gerekçesiz izin isteği, hesap silme yolunun bulunmaması.
Bunları geliştirme başlarken hazırlarsanız yayın günü sürprize dönüşmez. Mağaza sayfasının kendisi de ayrı bir iştir; başlık, görseller ve açıklama indirme oranını doğrudan etkiler.
İki mağazanın ritmi de aynı değildir. Biri aynı gün yanıt verirken diğeri birkaç gün bekletebilir; bu yüzden tek bir yayın tarihi yerine bir yayın haftası konuşuruz. Geliştirme süreci planında bu haftayı işaretlemek, lansman iletişimini de rahatlatır. Reddedilme sebepleri tahmin değil yazılı kuraldır; App Store inceleme kılavuzu hepsini sıralar.
“Kullanıcıları daha iyi koruyabilmek için uygulamalarınızı ayrıntılı olarak incelemek istediğimizden bazı geliştirici hesaplarında bu işlem normalden daha uzun sürecektir. Bu, uygulamanın incelenmesinin yedi gün kadar veya istisnai durumlarda daha uzun sürmesine yol açabilir.”
— Play Console Yardım, Uygulamanızı yayınlama
Takviminizi Birlikte Çıkaralım
Takvim, kapsam netleştiği anda gerçekçi olur. Görüşmede aşamaları, onay noktalarını ve kimin ne zaman karar vereceğini birlikte yazıyoruz. Elinizde tahmini bir süre değil, tarihli bir plan kalıyor. Mobil uygulama geliştirme süreci böyle kurulduğunda gecikmenin kaynağı da baştan görünür. Gecikme çoğu zaman koddan değil, bekleyen onaydan gelir.
Planı çıkarırken hangi kalemin bütçeyi hareket ettirdiğini de aynı masada konuşuruz; ikisini uygulama maliyeti yazısında ayrı ayrı açtık. Mobil uygulama hizmetimizi incelemek isterseniz sayfa hep açık.
Hangi Üç Tarih Takvimi Taşır?
Planı çıkarırken üç tarihi işaretleriz. Keşif çıktısının onaylandığı gün, tasarımın kilitlendiği gün ve mağazaya ilk gönderim günü. Bu üç tarih tutarsa geri kalanı kendiliğinden tutar. Mobil uygulama geliştirme süreci içinde en çok kayan tarih ikincisidir. Tasarım kilidi geciktiğinde her şey birlikte kayar. Kilidi korumak için onay süresini iki iş gününe bağlarız. Kısa bir kural gibi görünür ama takvimi tek başına ayakta tutar.
Aşama başına tipik uzunluk ve takvimi uzatan neden
Tipik bir mobil uygulama projesi keşiften mağaza yayınına yaklaşık 9-24 hafta sürer. En uzun dilim 6-16 haftalık geliştirmedir. Test ayrı bir aşama değil, turların içinde yürür. Takvimi çoğu zaman karar belirsizliği ve tur ortasında değişen kapsam uzatır. Mağaza yayınında ise gizlilik ve izin eksikleri beklemeye yol açar.
| Aşama | Tipik uzunluk | Takvimi uzatan |
|---|---|---|
| Keşif ve kapsam | 1-2 hafta | Karar verecek kişinin belirsizliği |
| Tasarım | 2-4 hafta | Durum çizimlerinin atlanması |
| Geliştirme | 6-16 hafta | Tur ortasında değişen kapsam |
| Test | Turların içinde | Sona bırakılması |
| Mağaza yayını | 3 gün - 2 hafta | Gizlilik ve izin eksikleri |
Takvimi Aşama Sayısı mı, Karar Hızı mı Belirler?
Mobil uygulama geliştirme süreci beş aşamadan oluşur ama takvimi aşama sayısı belirlemez. Kararların ne kadar hızlı çıktığı, kod yazma hızından daha belirleyicidir; planı da bu gerçeğin üstüne kurmak gerekir.