Keşif sprinti nedir, neden gerekir?
Keşif sprinti, bir yazılım projesinde tasarıma ve geliştirmeye başlamadan önce problemi, kullanıcıları ve mevcut sistemleri anlamak için ayrılan kısa ve sınırlı bir çalışma dönemidir. İngilizce kaynaklarda discovery sprint ya da discovery phase olarak geçer. Süresi baştan bellidir, çoğunlukla iki hafta; sonunda neyin teslim edileceği de.
Neden gerekir? Çünkü bir projenin süresini ve maliyetini belirleyen ayrıntılar ilk toplantıda konuşulanlarda değil, işin günlük akışındadır. “Bayilerimiz sipariş verebilsin” cümlesi tek ekranlık bir form da olabilir, kredi limitleri, kampanya kuralları ve birkaç sisteme bağlanan entegrasyonlar içeren bir platform da. Bu ayrım yapılmadan verilen süre ve bütçe, ne kadar iyi niyetli olursa olsun bir tahmindir. Keşif, bu tahmini bilgiye dayanan bir aralığa dönüştürür. “Yazılım projesi nasıl başlar?” sorusunun kısa yanıtı da budur: kod yazarak değil, problemi doğrulayarak.
Keşif, rafta kalacak bir analiz raporu için yapılmaz. Amacı karar vermektir: ilk sürümde ne olacak, ne olmayacak, hangi sırayla ilerlenecek ve başarı neye göre ölçülecek.
İki haftada neler yapılır?
İki haftanın ritmi basittir: ilk hafta dinlemek ve gözlemlemek, ikinci hafta görüleni düzenleyip karar vermek.
1. hafta: paydaşlar, saha ve sistemler
- Paydaş görüşmeleri. Karar vericiler, süreç sahipleri ve ürünü her gün kullanacak kişilerle ayrı ayrı konuşulur. Yönetimin hedefiyle sahadaki ihtiyacın nerede ayrıştığı çoğu zaman burada görünür.
- Saha gözlemi. İşin yapıldığı yerde, işi yapan kişinin yanında zaman geçirilir. İnsanlar süreci anlatırken istisnaları atlar; gözlemde ise kopyalanan tablolar, telefonla teyit edilen siparişler ve “bunu hep elle düzeltiriz” denen adımlar ortaya çıkar.
- Sistem ve veri envanteri. Hangi sistemler kullanılıyor, veri nerede doğuyor, kim güncelliyor, hangi sistemin API’si var, hangisine yalnızca dosya aktarımıyla ulaşılabiliyor? Entegrasyonlar projelerin en belirsiz kalemlerindendir; envanter bu belirsizliği erkenden görünür kılar.
2. hafta: harita, ölçüt ve kapsam
- Akış haritası. Bugünkü süreç; adımları, rolleri, kullanılan araçları ve tıkanma noktalarıyla tek bir haritada toplanır. Hedeflenen akış aynı haritanın üzerine çizilir.
- Başarı ölçütleri. Ürün canlıya çıktığında neyin değişmesi gerektiği ölçülebilir biçimde yazılır; örneğin bir onayın kaç saatte tamamlandığı ya da bir siparişin kaç adımda verildiği. Bugünkü değer bilinmiyorsa, nasıl ölçüleceği de çıktının parçasıdır.
- İlk sürüm kapsam önerisi. Ölçütleri en çok etkileyen akışlar seçilir; ilk sürüme girmeyenler gerekçesiyle listelenir.
- Yol haritası ve tahmin aralığı. İlk sürüm ve sonraki aşamalar sıralanır, her biri için önerilen ekip ve süre aralığı verilir. Aralık, kalan belirsizliği saklamadan gösterir.
İkinci haftanın sonunda ana akışın tıklanabilir bir prototipi de hazırdır. Keşif, bu prototipte neyin ve kiminle test edileceğini belirler; test 3. haftada gerçek kullanıcılarla yapılır.
Keşfin sonunda elinizde ne olur?
İki haftanın sonunda bir sunum dosyasından fazlası olmalı: sonraki adımları doğrudan besleyen çalışma belgeleri.
- Bugünkü ve hedeflenen süreci gösteren akış haritası
- Kullanıcı rolleri ve her rolün temel ihtiyaçları
- Sistem ve veri envanteri; entegrasyon yöntemleri ve bilinen riskler
- Ölçülebilir başarı ölçütleri ve nasıl ölçülecekleri
- İlk sürüm kapsam önerisi ve kapsam dışında bırakılanların listesi
- Ana akışın tıklanabilir prototipi ve 3. haftadaki kullanıcı testinin planı
- Aşamalı yol haritası, önerilen ekip ve süre aralığı
- Açık sorular; her biri için kimin, ne zamana kadar yanıt vereceği
Bu belgeler, projeye hangi ekiple devam ederseniz edin kullanılabilir olmalıdır. Keşfin değeri, sonrasında kiminle çalışacağınızdan bağımsızdır.
Varsayımsal bir örnek: nakit yönetimi
Diyelim ki orta ölçekli bir şirketin finans ekibi nakdi beş ayrı banka portalı ve elle güncellenen tablolarla izliyor; ödeme onayları e-posta zincirlerinde bekliyor. İlk talep büyük olasılıkla şöyle olur: “Bütün hesapları tek ekranda görelim, 90 günlük nakit akışını da tahmin edelim.”
Böyle bir keşfin ilk haftasında finans yöneticisinin sabahını yerinde gözlemleriz: hangi portallara hangi sırayla girildiğini, bakiyelerin nereye kopyalandığını, bir ödemenin onay için kimlerden geçtiğini. Envanterde hangi bankaların API sunduğu, vadeli tahsilat bilgisinin ERP’de mi yoksa tablolarda mı tutulduğu netleşir. İkinci hafta tutara ve role göre değişen onay kuralları haritaya dökülür; başarı ölçütü olarak örneğin ödeme onay süresi seçilir.
Bu bulgular kapsamı değiştirebilir. Vade verisi dağınıksa, 90 günlük tahmin ilk sürümde güvenilir sonuç vermez. Bu durumda ilk sürüm önerisi hesap görünümü ve onay akışı olur; tahmin, veri toparlandıktan sonraki aşamaya kalır. Kurumsal Nakit Yönetimi ürün konsepti, böyle bir ürünün nasıl görünebileceğini kurgusal X Ödeme şirketi üzerinden gösteriyor.
Keşif ne zaman gerekir, ne zaman gerekmez?
Her iş için iki haftalık bir keşif gerekmez. Belirsizlik ne kadar büyükse keşfin getirisi de o kadar yüksektir.
| Durum | Keşif gerekir mi? |
|---|---|
| Birden fazla ekibin kullanacağı yeni bir platform | Gerekir. Her ekip süreci farklı yaşar; kapsam tek bir toplantıdan çıkmaz. |
| Eski bir sistemin yerine geçecek ürün | Gerekir. Belgelenmemiş kurallar ancak kullanım gözlemlendiğinde ortaya çıkar. |
| Birçok sisteme bağlanan entegrasyon işi | Gerekir. Veri kalitesi ve erişim yöntemi süreyi doğrudan belirler. |
| Bilinen bir akışa iyi tanımlanmış küçük bir ekleme | Gerekmez. Kullanıcı, veri ve kurallar zaten biliniyor. |
| Tek ekibin kullanacağı, akışı net bir iç araç | Çoğu zaman gerekmez. Kısa bir tanım çalışmasının ardından doğrudan prototiple başlanabilir. |
Ara durumlarda keşif bir haftaya inebilir. Ölçüt basit: ilk sürümün kapsamını bugün bir sayfada, ilgili herkesin onaylayacağı biçimde yazabiliyorsanız uzun bir keşfe ihtiyacınız yoktur.
Keşfe nasıl hazırlanılır?
Keşfin verimi, ilk gün masada kimlerin ve nelerin olduğuna bağlıdır. Hazırlık birkaç gün sürer ve büyük ölçüde bir takvim işidir.
Hazırlık kontrol listesi
- Kararı verecek bir sponsor ve günlük sorumluluğu alacak bir ürün sahibi belirlendi.
- Ürünü her gün kullanacak rollerin her birinden en az bir kişiyle görüşme saati ayrıldı.
- Saha gözlemi için yer ve zaman ayarlandı: depo, çağrı merkezi, finans ekibi ya da saha ekibi.
- Bugün kullanılan tablolar, formlar ve ekran görüntüleri toplandı; kişisel veriler maskelendi.
- Kullanılan sistemlerin listesi, varsa API belgeleri ve teknik sorumluların iletişim bilgileri hazır.
- Daha önce denenen çözümler ve neden bırakıldıkları not edildi.
- Bilinen kısıtlar yazıldı: yasal gereklilikler, güvenlik politikaları, bütçe dönemi, değişmeyecek tarihler.
Görüşmeleri yalnızca yöneticilerle sınırlamak keşfin en büyük riskidir. Süreci en iyi bilenler çoğu zaman onu her gün yürütenlerdir; keşif takviminde onlara mutlaka yer açılmalıdır.
Keşiften sonra ne olur?
Keşif bittiğinde bir sonraki aşamanın girdileri hazırdır. Bizim sürecimizde iş şöyle devam eder:
- Tanım ve prototip (2–3 hafta). Keşifte hazırlanan prototip 3. haftada gerçek kullanıcılarla test edilir; kritik akışların ekranları bu geri bildirimle netleşir. İlk sürümün kapsamı bu testlerin ardından birlikte kesinleşir.
- İnşa (2 haftalık sprintler). Her hafta çalışan yazılımın demosu yapılır. Kapsamı birlikte belirlenen ilk sürüm 6–12. haftada canlıya çıkar.
- Büyüt ve işlet. Başarı ölçütleri canlıda izlenir, yol haritasındaki modüller sırayla eklenir. Büyük programlar tek seferde değil, aşama aşama ilerler: ilk aşama 6–12 haftada canlıya çıkar, sonrakiler yol haritasında planlanır.
Keşif, ürün stratejisi yetkinliğimizin ilk adımıdır; kullanıcı ve saha araştırması, başarı ölçütleri ve yol haritası bu çalışmanın parçalarıdır. Keşiften çıkan kapsam önerisinin nasıl daraltılacağını MVP kapsamının nasıl belirleneceğini anlatan yazımızda ele alıyoruz.
Projenize bir keşif sprintiyle başlamak isterseniz, ilk görüşmede kapsamın iki haftaya uygun olup olmadığını birlikte değerlendirebiliriz.