MVP Gerçekten Ne Kadar Minimum Olmalı?

MVP tartışmaları neredeyse her zaman kapsam tartışması olarak başlar: bu özellik girsin mi, şu ekran ilk sürümde olsun mu.

Bu tartışmaların uzamasının sebebi genellikle listenin uzunluğu değildir. Kimsenin şu soruyu yazmamış olmasıdır: bu sürümle neyi öğrenmek istiyoruz?

Cevap yoksa "minimum" ölçüsüz bir kelimedir. Herkes kendi sezgisine göre bir sınır çizer ve kapsam, en ısrarcı kişinin görüşüne göre şekillenir.

Eksik ürün ile minimum ürün aynı şey değil

İkisi dışarıdan benzer görünür: ikisinin de özelliği azdır. Fark, azaltmanın hangi eksende yapıldığındadır.

Minimum ürün daralmış bir üründür: daha az kullanıcı tipine, daha az kullanım senaryosuna hitap eder, ama hitap ettiği yerde işi baştan sona bitirir. Kullanıcı geldiği işi tamamlar ve bunu yaparken bir şeyin yarım olduğunu hissetmez.

Eksik ürün ise delinmiş bir üründür: kapsam geniştir ama her yolun ortasında bir boşluk vardır. Kullanıcı üç adım ilerler, dördüncüde bir e-posta göndermesi veya birini araması gerekir.

Bu ayrım pratikte tek bir soruya indirgenebilir: ilk sürümde kullanıcı, seçtiğiniz dar senaryoyu yardımsız tamamlayabiliyor mu? Cevap evetse ürün minimumdur; hayırsa eksiktir — kapsamı ne kadar küçük olursa olsun.

Önce hipotez, sonra kapsam

MVP'nin amacı ürünü küçültmek değil, bir belirsizliği azaltmaktır. Bu yüzden doğru sıra, kapsamdan değil sorudan başlar.

İyi bir hipotez üç şey içerir: neye inandığınız, bunu neyle ölçeceğiniz ve hangi sonucun sizi fikrinizden döndüreceği. Son kısım en çok atlanandır ve en değerlisidir; çünkü hiçbir sonucun değiştiremeyeceği bir hipotez aslında bir hipotez değildir.

Hipotez yazıldığında kapsam kendiliğinden daralır. "Bu kullanıcı grubunun, bu işi bizim yöntemimizle yapmayı tercih edip etmeyeceğini öğrenmek istiyoruz" cümlesi, hangi ekranların gerektiğini de söyler — ve daha önemlisi, hangilerinin gerekmediğini.

Hipotezin bir başka faydası, başarısızlığı okunabilir kılmasıdır. Ölçüt önceden yazılmadığında, düşük kullanım her zaman "pazarlama yetersizdi" ile açıklanabilir ve hiçbir şey öğrenilmez.

Kesilebilenler ve kesilemeyenler

Kapsam daraltmanın güvenli ve güvensiz eksenleri vardır.

Güvenle kesilebilenler:

Kullanıcı çeşitliliği. Tek bir kullanıcı tipine hizmet edip diğerlerini sonraya bırakmak, ürünü bozmaz. Yönetici paneli olmadan da bir ürün çalışabilir.

Senaryo sayısı. Ana akışı yapıp kenar durumları elle karşılamak makuldür — yeter ki elle karşılandığı bilinsin ve kullanıcıya yansımasın.

Otomasyon derecesi. İlk sürümde arkada birinin elle yaptığı bir iş, ürünün çalışmadığı anlamına gelmez. Aksine, o işi otomatikleştirmeye değip değmeyeceğini öğrenmenin en ucuz yoludur.

Ölçek hazırlığı. Yüz kullanıcı için çalışan bir sistem, yüz bin için hazır olmak zorunda değildir.

Kesilmemesi gerekenler:

Kullanılabilirlik. Dar bir kapsamda bile kullanıcı ne yapacağını anlamalıdır. Kullanılabilirlik kesildiğinde ölçüm bozulur: ürün mü işe yaramadı, arayüz mü anlaşılmadı — ayırt edilemez. Bu ayrımı güzel görünen ama kullanılamayan arayüzler yazısında ayrıca ele almıştık.

Veri bütünlüğü ve güvenlik. Gerçek kullanıcı verisi giriyorsa, "geçici" olması hiçbir şeyi hafifletmez.

Temel teknik sağlamlık. Sürüm alınabilmesi, geri alınabilmesi ve bir şey bozulduğunda görülebilmesi ilk günden gerekir.

Kime gösterildiği, ne gösterildiği kadar önemli

Kapsam doğru daraltılsa bile, yanlış kitleye gösterilen bir MVP yorumlanamaz bir sonuç üretir.

İki yönlü hata yapılır. Birincisi fazla dost bir kitledir: mevcut müşteriler, tanıdıklar, ekibin yakın çevresi. Bu grup ürünü kullanır çünkü ilişkiyi önemser; geri bildirimi nazik, kullanımı ise gerçek ihtiyaçtan bağımsızdır. Böyle bir gruptan gelen olumlu sinyal, ürünün işe yaradığını değil ilişkinin iyi olduğunu gösterir.

İkincisi fazla geniş bir kitledir. Herkese açılan bir ilk sürümde kullanıcıların çoğu, ürünün çözdüğü problemi zaten yaşamıyordur. Düşük kullanım bu durumda hiçbir şey söylemez, çünkü ölçüm hedef dışı insanlarla yapılmıştır.

Doğru kitle genellikle küçüktür ve tek bir özellikle tanımlanır: problemi bugün yaşıyor olmak. Bu kişiler ürünü kibarlıktan değil ihtiyaçtan kullanır ve bıraktıklarında sebebi ürünle ilgilidir — ki asıl öğrenilmek istenen budur.

Sayı da önemlidir. Beş ila on gerçek kullanıcı, yüzlerce ilgisiz kayıttan daha fazla bilgi verir. Az sayıda kullanıcıyla çalışmanın ek bir avantajı, her birini yakından izleyebilmektir: nerede takıldıkları, neyi yanlış anladıkları ve hangi adımı atladıkları doğrudan görülebilir.

Bu grup seçilirken bir şeyi baştan söylemek de işe yarar: bu bir ilk sürümdür, eksikler bilinçlidir ve geri bildirim beklenmektedir. Beklenti doğru kurulduğunda, eksiklikler güven kaybına değil katkıya dönüşür.

Kırılgan prototip tehlikesi

En sık karşılaşılan sonuçlardan biri, hızlı yapılmış bir prototipin üretime alınmasıdır.

Bu genellikle kötü bir kararla olmaz. Prototip beklenenden iyi çalışır, birileri onu müşteriye gösterir, müşteri kullanmak ister ve geçici olan kalıcı hâle gelir. Kimse "bunu üretime alalım" demez; yalnızca kimse durdurmaz.

Bunun bedeli hemen görünmez. Birkaç ay sonra, üzerine eklenen her yeni özellik beklenenden uzun sürmeye başlar — çünkü temel, taşımak için kurulmamıştı. Bu, teknik borcun en pahalı biçimlerinden biridir, zira bilinçli bir ödünleşme olarak kaydedilmemiştir.

Korunma yolu sadedir: prototipin atılabilir olduğu baştan söylenir ve üretime alınacaksa bunun ayrı bir karar olduğu kabul edilir. "Zaten çalışıyor" bir gerekçe değildir.

Zaten müşterisi olan bir üründe MVP

MVP kavramı genellikle sıfırdan başlayan ürünler için anlatılır. Oysa çoğu şirket bunu mevcut ve çalışan bir ürünün içine yeni bir yetenek eklerken uygular — ve koşullar orada farklıdır.

Mevcut müşteriler bir ilk sürümü aynı hoşgörüyle karşılamaz, çünkü onlar için bu bir deneme değil, kullandıkları ürünün yeni bir parçasıdır. Yarım kalmış bir akış, yeni bir üründe "henüz erken" olarak okunurken olgun bir üründe kalite düşüşü olarak okunur.

Bu durumda işe yarayan yol, kapsamı değil kitleyi sınırlamaktır. Yeni yetenek, isteyen veya seçilen bir gruba açılır; geri kalan kullanıcılar mevcut akışı kullanmaya devam eder. Böylece öğrenme sağlanır, güven riske atılmaz.

İkinci nokta, geri dönüş yolunun açık tutulmasıdır. Yeni akış beklendiği gibi çalışmazsa kullanıcının eskisine dönebilmesi gerekir. Bu, hem riski düşürür hem de tercihin kendisini bir ölçüm hâline getirir: kaç kişi yeni yolda kaldı?

MVP sonrası

MVP'nin en çok ihmal edilen kısmı, sonrasında ne olacağıdır.

Ölçüm yapıldıktan sonra üç seçenek vardır ve üçü de meşrudur: devam etmek, yönü değiştirmek veya durdurmak. Üçüncüsü genellikle hiç konuşulmaz, bu yüzden de hiç seçilmez — ürün, kimse karar vermediği için yaşamaya devam eder.

Kararı kolaylaştıran şey, ölçütün baştan yazılmış olmasıdır. Ayrıca bir tarih belirlemek işe yarar: bu sürümü ne kadar süre izleyeceğiz ve ne zaman karar vereceğiz?

Devam kararı verildiğinde ise ilk iş genellikle yeni özellik eklemek değildir. MVP sırasında bilinçli olarak ertelenen şeylerin listesi vardır; o liste yol haritasının başına konmadığında sessizce kaybolur.

Sonuç

"Ne kadar minimum" sorusunun tek bir doğru cevabı yoktur, çünkü doğru cevap hipoteze bağlıdır. Öğrenmek istediğiniz şey netleştiğinde kapsam tartışması genellikle kendiliğinden biter.

Pratikte iyi bir MVP, dar bir alanda tam çalışan bir üründür. Kullanıcı için küçük ama bütün hissettirir; ekip için ise sonraki kararın dayanağını üretir.

Yazılım danışmanlığı çalışmalarımızda ilk sürüm kapsamını genellikle özellik listesinden değil, "bu sürüm hangi soruyu cevaplayacak" sorusundan çıkarıyoruz.