MVP Nedir? İlk Sürümün Kapsamı Nasıl Belirlenir?

MVP, minimum viable product ifadesinin kısaltmasıdır. Ürün geliştirmede, temel bir değer önerisini gerçek kullanımla sınayabilecek en dar ürün kapsamını anlatmak için kullanılır. Burada “minimum”, yalnızca az sayıda ekran veya özellik demek değildir. Kullanıcının anlamlı bir işi tamamlayabilmesi gerekir.

Bir ilk sürümün sınırı, öğrenmek istediğiniz soruya göre çizilmelidir. “İnsanlar bunu kullanabilir mi?”, “Bu sonuç işlerine yarıyor mu?” ve “Tekrar kullanıyorlar mı?” farklı sorulardır. Tek bir lansmanın hepsini kesin biçimde cevaplamasını beklemeyin.

İlk sürüm için tek bir ana iş seçin

Bir ürün fikrinin çevresinde çok sayıda özellik birikir. Takvim, rapor, sohbet, otomasyon ve kişiselleştirme kendi başlarına faydalı görünebilir. İlk sürümde hepsinin bulunması gerekip gerekmediğini anlamak için şu cümleyi tamamlayın:

“Bu ürün sayesinde kullanıcı, … işini baştan sona tamamlayabilecek.”

Örnek bir dosya değerlendirme aracında bu iş, bir dosyayı paylaşmak ve karşı tarafın kararını görmek olabilir. Tema seçimi veya gelişmiş istatistikler bu ana işin ön koşulu olmayabilir. Buna karşılık yanlış kişiye dosya gösterilmesini önlemek temel gereksinimdir.

Özellikleri üç soruyla değerlendirin

İlk soru, özelliğin ana iş için zorunlu olup olmadığıdır. Kullanıcı bu özellik olmadan işi tamamlayamıyorsa kapsamda kalması güçlü bir adaydır.

İkinci soru, özelliğin sınadığınız varsayımla ilişkili olup olmadığıdır. İlk öğrenme hedefiniz dosya onayını kolaylaştırmaksa, geniş bir raporlama alanı bu soruya cevap vermeyebilir.

Üçüncü soru, özelliğin ertelenmesinin doğuracağı sonuçtur. Görsel bir seçenek sonraya kalabilir. Kullanıcının verisini kaybetmesine neden olacak bir boşluk aynı biçimde ele alınamaz.

Bu değerlendirmeyi kısa bir karar notuyla yapın. “Şimdilik yok” cümlesinin yanına nedenini ve hangi gözlemden sonra yeniden bakacağınızı ekleyin. Böylece kapsam dışına çıkan fikirler her toplantıda baştan tartışılmaz.

Prototip ile çalışan ilk sürümü ayırın

Tıklanabilir bir prototip, insanların ekranı anlamasını sınamak için kullanışlıdır. Ancak verilerin gerçekten kaydedildiğini veya ürünün günlük işte sürdürülebilir olduğunu göstermez. Çalışan bir ilk sürüm ise gerçek işlemleri ve bunların sonuçlarını gözlemleme fırsatı verir.

GOV.UK’nin keşif yaklaşımı, çözüm geliştirmeye bağlanmadan önce problemin anlaşılmasına önem verir. Bu ayrım MVP için de yararlıdır: Problem hâlâ belirsizse, önce daha ucuz bir araştırma adımı gerekebilir. GOV.UK — How the discovery phase works

Hangi aracı kullanırsanız kullanın, sınamanın sınırını belirtin. Bir ekranı beğenmek, o ürün için ödeme yapmakla aynı kanıt değildir.

Küçük kapsamda da hata anlarını düşünün

İlk sürüm tasarlarken yalnızca başarılı akışı çizmek eksik bir resim oluşturur. Dosya yüklenmezse ne olur? Bağlantı kesilirse kullanıcı yaptığı işi kaybeder mi? Yanlış bilgi girildiğinde geri dönülebilir mi?

Her olasılık için karmaşık bir sistem kurmanız gerekmez. Ancak sık karşılaşılabilecek sorunlarda kullanıcıya anlaşılır bir durum ve ilerleme yolu sunmalısınız. Küçük bir ürünün de verdiği sözü tutması gerekir.

İlk sürümden ne öğrendiğinizi yazın

Yayın sonrasında yalnızca kayıt sayısına bakmayın. Ana işi başlatan ve tamamlayan kişileri, yardım istenen adımları ve uygun zaman aralığında geri dönüşü inceleyin. Ürün haftada bir kullanılan bir işi çözüyorsa, günlük kullanım beklentisi yanıltıcı olabilir.

Bulguları üç başlıkta toplayın: işe yarayanlar, zorlayanlar ve henüz bilinmeyenler. Sonraki sürümü bu ayrımdan çıkarın.

Pist Studio’nun ürün geliştirme yönü için iyi bir ilk sürüm, anlaşılır bir amacı olan ve geliştirilecek yönleri görünür kılan sürümdür. Kapsamı daraltırken o amacı koruyun; yeni özellik eklerken de aynı soruya dönün: Kullanıcının hangi işini daha iyi tamamlamasını sağlıyor?