Mobil Uygulama Yaptırma Teklifinde Yayın Sonrası İşletme Maliyeti Nasıl Hesaplanır?

Mobil uygulama işletme maliyeti geliştirmeden nasıl ayrılır?

Mobil uygulama işletme maliyeti, analiz, tasarım, yazılım geliştirme, test ve ilk yayın gibi proje teslim kalemlerinden ayrı hesaplanmalıdır. Geliştirme bedeli uygulamanın oluşturulmasına yönelik tek seferlik veya aşamalı yatırım iken işletme giderleri canlı sistemin çalışmaya devam etmesi için gereken altyapı, servis, bakım ve operasyon harcamalarını kapsar. Teklifte bu iki grup tek toplam altında gösterilirse ilk yılın yüksek görünmesi veya sonraki yıl bütçesinin belirsiz kalması mümkündür.

İlk yatırım ve devam eden giderleri ayrı bütçeleyin

Karşılaştırma yaparken ilk yıl bütçesini iki parçaya ayırmak daha sağlıklıdır. Birinci parçada proje geliştirme ve ilk yayına hazırlık, ikinci parçada ise yayın sonrası on iki aylık tahmini işletme yükü yer alır. Sonraki dönemler için geliştirme bedeli otomatik olarak tekrar edilmez; yalnızca devam eden servisler, bakım kapsamı ve yeni talepler dikkate alınır. Böylece düşük başlangıç fiyatının yüksek devam maliyeti taşıyıp taşımadığı veya kapsamlı bir teklifin hangi operasyonları önceden dahil ettiği daha net görülür.

• Analiz, tasarım, geliştirme, test ve ilk yayın çalışmaları
• Bulut altyapısı, veri saklama ve trafik giderleri
• Bakım, izleme, hata müdahalesi ve sürüm uyumluluğu
• Yeni özellik, kapsam değişikliği ve ek entegrasyon çalışmaları

Fiyat ödediğiniz şeydir, değer ise elde ettiğiniz şeydir.- Benjamin Graham

Yayın sonrası düzenli giderler teklife nasıl eklenmelidir?

Yayın sonrası giderler, tek bir “bakım” veya “hosting” satırında toplanmak yerine teknik kaynak ve hizmet türüne göre ayrı gösterilmelidir. Sunucu işlem kapasitesi, veritabanı, dosya saklama, trafik, bildirim, analitik, hata kayıtları, e-posta veya mesaj servisleri farklı fiyatlama modellerine sahip olabilir. Bu nedenle teklif, hangi servisin sabit ücretli, hangisinin kullanıma bağlı olduğunu ve başlangıç hesabının hangi trafik veya kullanıcı varsayımına dayandığını belirtmelidir.

Altyapı varsayımlarını ve servis sınırlarını yazılılaştırın

Ödeme, üyelik, bildirim ve ölçüm araçları kullanan projelerde dış servislerin kim tarafından seçildiği, lisanslandığı ve faturalandırıldığı ayrıca açıklanmalıdır. Özellikle abonelik, ödeme, bildirim ve analitik altyapısının planlanması işletme giderleriyle birlikte ele alındığında, teknik mimari ile bütçe arasındaki ilişki görünür hale gelir. Böyle bir ayrım, sağlayıcı değiştiğinde hangi aboneliklerin devam edeceğini ve hangi hizmetlerin yeniden kurulması gerekeceğini de netleştirir.

• Sunucu, veritabanı, dosya saklama ve veri transferi
• Push bildirim, e-posta, SMS ve benzeri iletişim servisleri
• Analitik, crash reporting, loglama ve performans izleme araçları
• Harita, ödeme, kimlik doğrulama ve diğer harici API hizmetleri

Kullanıcı artışı uygulama sunucu maliyetini nasıl değiştirir?

Kullanıcı artışı uygulama sunucu maliyetini yalnızca kayıtlı kullanıcı sayısı üzerinden değil, oluşan teknik tüketim üzerinden değiştirir. Aynı kullanıcı sayısına sahip iki uygulamadan biri basit veri sorguları yaparken diğeri yoğun medya yükleme, gerçek zamanlı işlem veya sık arka plan görevleri kullanabilir. Bu nedenle aylık aktif kullanıcı, eş zamanlı oturum, API isteği, veri tabanı işlemi, depolama ve dışarı veri transferi birlikte değerlendirilmelidir.

Tek rakam yerine üç kullanım senaryosu oluşturun

Tekliflerde düşük, beklenen ve yüksek kullanım senaryoları istemek, altyapı maliyetinin büyümeyle nasıl değişeceğini anlamayı kolaylaştırır. Her senaryoda hangi kaynakların yeterli kabul edildiği, hangi tüketim sınırında kapasite artırımı gerektiği ve ölçekleme sırasında mimari değişiklik beklenip beklenmediği yazılmalıdır. Böylece şirket yalnızca bugünkü kullanıcı sayısına göre değil, büyüme halinde bütçenin hangi kalemlerden etkilenebileceğine göre karar verebilir. Bu yaklaşım kesin maliyet garantisi vermez; değişken giderlerin davranışını görünür hale getirir.

• Aylık aktif kullanıcı ve eş zamanlı oturum varsayımı
• API isteği, veri tabanı sorgusu ve arka plan iş yükü
• Dosya saklama, medya kullanımı ve veri transfer hacmi
• Önbellek, kuyruk, arama ve gerçek zamanlı servis tüketimi

İşletim sistemi güncellemeleri bakım kapsamına dahil midir?

İşletim sistemi güncellemeleri bakım kapsamına otomatik olarak dahil kabul edilmemeli, sözleşmede açıkça tanımlanmalıdır. Yeni iOS veya Android sürümleri SDK’larda, bağımlılıklarda, izin modellerinde, cihaz davranışlarında veya mağaza gereksinimlerinde değişiklik yaratabilir. Bazı bakım teklifleri yalnızca kritik hataların düzeltilmesini içerirken bazıları uyumluluk testlerini, gerekli teknik güncellemeleri ve yeniden mağaza yayınını da kapsar. Bu nedenle “güncelleme dahil” ifadesi tek başına yeterli değildir.

Sürüm uyumluluğunu test kapsamıyla birlikte tanımlayın

Teklifte desteklenen işletim sistemi sürümleri, test edilecek cihaz grupları, kütüphane güncellemeleri, regresyon testleri ve mağazaya yeniden gönderim sorumluluğu belirtilmelidir. sürüm yönetimi, test kapsamı ve teknik destek karşılaştırması bu ayrımı firma seçimi aşamasında somutlaştırır. Özellikle işletim sistemi üreticisinin zorunlu kıldığı bir değişiklik ile işletmenin talep ettiği yeni fonksiyon birbirinden ayrılmalı; bakım sözleşmesinin hangi tür işi kapsadığı önceden belirlenmelidir.

• Yeni iOS ve Android sürümleri için uyumluluk kontrolü
• SDK, kütüphane ve bağımlılık güncellemelerinin sınırı
• Cihaz ve işletim sistemi kaynaklı regresyon testleri
• Gerekli olduğunda mağaza paketi ve yeniden yayın desteği

Hata düzeltme ile yeni özellik geliştirme nasıl ayrılmalıdır?

Hata düzeltme ile yeni özellik geliştirme, onaylanmış gereksinim ve mevcut ürün davranışı esas alınarak ayrılmalıdır. Uygulamanın kabul edilmiş bir işlevi tanımlanan koşullarda çalışmıyorsa bu durum hata olarak değerlendirilebilir. Kullanıcı akışına yeni bir adım eklemek, mevcut iş kuralını değiştirmek, yeni rapor talep etmek veya farklı bir servis entegrasyonu istemek ise çoğunlukla kapsam değişikliği ya da yeni geliştirmedir. Bu sınır net değilse bakım paketi sınırsız geliştirme beklentisine dönüşebilir.

Değişiklik sınıflandırmasını destek sözleşmesine ekleyin

Mobil uygulama güncelleme ücreti hesaplanırken talebin kaynağı, etkilenen ekranlar, backend veya veri modeli değişikliği, test ihtiyacı ve mağaza yayını gerekip gerekmediği ayrı değerlendirilmelidir. Küçük içerik veya yapılandırma değişiklikleri için sınırlı bir aylık hizmet havuzu tanımlanabilir; yeni iş kuralları ve fonksiyonlar ise analiz edilerek ayrıca fiyatlandırılabilir. Böylece hem müşteri hangi talebin bakım kapsamında olduğunu bilir hem de sağlayıcı yeni özelliklerin mevcut destek bedeline dahil olmadığını şeffaf biçimde gösterebilir.

• Onaylı gereksinime aykırı davranışlar için hata kaydı
• Yeni kullanıcı akışı veya iş kuralı için kapsam değişikliği
• Backend, entegrasyon ve veri modeli etkisi için teknik analiz
• Test, sürümleme ve mağaza yayını ihtiyacının ayrı değerlendirilmesi

Mağaza hesapları ve üçüncü taraf servisler kime ait olmalı?

Mağaza hesapları ve kritik üçüncü taraf servis aboneliklerinin sahipliği teklif aşamasında belirlenmelidir. Uzun vadeli kontrol açısından Apple ve Google geliştirici hesapları, bulut ortamı, analitik araçları ve işletme açısından kritik API aboneliklerinin müşteri kurumu adına açılması; geliştirme ekibine ihtiyaç duyduğu yetkilerin verilmesi genellikle daha sürdürülebilir bir devir modeli sağlar. Ancak hesap sahibi, teknik yönetici ve faturayı ödeyen taraf aynı olmak zorunda değildir; bu roller sözleşmede ayrı ayrı yazılmalıdır.

İlk yayın desteğini devam eden hesap yönetiminden ayırın

Mağazaya ilk paketin hazırlanması ile sertifika, anahtar, yayın, abonelik yenileme ve fatura takibinin sürekli yönetilmesi farklı hizmetlerdir. UI UX, backend, test ve mağaza yayını hizmet bedelinin ayrıştırılması ilk yatırım ile devam eden operasyon sorumluluğunun karıştırılmasını önler. Ayrıca proje bittiğinde yönetici erişimlerinin, teknik anahtarların ve servis hesaplarının nasıl devredileceği önceden tanımlanırsa sağlayıcı değişiminde operasyonel risk azalır.

• Apple ve Google geliştirici hesaplarının kurumsal sahipliği
• Bulut, analitik, bildirim ve harici servis yönetici erişimleri
• Abonelik yenileme, ödeme yöntemi ve fatura sorumluluğu
• Proje sonunda hesap, anahtar ve erişimlerin devir yöntemi

Uygulama izleme hizmeti ve hata müdahalesi nasıl fiyatlanır?

Uygulama izleme hizmeti, kullanılan aracın lisans veya tüketim bedeli ile ekibin izleme ve müdahale emeği ayrılarak fiyatlanmalıdır. Crash kayıtlarını toplamak, performans metriklerini görmek veya alarm üretmek otomatik araçların yaptığı işler olabilir; bu kayıtları incelemek, kök neden araştırmak, düzeltme geliştirmek ve yeni sürüm hazırlamak ise insan emeği gerektirir. Bu nedenle teklif içinde bir izleme aracının bulunması, tek başına sürekli teknik operasyon veya sınırsız hata müdahalesi anlamına gelmemelidir.

Müdahale seviyelerini ve çalışma saatlerini ölçülebilir yazın

Destek modelinde olay öncelikleri, çalışma saatleri, ilk geri dönüş hedefi, teknik değerlendirme süreci ve çözüm planının nasıl paylaşılacağı tanımlanmalıdır. Kritik kesinti, yüksek öncelikli hata ve düşük etkili sorun için aynı süreç uygulanmak zorunda değildir. Ayrıca yirmi dört saat kapsama ihtiyaç varsa bunun ayrı ekip kapasitesi gerektirip gerektirmediği belirtilmelidir. “Anında çözüm” gibi belirsiz vaatler yerine hangi aşamada kimin sorumlu olduğu ve ücretin paket, saat veya talep bazında nasıl oluştuğu açıklanmalıdır.

• Crash, performans ve temel servis sağlığı izleme kapsamı
• Alarm eşikleri ve bildirimlerin yönlendirileceği sorumlu ekip
• Olay öncelikleri, çalışma saatleri ve ilk değerlendirme yöntemi
• Kök neden analizi, düzeltme ve sürümleme sorumlulukları

İlk yıl toplam mobil uygulama işletme maliyeti nasıl çıkarılır?

İlk yıl toplam mobil uygulama işletme maliyeti, tek seferlik geliştirme bedeli ile yayın sonrası sabit ve değişken giderlerin aynı dönem için ayrı gösterilip birlikte değerlendirilmesiyle çıkarılır. Geliştirme, ilk mağaza yayını, altyapı, dış servisler, bakım, izleme ve planlanan küçük değişiklikler farklı satırlarda bulunmalıdır. Böylece yönetim tek bir “yıllık paket” rakamına bağlı kalmadan hangi bileşenin bütçeyi oluşturduğunu, hangi kalemin kullanım arttıkça büyüyeceğini ve hangisinin isteğe bağlı olduğunu görebilir.

Sabit, değişken ve isteğe bağlı kalemleri üçe ayırın

Sabit kalemler sözleşmeye bağlı bakım veya destek bedelleri gibi dönemsel giderlerdir. Değişken kalemler sunucu tüketimi, veri transferi veya üçüncü taraf servis kullanımı gibi hacme bağlı giderlerdir. İsteğe bağlı kalemler ise yeni özellikler ve kapsam değişiklikleridir. Sonraki yıl bütçesinde ilk geliştirme bedelini yeniden yazmak yerine bu üç grup güncellenmelidir. Böyle bir model kesin tutar garantisi sağlamaz; ancak ilk yıl ile sonraki dönemlerin aynı hesap mantığı üzerinden karşılaştırılmasını ve maliyet artışının nedeninin anlaşılmasını sağlar.

• Tek seferlik geliştirme ve ilk yayın maliyetleri
• Sabit dönemsel bakım, izleme ve destek hizmetleri
• Kullanıma bağlı altyapı ve üçüncü taraf servis giderleri
• Talep halinde ayrıca değerlendirilecek yeni özellik çalışmaları

Mobil uygulama teklifleri aynı varsayımla nasıl karşılaştırılır?

Mobil uygulama teklifleri, tüm aday firmalara aynı kullanım senaryosu ve hizmet kapsamı verilerek karşılaştırılmalıdır. Bir firma yalnızca geliştirmeyi, diğeri bakım ve altyapıyı, üçüncüsü ise mağaza yayın desteğini de fiyatına dahil ediyorsa toplam rakamların doğrudan kıyaslanması yanıltıcı olur. Bu nedenle şirketler aday sağlayıcılardan ilk yıl ve sonraki dönem maliyetini ayrı göstermelerini, dahil edilen kullanım sınırlarını belirtmelerini ve kapsam dışı işlerin nasıl fiyatlanacağını açıklamalarını istemelidir.

App Store bakımı ve sürüm güncellemesini aynı şablonda sorun

App Store yayını, bakım ve sürüm güncellemelerinin tekliflerde karşılaştırılması özellikle devam eden giderlerin standartlaştırılmasına yardımcı olur. Aylık aktif kullanıcı, trafik, depolama, beklenen sürüm sıklığı, destek saatleri ve gerekli üçüncü taraf servisler tüm firmalara aynı varsayımla verilmelidir. Böylece fiyat farkının hizmet kapsamından mı, teknik mimariden mi, destek seviyesinden mi yoksa sağlayıcının yalnızca bazı maliyetleri teklif dışına bırakmasından mı kaynaklandığı daha kolay anlaşılır.

• Aynı kullanıcı, trafik ve veri saklama varsayımları
• Aynı bakım, izleme ve hata müdahale kapsamı
• Aynı mağaza yayın ve sürüm yönetimi sorumlulukları
• Aynı üçüncü taraf servis ve hesap sahipliği kabulleri

Mobil uygulama destek sözleşmesinde hangi maddeler olmalıdır?

Mobil uygulama destek sözleşmesi, yalnızca aylık veya yıllık bir bakım ücretini değil hizmet kapsamını, sorumluluk sınırlarını, hesap sahipliğini, müdahale yöntemini ve fiyatlandırma mantığını birlikte tanımlamalıdır. Hangi olayın hata, hangi talebin yeni geliştirme sayılacağı; hangi işletim sistemi güncellemelerinin kapsama girdiği; izleme ve mağaza yayın sorumluluğunun kimde olduğu açık olmalıdır. Sözleşme sona erdiğinde kaynak kodun, dokümantasyonun ve servis erişimlerinin nasıl devredileceği de operasyonel süreklilik açısından önemlidir.

Kararı toplam sahip olma maliyeti üzerinden tamamlayın

Teknik destek düzeyini değerlendirirken ürün ekibi, kaynak kod ve SLA kriterlerini de teklif kontrolüne eklemek gerekir. Sağlıklı satın alma kararı, yalnızca geliştirme ücretini değil ilk yıl toplamını, sonraki dönemlerin düzenli giderlerini, ölçek büyüdüğünde değişecek maliyetleri ve yeni taleplerin nasıl fiyatlanacağını birlikte görmeye dayanır. Aday firmalardan aynı kullanım varsayımlarıyla iki ayrı maliyet dökümü istemek, teklifleri gerçek işletme yükü üzerinden karşılaştırmayı kolaylaştırır.

• Bakım kapsamı, kapsam dışı işler ve talep sınıflandırması
• İzleme, olay önceliği ve müdahale sürecinin tanımı
• Kaynak kod, mağaza, bulut ve servis hesaplarının sahipliği
• Devir teslim, dokümantasyon ve hizmet sonlandırma prosedürü