İyi bir MVP tek bir kritik varsayımla başlar
Mobil uygulama fikirleri çoğu zaman uzun bir özellik listesiyle geliyor: üyelik, mesajlaşma, harita, puan sistemi, bildirimler ve yönetim paneli. Fakat ilk sürümün görevi bu listenin tamamını hayata geçirmek değil. Kullanıcının temel sorunu gerçekten yaşayıp yaşamadığını ve önerilen çözümü kullanmaya istekli olup olmadığını anlamaktır.
Bu ayrım yapılmadığında aylarca geliştirilen uygulama, ilk gerçek kullanıcıyla karşılaştığında temel akışın yanlış kurulduğunu gösterebilir. Erken doğrulama, bu riski daha kod yazılmadan azaltır.
İlk sürümün kapsamını nasıl ayırıyoruz?
Efes Yazılım'da özellikleri ‘olsa güzel olur’ listesine göre değil, test edilmek istenen davranışa göre sıralıyoruz. Kullanıcının uygulamaya girişinden temel işi tamamlamasına kadar olan en kısa yolu önce çıkarıyoruz.
- Sorunu yaşayan kişilerle görüşüp bugün kullandıkları çözümü anlamak.
- Uygulamanın değerini gösteren tek ana kullanıcı akışını seçmek.
- Bu akışı desteklemeyen özellikleri sonraki sürüm listesine taşımak.
- Tasarımı tıklanabilir prototiple gerçek kullanıcılara denetmek.
- Başarıyı indirme sayısı yerine tamamlanan ana işlemle ölçmek.
MVP eksik değil, bilinçli olarak sınırlıdır
Kapsamı küçültmek kaliteyi düşürmek anlamına gelmez. Kullanıcı hesabı, veri güvenliği, hata mesajları ve temel erişilebilirlik gibi konular ilk sürümde de ciddiyetle ele alınmalıdır. Sade bir ürün ile özensiz bir ürün aynı şey değildir.
Yayın sonrasında yorumları rastgele özellik talepleri olarak toplamak yerine davranışla birlikte okumak gerekir. Kullanıcı nerede durdu, hangi adımı tekrar etti, yardım için ne sordu? İkinci sürümün kapsamı bu cevaplardan çıkar.