MVP Tasarımında İlk Sürümün Kapsamını Belirleme

MVP kapsamı, bir ürünün bütün özelliklerinin küçük sürümlerinden oluşmamalıdır. İlk sürüm, seçilmiş bir kullanıcı grubunun önemli bir görevini tamamlamasını sağlamalı ve ürün hakkındaki kritik bir belirsizliği azaltmalıdır. Bunun için önce kimin hangi problemi yaşadığını ve neyi öğrenmek istediğinizi açıkça yazın.

“Rakipte var” veya “ileride gerekli olabilir” gerekçeleri tek başına ilk sürüme özellik almak için yeterli değildir. Bir özelliğin kullanıcı sonucuyla ve test edilen varsayımla ilişkisini gösterebilmeniz gerekir. Bu yaklaşım, yalnızca az özellik yapmak değil, tutarlı bir ilk kullanım deneyimi tasarlamaktır.

Kod yazmadan önce belirsizliği sınıflandırın

GOV.UK keşif rehberi, geliştirmeye başlamadan önce problemi ve hizmet bağlamını anlamaya odaklanır.[1] Kendi ürününüzde de sorunun talep, kullanılabilirlik, teknik yapılabilirlik veya operasyonla ilgili olup olmadığını ayırın. Bu rehberdeki öneriler, kamu hizmetlerine özgü zorunlu süreçler olarak değil, ürün kararlarını netleştiren ilkeler olarak ele alınmalıdır.

Kullanıcının akışı anlayıp anlamadığını öğrenmek istiyorsanız bir prototip yeterli olabilir. Gerçek kullanım, veri kalitesi veya operasyonel yük hakkında bilgi gerekiyorsa çalışan bir sürüme ihtiyaç duyabilirsiniz. GOV.UK alfa rehberi de riskli varsayımları test etmek için prototiplerden yararlanır.[2] Bir prototipin olumlu karşılanması, üretim ortamındaki talebi tek başına kanıtlamaz.

Bir kullanıcı sonucunu baştan sona çizin

Varsayımsal bir randevu ürününde temel görev, uygun saati bulmak ve onaylı rezervasyon oluşturmaktır. İlk sürümün yalnızca takvim ekranını içermesi bu görevi tamamlamaz. Uygunluk kontrolü, rezervasyon sonucu ve gerekli hata durumları da değerlendirilmelidir.

Öte yandan sadakat programı veya gelişmiş raporlama, ilk varsayımı sınamak için gerekli olmayabilir. Kapsam dışı bırakılan her özelliğin gerekçesini yazın; böylece aynı tartışmayı her görüşmede yeniden başlatmazsınız.

Dar kapsamı eksik güvenlikle karıştırmayın

İlk sürümün küçük olması, gerekli güvenlik, mahremiyet, erişilebilirlik veya yasal yükümlülüklerin göz ardı edilebileceği anlamına gelmez. Hangi koşulların yayına çıkış için zorunlu olduğunu ilgili uzmanlarla belirleyin. Deneme ortamı ile gerçek kullanıcıya açık sürümün riskleri aynı değildir.

Bazı operasyonlar başlangıçta elle yürütülebilir; ancak bunun kullanıcıya, veri yönetimine ve ekip kapasitesine etkisini değerlendirin. Manuel bir adım kullanılıyorsa sorumlusunu ve sınırlarını açıkça belirleyin. Otomasyon eksikliğini kullanıcıya yanlış bir sistem vaadiyle gizlemeyin.

Yayından önce öğrenme kararını yazın

Hangi kullanıcıların denemeye katılacağını, hangi görevin inceleneceğini ve neyin ilerleme, değişiklik veya durdurma kararı doğuracağını önceden belirleyin. Tek bir genel başarı yüzdesi yerine ürünün belirsizliğine uygun kanıt arayın. Kullanıcıların neden ilerleyemediğini anlamadan yalnızca yeni özellik eklemek kapsamı büyütür.

Sık sorulan sorular

MVP en hızlı yapılabilen sürüm müdür

Hız önemlidir; fakat sürümün anlamlı bir görev ve öğrenme amacı olmalıdır. Çok hızlı hazırlanmış eksik bir akış, yanlış sonuçlara götürebilir.

Prototip ile MVP aynı şey mi

Hayır. Prototip seçilmiş etkileşimleri temsil edebilir. Çalışan bir MVP gerçek kullanım ve operasyon hakkında farklı kanıtlar sağlar.

Kapsamı nasıl başlatalım

Hedef kullanıcıyı, tek ana görevi ve kritik varsayımı yazın. VOYA MVP ürün tasarımı hizmeti kapsamında ilk sürümün sınırlarını değerlendirebilirsiniz.

Kaynaklar

1. GOV UK Discovery phase
2. GOV UK Alpha phase