MVP'yi 6 Haftada Nasıl Çıkarırız?

"MVP'yi 3 ayda çıkaralım" diyen ekiplerin çoğu 9 ayda çıkarıyor. Sebep tembellik değil; kapsamın süreç içinde büyümesi. Altı haftalık bir takvim, kapsamı büyümeye karşı korumanın en etkili yolu: süre kısa olduğu için her yeni fikir "bu ilk sürüme girer mi?" sorusuna çarpıyor.

Aşağıda kendi projelerimizde uyguladığımız altı haftalık akışı hafta hafta paylaşıyoruz. Bu bir şablon değil, bir disiplin.

Önce: MVP ne değildir?

MVP, ürünün küçük hâli değil. MVP, en riskli varsayımınızı test eden en küçük şey. Bu ayrım pratikte şu farkı yaratıyor: ürünün küçük hâlini yapmak için tüm ekranları yarım yaparsınız; varsayımı test etmek için tek bir akışı tam yaparsınız.

• MVP, ayarlar ekranı olmayan bir üründür — ayarlar riskli varsayım değildir.
• MVP, admin paneli yerine veritabanına elle yazmayı kabul eder.
• MVP, üç ödeme sağlayıcısı yerine bir tanesini destekler.
• MVP, kullanıcının parasını ya da zamanını vermeye razı olup olmadığını ölçer.

Hafta 1 — Kapsamı kesmek

İlk hafta kod yazılmaz. Bu haftanın çıktısı tek sayfalık bir kapsam belgesidir: kim için, hangi problem, hangi tek akış, başarı ölçütü ne.

1. Hedef kullanıcıyı tek cümleyle tanımlayın; "herkes" bir cevap değildir.
2. En riskli varsayımı yazın: bu yanlışsa ürün anlamsız olur diyebileceğiniz şey.
3. O varsayımı test eden tek kullanıcı akışını çizin, baştan sona.
4. Akışın dışında kalan her şeyi "sonra" listesine yazın — silmeyin, listeye yazın. Silinen fikirler geri gelir, listeye yazılanlar beklemeye razı olur.

Hafta 2 — Tasarım ve veri modeli birlikte

Tasarım ve veri modeli ayrı ayrı yapıldığında ikisi de yeniden yapılır. Aynı hafta içinde ilerlettiğinizde arayüzün gerektirdiği veri ile veritabanının verebileceği veri erkenden hizalanır.

Bu haftanın sonunda tıklanabilir bir prototip ve şema taslağı hazır olur. Prototipi 5 kişiye gösterin. Beş kişi, istatistiksel anlamlılık için az; ama açık kullanılabilirlik hatalarını bulmak için fazlasıyla yeterli.

Hafta 3-4 — Tek akışı uçtan uca çalıştırmak

İki haftanın hedefi net: seçtiğiniz tek akış gerçekten çalışsın. Kayıt olan bir kullanıcı, akışı tamamlayıp sonucu görebilsin. Yarım kalan ikinci akış yerine tam çalışan tek akış her zaman daha değerlidir.

Sağ sütundakiler kötü fikirler değil; sadece bu altı haftanın işi değiller. Ürün doğrulandıktan sonra hepsi sıraya girer.

Hafta 5 — Gerçek kullanıcıyla test

Beşinci hafta lansman haftası değil, test haftası. Ürünü sınırlı bir gruba açın ve izleyin. Burada aranan şey övgü değil, takılma noktası.

• Kullanıcıya ne yapacağını söylemeyin; nereye tıkladığını izleyin.
• "Beğendiniz mi?" diye sormayın. "Bunun için para öder miydiniz?" diye sorun.
• Terk edilen adımı bulun; terk oranı en yüksek ekran, ilk düzeltilecek yerdir.
• Geri bildirimleri özellik isteği olarak değil, problem ifadesi olarak kaydedin.

Hafta 6 — Yayın ve ilk ölçüm

Son hafta ürünü yayına almak, temel analitiği kurmak ve ilk kullanıcıları getirmekle geçer. Analitik kurulmadan yapılan lansman, sonucu ölçülemeyen bir deneydir.

1. Dönüşüm hunisinin her adımını olay olarak işaretleyin.
2. Tek bir kuzey yıldızı metriği seçin ve ekrana asın.
3. İlk 20 kullanıcıyla birebir konuşun — ölçekleme sonra gelir.
4. İlk iki haftanın verisine göre "sonra" listesini yeniden sıralayın.

Altı hafta neden işe yarıyor?

Altı hafta, bir ekibin odağını kaybetmeden koşabileceği en uzun süre. Daha kısası kapsamı gerçekçi olmaktan çıkarır, daha uzunu aciliyeti öldürür. Ayrıca altı hafta, bir yatırımcı görüşmesi ile bir sonraki arasındaki tipik süreye denk düşer; yani her turda elinizde yeni bir kanıt olur.

Bu takvimin çalışmasının tek şartı var: kapsam belgesine sadık kalmak. Üçüncü haftada eklenen "küçük" bir özellik, altıncı haftayı dokuzuncu haftaya taşır.