MVP Kapsamı Nasıl Belirlenir? İlk Sürüme Neler Girmeli?

MVP kapsamı, ürününüzün en kritik varsayımını gerçek kullanıcılarla test edebilecek en küçük özellik setidir. Doğru belirlenmiş bir MVP, kullanıcının tek bir temel işi baştan sona yapabilmesini sağlar ve geri kalan her şeyi sonraki sürümlere bırakır. Bu yazıda MVP kapsamını belirlemek için adım adım bir yöntem, somut bir örnek ve kullanabileceğiniz bir kontrol listesi bulacaksınız.

MVP aslında ne değildir?

"Minimum Viable Product" ifadesi sık sık yanlış anlaşılır. MVP:

• Yarım kalmış, hatalı bir ürün değildir. Az şey yapar ama yaptığını düzgün yapar.
• Tüm özelliklerin basitleştirilmiş versiyonlarının toplamı değildir. Özelliklerin çoğu hiç yer almaz.
• Yalnızca bir prototip değildir. Gerçek kullanıcıların gerçek bir işi yapmak için kullanabileceği bir yazılımdır.

MVP'nin amacı öğrenmektir: Kullanıcılar bu problemi gerçekten yaşıyor mu, çözümünüzü kullanıyor mu, bunun için ödeme yapmaya istekli mi?

MVP kapsamını belirlemek için beş adım

1. En riskli varsayımınızı yazın

Her ürün fikri birkaç varsayıma dayanır. Örneğin: "Küçük restoranlar tedarikçi siparişlerini telefondan değil bir uygulamadan vermek ister." Bunlardan hangisi yanlış çıkarsa ürün tamamen anlamsızlaşır? O varsayım, MVP'nin test etmesi gereken şeydir.

2. Tek bir ana kullanıcı ve tek bir ana iş seçin

İlk sürümde birden fazla kullanıcı grubunu memnun etmeye çalışmak kapsamı hızla büyütür. "Kim için?" ve "Hangi işi yapması için?" sorularına tek cümlelik bir cevap verin. Örneğin: "Restoran sahibi, haftalık sebze siparişini iki dakikada verebilsin."

3. Bu işin uçtan uca akışını çizin

Kullanıcının işe başladığı andan tamamladığı ana kadar geçtiği adımları sıralayın. Kayıt, giriş, ana işlem, onay, bildirim gibi. Bu akışta olmazsa olmaz olan adımlar MVP'nin iskeletini oluşturur.

4. Her özelliği bir soruyla sınayın

Akışa eklenmek istenen her özellik için şunu sorun: "Bu olmazsa kullanıcı ana işi yapamaz mı?" Cevap "yapabilir" ise özellik büyük ihtimalle MVP'ye girmemelidir. Raporlama, gelişmiş filtreler, çoklu dil, rol bazlı karmaşık yetkiler, entegrasyonların çoğu bu soruda elenir.

5. Elle yapılabilecekleri ayırın

Bazı işler ilk aşamada yazılım yerine elle yapılabilir. Fatura kesmek, kullanıcı onaylamak, veri raporu hazırlamak gibi. Bu işleri otomatikleştirmek, talebin gerçek olduğunu gördükten sonra anlamlıdır.

Önceliklendirme için pratik bir yöntem: MoSCoW

Özellik listesi uzadığında MoSCoW yöntemi işe yarar. Her özelliği dört gruptan birine koyarsınız:

• Must have (Olmazsa olmaz): Bu olmadan ürün ana işini yapamaz.
• Should have (Olmalı): Önemli, ama ilk lansmanı durdurmaz.
• Could have (Olabilir): Hoş olur, zaman kalırsa.
• Won't have (Bu sürümde yok): Bilinçli olarak dışarıda bırakılanlar.

MVP genellikle yalnızca ilk gruptan oluşur. Son grubu yazılı olarak tutmak da önemlidir; dışarıda bırakılanların kayıt altında olması, ekip içinde "bunu unuttuk mu?" tartışmalarını azaltır.

Somut bir örnek: Randevu yönetim uygulaması

Diyelim ki güzellik salonları için bir randevu uygulaması fikriniz var. İlk akla gelen özellik listesi şöyle olabilir: online randevu, personel takvimi, SMS hatırlatma, ödeme alma, sadakat programı, stok takibi, raporlar, mobil uygulama, çoklu şube.

En riskli varsayım: "Salon müşterileri telefonla aramak yerine online randevu almayı tercih eder."

Bu varsayımı test eden MVP kapsamı şunlar olabilir:

1. Salonun hizmetlerini ve çalışma saatlerini tanımlayabildiği basit bir yönetim ekranı,
2. Müşterinin bir bağlantı üzerinden uygun saati seçip randevu alabildiği mobil uyumlu bir web sayfası,
3. Randevu sonrası salon ve müşteriye giden e-posta bildirimi,
4. Salonun günlük randevu listesini gördüğü tek bir ekran.

Ödeme, sadakat, stok, çoklu şube ve yerel mobil uygulama sonraki sürümlere kalır. SMS hatırlatma ise müşteri geri bildirimine göre ikinci sürümün ilk adayı olabilir.

Bu MVP ile şu sorulara cevap ararsınız: Salonlar randevu bağlantısını müşterileriyle paylaşıyor mu? Müşteriler bağlantıya tıklayınca randevuyu tamamlıyor mu, yoksa yarıda mı bırakıyor? Online alınan randevuların oranı zamanla artıyor mu? Bu sorulara olumlu cevap almadan ödeme veya sadakat sistemine yatırım yapmak, doğrulanmamış bir temel üzerine kat çıkmak gibidir.

Sık yapılan MVP kapsamı hataları

• Rakiple özellik yarışı: Rakibin yıllar içinde geliştirdiği özellikleri ilk sürümde yakalamaya çalışmak.
• Yönetim paneline aşırı yatırım: İlk kullanıcılar az olduğunda, birçok yönetim işi basit araçlarla veya doğrudan veritabanı üzerinden yapılabilir.
• Ölçekleme kaygısı: Henüz yüz kullanıcınız yokken yüz bin kullanıcıya göre mimari kurmak. Sağlam ama sade bir temel çoğu zaman yeterlidir.
• Ölçümü unutmak: MVP'nin amacı öğrenmekse, hangi verilere bakacağınızı baştan belirlemeniz gerekir.
• Kaliteyi kapsamla karıştırmak: Kapsamı küçültmek, temel kaliteden vazgeçmek demek değildir. Güvenlik, veri yedekleme ve hata izleme MVP'de de olmalıdır.

MVP'de kesilmemesi gerekenler

Kapsamı daraltırken bazı konular "sonra bakarız" listesine konmamalıdır. Bunlar kullanıcı sayısı az olsa bile ürünün güvenilirliğini belirler:

• Kimlik doğrulama ve yetkilendirme: Kullanıcı yalnızca kendi verisini görebilmelidir.
• Kişisel veri yükümlülükleri: KVKK kapsamındaki aydınlatma metni ve gerekli onaylar ilk günden yer almalıdır.
• Yedekleme: Veritabanının düzenli yedeği alınmalı ve geri yükleme en az bir kez denenmelidir.
• Hata izleme: Kullanıcıların karşılaştığı hataları siz haber almadan görebilmelisiniz.
• Temel analitik: Ana akışın hangi adımında kullanıcı kaybettiğinizi ölçebilmelisiniz.

Bu kalemler genellikle az zaman alır, ama eksik olduklarında MVP'den doğru sonuç çıkarmak zorlaşır.

MVP kapsamı kontrol listesi

Kapsamı netleştirdiğinizi düşündüğünüzde şu soruları yanıtlayın:

• Test ettiğimiz tek bir ana varsayım yazılı mı?
• Ana kullanıcı ve ana iş tek cümleyle tanımlı mı?
• Uçtan uca akıştaki her adım listede mi?
• Listedeki her özellik "bu olmazsa ana iş yapılamaz" testini geçiyor mu?
• Dışarıda bırakılan özellikler ayrı bir listede kayıtlı mı?
• Başarıyı hangi verilerle ölçeceğimiz belli mi?
• Lansmandan sonra ilk geri bildirimleri nasıl toplayacağımız planlandı mı?

Bu listeyi bir kez doldurup kenara koymayın. Geliştirme sırasında yeni bir özellik önerisi geldiğinde, önce bu listeye dönüp önerinin ana varsayımı test etmeye katkı sağlayıp sağlamadığını sorun. Katkı sağlamıyorsa öneriyi "bu sürümde yok" listesine ekleyin. Böylece kapsam, proje ilerledikçe sessizce büyümez ve lansman tarihi korunur. Lansmandan sonra da aynı liste, ilk geri bildirimlerle birlikte ikinci sürümün önceliklerini belirlemek için iyi bir başlangıç noktası olur.

Sonuç

MVP kapsamını belirlemek, neyi yapacağınıza karar vermekten çok neyi şimdilik yapmayacağınıza karar vermektir. Tek bir kullanıcıya, tek bir işe ve tek bir varsayıma odaklandığınızda daha kısa sürede, daha az maliyetle gerçek bir öğrenme elde edersiniz. Weras Labs'te MVP projelerinde kapsamı ilk görüşmede birlikte daraltıyor, yazılı teklifte neyin dahil olup neyin olmadığını açıkça belirtiyoruz; ayrıntılar için hizmetler sayfamıza göz atabilirsiniz.