MVP Kapsamı Nasıl Belirlenir?

Teknoloji ve SaaS Şirketleri İçin Web Tasarım sayfasında bu kararların içerik modeli, kullanıcı görevi ve teslim kapsamıyla nasıl ele alındığını inceleyebilirsiniz.

“Müşteriler uygulamayı kullanır” ifadesi ölçülebilir bir başlangıç değildir. Örneğin “mevcut müşteriler telefon görüşmesi yapmadan randevu talebini tamamlayabiliyor mu?” sorusu, belirli bir kullanıcıya ve sonuca odaklanır. Bu sorunun cevabı, ilk sürümde hangi akışın bulunması gerektiğini belirler.

Kullanıcı ihtiyacı ile teknik belirsizliği ayırın. İnsanların yeni akışı tercih edip etmeyeceği kullanıcı araştırmasıyla; mevcut planlama sistemine veri yazılıp yazılamayacağı ise teknik bir denemeyle sınanabilir. İkisini tek bir büyük geliştirme paketinde çözmeye çalışmak öğrenmeyi geciktirebilir.

Tıklanabilir bir prototip, gezinme ve anlaşılabilirlik sorularını geliştirme yapmadan araştırabilir. Gerçek veriyle çalışan ilk sürüm ise erişim, hata yönetimi ve operasyon sorumlulukları gerektirir. Hangi ortamda, kimlerin ve hangi verilerin kullanılacağı baştan belirlenmelidir.

GOV.UK alpha rehberi, prototiplerle riskli varsayımları sınamayı anlatır. Bu yaklaşım keşif için yararlıdır; kamuya açık olmayan bir prototipin koşullarını gerçek kullanıcıya hizmet veren bir MVP’ye doğrudan taşımayın. Test edilen fikirle işletilen hizmetin gereksinimleri farklıdır.

Temsili randevu ürününde müşterinin hizmeti seçmesi, uygun zaman aralığı talep etmesi ve talebinin durumunu öğrenmesi temel akıştır. İşletme tarafında da bu talebi görme ve kabul veya ret kararı verme yolu bulunmalıdır. Yalnızca güzel bir talep ekranı yapmak, bu işi tamamlamaz.

1. Kullanıcının başlangıç koşulunu ve beklediği sonucu yazın.
2. Sonuca ulaşmak için zorunlu adımları sıraya koyun.
3. Her adımın başarısızlık durumunu ve destek yolunu belirleyin.
4. Akışın bittiğini gösteren kaydı ve ölçüm olayını tanımlayın.

İlk sürümde bazı arka ofis görevlerini elle yürütmek mümkün olabilir. Örneğin işletme talebi inceleyip uygunluğu mevcut planlama aracından kontrol edebilir. Ancak bu işin kimin sorumluluğunda olduğu, nasıl izleneceği ve hangi hacimde sürdürülemeyeceği yazılmalıdır.

Kullanıcıya otomatik sonuç vaat edip arka planda belirsiz bir manuel kuyruk oluşturmayın. Kullanıcı ne zaman yanıt bekleyeceğini ve talebinin hangi durumda olduğunu anlamalıdır. Manuel adımın hata veya veri kaybı yaratmaması için kayıt ve kontrol yöntemi gerekir.

Yalnızca kayıt olan kişi sayısını takip etmek ürünün işe yaradığını göstermez. Temel akışı tamamlayan kullanıcıları, yardım gerektiren adımları, tekrar kullanım davranışını ve operasyon yükünü birlikte değerlendirin. Ölçüm için gerekli veriyle sınırlı kalın ve kullanılan tanımları sabitleyin.

Hangi gözlemde devam edeceğinizi, hangi bulguda kapsamı değiştireceğinizi ve hangi durumda fikri durduracağınızı görüşün. Eşikleri gerçek kullanım bağlamınıza göre belirleyin; bu rehberdeki örnek akış için evrensel bir başarı oranı yoktur. Ertelenen özellikleri de bu öğrenme sorularıyla yeniden önceliklendirin.

Yazılım şartnamesi ile rolleri ve kuralları yazın; proje takvimi ile bağımlılıkları görünür kılın. Kabul testleri üzerinden ilk sürümün hangi koşullarda kullanılabilir sayılacağını belirleyin.

Rezervasyon kapasite ve iptal rehberi ilk sürümde yer ayırma, geç bildirim ve iptal gibi temel davranışları tanımlar. Kapsamı daraltırken bu kritik akışları yarım bırakmayın.