Aydınlatma metni yükleniyor…
İstanbul’da mobil uygulama firması seçerken şehir içindeki bir adresi değil, projenin gerçekten yerinde çalışma gerektiren noktalarını ve ekibin bunları nasıl yöneteceğini değerlendirin. Kullanıcı araştırması, saha cihazı, fiziksel sistem entegrasyonu veya kurum içi atölye gerekiyorsa yerel erişim yararlı olabilir. Bunlar yoksa teslimat disiplini, teknik yeterlilik ve sahiplik; ofis yakınlığından daha belirleyicidir.
Bu sayfa firma sıralaması yapmaz. İstanbul odaklı arama yapan bir kurumun yerel ve uzaktan ekipleri aynı kanıtlarla karşılaştırmasına yardımcı olur. Genel teknik yeterlilik için ayrıca mobil uygulama firması seçim kontrol listesini kullanın.
Önce İstanbul’da Olmanın Projeye Katkısını Tanımlayın
“Firma İstanbul’da olsun” tek başına gereksinim değildir. Aşağıdaki görevlerden hangilerinin yüz yüze yapılacağını proje özetinde işaretleyin:
- Mağaza, depo, fabrika, hastane veya saha operasyonunu yerinde gözlemlemek
- Bluetooth, kiosk, yazıcı, sensör, ödeme terminali ya da kurum ağıyla cihaz testi yapmak
- Karar vericilerle ürün kapsamı veya süreç haritalama atölyesi yürütmek
- Kısıtlı erişimli bir ortamda kurulum ve kabul testi gerçekleştirmek
- Belirli olaylarda önceden tanımlanmış yerinde müdahale sunmak
Bu görevler yoksa toplantıların çevrim içi yürütülmesi aday havuzunu genişletebilir. Varsa “gerektiğinde geliriz” yerine lokasyon, bildirim süresi, sorumlu kişi ve beklenen çıktıyı teklife yazdırın.
Yerel Gereksinimi Üç Seviyede Sınıflandırın
| Seviye | Örnek | Teklifte istenecek kanıt |
|---|---|---|
| Zorunlu | Fiziksel cihaz veya kapalı kurum ağı testi | Yer, sorumlu, test senaryosu ve kabul ölçütü |
| Yararlı | Kullanıcı gözlemi veya başlangıç atölyesi | Gündem, katılımcı, çıktı ve takip yöntemi |
| Gereksiz | Rutin durum toplantısı ve ekran değerlendirmesi | Çevrim içi ritim, demo kaydı ve karar günlüğü |
Bu sınıflandırma, yerel olmanın fiyatı yükselten belirsiz bir beklentiye dönüşmesini engeller. Yüz yüze çalışmayı gün sayısıyla değil, çözdüğü risk ve ürettiği teslimatla tanımlar.
İstanbul’daki Adaylardan Aynı Proje Özetiyle Teklif Alın
Adaylara farklı kapsamlar gönderildiğinde fiyat ve süre karşılaştırması anlamını kaybeder. Tek özette kullanıcı, kritik görev, ilk sürüm, iOS/Android kapsamı, yönetim paneli, entegrasyonlar, güvenlik, erişilebilirlik, hedef tarih, bütçe aralığı ve yerinde çalışma maddeleri bulunmalıdır. Ürün kapsamı henüz net değilse 10 kritik mobil ürün kararını önce tamamlayın.
Teklifte analiz, UX/UI, mobil istemciler, backend, entegrasyon, test, mağaza teslimi, bulut ve üçüncü taraf servisler, garanti, bakım ve değişiklik bedelleri ayrı gösterilmelidir. “Anahtar teslim” ifadesi, teslimat envanteri yoksa karşılaştırılabilir bir kapsam oluşturmaz.
İlk Görüşmeyi Satış Sunumu Değil Risk Çalışması Yapın
60–90 dakikalık ilk görüşmede adayın yalnız portföyünü değil, düşünme biçimini gözlemleyin:
- Kullanıcının kritik görevini adaydan kendi cümlesiyle anlatmasını isteyin.
- En riskli üç varsayımı ve ilk sürümden çıkaracağı işleri sorun.
- Yerinde çalışma gerektiren maddeleri tek tek gerekçelendirin.
- Riskli entegrasyon için küçük bir teknik doğrulama tanımlayın.
- Projeyi yapacak ürün, tasarım, mobil, backend ve test ekibini görün.
- Kod, veri, mağaza ve servis hesaplarının kimin kontrolünde olacağını yazın.
- Demo, kabul, hata önceliği, değişiklik ve bakım ritmini netleştirin.
Görüşme sonunda cevaplanmamış soruları, varsayımları ve talep edilen kanıtları tek tutanakta toplayın. Teklif puanını vaatlere değil bu kanıtlara bağlayın.
Proje Devrini Firma Seçiminden Önce Konuşun
Mevcut bir uygulama devralınacaksa yalnız kaynak kod yeterli değildir. Depo ve dallar, veri tabanı, backend, tasarım kaynakları, API belgeleri, alan adı ve DNS, barındırma/panel, FTP veya SSH, imzalama anahtarları, Apple ve Google mağaza hesapları, bildirim, analiz, harita, ödeme ve diğer üçüncü taraf servisler envantere alınmalıdır.
Google Play ve App Store uygulama transferleri belirli uygunluk koşulları ve hazırlık adımları içerir; bu nedenle mağaza sahipliği devir gününde ele alınacak küçük bir ayrıntı değildir. (Google Play uygulama transferi; App Store uygulama transferi)
Güvenli bir devir akışında mümkünse kısa süre paralel çalışma yapılır, kritik olmayan değişiklikler geçici olarak durdurulur ve canlı dosyalar, veri tabanı ile medya yedeklenir. Parola ve API bilgileri güvenli aktarılır; kontroller tamamlanınca eski sağlayıcının erişimi kaldırılır. Kaynak kod, güncel veri tabanı veya kritik erişimler eksikse canlı taşıma ve kapsamlı müdahale başlamamalıdır.
Yerel ve Uzaktan Çalışmayı Aynı Kabul Ölçütleriyle Yönetin
İstanbul’daki bir ekiple yüz yüze görüşebilmek iletişim sorunlarını kendiliğinden çözmez. Her iki modelde de çalışan sürüm demosu, karar günlüğü, test kanıtı, erişim envanteri ve sorumlu kişiler görünür olmalıdır. Geliştirme ve teslimat sırasını karşılaştırmak için mobil uygulama geliştirme aşamalarını inceleyin.
Yerel ziyareti kabul koşuluna bağlayın: hangi cihazda hangi senaryo çalışacak, kim doğrulayacak ve başarısızlık nasıl kaydedilecek? Böylece yakınlık bir pazarlama ifadesi değil, ölçülebilir proje girdisi olur.
Karar Öncesi Kısa Kontrol Listesi
- İstanbul’da yüz yüze yapılması zorunlu görevleri yazdık mı?
- Tüm adaylara aynı kapsam ve kabul ölçütlerini verdik mi?
- Satış ekibiyle gerçek proje ekibini ayırdık mı?
- Riskli entegrasyon için doğrulama planı var mı?
- Kod, veri, mağaza ve servis hesaplarının sahipliği açık mı?
- Devir, bakım, olay müdahalesi ve değişiklik fiyatı ölçülebilir mi?
- Yerel ziyaretlerin çıktısı ve maliyeti teklifte ayrı mı?
Sonuç
İstanbul’da mobil uygulama firması seçmek, en yakın ofisi bulmak değildir. Önce yerinde çalışmanın hangi riski çözdüğünü belirleyin; sonra yerel ve uzaktan adayları aynı kapsam, ekip, teknik kanıt, sahiplik, devir ve bakım ölçütleriyle karşılaştırın. Şehir içi erişimi yalnız gerçekten gerekli görevlerde kullanın.