Internative Logo

Yazılım Keşif Fazı: Projeden Önce 2-4 Hafta Neden Bu Kadar Önemli?

Yazılım Keşif Fazı: Projeden Önce 2-4 Hafta Neden Bu Kadar Önemli?

Yazılım Keşif Fazı: Projeden Önce 2-4 Hafta Neden Bu Kadar Önemli?

Yazılım projelerinin önemli bir bölümü bütçeyi aşar, zamanında bitmez veya tamamen başarısız olur.


Sebepleri her vakada farklı görünür. Ama çoğunda aynı temel sorun karşımıza çıkar:


Keşif fazı atlanmıştır ya da yarım yapılmıştır.


“Keşfi atlayalım, vakit kaybı” diyen tedarikçi, projeyi sonradan doğacak kapsam değişiklikleri ve ek talepler üzerinden fiyatlandırır.


“Keşif zaten sözleşmenin içinde, ayrı kontrata gerek yok” diyen tedarikçi ise fiyatını korumak için kapsamı erken dondurur.


İki durumda da kazanan çoğu zaman tedarikçi olur.


Keşif fazı, projenin ana sözleşmesinden önce ve ayrı bir sözleşmeyle yapılmalıdır.


Süresi genellikle 2-4 haftadır. Maliyeti ise toplam proje bütçesinin yaklaşık %5-8’i arasında olur.


Bu yatırımı yapan projelerde nihai bütçe sapması çoğu zaman %10-20 seviyesinde kalır. Keşif yapılmadan başlanan projelerde ise %50-150 bütçe aşımı olağan hale gelebilir.


Bu yazıda keşif fazının ne olduğunu, hangi çıktıları üretmesi gerektiğini, kimlerin katılması gerektiğini, ne kadar sürmesi ve nasıl maliyetlenmesi gerektiğini açıklıyoruz.


Bu çerçeve, 16 yıllık deneyimden, hem yürüttüğümüz hem de sorunlu projeleri kurtarmaya çağrıldığımız vakalardan derlendi.


Keşif Fazı Nedir?


Keşif fazı, proje başlamadan önce yapılan 2-4 haftalık yapılandırılmış araştırma ve tasarım sürecidir.


Amacı 3 soruya kanıtlanmış cevap üretmektir:


1. Ne inşa edeceğiz?


Kapsam, kullanıcı akışları, veri modeli, API sözleşmesi ve arayüz beklentileri netleşir.


2. Nasıl inşa edeceğiz?


Mimari, teknoloji tercihleri, entegrasyonlar ve dağıtım planı belirlenir.


3. Risk ve maliyet nedir?


Risk listesi, kilometre taşı planı, süre bazlı çalışma üst limiti ve başarı metrikleri ortaya çıkarılır.


Keşif fazının çıktısı, ana sözleşmenin temelini oluşturur.


Keşif yapılmadan ana sözleşme imzalandığında, tedarikçi sözleşme sırasında bilmediği her şeyi güvenlik payı ve kapsam değişikliği olarak fiyatlandırır.


Neden Ayrı Sözleşmeyle Yapılmalı?


Keşif ve ana geliştirme aynı sözleşmede birleştiğinde üç temel sorun ortaya çıkar.


1. Tedarikçi değiştirme imkânı kalmaz


Keşif sonunda mevcut tedarikçiyle çalışmak istemediğinize karar verebilirsiniz.


Sebep kalite, ekip yapısı, iletişim ya da teknik uyum olabilir.


Ama keşif ve ana geliştirme aynı sözleşmedeyse hâlâ ana projeye bağlı kalırsınız.


Ayrı sözleşmede ise keşif sonu doğal bir çıkış noktasıdır.


Tedarikçi uygunsa devam edersiniz.


Uygun değilse, sahip olduğunuz keşif çıktılarını başka bir tedarikçiye verebilirsiniz.


Keşif sonunda tedarikçi değiştirmek, ana geliştirme sırasında değiştirmekten çok daha ucuzdur.


2. Tedarikçinin keşif motivasyonu yanlış olur


Aynı sözleşmede tedarikçi keşfi hızlıca bitirip ana geliştirme faturasına geçmek için motive olur.


Bu durumda keşif yarım kalır, kapsam tam tanımlanmaz, risk listesi zayıf çıkar.


Ayrı sözleşmede ise keşif tedarikçinin faturalı ve ölçülebilir işidir.


Kalitesi onun başarı kriteridir.


Keşif sonunda çıktılarını sizinle birlikte gözden geçiren ve gerçekten değer üreten tedarikçiyle devam edersiniz.


3. Keşif sonrası bilgiyle pazarlık yapamazsınız


Keşif sonunda gerçek kapsam ortaya çıkar.


Bazen proje ilk düşünülenden %30 daha küçük çıkar.


Bazen de %50 daha büyük olduğu görülür.


Aynı sözleşmede bu bilgiyle bütçeyi yeniden müzakere etmek zordur.


Ayrı sözleşmede ise keşif sonunda ana geliştirme için doğru bütçe ve doğru kapsam üzerinden yeniden konuşursunuz.


Sürpriz azalır.


Keşif Çıktıları: 10 Maddelik Liste


İyi bir keşif fazının sonunda aşağıdaki çıktıların elinizde olması gerekir.


1. Teknik Şartname


Sistem mimarisi, modüller, veri akışı ve entegrasyon noktaları açıklanır.


2. Kullanıcı Akışları ve Taslak Ekranlar


Her ana kullanıcı yolculuğu adım adım çıkarılır.


Düşük detaylı arayüz taslakları hazırlanır.


3. Veri Modeli


Varlık diyagramı, ilişkiler ve indeksleme stratejisi belirlenir.


4. API Sözleşmesi


Uç noktalar, istek ve yanıt şemaları, kimlik doğrulama modeli netleştirilir.


5. Teknoloji Tercihi Gerekçesi


Hangi teknolojinin neden seçildiği ve hangi alternatiflerin değerlendirildiği açıklanır.


6. Risk Listesi


10-20 arası risk belirlenir.


Her risk için etki, olasılık ve azaltma planı yazılır.


7. Kilometre Taşı Planı


Fazlara göre teslim takvimi, bağımlılıklar ve kritik yol çıkarılır.


8. Maliyet Tahmini


Saat veya iş puanı bazında efor tahmini yapılır.


Süre bazlı çalışma için üst limit önerisi belirlenir.


9. Başarı Metrikleri Çerçevesi


Proje başarısının nasıl ölçüleceği belirlenir.


Her yatırım getirisi metriği için mevcut durum ve hedef tanımlanır.


10. Bakım Planı


Canlı sonrası hizmet seviyesi, izleme ve nöbet yapısı netleştirilir.


Bu 10 maddeden en az 7’si üretilmemişse, keşif fazı yarım kalmış demektir.


Ana geliştirmeye geçmeden önce tamamlatılmalıdır.


Keşif Süresi ve Maliyeti

Süre


Küçük proje için:


3-6 ay sürecek projelerde 2 hafta keşif yeterli olabilir.


Orta ölçekli proje için:


6-12 ay sürecek projelerde 3-4 hafta keşif gerekir.


Büyük proje için:


12 ay üzeri projelerde 4-6 hafta keşif daha sağlıklı olur.


Maliyet


Keşif maliyeti genellikle toplam proje bütçesinin %5-8’i arasında olur.


İlk bakışta yüksek görünebilir.


Ama 1 milyon TL’lik bir projede 100 bin TL keşif yapmayan müşterinin ortalama final maliyeti 1.5-2 milyon TL’ye çıkabilir.


Yani keşif yapılmadığında 500 bin TL ile 1 milyon TL arasında fazla maliyet oluşabilir.


Keşif yatırımı çoğu zaman kendini 5-10 kat geri öder.


Sadece kötü kapsam tanımı ve kapsam değişikliği faturalarını engellemesi bile bu yatırımın karşılığını verir.


Fiyatlandırma Modeli


Keşif genellikle sabit ücretli yapılır.


Çünkü kapsam nettir:


2-4 haftalık paket, belli çıktılar ve net teslimler.


Bu modelde risk tedarikçidedir.


Çoğu tedarikçi ana sözleşmeyi kazanmak için keşif fazını makul bir fiyatla yapar.


Keşif Fazında Kimler Olmalı?

Tedarikçi Tarafı

Teknik Lider veya Çözüm Mimarı


Kıdemli olmalıdır.


İdeal olarak 8 yıl ve üzeri deneyime sahip olmalıdır.


Mimari kararları yönetir.


Ürün Yöneticisi


Kullanıcı yolculuğu ve kapsam yönetiminden sorumludur.


Kullanıcı Deneyimi Tasarımcısı


Kullanıcı akışları ve taslak ekranları hazırlar.


İş Analisti


Alan bilgisi ve gereksinim çıkarma sürecini yönetir.


Bu 4 rol keşif fazının ana ekibidir.


Junior ekip üyeleri öğrenme amacıyla katılabilir ama karar verici rol üstlenmemelidir.


Sizin Tarafınız

Proje Sponsoru


Genellikle CTO, CIO, COO veya ilgili üst düzey yöneticidir.


Büyük kararları onaylar.


Ürün Sahibi veya İç Proje Yöneticisi


Gereksinimleri sahiplenir.


Günlük karar akışını yönetir.


Teknik Lider


İç ekipte varsa mimari kararlarda eşit söz hakkına sahip olmalıdır.


Son Kullanıcı Temsilcileri


2-3 gerçek kullanıcı sürece dahil edilmelidir.


Uç senaryoları ve günlük kullanım gerçeklerini onlar gösterir.


Alan Uzmanı


Sektörel veya regülasyonla ilgili bilgiyi sağlar.


Bu kişilerin keşif boyunca erişilebilir olması gerekir.


Müsait olmayan paydaşlar keşif sürecini yarım bırakır.


Keşif Fazının 4 Aşaması

Aşama 1: Anlama


Genellikle ilk haftada yapılır.


Toplam keşif eforunun yaklaşık %25’ini oluşturur.


Bu aşamada:


Mevcut sistem incelenir.


Paydaş görüşmeleri yapılır.


8-15 kişiyle görüşme yapılabilir.


Alan araştırması yapılır.


Mevcut veri ve iş akışları analiz edilir.


Çıktı:


Problem tanımı ve 3-5 temel içgörü.


Aşama 2: Tasarım


Genellikle ikinci haftada yapılır.


Toplam keşif eforunun yaklaşık %35’ini oluşturur.


Bu aşamada:


Kullanıcı yolculukları çıkarılır.


Taslak arayüzler hazırlanır.


Veri modelinin ilk taslağı oluşturulur.


Mimari için 3 seçenek karşılaştırılır.


Çıktı:


Kullanıcı akışları, taslak ekranlar ve mimari öneri.


Aşama 3: Doğrulama


Genellikle üçüncü haftada yapılır.


Toplam keşif eforunun yaklaşık %25’ini oluşturur.


Bu aşamada:


Paydaşlarla gözden geçirme yapılır.


Geri bildirimlere göre iterasyon yapılır.


Riskli teknik alanlar küçük kod denemeleriyle test edilir.


Üçüncü taraf API entegrasyonları denenir.


Performans için kavram kanıtı yapılabilir.


Çıktı:


Doğrulanmış teknik şartname ve risk listesi.


Aşama 4: Planlama


Genellikle dördüncü haftada yapılır.


Toplam keşif eforunun yaklaşık %15’ini oluşturur.


Bu aşamada:


Detaylı kilometre taşı planı hazırlanır.


Efor kırılımı çıkarılır.


Başarı metrikleri çerçevesi hazırlanır.


Bakım ve devir planı oluşturulur.


Çıktı:


Ana sözleşme teklifi için hazır paket.


Keşif Sonunda Karar Vermeniz Gereken 5 Şey

1. Devam mı, duralım mı?


Keşif sırasında kapsam büyüdü mü?


Yatırım getirisi hâlâ pozitif mi?


Bu sorular net cevaplanmalıdır.


2. Bu tedarikçiyle mi devam edeceğiz?


Keşif sırasında ekiple çalışmak nasıldı?


Mimari kalitesi yeterli mi?


İletişim açık mı?


3. Fiyatlandırma modeli ne olacak?


Keşif sonrası ana sözleşme hangi modelle ilerleyecek?


Sabit fiyat mı, süre bazlı mı, sonuç bazlı mı, hibrit mi?


4. Bütçe uyumlu mu?


Keşif sonrası çıkan tahmin mevcut bütçenizle uyuşuyor mu?


Kapsam azaltılması gerekiyor mu?


5. Takvim gerçekçi mi?


Kilometre taşı planı pazardaki kritik zamanlamanızla uyumlu mu?


Bu 5 kararın yazılı verilmesi gerekir.


“İyi gitti, devam edelim” gibi sözlü onaylar ileride sorun yaratır.


Kırmızı Bayraklar: Keşif Fazında Tedarikçiyi Eleyin

1. Keşifsiz başlamayı öneriyor


“Birkaç atölye çalışmasında hallederiz” yaklaşımı, yüksek güvenlik payı veya sonradan kapsam değişikliği faturası anlamına gelebilir.


2. Keşfe junior ekip atıyor


Keşif fazındaki 4 ana rol için kıdemli kişiler gerekir.


Junior teknik lider, hatalı mimari kararlar anlamına gelebilir.


3. Paydaş görüşmeleri yapmıyor


“Brief’i okuduk, başlayabiliriz” yaklaşımı, kullanıcı gerçekleri yerine varsayımlar üzerine sistem kuracaklarını gösterir.


4. Risk listesi yok


Keşif sonunda 10-20 maddelik risk listesi yoksa, tedarikçi riskleri yeterince tanımıyor demektir.


5. Teknik deneme yapmıyor


Riskli alanları küçük kod denemeleriyle test etmeyen keşif süreci, ana geliştirmenin ilk 2 ayında sürprizlere açıktır.


6. Çıktılar yalnızca PowerPoint formatında


Sunum dosyası keşif çıktısı değildir.


Notion, Confluence, Markdown veya benzeri bir dokümantasyon ortamında gerçek dokümanlar gerekir.


7. Teknoloji tercihi karşılaştırma içermiyor


“Node ile yapacağız” tek başına yeterli değildir.


“Node, .NET ve Go karşılaştırıldı. Bu nedenle Node seçildi. Alternatiflerin avantaj ve dezavantajları şunlardır” gibi bir açıklama beklenmelidir.


Sonraki Adım


Keşif fazı, tedarikçi seçimi ve fiyatlandırma modeliyle birlikte değerlendirilmelidir.


İlgili yazılar:


Kurumsal Yazılım Geliştirme Şirketi Seçimi: 2026 CTO Kontrol Listesi

Özel Yazılım Fiyatlandırma Modelleri: Sabit Fiyat mı, Süre Bazlı mı, Sonuç Bazlı mı?

Özel Yazılım Yatırımının Geri Dönüşü: 2026 ROI Hesaplama Çerçevesi

Eğer halihazırda keşif yapılmadan başlanmış ve batma sinyalleri gösteren bir projeyi kurtarmak istiyorsanız, Software Graveyard kurtarma sürecimiz bu durum için tasarlandı.