Mevcut Uygulamayı Devralacak Yazılım Firması Nasıl Değerlendirilir?

Uygulama devralma neden yeni geliştirmeden farklıdır?

Uygulama devralma, hazır bir ürünün yalnızca kodunu teslim almak değil, mevcut teknik borcu ve operasyonel sorumlulukları görünür hale getirmektir. Yeni geliştirme projesinde kapsam geleceğe dönük tanımlanırken devralmada önce sistemin bugünkü durumu doğrulanmalıdır. Bu nedenle ilk aşamanın amacı yeni özellik sözü vermek değil, uygulamanın sürdürülebilir biçimde yönetilip yönetilemeyeceğini anlamaktır. Mevcut sistemin bilinmeyenleri azaltılmadan verilen kapsam ve süre taahhütleri, adaylar arasında yanıltıcı bir fiyat karşılaştırmasına yol açabilir.

İlk görüşmede hangi yaklaşım aranmalı?

Aday firmanın doğrudan geliştirme takvimi vermek yerine önce kaynak kodu, ortamları, mağaza hesaplarını, üçüncü taraf servisleri ve hata kayıtlarını incelemeyi önermesi daha kontrollü bir yöntemdir. Genel firma seçimi kriterlerini karşılaştırmak için mobil uygulama firmasında teknik yeterlilik ve destek kriterleri de ayrı bir kontrol çerçevesi sağlar. Devralmanın ilk çıktısı yeni özellik listesi değil, doğrulanmış mevcut durum olmalıdır.

• Mevcut mimari ve teknoloji yığınının görünür hale gelmesi
• Çalışan ve sorunlu modüllerin ayrıştırılması
• Erişim ve hesap sahipliklerinin doğrulanması
• Kritik güvenlik ve sürüm risklerinin işaretlenmesi
• Acil bakım ile planlı geliştirme taleplerinin ayrılması

Program testleri hataların varlığını gösterebilir, ama yokluğunu asla gösteremez.- Edsger W. Dijkstra

Devralma öncesinde hangi erişimler hazırlanmalıdır?

Devralma öncesinde hazırlanması gereken erişimler, uygulamanın çalışmasını ve yayınlanmasını etkileyen tüm teknik varlıkları kapsamalıdır. Kaynak kod deposu, sunucu veya bulut ortamı, veritabanı, App Store ve Play Store hesapları, alan adları, API anahtarları, bildirim servisleri, analitik araçları ve hata izleme sistemleri tek bir teslim envanterinde toplanmalıdır.

Teslim envanteri nasıl düzenlenmeli?

Envanter yalnızca kullanıcı adı ve parola listesi olmamalıdır. Her varlığın sahibi, yetki seviyesi, kim tarafından yönetildiği, üretim ortamıyla ilişkisi ve erişim devrinin tamamlanıp tamamlanmadığı belirtilmelidir. Parolalar güvenli parola yöneticileri veya kurumun onayladığı güvenli kanal üzerinden paylaşılmalı; kişisel hesaplara bağlı kritik servisler mümkünse kurumsal hesaplara taşınmalıdır. Ayrıca erişimlerin yalnızca mevcut olup olmadığı değil, hangi ortamda hangi yetkiyi sağladığı da kısa bir açıklamayla kaydedilmelidir; bu bilgi yeni ekibin keşif süresini ve yanlış erişim riskini azaltır.

• Git deposu ve kullanılan ana branch yapısı
• Backend, veritabanı, bulut ve yedekleme erişimleri
• Apple App Store Connect ve Google Play Console yetkileri
• Push bildirim, e-posta, SMS ve ödeme servisleri
• Analytics, crash reporting ve log izleme araçları
• DNS, alan adı, SSL ve CDN yönetimi

Kodun durumu ilk teknik incelemede nasıl değerlendirilir?

İlk teknik inceleme kodun “iyi” veya “kötü” olduğuna dair genel bir yorumla bitmemelidir; çalıştırılabilirlik, yapı, bağımlılıklar, test kapsamı, güvenlik riski ve yayınlanabilirlik gibi gözlenebilir kriterlerle sonuçlanmalıdır. Aday firma projeyi kendi ortamında ayağa kaldırabilmeli, kritik akışları test edebilmeli ve bakım yapılmasını zorlaştıran noktaları sınıflandırabilmelidir. İnceleme yalnızca mobil istemci koduyla sınırlı kalmamalı; uygulamanın bağlı olduğu backend, API sözleşmeleri, veritabanı değişiklikleri ve dağıtım otomasyonları da erişilebildiği ölçüde aynı teknik bütünün parçası olarak ele alınmalıdır.

Kod incelemesinin somut çıktıları neler olmalı?

İncelemede uygulamanın derlenip derlenmediği, bağımlılıkların güncelliği, gizli anahtarların kod içinde bulunup bulunmadığı, hata yönetimi, mimari katmanlar, testler ve dağıtım süreci kontrol edilmelidir. kod kalitesi, test ve kaynak kod teslimi değerlendirme kriterleri bu aşamada aday firmaların aynı teknik başlıklarla karşılaştırılmasına yardımcı olur. Riskler önem derecesi ve önerilen aksiyonla birlikte yazılmalıdır.

• Projenin temiz ortamda kurulup derlenebilmesi
• Kritik bağımlılık ve framework sürümlerinin durumu
• Test otomasyonu ve manuel test ihtiyacı
• Güvenlik açıkları ve gizli anahtar kullanımı
• Loglama, hata yakalama ve gözlemlenebilirlik düzeyi
• Release ve deployment adımlarının tekrarlanabilirliği

Yayın hesaplarının ve kritik varlıkların sahibi kim olmalı?

Yayın hesapları ve uygulamanın sürekliliği için kritik dijital varlıklar mümkün olduğunca işletmenin kurumsal kontrolünde kalmalıdır. Yazılım firması gerekli rol ve yetkilerle çalışabilir; ancak mağaza hesabı, üretim sunucusu, alan adı, analitik varlıkları ve temel servis aboneliklerinin yalnızca tedarikçinin kişisel hesabına bağlı olması ileride yeni bir devir riskine dönüşebilir. Kurumun yönetici erişimini elinde tutması, tedarikçi değişikliğinde operasyonun kesilmesini önlemek için sahiplik ile günlük kullanım yetkisinin birbirinden ayrılmasını sağlar.

Mağaza hesaplarında hangi kontroller yapılmalı?

Apple tarafında kaynak kod devri ve yayın yetkilerini ele alan iOS yayın yetkileri ve kaynak kod devri rehberi, Android tarafında ise yayın hesabı ve imzalama anahtarı sahipliği özellikle kontrol edilmelidir. Ekip değişse bile şirketin uygulamayı yayınlama, erişimleri iptal etme ve yeni yetki verme kabiliyeti korunmalıdır.

• Mağaza hesabının kurumsal sahipliği
• İmzalama anahtarları ve sertifikaların güvenli saklanması
• Üretim ortamına erişimde rol bazlı yetkilendirme
• Faturalama ve servis aboneliklerinin görünürlüğü
• Eski ekip hesaplarının kontrollü kapatılması

Acil bakım ile yeni geliştirme nasıl birbirinden ayrılır?

Acil bakım ile yeni geliştirme aynı iş kuyruğunda değerlendirilmemelidir. Uygulamayı kullanılamaz hale getiren hatalar, güvenlik açıkları, mağaza reddi, kritik entegrasyon kesintisi veya veri kaybı riski gibi konular operasyonel öncelik taşırken; yeni ekranlar, özellikler ve deneyim iyileştirmeleri ayrı ürün geliştirme planında ele alınmalıdır. Bu ayrım bütçe takibini de netleştirir; işletme mevcut sistemin stabilizasyonuna harcanan efor ile ürüne yeni değer ekleyen geliştirme yatırımını ayrı izleyebilir.

Önceliklendirme modeli nasıl kurulabilir?

İlk devralma döneminde hata kayıtları etki ve aciliyet düzeyine göre sınıflandırılabilir. Ardından bakım kapasitesi ile ürün geliştirme kapasitesi ayrı tahsis edilerek yeni taleplerin kritik düzeltmeleri geciktirmesi önlenir. sürüm yönetimi, test kapsamı ve teknik destek karşılaştırması adayların bu ayrımı nasıl yönettiğini anlamak için kullanılabilir. Her talebin kategori, etki, öncelik ve onaylanan kapsam bilgisi olmalıdır.

• Seviye 1 kritik kesinti ve güvenlik sorunları
• Seviye 2 temel işlevi bozan yüksek etkili hatalar
• Seviye 3 sınırlı kullanıcı etkisine sahip düzeltmeler
• Planlı bakım ve sürüm uyumluluk işleri
• Yeni özellik ve ürün geliştirme talepleri

Belirsiz teknik riskler teklifte nasıl ele alınmalıdır?

Belirsiz teknik riskler tek bir sabit fiyatın içine görünmez biçimde gömülmemelidir; hangi konuların doğrulandığı, hangilerinin henüz bilinmediği ve hangi varsayımlarla fiyatlandırma yapıldığı açıkça yazılmalıdır. Devralma projelerinde erişilemeyen servisler, eksik dokümantasyon, eski bağımlılıklar veya bilinmeyen üretim sorunları ilk incelemeden sonra ortaya çıkabilir. Bu nedenle teklifin belirsizliği tamamen ortadan kaldırıyormuş gibi görünmesi yerine, belirsizliğin hangi adımlarla azaltılacağını ve hangi noktada yeniden kapsamlandırma yapılacağını göstermesi daha değerlidir.

Risk raporu ve ticari teklif nasıl bağlanmalı?

Sağlıklı teklif, bilinen işleri tanımlı kapsam olarak ayırır; bilinmeyen başlıklar için ise inceleme gerektiren koşulları, olası ek çalışma mekanizmasını ve değişiklik onay sürecini belirtir. Böylece işletme riskin varlığını görür, tedarikçi de doğrulamadığı bir sistem için ölçüsüz garanti vermemiş olur. Belirsizlik gizlenmek yerine karar verilebilir hale getirilmelidir.

• Doğrulanmış teknik bulgular
• Erişim eksikliği nedeniyle doğrulanamayan alanlar
• Kritik riskler ve önerilen iyileştirme sırası
• Teklifte kullanılan teknik ve operasyonel varsayımlar
• Kapsam değişikliğinin nasıl onaylanacağı
• Ek inceleme gerektiren bağımlılıklar

İnceleme ve bakım teklifleri neden ayrı aşamalar olmalı?

Teknik inceleme ile uzun dönem bakım-geliştirme teklifini ayrı aşamalara bölmek, özellikle kodun durumu baştan bilinmiyorsa daha sağlıklı karşılaştırma sağlar. İlk aşamada sınırlı kapsamlı mobil uygulama teknik denetimi yapılır; ikinci aşamada doğrulanmış bulgular üzerinden bakım, sürüm güncelleme, hata çözümü ve yeni geliştirme kapasitesi planlanır. Böylece bakım firması adayları tahmine dayalı geniş güvenlik payları eklemek yerine, aynı teknik bulgular üzerinden daha şeffaf bir kapsam oluşturabilir.

İki aşamalı teklif nasıl yapılandırılır?

İlk teklifin teslimatı; erişim kontrolü, uygulama kod incelemesi, risk kaydı ve öncelikli aksiyon önerileri olabilir. Sonraki uygulama sürdürme hizmeti ise çalışma modeli, hizmet seviyesi sözleşmesi (SLA), müdahale kapsamı, sürüm yönetimi ve geliştirme talep süreciyle tanımlanmalıdır. App Store yayını, bakım ve sürüm güncellemelerini karşılaştırmak için bakım ve sürüm güncelleme tekliflerinin kapsamı da incelenebilir.

• Aşama 1 erişim ve teknik durum doğrulaması
• Aşama 1 risk, borç ve öncelik raporu
• Aşama 2 bakım ve müdahale çalışma modeli
• Aşama 2 sürüm, test ve mağaza yayın süreci
• Aşama 2 yeni geliştirme talep ve onay akışı

Aday yazılım firmaları hangi kriterlerle karşılaştırılmalı?

Aday yazılım firmaları yalnızca saatlik ücret veya ekip büyüklüğüyle değil, devralma metodolojisi ve risk yönetme biçimiyle karşılaştırılmalıdır. İyi bir değerlendirme; teknik inceleme kalitesini, sorumluluk sınırlarını, erişim güvenliğini, dokümantasyonu, test yaklaşımını, iletişim düzenini ve bakım sürecinin ölçülebilirliğini aynı çerçevede inceler. Ayrıca firmanın önceki projelerinde benzer teknoloji yığınlarını devralıp devralmadığı, kritik üretim sistemlerinde nasıl iletişim kurduğu ve bağımlı olduğu uzmanlıkların ekip içinde mi dışarıda mı bulunduğu sorgulanabilir.

Karşılaştırma görüşmesinde ne sorulmalı?

Her adaya aynı temel sorular yöneltilmelidir: İlk hafta hangi varlıkları doğrulayacak, çalışmayan bir build ile karşılaşırsa nasıl ilerleyecek, bilinmeyen riskleri nasıl raporlayacak, acil hatalara nasıl müdahale edecek ve yeni geliştirmeyi hangi akışla planlayacak? Yanıtların sözlü vaat yerine teklif ve süreç dokümanına dönüşmesi, firmalar arasındaki gerçek farkı görmeyi kolaylaştırır.

• Devralma ve teknik keşif metodolojisi
• Kod kalitesi ve güvenlik inceleme yaklaşımı
• Test, release ve mağaza yayın deneyimi
• SLA ve acil müdahale süreçlerinin açıklığı
• Dokümantasyon ve bilgi devri disiplini
• Yeni geliştirme için kapsam ve değişiklik yönetimi

Kontrollü teknik keşif ve devir süreci nasıl başlatılır?

Kontrollü devralma süreci, önce erişimleri düzenleyip sonra aday firmalara aynı teknik keşif kapsamını vererek başlatılmalıdır. Böylece her firma benzer veriyi inceler, riskleri aynı başlangıç noktasından raporlar ve yazılım devralma teklifi daha karşılaştırılabilir hale gelir. İşletme de kritik hesaplarını rastgele paylaşmak yerine yetkilendirilmiş, izlenebilir bir süreç kurar. İlk keşif için mümkün olduğunda salt okunur veya sınırlı roller kullanmak, üretim ortamında değişiklik yapılmasını ayrı onaya bağlamak ve erişim hareketlerini kayıt altında tutmak devir sürecinin kontrolünü artırır.

İlk görüşme öncesi pratik kontrol listesi

Kaynak kod, mağaza hesapları, sunucu ortamları, servis abonelikleri ve hata kayıtları tek yerde listelenmeli; erişim sahipleri belirlenmeli; kritik üretim bilgilerinin yedekleri kontrol edilmelidir. Ardından adaylardan inceleme kapsamı, teslim edeceği rapor, varsayımlar, acil bakım yaklaşımı ve sonrasında hazırlayacağı bakım-geliştirme modelini yazılı olarak açıklaması istenmelidir. Hedef, uygulamayı bir firmadan diğerine aktarmak değil, işletmenin teknik kontrolünü güçlendirerek sürdürülebilir bir çalışma düzeni kurmaktır.

• Erişim ve varlık envanterini tamamlayın
• Kritik hesapların kurumsal sahipliğini doğrulayın
• Mevcut hata ve talep listesini sınıflandırın
• Aynı teknik keşif kapsamını adaylarla paylaşın
• Risk raporu ve sonraki teklif yapısını karşılaştırın
• Yetki devri ve eski erişimlerin kapatılmasını planlayın