İlk MVP neleri içermeli?

1. Kullanıcıyı, problemi ve soruyu seç.

MVP (minimum viable product), önemli bir varsayımı sınamak için geliştirilen, kullanılabilir bir ilk ürün sürümüdür. Ekranları listelemeden önce ürünü kimin deneyeceğini, bugün neyle zorlandığını ve kullanımından ne öğrenmen gerektiğini yaz.

Şu cümleyi tamamla: “İlk sürüm, [belirli kullanıcının] [bir işi] tamamlamasına yardımcı olur; böylece [belirli bir varsayımın doğru olup olmadığını] öğrenebiliriz.” Soru yalnızca insanların bir ekranı anlayıp anlamadığıysa prototip yeterli olabilir.

2. Akışın tamamını tarif et.

Ürüne girişten işe yarar bir sonuç almaya kadar olan adımları yaz. Kullanıcının hangi bilgileri girdiğini, ürünün ne yaptığını ve kullanıcının işin bittiğini nasıl anladığını belirt. Kullanıcı ekranlar arasında takılıp kalıyorsa ekranların güzel olması yetmez.

Bağımsız özel ders öğretmenleri için varsayımsal bir rezervasyon aracı düşün. İlk akış şöyle olabilir: öğretmen uygun saatlerini paylaşır, öğrenci bir saat seçer ve ikisi de onay alır. İptal durumunda veya başkasının az önce aldığı bir saat seçildiğinde ne olacağını da yaz.

3. Gerekli özellikleri sonraki fikirlerden ayır.

Her özellik için şunu sor: “Bu olmadan ilk kullanıcı ana işi tamamlayabilir mi, biz de sorumuzun yanıtını öğrenebilir miyiz?” İkisinden biri için gerekli olan özellikleri tut. Diğerlerini, neden yeniden ele alınacağına dair kısa bir notla sonraki işler listesine al.

Öğretmen örneğinde uygun saatler, rezervasyon, onay ve aynı saatin iki kişiye verilmesini önlemek ilk kapsama girer. Özel profil temaları, arkadaş davet programı veya çok şubeli yönetim paneli ilk deneme için gerekli değilse bekleyebilir.

Başlangıçta bazı işler elle yapılabilir. Kurucu, herkesin kendi başına kullanacağı bir kurulum sihirbazı geliştirmek yerine ilk öğretmenlerin kurulumuna bizzat yardımcı olabilir. Bu işi kimin yapacağını ve kullanıcıların ne beklemesi gerektiğini açıkça belirt.

4. Prototipin yeterli olup olmadığına karar ver.

Tıklanabilir prototip; gezinmeyi, metinleri ve bir etkileşimin anlaşılıp anlaşılmadığını kontrol etmek için yararlıdır. Hizmetin gerçek verilerle çalıştığını, insanların geri geleceğini veya ödeme yapacağını tek başına göstermez.

Gerçek rezervasyonları, yüklenen dosyaları veya tamamlanan başka bir işi gözlemlemen gerekiyorsa ürünün o kısmının gerçekten çalışması gerekir. Belirsiz bir entegrasyona bağlı özelliğe yatırım yapmadan önce küçük bir teknik deneme de yararlı olabilir. Sonraki adımı çözmen gereken belirsizliğe göre seç.

5. Temel gereksinimleri ilk sürümden çıkarma.

Küçük kapsamlı bir ürün de işlediği bilgi ve verdiği sözler konusunda sorumlu davranmalı. Proje tahmininden önce şu temelleri konuş:

• Erişim: hangi bilgiyi kimin görebileceği veya değiştirebileceği ve hesap gerekip gerekmediği.
• Hata durumları: geçersiz bir giriş yapıldığında, bir istek başarısız olduğunda veya biri aynı işlemi tekrarladığında ne olacağı.
• Veri: neyin saklanacağı, nasıl silinebileceği ve neyin yedeklenip geri yüklenebilmesi gerektiği.
• Bağımlılıklar: dış hizmetler, işletme maliyetleri ve bir sağlayıcıya ulaşılamadığında ne olacağı.
• Kullanım ve destek: desteklenen cihazlar, temel işlemlerin erişilebilir olması ve sorun bildirmek için anlaşılır bir yol.

6. Yayından sonra ne öğreneceğini belirle.

Başlangıçtaki soruyla bağlantılı bir gözlem seç. Öğretmen örneğinde öğrencilerin yardım almadan rezervasyonu tamamlayıp tamamlayamadığına, işlemi akışın hangi adımında yarıda bıraktıklarına ve öğretmenlerin tekrar kullanıp kullanmadığına bak.

İlk kullanıcıları kimin davet edeceğini, geri bildirimleri kimin toplayacağını ve değerlendireceğini kararlaştır. Kullanım olaylarını kaydedeceksen hangilerine ihtiyaç duyduğunu ve kullanıcıların gizliliğini nasıl koruyacağını belirle. Yalnızca sayfa ziyaretleri, rezervasyon akışının işe yarayıp yaramadığını göstermez.

Hangi bulguların akışı iyileştirmene, fikri değiştirmene veya projeyi durdurmana yol açacağını yaz. MVP, bu karara dayanak oluşturduğunda işe yarar; sonraki adım beklediğinden küçük olsa bile.

7. Geliştiriciyle anlaşmadan önce kısa bir özet hazırla.

Kusursuz bir şartnameye ihtiyacın yok. Kısa ve açık bir proje özeti kapsam görüşmesini daha verimli hale getirir. Şunları ekle:

• Hedef kullanıcı, bu işi bugün nasıl idare ettiği ve sınamak istediğin soru.
• Başarılı bir sonucun somut örneğiyle birlikte ana kullanıcı akışı.
• İki liste: ilk sürüme dahil olanlar ve bilerek sonraya bırakılanlar.
• Gerekli veriler, entegrasyonlar, tasarımlar ve varsa mevcut kod.
• Bütçe aralığı, zaman kısıtları ve kapsam kararlarını kimin vereceği.
• Sürümü nasıl kontrol edeceğin, hesapların ve kodun kime ait olacağı ve yayından sonra ne tür destek beklendiği.

Yazılı kapsama ve kabul ölçütlerine bağlı bir tahmin iste. Rezervasyon aracı için bir ölçüt şu olabilir: “İki öğrenci aynı saati almaya çalıştığında yalnızca bir rezervasyon onaylanır; diğer öğrenci anlaşılır bir açıklama görür.” Bunu değerlendirmek, “rezervasyon sayfası tamamlandı” ifadesini değerlendirmekten daha kolaydır.