MVP nedir, kapsamı nasıl belirlenir

MVP, yani en küçük uygulanabilir ürün, bir ürün fikrinin en riskli varsayımını gerçek kullanıcıyla sınamaya yeten en küçük çalışan sürümdür. Tanımdaki önemli kelime “küçük” değil, “sınamak”. Çoğu MVP bu yüzden büyüyor: ekip neyi sınadığını yazmadan neyi yapacağını listelemeye başlıyor.

MVP ne değil

MVP bir prototip değil. Prototip bir fikri göstermek için yapılıyor ve atılıyor; MVP gerçek kullanıcının gerçek işini görüyor.

MVP ürünün ilk sürümü de değil. İlk sürüm satılmak için çıkıyor; MVP öğrenmek için. İkisi aynı kod olabilir, ama kapsam kararını başka sorular veriyor.

Ve MVP “her özelliğin yarısı” değil. On özelliğin hepsini yarım yapmak, hiçbirini sınamamak demek. Tek bir akışı baştan sona, eksiksiz çalıştırmak daha küçük ve daha öğretici.

Önce varsayımı yaz

Kapsam toplantısı özellik listesiyle başladığında liste yalnızca uzuyor. Çünkü her özellik tek başına makul.

Daha iyi başlangıç tek cümle: “Şu kişiler, şu sorun için, bunu kullanır ve karşılığında şunu yapar.” Son kısım önemli. “Kullanır” bir varsayım; “para öder”, “ekibini davet eder”, “ertesi hafta geri gelir” başka başka varsayımlar ve her biri farklı bir ürün gerektiriyor.

Varsayım yazıldıktan sonra her özellik için tek soru kalıyor: bu olmadan varsayım sınanabilir mi? Sınanabiliyorsa özellik ikinci sürümün.

Tek akışı baştan sona kur

Bir SaaS ürününde değeri taşıyan genellikle tek bir akış var: kullanıcı geliyor, bir şey giriyor, bir sonuç alıyor. MVP bu akışın tamamı.

Akışın tamamı derken kayıt, asıl iş ve sonucun kullanıcıya ulaşması kastediliyor. Aradaki adımlardan biri eksikse kullanıcı sonuca varamıyor ve sınadığınız şey ürün değil, eksik adım oluyor.

Akışın dışında kalanlar ise şaşırtıcı ölçüde ertelenebilir: ayrıntılı yetki rolleri, ayarlar sayfası, bildirim tercihleri, dışa aktarma, ikinci dil. Bunların hepsi gerçek ihtiyaç ve hiçbiri ilk varsayımı sınamıyor.

Elle yapılabilen şeyi otomatikleştirme

İlk on kullanıcı için pek çok adım elle yürütülebilir. Hesabı siz açarsınız, faturayı siz kesersiniz, raporu siz hazırlayıp gönderirsiniz.

Bu, kullanıcının gördüğü ürünü değiştirmiyor ama haftalarca geliştirmeyi erteliyor. Daha önemlisi, hangi adımın gerçekten otomatikleşmeye değdiğini gösteriyor. Kimsenin kullanmadığı bir adımın otomasyonunu yazmak, MVP’lerde en sık görülen israf.

Bir sınır var: elle yapılan adım kullanıcıya verilen sözü geciktirmemeli. “Anında” denmişse arkada bir insan beklememeli.

Ertelenemeyenler

Her şey ertelenebilir değil. Üç şey baştan doğru kurulmadığında sonradan düzeltmesi ürünün kendisinden pahalıya geliyor.

Birincisi veri modeli. Birden çok müşteriye hizmet verecek bir üründe verinin müşteriye göre ayrılması ilk günden tasarlanmalı.

İkincisi kimlik ve yetki. Kimin neyi görebildiği sonradan eklenen bir özellik değil, her sorgunun parçası.

Üçüncüsü ölçüm. Varsayımı sınamak için kurulan bir ürün, varsayımın doğrulanıp doğrulanmadığını gösteren olayları kaydetmiyorsa amacını kaçırıyor.

MVP kapsamının beş satırı

1. Sınanan varsayım, tek cümle.
2. O varsayımı sınayan tek akış, adım adım.
3. Elle yürütülecek adımlar.
4. Bilerek ertelenenler, liste hâlinde.
5. Varsayımın doğrulandığını gösteren ölçü.

Dördüncü satır en çok atlananı. Ertelenenler yazılmadığında her biri geliştirme sırasında “küçük bir ekleme” olarak geri geliyor ve MVP, kimsenin karar vermediği bir ilk sürüme dönüşüyor.