Uygulama çalışıyor. Paket oluştu, telefonda açılıyor.
Mağaza sırası başlıyor ve burada kod bilgisi işe yaramıyor.
Hesap doğrulaması, test, mağaza açıklamaları, veri beyanı ve inceleme. Hiçbiri zor değil; hepsi zaman alıyor ve çoğu takvime yazılmıyor.
Bu yazı o sıranın lansman gününden önce nasıl planlanacağını anlatıyor.
Kutuyu rafa bırakmıyorsun
Bir ürünü fiziksel mağazaya koyarken yalnız kutuyu bırakmıyorsun. Üstünde ne sattığın, kimden alındığı ve sorun çıkınca nereye başvurulacağı yazıyor.
Uygulama mağazalarında da kullanıcıya verdiğin bilginin çalışmayla tutarlı olması gerekiyor. Ekran görüntüsü bir özelliği gösteriyorsa uygulamada gerçekten çalışmalı. Gizlilik açıklamasında söylediğinle veri davranışı örtüşmeli.
Kodun hangi araçla üretildiği bu sorumluluğun adresini değiştirmiyor. Model yazdı diye beyanın sahibi değişmiyor.
Bu ayrımı erken yapmak işe yarıyor. Mağaza kodu incelemiyor; kullanıcıya verdiğin sözü inceliyor. Sözü sen veriyorsun.
İki mağaza tek düğme değil
App Store ve Google Play'i tek bir yayın düğmesi gibi düşünme. Hesap türleri, test beklentileri, inceleme biçimleri ve beyan ekranları birbirinden ayrı.
Her birinin güncel koşulunu kendi hesabın için ayrı kontrol et. Başka bir geliştiricinin bir yıl önce gördüğü akış seninkine aynen uygulanmıyor.
Özellikle yeni açılan hesaplarda koşullar farklı işleyebiliyor. Forumdaki bir anlatım yol gösteriyor; kendi panelindeki görev listesi karar veriyor.
Bu yüzden takvimi de ayrı tut. İki mağazaya aynı gün çıkmak bir hedef olabilir; aynı hazırlıkla çıkmak olmuyor.
İlk kez çıkıyorsan tek mağazayla başlamak da bir seçenek. Bir sırayı baştan sona görmek, iki sırayı yarım bilmekten hızlı öğretiyor.
Görünür adını baştan seç
Bireysel kayıtta yasal adın satıcı adı olarak görünebiliyor. Şirket adıyla görünmek istiyorsan bunu kayıt sonrasında çözülecek küçük bir tasarım ayrıntısı sayma.
İki hesap türünün gereksinimlerini baştan karşılaştır. Kimlik, iletişim ve doğrulama bilgilerini tutarlı hazırlamak sürecin görünmeyen ama uzun parçası.
Takma ya da eksik bilgiyle bir an önce geçmeye çalışma. Doğrulama takıldığında geri dönüş, baştan doğru doldurmaktan çok daha uzun sürüyor.
Hesap türünü yalnız hızlı onay için seçme. Gerçek durumunu doğru yansıtması gerekiyor ve sonradan değiştirmek çoğu zaman yeni bir süreç açıyor.
Kayıt ekranını tamamlamakla ücretli satışın mali hazırlığını da aynı iş sayma. Hesap açıldı diye fatura ve gelir tarafı çözülmüş olmuyor.
Testi lansmandan önce planla
Mağazaların test beklentileri var ve bunlar değişiyor. Koşulu başvuracağın gün kendi hesabının panelinden oku.
Asıl mesele koşulu tamamlamak değil. Bitki bakım hatırlatıcısı yaptığını düşün.
Testçiye "kur ve bak" demek yerine görev ver. Bitki ekle, hatırlatma ayarla, kaydı sil. Üç görev, üç ayrı ekranı sınıyor.
Farklı cihazlarda hangi adımın aksadığını kaydet. Kullanıcının ne denediğini bilmiyorsan listende testçi olması ürün hakkında bilgi üretmiyor.
Testçiye ne soracağını da önceden yaz. "Nasıl buldun" sorusu kibar cevap getiriyor; "hangi adımda durakladın" sorusu kullanılabilir cevap getiriyor.
Geri bildirimin işlenmesi de plana girsin
Test süresini beklenecek bir takvim cezası gibi görmek en yaygın hata. O süre, incelemeden önce hata bulabileceğin tek alan.
Gelen geri bildirimi nereye yazacağını ve kimin düzelteceğini önceden belirle. Toplanıp işlenmeyen geri bildirim, testi tamamen boşa çıkarıyor.
Testçi bulmak da bir iş. Kime soracağını ve nasıl davet edeceğini test başlamadan önce hazırla; davet listesini son güne bırakan takvim kayıyor.
Koşulu tamamlamak da otomatik yayın onayı anlamına gelmiyor. Ardından ayrı bir erişim başvurusu duruyor.
Bu iki adımı takvimde ayrı satır yap. Aynı satıra yazılan iki iş, ikisinden birinin unutulmasıyla bitiyor.
İnceleyen kişinin yolunu aç
İnceleme için çalışan bir sürüm ve erişilebilir işlevler hazır olmalı. Hesap gerektiren özelliklerde demo erişimi hazırla.
İnceleyen kişi senin anlattığın yolu takip edebilmeli. Giriş bilgisi eksikse ya da arka uç kapalıysa iyi yazılmış bir tanıtım metni bunu telafi etmiyor.
İnceleme notunu da kısa tut: nereden girilecek, hangi ekranda ne görülecek, hangi özellik nerede. Üç satır çoğu zaman yetiyor.
Yayın paketinin kendisini ayrıca dene. Geliştirme ortamında çalışan bir şey, yayın paketinde çalışmayabiliyor ve bunu ilk fark eden inceleme oluyor.
Bir de temiz bir cihazda dene. Kendi telefonunda yıllardır duran bir izin ya da hesap, yeni kullanıcıda olmayacak.
Verinin haritasını sen çıkar
Uygulama hangi bilgiyi alıyor, nerede saklıyor, hangi hizmete gönderiyor? Kodu bir araç üretmiş olsa bile bu haritayı anlaman gerekiyor.
Bitki uygulamasında fotoğraf, e-posta ve kullanım kaydı farklı veri türleri. Eklediğin analiz ve bildirim hizmetleri de resme giriyor; onlar da veri alıyor ve beyana giriyor.
Haritayı çıkarmanın hızlı yolu şu: her dış çağrının yanına ne gönderdiğini yaz. Liste çoğu projede tahmin edilenden uzun çıkıyor.
Gizlilik ve mağaza beyanlarını hazır şablondan körlemesine kopyalama. Teknik incelemeden aldığın gerçek bilgiyle doldur; bilmediğin alanı sorup öğren.
Yanlış beyan, çalışan bir uygulamayı da yayından düşürüyor. Üstelik bunu genellikle yayına çıktıktan sonra öğreniyorsun.
Ödeme kuralını ürün türüne göre oku
Ücretli özellik sunacaksan mağazanın ödeme kurallarını ürününün türüne göre oku. Dijital içerik, abonelik ve fiziksel hizmet aynı koşulları taşımıyor; hangi kategoride olduğunu baştan bilmen gerekiyor.
Türkiye'deki kayıt, fatura ve gelir yükümlülüklerini kendi durumun için mali müşavirinle değerlendir. Tahsilat yolunu seçmek ayrı bir karar ve mağaza onayı onu çözmüyor.
Ödeme ekranını hazırlamadan önce ne sattığını ve tahsilatı nasıl yürüteceğini netleştir. Teknik düğme, ticari hazırlığın tamamı değil.
Burada tek bir ödeme yöntemi ya da vergi sonucu bütün okurlara uygulanamıyor. Ürün türün, müşterinin bulunduğu ülke ve şirket yapın sonucu değiştiriyor.
Reti düzeltme işine çevir
Ret ya da ek bilgi isteği geldiğinde uygulamanın bütününü yeniden üretmeye çalışma.
Mesajdaki gerekçeyi ilgili koşulla eşleştir. Hangi davranışın sorun olduğunu bul ve yalnız o alanı düzelt.
Yaptığın değişikliği kısa ve somut anlat. İnceleme ekibinin neyi yeniden sınayacağını açık bırakma; belirsiz bir açıklama ikinci bir turu garantiliyor.
Sahip olmadığın bir izin ya da özellik varmış gibi açıklama yapmak sorunu çözmüyor, yeni belirsizlik üretiyor. Kanıtı çalışan uygulamada göster.
Kim için
Uygulamasını bitirmiş ve mağaza sırasına ilk kez girecek herkes için. Kodu kimin yazdığı fark etmiyor; sıra herkes için aynı.
Mağazaya kabul edilmeyi dağıtım sanan için değil. Kabul, ürünü bulunur yapmıyor; ilk kullanıcıları bulmak ayrı bir emek kalemi.
Bir sınır daha: burada güncel mağaza koşulu yazmıyor. Koşullar değişiyor ve her hesap için ayrı; kaynağın mağazanın kendi paneli.
Bugün yapılacak tek şey
Lansman takvimine yalnız kodun bitiş gününü yazma.
Altı satır aç: hesap, test, açıklamalar, veri beyanı, ödeme kuralı, inceleme hazırlığı. Her satırın yanına ne zaman biteceğini ve kimin yapacağını yaz.
Bir satır bile boşsa lansman tarihi henüz bir tahmin.
Başvurunu bu satırlar dolduğunda gönder. Önce verdiğin bilgiyi ve çalışan uygulamayı aynı hizaya getir.
Dosya bittiğinde iş bitmiyor. Sıra başlıyor.