MVP kapsamı nasıl belirlenir?

1. İlk sürüm hangi kararı vermenizi sağlayacak?

MVP yaklaşımının odağı ürün fikrini gerçek kullanıcı davranışıyla sınamaktır. Yalnızca az sayıda özellik teslim etmek, işe yarayan bir öğrenme sağlamayabilir. Agile Alliance’ın MVP açıklaması da bu ayrımı vurgular.

Başlangıç notunu dört soruyla yazın: Kimin hangi işini ele alıyoruz, bugün nasıl yapılıyor, hangi davranışın değişeceğini düşünüyoruz ve bunu gözlersek hangi sonraki adımı değerlendireceğiz? Örneğin bir bayi portalında yalnızca hesabın açılmasıyla, gerçek bir talebin portal üzerinden tamamlanması aynı gözlem değildir.

“Kullanıcılar beğenir mi?” yerine, kullanıcının hangi durumda ürünü deneyeceğini ve işi tamamlamak için hangi yardıma ihtiyaç duyduğunu inceleyin. Görüşmeler ihtiyacı anlamaya yardımcı olur; gelecekte ne yapacağını söylemek ile gerçek kullanım aynı kanıt sayılmamalıdır.

2. Varsayımı sınamak için uygun yolu seçin

Belirsizlik kullanıcının yaşadığı sorunla ilgiliyse önce süreci dinlemek ve mevcut çalışma örneklerini incelemek faydalıdır. Bir ekran akışının anlaşılıp anlaşılmadığını görmek için etkileşimli prototip kullanılabilir. Hizmetin gerçekten tercih edilip edilmediğini gözlemek için bazı arka plan adımları elle yürütülebilir. Bu seçeneklerin her biri farklı bir soruyu yanıtlar.

Teknik bağlantı, veri doğruluğu veya gerçek kullanım koşulları sınanacaksa çalışan bir pilot gerekebilir. Örneğin eski bir sistemden gerekli veriye erişilemiyorsa yalnızca ekran prototipi bu belirsizliği gidermez. Pilotun kapsamına hangi teknik denemenin neden girdiğini açıkça yazın.

GOV.UK Service Manual, alpha aşamasında riskli varsayımları prototiplerle sınamayı ve sonraki aşamayı kanıta göre seçmeyi önerir. Bu rehberde bu düşünceden yararlanıyoruz; kamu hizmetindeki alpha sürecini üretimde kullanılacak bir MVP ile aynı kabul etmiyoruz.

3. Çalışan pilot için baştan sona bir akış çizin

İlk kapsam görüşmesinde, odaklanmayı kolaylaştırmak için tek bir kullanıcı grubunun tamamlayacağı temel akışı seçmenizi öneriyoruz. Bu, bütün MVP’lerin tek akış içermesi gerektiği anlamına gelmez. Seçim, sınamak istediğiniz varsayımı gerçekten gözlemleyebilmenizi sağlamalıdır.

Varsayımsal örneğimizde bayi bir talep oluşturur, yetkili operasyon ekibi inceler ve bayi talebin durumunu görür. Başlangıç koşulu, talepte zorunlu bilgiler, işlemi üstlenen kişi ve tamamlanmanın kullanıcıya nasıl görüneceği yazılır. Bu örnek Elmalı Tech müşteri vakası veya teslim edilmiş proje anlatımı değildir.

Sonra kopabilecek noktaları kontrol edin: Eksik bilgiyle ne olur, talebi yalnızca doğru bayi mi görebilir, operasyon değerlendirmesi gecikirse durum nasıl anlaşılır? Akışın yalnızca sorunsuz ilerleyen yolu, kullanıcıya sunulacak pilotun tüm kapsamını açıklamaz.

4. İlk sürümü ve sonraki adımları gerekçesiyle ayırın

Her özellik için, çıkarıldığında öğrenme hedefinin veya temel akışın hangi kısmının bozulacağını sorun. Yanıt belirsizse ilk sürüme otomatik eklemek yerine sonraki karar listesine alın. Kapsam dışı bir maddeyi yalnızca silmek yerine neden ertelendiğini ve ne öğrenilirse yeniden ele alınacağını kaydedin.

Bayi örneğinde talep oluşturma, değerlendirme ve durum görme temel akışta kalabilir. Gelişmiş gösterge panosu ve farklı kullanıcı gruplarına ait ek akışlar ilk denemenin sorusunu yanıtlamıyorsa ertelenebilir. Buna karşılık kullanıcı erişimi, anlaşılır hata mesajları ve kullanım bağlamına uygun veri koruması yalnızca “sonra yaparız” listesine bırakılmamalıdır.

Canlı ERP entegrasyonunun gerekli olup olmadığı, denenen varsayıma bağlıdır. Amaç talep kanalının kullanılıp kullanılmadığını görmekse, sorumlusu ve sınırları belirlenmiş manuel aktarım yeterli olabilir. Amaç sipariş bilgisinin doğru ve zamanında iki sistem arasında işlemesini sınamaksa entegrasyon pilotun merkezindedir. Manuel yöntemin oluşturduğu yük ve veri tutarsızlığı ihtimalini de karar dosyasına yazın.

• İlk sürüm: gözlenecek davranış için gereken iş adımları ve kabul koşulları.
• Pilotun işletimi: erişimler, destek sorumlusu, hata durumları ve veri kullanım sınırları.
• Sonraki kararlar: gerekçesiyle ertelenen özellikler ve yeniden değerlendirme koşulları.

5. Teslim kabulünü ve ürün öğrenmesini ayrı ölçün

Teslim kabulü, üzerinde anlaşılan yazılımın beklenen şekilde çalışıp çalışmadığını kontrol eder. Örneğin bayi kendi talebini görebiliyor mu, yetkisiz kullanıcı başka bir talebe erişemiyor mu, değerlendirme sonucu doğru durumla gösteriliyor mu? Bu örnekler iş ve geliştirme ekiplerinin aynı teslimi incelemesini kolaylaştırır.

Ürün öğrenmesi ise kullanıcıların bu akışı hangi koşullarda tercih ettiğini ve tamamlayabildiğini inceler. Davet edilen uygun kullanıcı sayısı, akışa başlayanlar, tamamlayanlar, yardım gerektiren adımlar ve kullanımın neden yarıda kaldığı birlikte değerlendirilir. Teknik testlerin geçmesi tek başına ürün talebinin doğrulandığı anlamına gelmez.

Ölçüm süresini, hedef kullanıcı grubunu ve devam, değiştir veya durdur kararında hangi bulguları dikkate alacağınızı denemeden önce belirleyin. Eşikler ürünün kullanım sıklığına ve kararın önemine göre seçilir; her MVP için geçerli bir başarı yüzdesi yoktur. Az sayıdaki katılımcıdan elde edilen sonucu bütün pazarın davranışı gibi sunmayın.

6. Kapsam görüşmesine bir sayfalık bilgiyle gelin

İlk görüşme için ayrıntılı teknik şartname hazırlamanız gerekmez. Aşağıdaki bilgiler, çözülmek istenen iş ile teklifin sınırlarını birlikte değerlendirmek için bir başlangıç sağlar. Bilmediğiniz bir konu varsa tahminle doldurmak yerine açık soru olarak işaretleyin.

Elmalı Tech’in özel yazılım hizmetinde keşif, kullanıcı akışları, entegrasyonlar ve kabul ölçütleri birlikte ele alınır. Hazırladığınız kısa not, mevcut ürünü kullanma, entegrasyon yapma veya özel geliştirmeye başlama seçeneklerini aynı ihtiyaç üzerinden konuşmayı kolaylaştırır.

• Hedef kullanıcı ve bugün tamamlamaya çalıştığı iş.
• Sınanacak varsayım, gözlenecek davranış ve verilecek sonraki karar.
• İlk akışın başlangıç ve bitişi; işin operasyon tarafındaki sorumlusu.
• Gerekli veri kaynakları ve erişimin kim tarafından sağlanacağı.
• Pilot için gerekli entegrasyonlar ve ertelenen bağlantıların gerekçesi.
• Kapsam dışı özellikler ve bunları yeniden ele alma koşulları.
• Teslimi değerlendirecek kişi, örnek kabul senaryoları ve ölçüm yöntemi.