Mobil Uygulama Bakımı ve Güncelleme: Yayın Sonrası Neleri Planlamalısınız?

Mobil uygulamanız mağazada yayına girdiğinde proje bitmiş görünür; müşteriler kullanmaya başladığında ise yeni bir dönem başlar. Cihazlar, işletim sistemleri, bağlı hizmetler ve işletmenizin ihtiyaçları zamanla değişebilir. Bu rehber, bakım kapsamını belirlemenizi, güncellemeleri kontrollü yayınlamanızı ve devam eden giderleri planlamanızı sağlar.

Mobil uygulama bakımı hangi işleri kapsar?

Bir sipariş uygulamasında müşteri hesabına giriş yapamıyorsa önce sorunun kaynağını bulmak gerekir. Uygulamadaki hata, sunucu kesintisi veya dış hizmetteki sorun aynı kullanıcı şikâyetiyle ortaya çıkabilir. Bakım planı bu parçaların kim tarafından inceleneceğini açıklamalıdır.

Bakım; hata düzeltme, cihaz uyumu, kullanılan bileşenlerin değerlendirilmesi, sunucu izleme ve destek işlerini içerebilir. Bunların hepsinin tek bedelde sınırsız sunulduğunu varsaymayın. Teklifinizde hangi hizmetin hangi koşulda verileceğini kalem kalem görün.

İlk ayrım, bakım ile yeni özellik geliştirmesi arasındadır. Üzerinde anlaşılmış sipariş akışının çalışmaması hata olabilir; aynı akışa sadakat puanı eklemek yeni kapsamdır. Kararı kişisel yoruma bırakmamak için kabul edilmiş davranışları ve sürüm geçmişini saklayın.

Hata garantisi ile bakım sözleşmesi aynı mı?

Hata garantisi belirli teslim koşullarındaki sorunların düzeltilmesini kapsayabilir. Sürekli izleme, dış hizmet değişikliklerine uyum ve kullanıcı taleplerini değerlendirme ise ayrı işler olabilir. Süre, kapsam ve istisnaları sözleşmenizde açıkça tanımlayın.

Bir destek paketini değerlendirirken yalnızca aylık saat sayısına bakmayın. Kimlerin talep açabildiği, kullanılmayan kapasitenin ne olduğu ve acil işlerin nasıl ele alındığı da önemlidir. Önceliklendirme kararı işletmenizin kullanım şekline uygun olmalıdır.

Hangi sorun önce ele alınmalı?

Her sorun aynı etkiye sahip değildir. Bütün müşterilerin sipariş verememesi ile bir açıklamanın yanlış hizalanması farklı öncelikler gerektirir. Teknik ekibe yalnızca “acil” yazmak yerine etkilenen işi ve kapsamı belirtin.

• İş kesintisi: Temel işlem tamamlanamıyor veya kayıtlar yanlış oluşuyor.
• Sınırlı işlev kaybı: Belirli cihazlarda veya bir kullanıcı grubunda sorun var.
• Kullanım güçlüğü: İş tamamlanıyor ancak açıklama veya yerleşim kullanıcıyı zorluyor.
• Geliştirme isteği: Mevcut davranışa yeni bir seçenek eklenmesi isteniyor.

Yanıt süresi ile çözüm süresini ayırın. Talebin kısa sürede görülmesi, dış hizmete bağlı bir sorunun aynı sürede çözüleceği anlamına gelmez. Ekipten ilk değerlendirmeyi, geçici çözümü ve sonraki bilgilendirme zamanını açıkça isteyin.

Sorun bildirirken cihaz modeli, uygulama sürümü, gerçekleşen adımlar ve beklenen sonuç yararlıdır. Müşteri şifresi gibi gereksiz bilgileri destek kaydına eklemeyin. Gerekli teknik kayıtlar yetkili kişiler tarafından uygun erişimle incelenmelidir.

Neleri düzenli olarak kontrol etmelisiniz?

Uygulama açılıyor diye bütün sistemin çalıştığını düşünmeyin. Siparişin sunucuya ulaşması, yönetim panelinde görünmesi ve bildirim görevinin tamamlanması farklı kontrol noktalarıdır. Temel iş akışına göre izleme listesi hazırlayın.

Yedek alındığının görülmesi de tek başına yeterli değildir. Gerekli durumda geri yüklemenin nasıl yapılacağı, kim tarafından başlatılacağı ve hangi kayıtların etkilenebileceği bilinmelidir. Deneme geri yüklemesini gerçek kullanıcı verisini gereksiz yere açığa çıkarmayan kontrollü bir ortamda planlayın.

Erişimleri de dönemsel olarak gözden geçirin. İşten ayrılan kişinin hesabı, artık kullanılmayan dış hizmet anahtarı veya sahipsiz mağaza hesabı bakım toplantısında ele alınabilir. Genel güvenlik yaklaşımını işletmeler için güvenlik rehberindeki sorumluluklarla birlikte değerlendirin.

Bir güncelleme yayına çıkmadan önce ne yapılmalı?

Önce değişikliğin neyi etkilediğini belirleyin. Profil ekranındaki düzenleme ile sipariş hesaplamasındaki değişiklik aynı test kapsamına sahip değildir. Etkilenen müşteri ve çalışan akışlarını kısa bir kontrol listesine dönüştürün.

1. Değişikliği tanımlayın: Düzeltilen sorun veya eklenen davranış açıkça yazılsın.
2. Deneme ortamında kontrol edin: Gerçek kullanıcı işlemlerini etkilemeden temel senaryoları deneyin.
3. Uyumu inceleyin: Yeni uygulama sürümünün mevcut sunucuyla nasıl çalışacağını kontrol edin.
4. Yayın sorumlusunu belirleyin: Onayı kimin vereceği ve yayını kimin izleyeceği belli olsun.
5. Geri dönüşü planlayın: Sorun çıkarsa hangi teknik seçeneğin kullanılacağını önceden değerlendirin.

Kullanıcının uygulamayı hemen güncellemeyebileceğini unutmayın. Eski sürümlerin ne kadar süre destekleneceği ürün kararınızın parçasıdır. Zorunlu güncelleme düşünülüyorsa müşterinin işlem sırasında nasıl etkileneceğini ve sunucu tarafındaki uyumu ayrıca değerlendirin.

Bakım bütçesi nasıl hazırlanır?

Bütçeyi geliştirme bedelinin rastgele bir yüzdesi olarak belirlemek yerine yapılacak işlerden çıkarın. İzleme, planlı kontrol, destek kapasitesi ve düzenli test işleri ayrı görülsün. Sunucu, mesajlaşma veya diğer dış hizmetlerin ücretlerini hizmet bedelinden ayırın.

Hesap yöntemini göstermek için aylık 12-20 saat planlı çalışma ve varsayımsal 1.500 TL saat bedeli düşünelim. Bu örnekte 18.000-30.000 TL hizmet bütçesi oluşur. Bu tutarlar piyasa ortalaması veya Navdion teklifi değildir; KDV, altyapı ve yeni özellik geliştirmesi dahil değildir.

Gerçek teklifte bu kapasitenin hangi işleri kapsadığını sorun. Yoğun işlem alan bir ürünle küçük bir işletme uygulamasının izleme ve destek ihtiyacı farklı olabilir. Önce kullanım şeklinizi ve çalışma saatlerinizi paylaşın, ardından hizmet modelini belirleyin.

Bakımı işletmenin günlük düzenine nasıl yerleştirirsiniz?

Örnek bir aylık düzende ilk hafta sorun listesini inceleyebilir, sonraki hafta onaylı işleri test edebilir ve uygun zamanda yayın yapabilirsiniz. Bu bir standart veya süre taahhüdü değildir. Kritik sorunlar planlı takvimin dışında ele alınabilir; yöntemi baştan kararlaştırın.

Tek bir işletme sorumlusunun talepleri toplaması yararlıdır. Farklı çalışanların aynı konu için çelişen istekler açması değerlendirmeyi zorlaştırır. Talepleri gerçek kullanım örnekleriyle birleştirip ürün üzerindeki etkisine göre önceliklendirin.

Ay sonunda yalnızca kapatılan kayıt sayısını istemeyin. Tekrarlayan sorunları, henüz giderilmeyen riskleri ve gelecek dönemde karar gerektiren değişiklikleri konuşun. Bakım raporu, yöneticinin anlayacağı iş etkisini göstermelidir.

Bakım ekibi değişirse hangi bilgiler gerekli?

Kaynak kod, kurulum belgeleri, mağaza hesapları, sunucu erişimleri ve kullanılan dış hizmetler düzenli tutulmalıdır. Hangi hesabın işletmeye ait olduğu ve erişimi kimin yönettiği belli olsun. Ekip değiştiğinde bu bilgiler birlikte incelenebilir.

Devirde yalnızca dosya kopyalamakla yetinmeyin. Yeni ekibin deneme ortamını çalıştırabildiğini, temel akışı anlayabildiğini ve yayın yöntemini doğrulayabildiğini kontrol edin. Bekleyen sorunları ve daha önce alınan önemli kararları da paylaşın.

Ürünün kapsamı değişecekse bakım bütçesiyle yeni proje bütçesini karıştırmayın. İşletme hedeflerini ve müşteri akışını yeniden değerlendirin. Bu yaklaşımı dönüşüm optimizasyonu rehberindeki kullanıcı davranışı incelemesiyle destekleyebilirsiniz.

Bir sipariş sorunu için örnek müdahale akışı

Müşteri “siparişim oluşmadı” dediğinde ilk kontrol, yalnızca uygulamayı yeniden açtırmak olmamalıdır. İşletme sorumlusu ilgili işlem zamanını ve müşterinin gördüğü durumu toplar. Teknik ekip, gereksiz kişisel bilgi istemeden siparişin uygulama, sunucu ve panel tarafındaki izini kontrol eder.

Kayıt merkezde oluşmuş fakat müşteri ekranına sonuç dönmemiş olabilir. Bu durumda müşteriye yeniden sipariş verdirmek ikinci kayıt yaratabilir. Geçici çözüm, gerçek durum doğrulandıktan sonra belirlenmelidir; çalışanların aynı sorun için farklı talimatlar vermesini önleyin.

Düzeltme tamamlandığında hem yeni sipariş hem daha önce etkilenmiş kayıtlar değerlendirilmelidir. Yazılım hatasının giderilmesi, yanlış oluşmuş operasyon kaydının kendiliğinden düzeldiği anlamına gelmez. Teknik düzeltme ile işletmenin veri kontrolünü ayrı sorumluluklar olarak takip edin.

Son bilgilendirmede sorunun neyi etkilediğini, hangi işlemin yapıldığını ve kullanıcıdan ek adım beklenip beklenmediğini açıklayın. İnceleme sonucunu kısa ve anlaşılır tutun. Kesinleşmemiş nedeni müşteriye kesin bilgi gibi iletmeyin.

Bakım için küçük bir sistem envanteri oluşturun

Uygulamanın bağlı olduğu hizmetleri, hesap sahiplerini ve yenileme gerektiren kalemleri tek listede tutun. Bu liste şifreleri açık metinle saklayan bir dosya olmamalıdır. Amaç, hangi hizmetin neden kullanıldığını ve sorumlusunu bulabilmektir.

Her önemli değişiklikte envanteri güncelleyin. Kullanımdan kaldırılan bir hizmetin yerine yenisi geldiyse bağlantı ve destek sorumluluğu da değişebilir. Ekipteki bir kişinin ayrılmasıyla bütün ürün bilgisinin kaybolmasını önlemek için belgeleri işletmenin erişebildiği düzenli alanda tutun.

Bakım toplantısına müşteri desteği ve operasyon tarafındaki gözlemleri de getirin. Teknik kayıtta görünmeyen fakat kullanıcıyı sürekli zorlayan bir açıklama veya süreç bulunabilir. Bu gözlemleri yeni özellik taleplerinden ayırarak değerlendirmeniz, mevcut ürünün daha güvenilir kullanılmasına yardım eder.

Sonuç: Yayından sonrasını da planlayın

Bakım kapsamını, destek önceliklerini ve güncelleme yöntemini yazılı hâle getirin. Temel akışları izleyin, değişiklikleri test edin ve işletme sorumluluğunu net tutun. Navdion ile uygulamanızın bakım ve geliştirme ihtiyaçlarını değerlendirmek için ücretsiz proje analizi talep edebilirsiniz.