MVP (minimum uygulanabilir ürün) çoğu ekipte “küçültülmüş ürün” olarak anlaşılıyor. Oysa amaç ürünü küçültmek değil, bir varsayımı en hızlı şekilde test etmek. Bu ayrım netleşmediğinde ilk sürüm hem geç çıkar hem de öğrenme sağlamaz.
Önce varsayımı yazın, sonra özelliği
Her özellik bir varsayımın karşılığıdır. Özelliği yazmadan önce onu doğuran cümleyi yazın: “Kullanıcı X işini bugün Y şekilde yapıyor ve bu ona pahalıya mal oluyor.” Varsayımı tek cümlede yazamıyorsanız, o özellik ilk sürüme girmemeli.
Kapsamı üç kovaya ayırın
| Kova | Ne içerir | İlk sürümde |
|---|---|---|
| Çekirdek | Ürünün var olma sebebi olan tek akış | Evet |
| Destek | Çekirdek akışı çalışır kılan asgari şeyler (kayıt, hata durumu) | Asgari düzeyde |
| Konfor | Panolar, temalar, dışa aktarma, entegrasyonlar | Hayır |
Kendi ürünlerimizde bu ayrımı somut tuttuk. Yüzdebin'de çekirdek akış tek bir şeydi: kullanıcı bir hesaplayıcıya girsin, kayıt olmadan sonucu görsün. Hesaplayıcıların ortak bir motor ve registry üzerinde durması sayesinde “yüzlerce araç” hedefi ilk sürümün kapsamına değil, mimarisine yazıldı.
Çıkarmayı kolaylaştıran üç soru
- Bu özellik olmadan kullanıcı işini bitirebiliyor mu? Bitiriyorsa ertelenebilir.
- Bu özelliği elle (manuel) yapabilir miyiz? İlk 100 kullanıcı için elle yapılan iş, yazılmamış koddan ucuzdur.
- Bu özelliği çıkarmak öğrenmemizi engelliyor mu? Engellemiyorsa kapsam dışıdır.
Kapsamı mimariyle koruyun
İlk sürümü dar tutmanın bedeli, sonradan gelen her özelliğin sistemi bozmasıdır. Bunu engellemenin yolu, ürünü veri odaklı kurmaktır: içerikler, araçlar ve sayfalar tek bir kayıt listesinden besleniyorsa yeni bir birim eklemek arayüzü değil yalnızca veriyi değiştirir. Bu sitede projeler ve yazılar da aynı mantıkla, tek bir veri dosyasından üretiliyor.
İlk sürümün başarısı kaç özellik içerdiğiyle değil, ikinci sürümü ne kadar hızlı yazdırdığıyla ölçülür.