Mobil uygulama geliştirmek ne kadar sürer?

“Bir uygulama geliştirmek ne kadar sürer?” sorusuna, uygulama hakkında hiçbir şey bilmeden tek bir rakamla cevap veren herkes tahmin yürütüyordur. Dürüst cevap bir aralıktır ve asıl anlaşılması faydalı olan, bir projeyi bu aralığın kısa ucundan uzun ucuna gerçekte neyin taşıdığıdır; çünkü etkileyebileceğiniz kısım orasıdır.

Kabaca, gerçekçi aralıklar

• Basit bir MVP: Birkaç ekran, tek bir temel iş akışı, karmaşık bir backend yok; bitmiş bir ürün olmaktan çok bir fikri doğrulamak için geliştirilir. Sıfırdan lansmana hazır bir sürüme ulaşmak genellikle iki ila dört ay civarında sürer.
• Standart bir kurumsal ya da tüketici uygulaması: Kullanıcı hesapları, birkaç veri modeli içeren gerçek bir backend, bir avuç temel özellik ve makul düzeyde tasarım cilası. Genellikle dört ila yedi aylık aralığa düşer.
• Karmaşık bir platform: Gerçek zamanlı özellikler, ödemeler, birden fazla kullanıcı rolü, üçüncü taraf entegrasyonları ya da bir işlemin iki tarafını buluşturan bir pazar yeri. Özellikle ilk günden itibaren hem iOS'ta hem Android'de tam özellik eşitliğiyle yayına çıkacaksa, genellikle yedi aydan bir yıla ya da daha uzun sürer.

Bu aralıklar, uygulamanın tüm yaşam döngüsü için değil, odaklı tek bir ilk sürüm içindir. Her gerçek uygulama ilk yayınından çok sonra da gelişmeye devam eder ve bu süregelen çalışma zaten “geliştirmek ne kadar sürer?” sorusunun kapsamında değildir.

Süreyi gerçekte ne değiştirir?

Geliştirme başlamadan önce kapsamın ne kadar net olduğu

Belirsiz ya da sürekli değişen gereksinimlerle geliştirmeye başlayan projeler, aynı özellik seti için baştan net bir şartname olsaydı harcanacak süreden neredeyse her zaman daha uzun sürer; çünkü belirsizlikler geliştirme öncesinde değil ortasında çözülür ve bu da yeniden çalışma demektir. Kod yazmadan önce planlamaya ve tasarıma ayrılan zaman çok nadiren boşa gider.

Native mi platformlar arası mı, tek platform mu iki platform mu?

iOS ve Android için native olarak ayrı ayrı geliştirmek, uygulama çalışmasının büyük bir kısmını kabaca ikiye katlar. Flutter veya React Native gibi platformlar arası bir framework, iki platformun süresini tek bir zaman çizelgesine çok daha fazla yaklaştırabilir; ancak birebir aynı olmaz, çünkü framework ne olursa olsun platforma özgü bir miktar geliştirme ve test işi kalır.

Backend karmaşıklığı

Büyük ölçüde mevcut ve stabil bir API'nin üzerine kurulan bir frontend'den ibaret olan bir uygulama, yanında sıfırdan bir backend (kullanıcı yönetimi, iş mantığı, entegrasyonlar, yönetim araçları) geliştirilmesi gereken bir uygulamadan çok daha hızlı ilerler. Görünen uygulama çoğu zaman asıl mühendislik işinin küçük yarısıdır.

Tasarımın olgunluğu

Geliştirme başlamadan önce tamamlanmış ve onaylanmış tasarımlara sahip olmak, proje ortasındaki gecikmelerin en yaygın kaynaklarından birini ortadan kaldırır. Belirsiz bir brifle tamamen paralel yürüyen tasarım ve geliştirme, aradaki boşluk görünür hâle geldiğinde her iki tarafta da yeniden çalışmaya yol açma eğilimindedir.

Mağaza incelemesi

Bu, insanların beklediğinden daha küçük bir etkendir ama sıfır da değildir. Özellikle Apple'ın incelemesi bir günden kısa bir sürede de tamamlanabilir, bir haftadan uzun da sürebilir; bir başvuruyu, yeniden gönderim döngüsü gerektiren düzeltmeler için geri de çevirebilir. Bu durum özellikle ödeme içeren, sağlık verisi işleyen ya da Apple'ın daha yakından incelediği başka konulara dokunan uygulamalarda sık görülür.

Gerçekçi bir süreyi gerçekten kısaltmanın yolları

Dürüst kaldıraçlar şunlardır: Kapsamı ve tasarımı geliştirme sırasında değil, geliştirme başlamadan önce netleştirin; planlanan her özelliği ilk sürüme sığdırmaya çalışmak yerine gerçekten minimal bir ilk sürümle yayına çıkın ve gerçek kullanıcılar geldikten sonra özellik ekleyin; native ya da platformlar arası tercihini üzerinde düşünmeden varsayılana göre değil, uygulamanın gerçek ihtiyaçlarına göre bilinçli olarak yapın, çünkü buradaki yanlış bir tercih günler değil aylar ekleyebilir.

Burncode'da her mobil uygulama geliştirme projesi tam olarak bu tür bir kapsam belirleme görüşmesiyle başlar; çünkü bir işletmenin lansman tarihine güvenle plan yapabilmesini sağlayan şey, genel bir sektör ortalaması tahmini değil, gerçekçi ve projeye özgü bir zaman çizelgesidir.