E-Ticaret Sitesi Devralma Firması Seçiminde Canlı Mağaza Yetkinliği Nasıl Ölçülür?

Canlı mağaza devralma deneyimi neden ayrı değerlendirilir?

Canlı bir mağazayı devralmak, sıfırdan e-ticaret sitesi geliştirmekten daha yüksek operasyon hassasiyeti gerektirir. Yeni firma mevcut kodun mantığını, üretim ortamındaki bağımlılıkları ve satış akışının kırılgan noktalarını anlamadan değişiklik yapmamalıdır. Devralma yetkinliği, yalnız yazılım geliştirme becerisi değil; mevcut sistemi kontrollü biçimde okuma, riskleri önceliklendirme ve satış devam ederken müdahaleyi sınırlama becerisidir.

Referansları proje türüne göre ayırın

Aday firmanın portföyünde çok sayıda yeni proje bulunması, çalışan bir mağazayı başarıyla devraldığı anlamına gelmez. Özellikle başka ekipten teslim alınmış sistemlerde kod kalitesi farkları, eksik dokümantasyon, eski eklentiler ve kişilere bağlı erişimler görülebilir. Bu nedenle benzer teknoloji yığınına, işlem hacmine veya entegrasyon yapısına sahip devralma örnekleri isteyin ve geçiş sırasında hangi risklerin tespit edildiğini sorun.

• Sıfırdan geliştirme ve devralma referansları ayrı sunuluyor mu?
• Canlı satış sürerken yapılan geçiş örnekleri var mı?
• Eksik dokümantasyonla çalışma deneyimi bulunuyor mu?
• Kritik entegrasyonları devralma yöntemi açıklanabiliyor mu?
• İlk haftalarda değişiklik sınırlandırma yaklaşımı var mı?

Herhangi biri bilgisayarın anlayabileceği kod yazabilir. İyi programcılar insanların anlayabileceği kod yazar. - Martin Fowler

Firma kodu devralmadan önce hangi teknik denetimi yapmalı?

Firma üretim koduna müdahale etmeden önce uygulama mimarisini, sürüm kontrol geçmişini, bağımlılıkları, sunucu yapılandırmasını, hata kayıtlarını, veritabanı yapısını ve kritik entegrasyonları kapsayan bir mevcut mağaza teknik denetimi yapmalıdır. Amaç ilk günden her sorunu çözmek değil, değişiklik yapmadan önce risk haritası oluşturmaktır. Denetim çıktısı kritik, yüksek, orta ve düşük öncelikli bulgular şeklinde sınıflandırılabilir.

Ön incelemenin teslimatını somutlaştırın

Aday firmadan yalnız “kodu inceleriz” ifadesi yerine hangi alanları kontrol edeceğini ve sonunda hangi belgeyi sunacağını isteyin. kaynak kod, SLA ve ekip yetkinliği üzerinden e-ticaret yazılım firması seçimi de bu ön incelemeyi genel sağlayıcı değerlendirmesiyle birlikte ele almanıza yardımcı olur. İlk rapor; teknik borç, güvenlik riski, gözlemlenebilirlik eksikleri ve müdahale önceliklerini ayırmalıdır.

• Kod deposu ve branch yapısı inceleniyor mu?
• Bağımlılıklar ve güncelliğini yitirmiş bileşenler listeleniyor mu?
• Sunucu, veritabanı ve yedekleme yapısı kontrol ediliyor mu?
• Ödeme, kargo, ERP ve pazaryeri entegrasyonları haritalanıyor mu?
• Bilinen hatalar ile yeni bulunan riskler ayrıştırılıyor mu?

Erişim yetkileri yeni firmaya hangi sırayla açılmalı?

Yeni firmaya tüm üretim erişimlerini ilk gün vermek yerine, yetkiler denetim ihtiyacına göre kademeli açılmalıdır. Önce salt okunur kod deposu, hata izleme ve dokümantasyon erişimleri; ardından test ortamı ve gerekli servis hesapları; üretim yetkileri ise sorumluluklar netleştiğinde verilmelidir. Bu yaklaşım hem mevcut operasyonu korur hem de hangi erişimin hangi amaçla kullanıldığını izlemeyi kolaylaştırır.

Yetki matrisini devir planının parçası yapın

Canlı e-ticaret sitesi devralma sürecinde kişi bazlı şifre paylaşımı yerine rol bazlı hesaplar ve kayıt altına alınabilir erişimler tercih edilmelidir. e-ticaret ajansı değişiminde kod, veri, entegrasyon ve hesap devir teslimi için hazırlanan yaklaşım, erişim envanterinin yalnız teknik değil operasyonel bir varlık olarak yönetilmesini destekler. Hangi erişimin marka tarafından sahiplenildiği ayrıca belgelenmelidir.

• Kod deposu için kişisel değil kurumsal kullanıcılar mı kullanılıyor?
• Üretim erişimi yalnız gerekli rollere mi açılıyor?
• Yetki yükseltme ve kaldırma süreci kayıt altına alınıyor mu?
• Paylaşılan anahtar ve parolalar güvenli biçimde değiştiriliyor mu?
• Eski sağlayıcının erişimleri kontrollü sırayla kapatılıyor mu?

Kaynak kod ve üçüncü taraf hesap sahipliği nasıl doğrulanır?

Kaynak kodun, alan adının, bulut hesabının, ödeme altyapısının, analitik araçların ve üçüncü taraf servislerin kimin adına kayıtlı olduğu devirden önce doğrulanmalıdır. Marka yalnız kullanım yetkisine sahip olup asıl sahiplik eski sağlayıcıda kalıyorsa geçiş riski artar. Hesap sahipliği, fatura kimin adına kesiliyor sorusundan daha geniştir; yönetici rolü, sözleşme sahibi, kurtarma e-postası ve lisans devredilebilirliği birlikte kontrol edilmelidir.

Sahiplik ile erişimi birbirinden ayırın

Aday e-ticaret sitesi devralma firması, hangi varlıkların marka hesabına taşınması gerektiğini ve hangi servislerin teknik olarak devredilemeyeceğini açıklayabilmelidir. Kod deposunda marka yöneticiliği, sunucu hesabında faturalandırma ve kurtarma yetkisi, ödeme tarafında ticari hesap sahipliği ayrı ayrı doğrulanmalıdır. Devredilemeyen lisans veya eklentiler için yeni satın alma, yeniden kurulum veya alternatif ürün gerekip gerekmediği önceden belirlenmelidir.

• Kaynak kod deposunun yönetici hesabı kimde?
• Hosting veya bulut hesabının sözleşme sahibi kim?
• Ödeme ve kargo servisleri marka hesabına mı bağlı?
• Üçüncü taraf lisansları devredilebilir mi?
• Kurtarma e-postaları ve çok faktörlü doğrulama kimde?

Entegrasyon bağımlılıkları devralmada nasıl haritalanmalı?

E-ticaret mağazasında görünen arayüz, sistemin yalnız bir bölümüdür; sipariş, stok, fiyat, kargo, ödeme, ERP, CRM, pazaryeri ve bildirim servisleri arka planda birbirine bağlı olabilir. Devralma firması bu akışları işlem yönü, kimlik doğrulama yöntemi, hata davranışı ve veri sahipliği açısından haritalamalıdır. Böylece tek bir servis değişikliğinin hangi operasyonları etkileyebileceği önceden görülebilir.

Hata senaryolarını entegrasyon bazında sorun

Özellikle ödeme ve sipariş akışında yalnız “entegrasyon çalışıyor” yanıtı yeterli değildir. e-ticaret entegrasyonu firması seçerken hata yönetimi ve teknik destek değerlendirmesi, başarısız çağrıların, tekrar denemelerin ve destek sorumluluğunun nasıl sorgulanabileceğini gösterir. Yeni ekip, hangi hata kayıtlarını izleyeceğini ve dış servis sağlayıcıyla kim iletişim kuracağını bilmelidir.

• Her entegrasyonun sahibi ve teknik irtibatı belli mi?
• API anahtarları ve sertifikalar envantere alınmış mı?
• Başarısız işlemler için yeniden deneme mantığı var mı?
• Webhook ve zamanlanmış görevler belgelenmiş mi?
• Dış servis kesintilerinde alternatif işlem akışı tanımlı mı?

Ödeme ve sipariş kesintisinde müdahale süresi nasıl yazılır?

Ödeme veya sipariş kesintisinde müdahale süresi, genel bir “hızlı destek” ifadesiyle değil olay seviyelerine göre tanımlanmalıdır. Sözleşmede kritik olayın ne olduğu, bildirimin hangi kanaldan açıldığı, ilk yanıt süresi, incelemeye başlama süresi, geçici çözüm sorumluluğu ve kalıcı düzeltmenin nasıl planlanacağı ayrılmalıdır. Yanıt süresi ile çözüm süresi aynı şey değildir ve teklif karşılaştırırken ayrı değerlendirilmelidir.

SLA’yı mağazanın gerçek operasyonuna göre kurun

Her mağaza için aynı hizmet seviyesi gerekli olmayabilir. İşletme saatleri, satış yoğunluğu, kampanya dönemleri, yurtdışı satışları ve ödeme bağımlılıkları destek modelini etkiler. e-ticaret firması değiştirirken kesintisiz işletim için yeni sağlayıcı seçimi, destek taahhüdünü geçiş riskiyle birlikte değerlendirmek için tamamlayıcı bir çerçeve sunar. Süreler, firmanın gerçekten sağlayabildiği ekip düzeniyle uyumlu olmalıdır.

• Kritik olay tanımı sözleşmede açık mı?
• İlk yanıt ve incelemeye başlama süreleri ayrı mı?
• Mesai dışı olaylarda hangi kanal kullanılacak?
• Geçici çözüm ve kalıcı düzeltme sorumlulukları ayrılmış mı?
• Olay sonrası kök neden raporu gerekip gerekmediği tanımlı mı?

Aday firmaya hangi kontrollü küçük pilot görev verilebilir?

Pilot görev, aday firmanın canlı sisteme kapsamı belirsiz büyük bir müdahale yapması değil; sınırlı risk taşıyan gerçek bir problemi analiz edip kontrollü çözüm önermesidir. İyi bir pilot, kod okuma, test etme, dokümantasyon, iletişim ve teslim disiplinini aynı anda gösterir. Örneğin düşük riskli bir hata düzeltmesi, belirli bir yönetim ekranındaki performans sorununun analizi veya test ortamında küçük bir entegrasyon iyileştirmesi seçilebilir.

Pilotu sonuçtan çok çalışma biçimini ölçmek için kullanın

Pilot sonunda yalnız görevin tamamlanıp tamamlanmadığına bakmayın. Adayın sorunu nasıl yeniden tanımladığı, hangi riskleri not ettiği, test senaryosu oluşturup oluşturmadığı ve değişikliği geri alma planını düşünüp düşünmediği daha değerlidir. e-ticaret firması seçerken sürekli geliştirme taleplerinin yönetimi de pilot sonrasındaki backlog, öncelik ve teslim yaklaşımını karşılaştırmanıza yardımcı olur.

• Görev sınırlı ve geri alınabilir mi?
• Önce analiz ve risk notu hazırlanıyor mu?
• Değişiklik test ortamında doğrulanıyor mu?
• Teslimde yapılan işlem belgeleniyor mu?
• İletişim ve onay adımları öngörülebilir mi?

Eski sağlayıcıdan hangi belgeler ve kayıtlar alınmalı?

Devir teslim yalnız kaynak kodun paylaşılmasıyla tamamlanmaz. Eski sağlayıcıdan sistem mimarisi, sunucu bilgileri, dağıtım adımları, veri tabanı yedekleme süreci, entegrasyon listesi, lisanslar, cron görevleri, DNS kayıtları, hata izleme araçları, bilinen sorunlar ve acil durum kişilerinin bulunduğu bir teknik paket istenmelidir. Belgelerin güncelliği yeni firma tarafından örnek kontrollerle doğrulanmalıdır.

Belge listesini teslim onayına bağlayın

Devir teslim planı, “dokümanlar paylaşılacak” gibi açık uçlu bir madde yerine dosya ve erişim bazında kontrol listesi içermelidir. Eksik bir servis hesabı veya unutulmuş sertifika, haftalar sonra kritik kesintiye dönüşebilir. Yeni firma belgeleri aldıktan sonra yalnız arşivlememeli; önemli erişimleri test etmeli, üretime dokunmadan bağlantıları doğrulamalı ve eksikleri eski sağlayıcı erişimi kapanmadan raporlamalıdır.

• Mimari ve ortam şemaları teslim edildi mi?
• Deployment ve geri alma adımları belgeli mi?
• Lisans, abonelik ve yenileme tarihleri listelendi mi?
• Bilinen hatalar ve teknik borç kaydı paylaşıldı mı?
• Yedekleme ve felaket kurtarma prosedürü doğrulandı mı?

E-ticaret sitesi devralma firmaları nasıl karşılaştırılmalı?

E-ticaret sitesi devralma firması karşılaştırırken portföy, teklif bedeli veya ekip büyüklüğünü tek başına karar kriteri yapmayın. Aynı adaylardan ön denetim yaklaşımı, erişim planı, olay müdahale modeli, pilot çalışma yöntemi, sahiplik kontrolü ve devir teslim listesi isteyin. Böylece değerlendirme, satış sunumundan çıkıp kendi mağazanızın operasyon riskine bağlanır. Özellikle canlı sistemlerde en güçlü aday, en çok özellik vaat eden değil, hangi değişikliği ne zaman yapmaması gerektiğini de açıklayabilen ekip olacaktır.

Teklifleri aynı kontrol çerçevesine getirin

Karşılaştırma formunda her firmanın hangi kapsamı fiyatına dahil ettiğini, hangi işleri ön inceleme sonrasına bıraktığını ve hangi üçüncü taraf maliyetlerinin ayrıca oluşabileceğini not edin. Devralınabilirlik değerlendirmesi, sözleşme imzalanmadan önce kritik bilinmezleri görünür hale getirir ve bakım kapsamının daha gerçekçi tanımlanmasını sağlar. Teknik ön inceleme sonucu, destek sözleşmesinin kapsamı ve önceliklendirme modeli aynı kararda birlikte değerlendirilmelidir.

• Ön denetim yöntemi ve teslimatı somut mu?
• Hesap sahipliği ve erişim geçişi planlı mı?
• Kritik olaylar için destek modeli tanımlı mı?
• Pilot görev çalışma biçimini gösterecek kadar gerçekçi mi?
• Devir teslim kontrol listesi sözleşmeye bağlanıyor mu?