Web Yazılım Ajansı Değiştirirken Canlı Proje Devri Nasıl Yönetilmeli?

Ajans değişikliğinde proje devri neden ayrı yönetilmeli?

Ajans değişikliğinde proje devri ayrı yönetilmelidir çünkü canlı sistemin sürekliliği, yeni özellik geliştirmeden farklı riskler taşır. Yeni ekip henüz kodun geçmişini, iş kurallarını, entegrasyonların hassas noktalarını ve operasyon alışkanlıklarını bilmiyorsa doğrudan geliştirmeye başlamak beklenmeyen kesintilere, hatalı müdahalelere veya geri dönüşü zor değişikliklere yol açabilir.

Devir sürecinin temel amacı nedir?

Temel amaç, yeni ajansın sistemi değiştirmeden önce onu güvenli biçimde gözlemleyebilmesi ve sorumluluğu hangi koşullarda devralacağını netleştirmesidir. Bu yaklaşım eski sağlayıcıyı dışlamak yerine bilgi kaybını azaltır; yeni sağlayıcıya da sistemin gerçek durumunu görerek bakım, iyileştirme ve geliştirme önceliklerini ayrı ayrı planlama imkânı verir. Ayrıca yönetim ekibi, hangi riskin devirden önce kapatılması ve hangisinin sonraki bakım planına alınması gerektiğini daha sağlıklı değerlendirebilir.

• Canlı hizmetin hangi bileşenlerden oluştuğunu görünür hâle getirmek
• Kritik erişim ve sahiplik boşluklarını devirden önce belirlemek
• İlk müdahale öncesinde yedekleme ve geri dönüş yöntemini doğrulamak
• Eski ve yeni ekip arasındaki sorumluluk sınırlarını yazılılaştırmak
• Bakım ile yeni geliştirme taleplerini birbirinden ayırmak

Programlar insanlar tarafından okunmak için, yalnızca ikincil olarak makineler tarafından çalıştırılmak için yazılmalıdır. - Harold Abelson ve Gerald Jay Sussman

Devir öncesi teknik envanter hangi varlıkları kapsamalı?

Devir öncesi teknik envanter, yalnızca kaynak kod listesinden ibaret olmamalıdır; uygulamanın çalışmasını sağlayan tüm teknik varlıkları ve bunların sahiplik ilişkilerini kapsamalıdır. Kod depoları, alan adları, DNS kayıtları, sunucular, veritabanları, dosya depoları, e-posta servisleri, sertifikalar, zamanlanmış işler, kuyruklar ve üçüncü taraf hesapları birlikte değerlendirilmelidir.

Envanter neden ilişki haritası olarak hazırlanmalı?

Bir varlığın adını bilmek tek başına yeterli değildir; hangi sistemin hangi servise bağımlı olduğu da görülmelidir. Özellikle API, ERP, CRM, ödeme, e-posta veya kimlik doğrulama bağlantıları bulunan projelerde entegrasyon ve veri yönetimi ilişkilerini aynı envanterde göstermek, yeni ajansın bir değişikliğin hangi başka bileşenleri etkileyebileceğini anlamasını kolaylaştırır. Envanterde teknik sahibin, iş sahibinin ve erişim sahibinin ayrı gösterilmesi de olası bir kesintide doğru kişiye hızlı ulaşılmasını destekler.

• Kaynak kod depoları ve kullanılan ana dallar
• Canlı, test ve geliştirme ortamları ile veritabanları
• Alan adı, DNS, SSL ve e-posta servis hesapları
• Üçüncü taraf API anahtarları ve kritik entegrasyonlar
• Zamanlanmış görevler, kuyruklar, yedekler ve izleme araçları

Yeni ajans devralmadan önce hangi erişimleri almalı?

Yeni ajans devralmadan önce sistemi incelemeye yetecek, ancak kontrolsüz değişiklik yapmayacak şekilde rol bazlı ve izlenebilir erişimler almalıdır. İhtiyaç duyulan erişimler projenin mimarisine göre değişse de kaynak kod, sunucu veya bulut ortamı, veritabanı, alan adı yönetimi, loglar, izleme araçları ve kullanılan üçüncü taraf servisler temel inceleme alanlarıdır.

Erişimler hangi sırayla verilmelidir?

Önce salt okunur veya sınırlı yetkili inceleme erişimleri, ardından doğrulanan sorumluluklara göre operasyon yetkileri verilmesi daha kontrollü bir model oluşturur. Özellikle bulut ve sunucu yönetimi tarafında yönetici hesaplarının kişilere ait e-posta adreslerine bağlı olması yerine şirket sahipliğinde tutulması, ajans değişikliklerinde erişim sürekliliğini güçlendirir.

• Git veya benzeri kaynak kod deposu erişimi
• Sunucu, bulut paneli ve dağıtım altyapısı erişimi
• Veritabanı ve güvenli yedek erişimi
• DNS, alan adı ve sertifika yönetim erişimi
• Log, izleme ve üçüncü taraf servis erişimleri

İlk teknik inceleme hangi alanları ve riskleri kapsamalı?

İlk teknik inceleme, sistemin çalışıp çalışmadığını kontrol etmekten daha geniş olmalı; mimari, güvenlik, veri, dağıtım ve operasyon risklerini birlikte ele almalıdır. Yeni ajansın amacı ilk aşamada kusur avına çıkmak değil, mevcut sistemin nasıl çalıştığını, hangi bileşenlerin kritik olduğunu ve müdahale öncesinde hangi koruma adımlarının gerekli olduğunu anlamaktır.

İnceleme raporunda hangi çıktılar beklenmeli?

İnceleme raporu gözlemleri önem ve müdahale gereksinimine göre sınıflandırmalı; kanıtı olmayan büyük yeniden yazım önerilerinden kaçınmalıdır. Canlı sistemin yanıt süreleri, hata kayıtları, izleme kapsamı, yedeklerin geri yüklenebilirliği ve darboğazları değerlendirilirken performans ve süreklilik yaklaşımı da teknik devralmanın doğal bir parçası olarak ele alınmalıdır.

• Uygulama mimarisi ve kullanılan teknoloji bileşenleri
• Bağımlılıklar, paketler ve güncelleme riski taşıyan alanlar
• Kimlik doğrulama, yetkilendirme ve hassas veri akışları
• Yedekleme, geri yükleme ve dağıtım mekanizmaları
• Loglama, izleme, hata bildirimleri ve kritik operasyon noktaları

Kod tabanı değerlendirmesi devralma kararını nasıl etkiler?

Kod tabanı değerlendirmesi, yeni ajansın bakım kapasitesini ve ilk müdahale planını belirlemesinde merkezi rol oynar; ancak kod kalitesi tek başına ajans seçme kriteri değildir. Projenin iş değeri, test kapsamı, dokümantasyon seviyesi, bağımlılıkları, dağıtım süreci ve geçmiş kararları birlikte incelenmeden yalnızca biçimsel kod standartlarına göre hüküm vermek yanıltıcı olabilir.

Yeni ajans kodu hangi bakışla incelemeli?

İlk değerlendirme; kritik modüllerin anlaşılabilirliği, tekrar eden yapılar, test edilebilirlik, yapılandırma yönetimi, gizli anahtarların saklanma biçimi ve üretim ortamına çıkış yöntemleri gibi pratik sorulara odaklanmalıdır. Amaç eski ekibi puanlamak değil, bakım sırasında hata riskini artırabilecek noktaları ve geliştirme hızını etkileyebilecek teknik borcu görünür hâle getirmektir. İnceleme, hangi alanların dokunulmadan korunması gerektiğini ve hangi alanlarda küçük güvenli iyileştirmelerin önceliklendirilmesini de ortaya koymalıdır.

• Klasör ve modül yapısının anlaşılabilirliği
• Testlerin kapsamı ve kritik akışları doğrulama yeteneği
• Bağımlılıkların güncelliği ve sürüm çakışması riski
• Ortam ayarları ile gizli bilgilerin yönetim yöntemi
• Dağıtım, geri alma ve değişiklik izleme uygulamaları

Eski ajansla bilgi aktarımı nasıl planlanıp kaydedilmeli?

Eski ajansla bilgi aktarımı, tek bir toplantıya sıkıştırılmamalı; konu başlıkları ve sorumlular üzerinden yapılandırılmış bir devir akışı olarak planlanmalıdır. Yeni ekip önce teknik envanteri ve ilk sorularını hazırlamalı, eski ekip ise sistemin alışılmadık davranışlarını, manuel operasyonlarını, kritik entegrasyon bağımlılıklarını ve sık karşılaşılan hata senaryolarını açıklamalıdır.

Bilgi aktarımında hangi kayıtlar tutulmalı?

Toplantı notları, mimari şemalar, dağıtım adımları, acil müdahale yönergeleri ve açık sorunlar ortak bir kayıt alanında tutulmalıdır. Özellikle “bunu sadece eski ekip biliyor” türü kişiye bağlı bilgiler yazılı sürece dönüştürülmeli; belirsiz kalan her konu için sahibi, doğrulama yöntemi ve sonraki aksiyon net biçimde belirlenmelidir. Böylece aktarım tamamlandıktan sonra yeni ekibin aynı soruları tekrar tekrar eski sağlayıcıya yöneltme ihtiyacı azalır.

• Mimari ve kritik iş kuralları anlatımı
• Canlıya çıkış ve geri dönüş prosedürleri
• Manuel çalışan operasyon adımları
• Bilinen hatalar ve geçici çözümler
• Açık geliştirmeler, bekleyen kararlar ve teknik borç başlıkları

Canlı sistemde acil hata olursa ilk sorumluluk kimde olmalı?

Canlı sistemde acil hata olduğunda ilk sorumluluk, geçiş başlamadan önce yazılı olarak tanımlanmış olmalıdır; sorumluluk varsayımla değil devralma statüsüyle belirlenmelidir. Yeni ajans yalnızca inceleme aşamasındaysa üretim müdahalesinin otomatik olarak ona geçtiği kabul edilmemeli; eski sağlayıcı, şirket içi ekip ve yeni ajans arasındaki görev sınırı açıkça belirtilmelidir.

Acil müdahale matrisi nasıl kurulmalı?

Her kritik olay için kim alarmı alır, kim teknik incelemeyi başlatır, kim değişiklik onayı verir, kim müşteriye bilgi aktarır ve gerektiğinde kim geri dönüş işlemini yürütür soruları cevaplanmalıdır. Yeni ajansın sorumluluğu, erişimlerin tamamlanması, yedeklerin doğrulanması ve temel sistem bilgisinin edinilmesi gibi kabul koşullarına bağlanabilir. Bu koşullar gerçekleşmeden üretim sorumluluğunun sessizce el değiştirdiği varsayılmamalıdır.

• Alarmı ve ilk bildirimi alan sorumlu taraf
• Teknik teşhisi yürütecek ekip ve yetki seviyesi
• Canlı değişiklik onayını verecek kişi veya rol
• Geri alma kararını ve uygulamasını yönetecek taraf
• Olay sonrası kayıt ve iletişim sorumlusu

Erişim ve hesap sahipliği geçişte nasıl güvenceye alınmalı?

Erişim ve hesap sahipliği, ajans değişikliğinin sonunda değil başında ele alınmalıdır; kritik hesapların kurumsal sahipliği devrin temel kontrol noktalarından biridir. Alan adı, bulut hesabı, kod deposu, e-posta servisi, analitik araçları ve üçüncü taraf platformlar yalnızca mevcut ajansın kişisel hesabına bağlıysa şirket için süreklilik riski oluşur.

Eski erişimler ne zaman ve nasıl kapatılmalı?

Yeni erişimler doğrulanmadan eski erişimleri topluca kapatmak kesinti yaratabilir; buna karşılık devir tamamlandıktan sonra gereksiz hesapları açık bırakmak da güvenlik riski oluşturur. Yetki değişikliklerinin sözleşmesel kapsamı ve sahiplik maddeleri, web ajansı sözleşmesinde bulunması gereken unsurlar gibi daha geniş tedarikçi yönetişimi başlıklarıyla birlikte değerlendirilmelidir.

• Hesap sahibinin şirket veya yetkili şirket kullanıcısı olması
• Çok faktörlü doğrulamanın kurumsal yöntemle yönetilmesi
• Yönetici, geliştirici ve salt okunur rollerin ayrılması
• Eski kullanıcıların planlı şekilde kaldırılması
• Yetki değişikliklerinin tarih ve sorumlu bilgisiyle kaydedilmesi

Devir ile düzenli bakım neden ayrı teklif edilmelidir?

Devir ile düzenli bakım ayrı teklif edilmelidir çünkü bunlar farklı amaç, belirsizlik ve teslimatlar içerir; devralma çalışması teşhis ve güvenli geçişe, bakım ise devam eden operasyon sorumluluğuna odaklanır. Bu ayrım şirketin ilk inceleme sonucunu görmeden uzun dönemli kapsamı kabul etmesini önler ve aday ajansların neyi hangi aşamada üstleneceğini daha şeffaf hâle getirir.

Teklifler hangi teslimatlar üzerinden karşılaştırılmalı?

İlk aşama için devralma kontrol listesi, teknik inceleme raporu, erişim matrisi, risk listesi ve geçiş planı; devamındaki bakım için ise müdahale kapsamı, çalışma yöntemi, değişiklik yönetimi ve raporlama modeli ayrı tanımlanabilir. Adayları değerlendirirken yazılım firması tekliflerini karşılaştırma yaklaşımı, sadece toplam bedel yerine kapsam ve sorumluluk farklarını görünür kılmaya yardımcı olur.

• Devralma kontrol listesi ve mevcut durum envanteri
• İlk teknik inceleme ve önceliklendirilmiş risk raporu
• Erişim, sahiplik ve sorumluluk geçiş planı
• Bakım kapsamı ve değişiklik talebi yönetim yöntemi
• Dönemsel raporlama ve geliştirme taleplerinin ayrı ele alınması

Devir sonrası izleme ve bakım modeli nasıl başlatılmalı?

Devir sonrası dönem, yeni ajansın hemen büyük değişikliklere yöneldiği bir aşama değil; gözlem, doğrulama ve kontrollü iyileştirme dönemi olarak başlatılmalıdır. Yeni ekip logları, hata bildirimlerini, dağıtım akışını, yedeklemeyi ve kritik entegrasyonları izleyerek ilk incelemede oluşturulan varsayımları canlı davranışla karşılaştırmalıdır.

Yeni ajansla çalışmaya başlarken hangi çerçeve kurulmalı?

Şirket ve ajans; acil müdahale kanalı, değişiklik onayı, bakım taleplerinin sınıflandırılması, geliştirme işlerinin nasıl teklifleneceği ve raporlamanın hangi içerikle yapılacağı konusunda ortak çalışma düzeni kurmalıdır. Böylece kesintisiz proje devri tek seferlik bir teslim değil, ölçülebilir sorumluluklar üzerinden sürdürülen bir hizmet ilişkisine dönüşür.

• Kritik sistem davranışlarının düzenli olarak gözlemlenmesi
• Bakım ve yeni geliştirme taleplerinin ayrı iş akışlarında tutulması
• Canlı değişiklikler için onay ve geri alma adımlarının korunması
• Risk listesinin gerçekleşen bulgularla güncellenmesi
• Teknik raporlamanın karar vericilerin anlayacağı biçimde sunulması