Birçok ekip MVP’ye şu beklentiyle başlar:
“Hızlıca bir şey çıkaralım, sonra bakarız.”
Bu yaklaşım masum görünür ama MVP projelerinin önemli bir kısmı tam da bu noktada raydan çıkar. Çünkü MVP’de yapılan hataların çoğu eksik geliştirmeden değil, yanlış karar önceliklendirmesinden kaynaklanır.
MVP’nin amacı kod yazmak değil, öğrenmektir.
Ancak pratikte MVP’ler çoğu zaman:
- yarım ürünlere,
- teknik borçlu prototiplere,
- veya “nasıl devam edeceğimizi bilmiyoruz” noktasına dönüşür.
Sorun MVP kavramında değil, MVP’ye nasıl yaklaşıldığında.
MVP neden erken aşamada bu kadar risklidir?
Erken aşamada üç şey aynı anda doğrudur:
- Belirsizlik yüksektir
- Zaman baskısı vardır
- Kararların etkisi orantısız büyüktür
Bu kombinasyon tehlikelidir.
MVP aşamasında alınan küçük bir karar:
- yanlış kullanıcıyı hedeflemenize,
- yanlış problemi çözmenize,
- ya da ürünü erken kilitlemenize neden olabilir.
Üstelik bu kararlar genellikle “mantıklı” gerekçelerle alınır:
- “Bunu da ekleyelim hazır yapıyorken”
- “Sonra değiştiririz”
- “Şimdilik böyle gitsin”
MVP’yi riskli yapan şey eksiklikler değil,
yanlış varsayımların erken kodlanmasıdır.
MVP’de en sık yapılan yanlış kararlar
MVP’yi küçük ürün gibi tasarlamak
MVP çoğu zaman “küçük ama tam” bir ürün gibi düşünülür.
Oysa MVP, bilinçli olarak eksik olmalıdır.
Şu sorular sorulmadan yapılan MVP’ler sorunludur:
- Bu MVP ile tam olarak neyi test ediyoruz?
- Test etmediğimiz şeyleri neden özellikle dışarıda bırakıyoruz?
Her özelliğin bir maliyeti vardır.
Ama MVP’de asıl maliyet, yanlış şeyi test etmektir.
Teknik kararları “nasıl olsa değiştiririz” diye almak
Erken aşamada teknik kararların geri alınabilir olması gerekir.
Ama pratikte MVP’lerde şunları sık görürüz:
- erken mimari katmanlaşma
- gereksiz ölçeklenme kurguları
- henüz ihtiyaç olmayan optimizasyonlar
Bu kararlar MVP’yi daha sağlam yapmaz.
Sadece hareket kabiliyetini azaltır.
MVP’de teknik mükemmeliyet değil,
karar esnekliği önemlidir.
MVP’yi hız projesi gibi görmek
“MVP hızlı yapılır” düşüncesi en yaygın yanılgılardan biridir.
MVP hızlı kodlanabilir,
ama hızlı öğrenme üretmiyorsa amacını kaçırmıştır.
Gerçek hayatta sık gördüğümüz tablo şudur:
- MVP hızla çıkar
- ama ne öğrendiğimiz belirsizdir
- sonraki adım net değildir
Bu noktada ekip şunu sorar:
“Şimdi ne yapacağız?”
Bu soru MVP bittikten sonra değil,
MVP’ye başlamadan önce cevaplanmalıdır.
Daha sağlıklı bir MVP karar çerçevesi
İyi bir MVP şu özellikleri taşır:
- Test edilen varsayım nettir
- Test edilmeyen konular bilinçli olarak dışarıda bırakılmıştır
- Teknik kararlar mümkün olduğunca geri alınabilirdir
MVP öncesinde şu sorulara net cevap verilmelidir:
- Bu MVP başarısız olursa ne öğreneceğiz?
- Başarılı olursa hangi kararları değiştireceğiz?
- Hangi kararları özellikle kilitlemiyoruz?
Bu sorulara cevap yoksa,
MVP büyük ihtimalle sadece “ilk versiyon”dur.
MVP ile ürün arasındaki geçiş neden zor olur?
Birçok ekip MVP’den sonra şuraya takılır:
- “Bunu devam mı ettireceğiz?”
- “Baştan mı yazmalıyız?”
- “Bu mimariyle büyüyebilir miyiz?”
Bu soruların ortaya çıkması sürpriz değildir.
Çünkü MVP sırasında:
- ürünleştirme kararları,
- büyüme varsayımları,
- teknik sınırlar
bilinçli olarak netleştirilmemiştir.
Sorun MVP’nin yetersiz olması değil,
MVP’nin hangi noktaya kadar MVP olarak kalacağının net olmamasıdır.
Gerçek hayatta sık karşılaşılan senaryolar
MVP sonrası şu işaretler sık görülür:
- Yeni özellik eklemek beklenenden zor geliyordur
- Küçük değişiklikler büyük yan etkiler yaratıyordur
- “Şimdilik idare eder” kararları birikmiştir
Bu noktada ekip genellikle teknik bir problem arar.
Oysa sorun çoğu zaman daha eskidedir:
MVP sırasında alınmış, ama hiç sorgulanmamış kararlar.
Başlangıçta biraz daha yavaş ama daha bilinçli ilerleyen ekipler,
MVP sonrasında çok daha net bir yol haritasına sahip olur.
Kapanış
MVP, hız yarışını kazanmak için değil,
doğru soruları sormak için vardır.
Erken aşamada alınan kararlar:
- ürünün ne olacağını,
- ama daha önemlisi ne olamayacağını belirler.
Bu yüzden MVP’de asıl mesele “ne yapıyoruz” değil,
“hangi kararları bilerek erteliyoruz” sorusudur.
