Mobil Uygulama Geliştirme
Mobil Uygulama Projesi İçin Bütçe Nasıl Planlanır?
Mobil uygulama bütçesini yalnızca geliştirme bedeliyle sınırlamayın. Kapsam, tasarım, altyapı, test ve bakım ihtiyaçlarını birlikte değerlendirerek karşılaştırılabilir teklifler alın.
Bütçeyi yalnızca geliştirme bedeli olarak düşünmeyin
Mobil uygulama bütçesini planlamanın başlangıç noktası, uygulamanın hangi iş sonucunu üretmesini beklediğinizdir. Satış yapmak, saha operasyonunu yönetmek veya müşterilerin işlem takibini kolaylaştırmak farklı gereksinimler doğurur. Bu nedenle bütçeyi ekran sayısından önce kullanıcıların tamamlayacağı işler ve bunları destekleyen teknik yapı üzerinden değerlendirin.
İlk geliştirme bedeli toplam maliyetin yalnızca bir parçasıdır. Ürün keşfi, tasarım, sunucu altyapısı, entegrasyonlar, test, mağaza hazırlığı ve yayın sonrası bakım da plana dahil edilmelidir. Yeni özellik geliştirme bütçesini, mevcut ürünü çalışır durumda tutma giderlerinden ayrı izleyin. Böylece harcamaların hangi ihtiyacı karşıladığını daha açık görebilirsiniz.
Başlangıçta tek bir toplam tutara ulaşmaya çalışmak yerine bütçeyi kalemlere ayırın. Her kalemin kapsamını, sorumlusunu ve ödeme koşullarını kaydedin. Henüz doğrulanmamış varsayımları kesinleşmiş gereksinimlerden ayırmak da önemlidir. Bu yaklaşım, teklifin hangi koşullarda geçerli olduğunu ve hangi kararların maliyeti değiştirebileceğini anlamanızı kolaylaştırır.
Öne çıkanlar
Ürün kapsamını kullanıcı senaryolarıyla netleştirin
“Üyelik, ödeme ve bildirim olsun” gibi bir özellik listesi, geliştirme işini açıklamak için yeterli değildir. Her özelliğin kim tarafından, hangi koşulda ve hangi sonuç için kullanılacağını yazın. Aynı özellik adı, farklı projelerde oldukça farklı iş yükleri anlamına gelebilir. Kullanım senaryoları, ekiplerin aynı ihtiyacı değerlendirmesine yardımcı olur ve tekliflerin dayandığı varsayımları azaltır. Örneğin bir randevu uygulamasında kullanıcı yalnızca saat seçebilir veya hizmete göre uygun personeli, lokasyonu ve müsaitliği birlikte değerlendirebilir. İptal, yeniden planlama ve ödeme iadesi de ayrı akışlardır. İlk sürümü belirlerken kullanıcı faydasını, operasyonel zorunlulukları ve teknik bağımlılıkları birlikte ele alın. Kapsamı daraltmak, temel güvenlik ve kullanılabilirlik ihtiyaçlarını ihmal etmek anlamına gelmemelidir. Yönetim panelini ve içerik yönetimini de kapsam görüşmesine dahil edin. Kullanıcının uygulamada gördüğü bir işlem, arka planda çalışanların veri girmesini veya talepleri onaylamasını gerektirebilir. Bu işleri baştan tanımlamak, yalnızca görünür ekranlara dayanan eksik bir bütçe hazırlanmasını önler. Sonraki sürümlere bırakılan ihtiyaçları da ayrı bir listede tutun.
Kullanıcı rolleri
Müşteri, çalışan ve yöneticilerin görebileceği verileri ve yapabileceği işlemleri tanımlayın.
Alternatif akışlar
Başarılı işlemlerin yanında hata, iptal, iade ve bağlantı kesintisi durumlarını da açıklayın.
Karşılaştırma
Platform seçimini toplam ihtiyaç üzerinden değerlendirin
Native: iOS ve Android için platforma özgü çalışmalar planlanır.
Cross-platform: Ortak kod kullanılabilir; platforma özel işler yine gerekebilir.
Native: Platformların doğrulama çalışmaları ayrı planlanır.
Cross-platform: Ortak bileşenler ve platform farklılıkları birlikte test edilir.
Uygulama süreci
Tasarım, sunucu ve entegrasyon kalemlerini belirleyin
UI/UX çalışması yalnızca ekranların görünümünü belirlemek değildir. Kullanıcının doğru adımı bulabilmesi, form hatalarını anlayabilmesi ve işlemini tamamlayabilmesi de tasarım kapsamındadır. Kullanıcı akışlarını, prototipleri, revizyonları ve tasarım dosyalarının teslim biçimini konuşun. Boş liste, yüklenme ve başarısız işlem gibi durumları da unutmayın. Mevcut marka rehberinizi ve tasarım varlıklarınızı paylaşın. Uygulamanın arkasında veri saklama, kimlik doğrulama, bildirim ve yönetim işlemleri bulunabilir. Mevcut altyapının olması, uygulamanın doğrudan bağlanabileceği anlamına gelmez. API belgelerini, test ortamlarını ve erişim koşullarını incelemeye açın. Kullanıcıların dosya yüklemesi veya yoğun işlem yapması gibi kullanım beklentileri de altyapı planlamasını etkiler. Henüz kullanım veriniz yoksa varsayımları açıkça kaydedin. Ödeme, harita veya mesajlaşma gibi dış hizmetlerde geliştirme çalışmasıyla kullanım ücretini ayrı değerlendirin. Hesapların kime ait olacağını, ücretleri kimin karşılayacağını ve servis değişikliklerinin bakım kapsamında nasıl ele alınacağını belirleyin. Entegrasyonun tamamlanması, dış hizmetle ilgili sorumlulukların sona erdiği anlamına gelmez. Veri aktarımındaki hatalar ve tekrar deneme davranışı da kapsamda yer almalıdır.
- 01
Tasarım kapsamını belirleyin
Akışları, prototipleri, revizyonları ve geliştirmeye aktarılacak dosyaları listeleyin.
- 02
Entegrasyonları inceleyin
Verinin hangi yönde aktarılacağını, eksik servisleri ve teknik sorumluları belirleyin.
- 03
İşletme giderlerini ayırın
Sunucu, depolama, yedekleme, izleme ve ücretli dış servisleri listeleyin.
Kontrol listesi
Test ve mağaza hazırlığını baştan planlayın
Test bütçesini geliştirme sonunda kalan kaynakla şekillendirmeyin. Desteklenecek cihazları, işletim sistemi sürümlerini ve kritik akışları baştan konuşun. Kullanıcı kabul testinde kimlerin görev alacağını ve geri bildirimin nasıl toplanacağını belirleyin. “Çalışıyor” demek yerine, belirli bir işlemin doğru yetkilerle tamamlanması gibi gözlemlenebilir kabul koşulları kullanın. Mağaza yayını da yalnızca uygulama dosyasını yüklemek değildir. Açıklamalar, görseller, gizlilik bilgileri ve hesap erişimleri hazırlanmalıdır. İnceleme geri bildirimlerine yönelik çalışmaların teklif kapsamındaki sınırlarını sorun. Geliştirme ekibinin teslimatıyla mağazanın yayın kararını birbirinden ayırın; yayın sonucunu kesin kabul etmeyin. Teslim öncesinde giderilecek hatalarla yeni geliştirme taleplerini de ayrı değerlendirin. Performans ve güvenlik kontrollerinin kapsamını ayrıca netleştirin. Hassas veri alanlarını ve beklenen kullanım koşullarını paylaşın. Genel bir “test dahildir” ifadesi yerine, hangi akışların ve koşulların doğrulanacağını görmek daha yararlıdır. Bulunan sorunların nasıl kaydedileceği ve düzeltmelerin nasıl yeniden kontrol edileceği konusunda ortak bir yöntem belirleyin.
- ✓
İşlev testleri
Başarılı işlemler, hatalı girişler, bağlantı kesintileri ve yetkisiz erişim durumlarını kapsamda değerlendirin.
- ✓
Kontrol kapsamı
Performans ve güvenlik kontrollerinin hangi ihtiyaçlara göre planlandığını sorun.
- ✓
Yayın sorumluluğu
Mağaza içeriklerini, hesap sahipliğini ve başvuru işlemlerinden sorumlu tarafları belirleyin.
Bakım ile yeni özellik geliştirmeyi ayırın
Uygulama yayımlandığında bütçe ihtiyacı bitmez. İşletim sistemi değişiklikleri, dış servis güncellemeleri ve kullanıcıların bildirdiği sorunlar yeni çalışmalar gerektirebilir. Bakımın kapsadığı işlerle yeni özellik taleplerinin fiyatlandırılması farklı konulardır. Genel bir “destek dahildir” ifadesi yerine, yapılacak işlerin sınırlarını ve destek koşullarını yazılı olarak görmek daha yararlıdır.
Sorunların hangi kanaldan bildirileceğini, öncelikleri kimin belirleyeceğini ve müdahale kapsamını konuşun. Mağaza, sunucu ve dış hizmet hesaplarının erişimlerini güncel tutacak sorumluları da belirleyin. Hata düzeltmesini, mevcut akışın iyileştirilmesini ve tamamen yeni bir özelliği ayrı sınıflandırın. Böylece sürekliliği sağlayan harcamalarla ürüne yeni değer ekleyen çalışmaların bütçelerini ayrı izleyebilirsiniz.
Kaynak kod, tasarım dosyaları ve teknik dokümantasyonun teslim koşullarını da bakım görüşmesinin dışında bırakmayın. Bu varlıkların nerede tutulacağını ve kimlerin erişebileceğini bilmek, teslim sonrası sorumlulukları açıklığa kavuşturur. Teknik bağımlılıkların takibi ile hesap sahipliği birbirinden farklı işlerdir; her biri için sorumlu tarafı belirleyin. Değişikliklerin nasıl onaylanacağını da konuşun.
Uygulama süreci
Aşamalı teslimatla bütçeyi yönetin
Aşamalı teslimat, özellik listesini küçük parçalara bölmekten fazlasıdır. Her aşamanın kullanıcıya sunduğu değer ve tamamlanma ölçütü tanımlanmalıdır. Minimum uygulanabilir ürün, yani MVP, temel ihtiyacı karşılayan kullanılabilir bir sürüm olmalıdır. Bütçeyi daraltmak için güvenlik, veri bütünlüğü veya kritik testleri belirsiz bırakmayın. Görünen özelliklerin sunucu ve yönetim paneli bağımlılıklarını da hesaba katın. Her aşama için çıktıları, onay sorumlusunu ve sonraki aşamaya geçiş koşullarını belirleyin. Ödeme planının teslimlerle ilişkisini açıklığa kavuşturun. Plan dışı taleplerde iş değerini ve tasarım, geliştirme, test üzerindeki etkileri birlikte değerlendirin. Yeni ihtiyacın başka bir özelliğin yerine alınması veya sonraya bırakılması da seçenekler arasında olsun. Böylece öncelik değişikliğiyle bütçe artışını birbirine karıştırmazsınız. Keşif aşamasında açık soruları ve kritik varsayımları kaydedin. Bazı konular için araştırma veya prototip gerekebilir; bunların amacı ve beklenen çıktısı belli olmalıdır. Sonraki aşamalarda kullanıcı geri bildirimlerini operasyon ihtiyaçlarıyla birlikte sıralayın. Her talebi doğrudan plana eklemek yerine, kapsam ve teslim takvimine etkisini değerlendirdikten sonra karar verin.
- 01
Kapsamı doğrulayın
İş hedefini, kullanıcı akışlarını, teknik bağımlılıkları ve araştırılması gereken soruları belirleyin.
- 02
Temel ürünü teslim edin
Ana işlemi uçtan uca tamamlayan sürümü; tasarım, geliştirme, test ve yayın hazırlığıyla birlikte planlayın.
- 03
Geri bildirimle genişletin
Yeni ihtiyaçları önceliklendirin ve her değişikliğin bütçe ile teslim planına etkisini değerlendirin.
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.
