Kararın dayanağı
Prototip etkileşimin anlaşılmasını, kavram kanıtı belirli koşullarda teknik yapılabilirliği sınar. MVP gerçek kullanıcıya sınırlı ama kullanılabilir sonuç verir. Biri diğerlerini kendiliğinden kanıtlamaz.
Somut bir örnek
İrsaliyeyi okuyup stok güncelleme örneğinde prototip miktar düzeltme arayüzünü sınar. Teknik deney etiketli örneklerde veri çıkarmayı ölçer. MVP ise belge alımı, inceleme, yetkili stok güncellemesi ve hata sonrası toparlanmayı birleştirir.
Her çıktı için farklı bir kabul testi yazmak
Prototipte katılımcıdan yönlendirme almadan miktarı düzeltmesini ve sonraki işlemin ne yapacağını anlatmasını isteyin. Tasarımı ne kadar övdüğünden çok nerede yanlış anladığını gözleyin. Teknik deneyde kullanılacak etiketli belgeleri, değerlendirilecek alanları ve kabul edilmeyen hata türlerini önceden belirleyin. MVP’de ise yetkili kullanıcının belgeden stok güncellemesine uzanan gerçek akışını, inceleme kuyruğu ve başarısız güncellemeyle birlikte izleyin. Bunlar üç ayrı testtir; birindeki başarıyı ürünün bütünüyle hazır olduğuna kanıt saymayın.
Kısayolları devir sırasında görünür kılmak
Prototipte sabit değerler, teknik deneyde yalnız bir geliştiricinin bilgisayarı, MVP’de ise manuel istisna süreci kullanılabilir. Sınırları açık yazıldığında bunlar makul tercihler olabilir. Varsayımları, yapılmayan davranışları, test ortamını ve veri izinlerini kaydedin. Konsept ekranlarını çalışan müşteri ürünü sanılmayacak şekilde etiketleyin. Deney kodunu yeniden kullanacaksanız deney sırasında gerekmeyen kimlik doğrulama, ayarlar, hata yönetimi, izleme, yayın ve bakım sorumluluğunu ayrıca inceleyin. Yeniden kullanım, gizli yükleri üretim ortamına taşımak yerine doğrulanmış işten yararlanmalıdır.
Sonraki adımı elde edilen sonuca göre seçmek
Kullanıcı düzeltme ekranını anlayamıyorsa başka bir veri çıkarma deneyi bu sorunu çözmez. Zorunlu bir belge düzeni doğru okunamıyorsa arayüzü güzelleştirmek de yeterli olmaz. İkisi çalıştığı halde belgeler gereken anda kullanıcının elinde bulunmuyorsa ürünü büyütmeden önce işletme sürecini araştırın. Her testten sonra ne öğrenildiğini, neyin bilinmediğini ve sıradaki değişikliği kısaca yazın. Böylece her fikre aynı teslim sırasını dayatmadan ve her deneyi yayınlanacak ürün saymadan belirsizliği azaltabilirsiniz.
Değerlendirilecek seçenekler
- Kullanım belirsizse prototip, teknik mümkünlük belirsizse deney, benimsenme veya iş değeri belirsizse MVP seçin. Birden fazlası gerekebilir; soruları ve bitiş ölçütleri ayrı olsun. Deney kodunu yeniden kullanmak da bir karardır.
Planın aksadığı yer
Özenli maket veri çıkarmanın çalıştığını göstermez. Çalışan script de yetki, yayın ve destek düzenini doğrulamaz. Kısayolları ve deney koşullarını kaydedin.
İşe başlamadan önce
Kanıt hangi kararı değiştirecek? Girdiler temsili mi? Ne başarısızlık sayılacak? Çıktı ve tarih seçmeden MVP geliştirme ortağınızla bunları belirleyin.