MVP denince çoğu ekip hâlâ şunu anlıyor:
“Hızlıca bir şey çıkaralım, kullanıcıdan geri bildirim alırız.”
Bu cümle kulağa doğru geliyor.
Ama sahada gördüğümüz sorunların büyük kısmı bu yaklaşımın nasıl uygulandığıyla ilgili.
Çünkü MVP’lerde asıl risk:
- eksik özellikler değildir,
- kaba arayüzler değildir,
- hatta hatalar bile değildir.
Asıl risk, yanlış şeylerin erken kilitlenmesidir.
MVP’de neden bu kadar çok yanlış karar alınır?
Erken aşamada üç şey aynı anda olur:
- belirsizlik çok yüksektir
- zaman baskısı vardır
- kararların etkisi düşündüğümüzden büyüktür
Bu ortamda alınan kararlar genellikle şu niyetle alınır:
“Şimdilik böyle olsun.”
Sorun şu ki, MVP aşamasında “şimdilik” dediğimiz şeyler,
çoğu zaman kalıcı hale gelir.
Bu yüzden birçok ürün,
daha büyümeden manevra kabiliyetini kaybeder.
MVP’yi ürün gibi tasarlamak en yaygın hata
Sahada en sık gördüğümüz hatalardan biri şudur:
MVP, küçük ama tamamlanmış bir ürün gibi ele alınır.
Oysa MVP’nin amacı:
- çalışmak değil,
- öğrenmektir.
Şu sorular net cevaplanmadan yapılan MVP’ler risklidir:
- Bu MVP ile hangi varsayımı test ediyoruz?
- Test etmediğimiz şeyleri neden özellikle dışarıda bırakıyoruz?
- Bu MVP başarısız olursa ne öğreneceğiz?
Bu sorular sorulmadığında MVP,
ürün olmaya çalışan ama
ne olduğu net olmayan bir ara forma dönüşür.
(→ Yazılım Projelerinde Kararlar Neden Zamanla Ürünü Kilitler?)
“Sonra değiştiririz” en pahalı cümledir
MVP aşamasında teknik kararlar alınırken sıkça şu cümle kurulur:
“Sonra değiştiririz.”
Bu cümle tek başına yanlış değildir.
Ama hangi koşulda değiştirileceği hiç konuşulmazsa,
ileride ciddi bedeller doğurur.
Örneğin:
- yetkilendirme yapısı,
- veri modeli,
- modülerlik kararları
Bunlar MVP’de basit tutulabilir.
Ama ne zaman karmaşıklaşacağı tanımlanmazsa,
ürün büyüdüğünde herkes bu kararlardan kaçınmaya başlar.
(→ Ürün Büyürken Teknik Borç Nerede ve Neden Problem Olur?)
MVP’de hız mı, esneklik mi?
MVP genellikle hızla ilişkilendirilir.
Ama sahada gördüğümüz şudur:
Hızlı yapılan MVP’ler değil,
esnek tasarlanan MVP’ler hayatta kalır.
Esneklik demek:
- her şeyi doğru yapmak değil,
- geri alınabilir kararlar almaktır.
İyi bir MVP:
- bazı şeyleri bilerek kötü yapar
- ama hangi kararların geçici olduğunu bilir
Bu ayrım yapılmadığında MVP,
ilk versiyon olmaktan çıkıp
erken bir legacy’ye dönüşür.
(→ Mevcut (Legacy) Sistemler Neden Gerçekten Zordur?)
MVP sonrası “şimdi ne yapacağız?” sorusu neden sık sorulur?
Birçok ekip MVP tamamlandıktan sonra şu noktaya gelir:
“Tamam, çalışıyor… şimdi ne yapacağız?”
Bu soru MVP bittikten sonra değil,
MVP’ye başlamadan önce cevaplanmalıdır.
Eğer MVP’nin sonunda:
- hangi kararların değişeceği,
- hangi alanların yeniden ele alınacağı,
- ürünleşme için neyin gerekli olduğu
net değilse,
MVP sadece “ilk sürüm” olur.
Öğretici bir araç olmaktan çıkar.
Sağlıklı MVP’lerde ortak bir refleks
Sahada daha sağlıklı ilerleyen ekiplerde ortak bir refleks görüyoruz:
- MVP kararları yazılıdır (en azından zihinsel olarak)
- “Bu karar geçicidir” net şekilde bilinir
- büyüme senaryosu erkenden konuşulur
Bu ekipler MVP’yi:
- acele edilmesi gereken bir iş değil,
- bilinçli olarak sınırlanmış bir deney olarak görür.
Bu bakış açısı,
ürünün ilerleyen aşamalarında
çok daha az kilitlenme yaşanmasını sağlar.
Kapanış
MVP’nin en büyük riski,
eksik olması değildir.
Asıl risk:
yanlış şeyleri erken ciddiye almaktır.
Bu yüzden MVP’de sorulması gereken asıl soru şudur:
“Hangi kararları bilerek erteliyoruz
ve hangi koşulda geri dönüp bakacağız?”
Bu soruya net cevap veren ekipler,
MVP’yi sadece hızlı başlatmaz,
sağlam devam eder.
