Kurumsal hedefi uygulama geneline çevirmek: önce sorular
Kurumsal mobil uygulamayı başlatmadan önce “uygulama neyi yönetmeyecek?” sorusunu da sorun. İlk kararlar; giriş kanalı (SSO/SMS/şifre), kullanıcı sayısı değil kullanıcı türüdür. Örneğin çalışan, yönetici, müşteri ve bayi rolleri ayrı ekran ve yetki gerektirir. Uygulamanın içinde hangi iş akışları “tek tık” olacak, hangileri web üzerinden kalacak belirleyin. Her rol için 3–5 ana ekranı yazın; sonra bu ekranların veri kaynağını netleştirin (ERP/CRM/üyelik sistemi). Bu çıktı olmadan geliştirme ekibi ekran üretir, yönetim tarafı ve bildirim stratejisi geride kalır. Böylece sonradan “yetki” değişiklikleri maliyeti büyütür.
Kullanıcı rolleri ve yetki modelini en başta kurun
Rol tasarımı yalnızca menüleri belirlemez; yönetim panelinde kim neyi onaylar sorusunu da cevaplar. Minimum model: rol (role), yetki (permission), veri kapsamı (scope) ve işlem türü (action). Örnek: Yönetici, “sipariş onayı” işlemini yapar ama “müşteri bilgilerini düzenlemez”. Çalışan, kendi birimi içindeki kayıtları görüntüler, başka birime müdahale edemez. Bu kararları yazılı hale getirin ve ekran bazında yetki haritası çıkarın. Hatalı kurulumda uygulama açılır ama kullanıcılar “başvuru yapamıyor” ya da “yanlış veriyi görüyor” gibi sorunlarla karşılaşır. Doğru yaklaşım, yetki kontrollerini hem uygulama içi hem API tarafında düşünmek, panelin de aynı kural setini kullanmasını sağlamaktır.
iOS ve Android kapsamı: tek kod mu, iki platform mu?
Karar vermeniz gereken ilk konu platform kapsamıdır. Kurumsal uygulama için genelde ikisi birden istenir; ama özellik farkları planlanmadığında sürüm farkı birikir. iOS’ta Apple kimlik doğrulama tercihleri, Android’de farklı cihaz üreticileri ve bildirim izinleri etkiler. Hangi sürümlerde destek verileceğini ve uygulamanın minimum işletim sistemi seviyesini (SDK) yazın. Sonra UI farklılıklarını belirleyin: tek tema mı, platforma göre uyarlanacak bileşen var mı? Yönetim paneli aynı arayüzü sunacaksa, uygulama katmanı sadece tüketici olacak şekilde kurgulayın. Yanlış kurulumda “iOS’ta çalışan bildirim” varken Android’de görünmeme gibi durumlar çıkar. Doğru mimaride sürüm planı, test matrisi ve yayın takvimi birlikte ilerler. Böylece mağaza süreçleri sürüklenmez.
Y��netim paneli: hangi veriler eklenip yönetilecek?
Uygulama sadece kullanıcı tarafı değildir; yönetim paneli olmadan çoğu kurumsal talep “edit yetkisi” yüzünden tıkanır. Panelde hangi işlemler olmalı sorusunu netleştirin: kullanıcı yönetimi, içerik/duyuru yönetimi, başvuru/işlem onayı, raporlama ve durum takibi. Panelin kullanıcı rolleri ile aynı yetki modelini kullanması kritik. Örneğin içerik yayınlayan kişi ile işlem onaylayan kişi aynı olmasın. Ayrıca panelde tarih aralığı filtreleri, dış sistemle senkron kontrolü ve log görünümü gerekip gerekmediğini düşünün. Hatalı kurulumda panel ya “çok küçük” kalır ve sık güncellemede geliştiriciye bağımlılık oluşur ya da “fazla geniş” olur, yetkisiz değişiklik riski artar. Doğru plan, panelin API’ye kontrollü erişim vermesini, audit kaydı tutmasını ve uygulamada görünen verilerle aynı doğrulama kurallarını kullanmasını içerir.
Bildirim planı: amaç, tür, hedefleme ve onay metni
Kurumsal uygulamada bildirim; bilgilendirme, hatırlatma ve işlem bildirimi olarak ayrılır. En başta bildirim türlerini ve hedefleme kuralını tanımlayın: rol, bölüm, il/şube ve bireysel kullanıcı. Sonra içerik sınırlamalarını yazın: kısa mesaj mı olacak, uygulama içi sayfaya yönlendirecek mi? Kullanıcı deneyimi için bildirim izin akışını da belirleyin. iOS’ta izin talebinin zamanlaması ve Android’de bildirim kanal tasarımı önemlidir. Yanlış kurulumda kullanıcı izin vermez, bildirimler görünmez; ya da yanlış hedefleme yüzünden kullanıcı işlemlerle ilgili alakasız uyarılar görür. Doğru mimaride bildirim gönderiminde deneme (test) akışı, abonelik durum yönetimi, iptal ve tekrar deneme stratejisi bulunur. Ayrıca uygulama içinde “bildirim geçmişi” tutmanız geri dönüşlerinizi azaltır.
Mağaza süreci ve sürüm yönetimi: planı şimdi çıkarın
Uygulama mağazaya çıkmadan gerçek kullanım başlamaz. Bu nedenle App Store ve Google Play süreçlerini geliştirme takvimine bağlayın. Kurumsal uygulamalarda yayın türü (genel yayın mı, kurumsal erişim mi), hesap gereksinimleri ve sürümleme kuralı net olmalı. Her sürümde hangi değişikliklerin “zorunlu güncelleme” sayılacağına karar verin. iOS için sürüm numarası ve beta dağıtım akışı, Android için sürüm kodu ve test kanalı planı önceden hazırlanmalıdır. Uygulama içi linkler (Gizlilik Politikası, Yardım, İletişim) ve minimum veri toplama metinleri de uygulama öncesinde hazır olmalı. Hatalı kurulumda yayın gecikir, aynı gün içinde birden fazla sürüm çıkar ve kullanıcılar güncellemede tutarsız ekranlarla karşılaşır. Doğru yaklaşım, “yayın öncesi kontrol listesi” ile her sürümde aynı adımları uygular.
Kabul kriterleri ve test matrisi: ekran değil senaryolar
Geliştirmenin bitişi ekran saymak değildir; kabul kriteri senaryolardır. Rol başına kritik senaryoları yazın: giriş, yetki kontrolü, veri görüntüleme, işlem başlatma, onay, bildirim tetiklemesi ve yönlendirme. Test matrisi mutlaka iOS ve Android cihaz farklılıklarını içermeli: ekran boyutu, bildirim izni durumu, ağ koşulları ve oturum süresi. Yönetim paneli tarafı için de senaryo tanımlayın: kullanıcı rol atama, içerik yayınlama, log kontrolü ve geri alma akışı. Yanlış kurulumda “uygulama açılıyor” kabulü yapılır; ama yönetim paneli ve bildirim hedefleme devreye alınmadığı için pilot kullanım boşa gider. Doğru mimari, API sözleşmelerini ve doğrulama kurallarını test edilebilir hale getirir. Pilot öncesi rapor ekranları ve bildirim geçmişi gibi geri bildirim mekanizmalarını da senaryoya ekleyin.
Neptün Medya yaklaşımı: karar dokümanı, sonra geliştirme
Uygulama yaptırmaya başlamadan önce sizden beklediğimiz ilk çıktı; rol-yetki matrisi, platform kapsamı, panel yetkileri, bildirim türleri ve mağaza yayın planıdır. Bu çıktılar netleşince geliştirme ekibi doğru menüyü değil doğru davranışı üretir. Neptün Medya, uygulamayı iOS ve Android üzerinde aynı mantıkla çalıştıracak şekilde yetki kontrollerini tasarımın içine yerleştirir; yönetim panelini de uygulamanın karar mekanizması gibi ele alır. Bildirim tarafında kanal/izin ve hedefleme kurallarını test edilebilir şekilde kurgularız. Son olarak mağaza süreçlerini takvime bağlarız; sürümleme ve zorunlu güncelleme kriterlerini belirleyince pilotu hızlandırır. Böylece sonradan “içerik yönetimi yok”, “bildirim çalışmıyor” veya “rol değişti” gibi riskleri azaltırsınız.
Uygulama sonrası kontrol listesi
- Mobil görünüm, form ve WhatsApp yönlendirmeleri test edilir.
- Title, description, canonical ve sitemap kayıtları kontrol edilir.
- Kırık link, hatalı görsel ve boş CTA alanı bırakılmaz.
- İçerikler gerçek hizmet kapsamıyla uyumlu kalır.