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

MVP kapsamı, ürününü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ğin bir kontrol listesi bulacaksın.

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ü 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ı yaz

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ç

İ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 ver. Örneğin: "Restoran sahibi, haftalık sebze siparişini iki dakikada verebilsin."

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

Kullanıcının işe başladığı andan tamamladığı ana kadar geçtiği adımları sırala. 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ına

Akışa eklenmek istenen her özellik için şunu sor: "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

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:

• 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ı fikrin 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: 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 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ı baştan belirlemen 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ı sana haber verilmeden görebilmelisin.
• Temel analitik: Ana akışın hangi adımında kullanıcı kaybettiğini ölçebilmelisin.

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ğini düşündüğünde şu soruları yanıtla:

• 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 koyma. 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ı sor. Katkı sağlamıyorsa öneriyi "bu sürümde yok" listesine ekle. 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ğına karar vermekten çok neyi şimdilik yapmayacağına karar vermektir. Tek bir kullanıcıya, tek bir işe ve tek bir varsayıma odaklandığında daha kısa sürede, daha az maliyetle gerçek bir öğrenme elde edersin. 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 atabilirsin.