1. Çıkış maliyeti simülasyonu
Sunk costs yöneticilerin kararını bulandırır.
Geleneksel fixed-bid sözleşmesinde projeyi durdurmanın kaybını esnek DaaS/Staff Augmentation modeliyle karşılaştırın.
Kümülatif maliyet karşılaştırması
Çıkmaya (iptal etmeye) karar verdiğiniz ayı değiştirmek için kaydırıcıyı hareket ettirin.
Geleneksel risk (fixed-bid)
Fesih cezaları ve ara deliverable'lar için buyout yükümlülükleri sıkça uygulanır; sunk cost riskini maksimuma çıkarır.
DaaS riski (esnek sözleşme)
Yalnızca yapılan iş için ödeme yaparsınız. Her an durabildiğiniz için zarar büyümeden çıkabilirsiniz.
Her an iptal edebilme, tedarikçiyi yüksek kaliteyi sürdürmeye teşvik eder.
2. vendor lock-in ve "şeffaflık" anatomisi
Lock-in korkusu içeride ne olduğunu görememekten kaynaklanır.
Black box'ı önleyen ve özerk kontrolü geri kazandıran unsurları karşılaştırın.
Black-box geliştirme
Ayrıntılı spesifikasyon yalnızca tedarikçinin kafasında yaşar
-
✕
Belirsiz kod sahipliği
Özel framework'ler ve kütüphaneler başka bir ekibin devralmasını zorlaştırır.
-
✕
Eksik dokümantasyon
Çalışan bir ürün alırsınız, ancak arkasındaki "neden"i değil.
-
✕
Kişi bağımlılığı
Kilit kişi ayrılırsa sistem durabilir.
White-box geliştirme
Sistemi her an devre hazır tutun
-
✓
Standart teknoloji seçimi
Geniş kabul görmüş dilleri ve framework'leri seçerek değişim seçeneklerini koruyun.
-
✓
GitHub vb. her zaman paylaşılır
İlerleme ve kaliteyi gerçek zamanlı görmek için müşteri reposuna günlük commit yapın.
-
✓
Çıkış stratejisi en baştan tanımlı
İlk günden internalization/transition planını tasarlayın.
Partner seçimi için değerlendirme eksenleri (Risk Radar)
Partner seçerken yalnızca fiyatı değil, aşağıdaki beş ekseni de değerlendirerek geri dönebilirliği ölçün.
- Şeffaflık: Bilgiye erişim
- Standart teknoloji: Tech stack ne kadar yaygın
- Sözleşme esnekliği: İptal kolaylığı
- Dokümantasyon: Kayıtlı tasarım niyeti
- Kendi kendine yeterlilik desteği: internalization'a yardım isteği
3. Bağımlılıktan kurtulun: Çıkış stratejisi
Sözleşme lock-in'inden değer temelli ilişkiye geçin.
Gerektiğinde sorunsuz çıkış ve devri için roadmap tanımlayın.
Adım 01 Varlık sahipliğini güvenceye alın
Kaynak kod, tasarım verileri ve dokümantasyonun müşteriye ait olduğundan emin olun.
Müşteri repository'yi (GitHub vb.) oluşturur ve tedarikçiyi davet eder.
Adım 02 Bilgiyi kişisel olmaktan çıkarın
Toplantı notlarının yanı sıra kod yorumlarını ve ADR'leri de dokümante edin.
"Neden" bağlamını bırakmak devir maliyetini azaltır.
Adım 03 Çakışma dönemi
Internalization veya tedarikçi değişiminde 1-2 aylık çakışma süresi planlayın.
Pair programming ve code review ile yetkiyi iş düzeyinde aktarın.
Hedef Tam bağımsızlık
Sistemin dış ortaklar olmadan çalışmaya devam ettiği durum.
Bu, risk yönetiminin nihai hedefidir — sağlıklı bir geliştirme duruşu.