Mobil Uygulama Fikrinden İlk Sürüme: MVP Kapsamı Nasıl Belirlenir?

Bir mobil uygulamanın ilk sürümüne mümkün olan en fazla özelliği eklemek yerine, uygulamanın temel değerini gerçek kullanıcılarla test etmeye yetecek kapsamı belirlemek gerekir.

MVP kapsamındaki her özellik ya kullanıcının ana işlemi tamamlamasını sağlamalı ya da ürünle ilgili önemli bir varsayımı test etmeye yardımcı olmalıdır.

Bir özelliği çıkardığınızda uygulamanın temel kullanım senaryosu hâlâ çalışıyorsa, o özellik ilk sürüm için zorunlu olmayabilir.

Kısa yanıt

Mobil uygulama MVP'si, hedef kullanıcının temel problemini çözen uçtan uca akışı güvenilir biçimde tamamlamalı ve ürünle ilgili belirli bir varsayımı test etmelidir. İlk sürüm kapsamına özellik adı yazarak değil, kullanıcı, problem, başarı ölçütü ve kabul koşulunu tanımlayarak başlayın.

MVP nedir?

MVP, Minimum Viable Product ifadesinin kısaltmasıdır. Türkçede genellikle minimum uygulanabilir ürün veya minimum işlevsel ürün olarak kullanılır.

Buradaki "minimum" ifadesi kalitesiz veya yarım çalışan bir uygulama anlamına gelmez.

Amaç, ürünün temel değerini mümkün olan en kontrollü kapsamla gerçek kullanıcı karşısına çıkarmaktır.

MVP şu soruların cevabını almaya yardımcı olmalıdır:

• Kullanıcı gerçekten bu probleme çözüm arıyor mu?
• Tasarladığımız ana akışı kullanıyor mu?
• Ürünün sunduğu değeri anlıyor mu?
• Hangi aşamalarda sorun yaşıyor?
• Hangi özelliklere gerçekten ihtiyaç duyuyor?
• Ürünü kullanmaya devam ediyor mu?

Bu sorular cevaplanmadan çok büyük bir ürün geliştirmek gereksiz maliyet ve zaman oluşturabilir.

Özellik listesiyle değil problemle başlayın

MVP planlamasında ilk doküman uzun bir özellik listesi olmamalıdır.

Önce şu üç soruya cevap verin:

Kim kullanacak?

Hangi problemi çözüyoruz?

Kullanıcı uygulamada hangi temel işi tamamlayacak?

Örneğin:

Kullanıcıların çevresindeki hizmet işletmelerinden uygun tarih seçerek randevu oluşturmasını sağlayan bir mobil uygulama.

Bu tek cümle kapsam kararlarının önemli bölümünü kolaylaştırır.

Uygulamanın ilk hedefi randevu oluşturmaksa canlı sohbet, sadakat puanı, sosyal medya paylaşımı veya gelişmiş profil özelleştirmesi faydalı olabilir ancak temel kullanım senaryosu için zorunlu değildir.

Ana kullanıcı akışını çıkarın

MVP'nin merkezinde ekran sayısı veya özellik sayısı değil, baştan sona tamamlanabilen bir kullanıcı akışı bulunmalıdır.

Randevu uygulaması örneğinde temel akış şöyle olabilir:

1. Kullanıcı uygulamayı açar.
2. İşletmeyi veya hizmeti seçer.
3. Uygun tarihleri görüntüler.
4. Uygun saati seçer.
5. Gerekli bilgileri girer.
6. Randevuyu oluşturur.
7. Randevunun oluşturulduğunu görür.

Bu zincirdeki kritik bir adım çalışmıyorsa uygulamanın temel amacı tamamlanamaz.

Buna karşılık kullanıcı randevusunu sosyal medyada paylaşamıyorsa ana ürün hâlâ çalışabilir.

Bu ayrım, ilk sürüm kapsamını belirlemek için kullanılabilir.

Her özellik için dört soru sorun

Özellik listesini oluşturduktan sonra tüm maddeleri aynı ölçütlerle değerlendirin.

1. Bu özellik ana problemi çözmek için gerekli mi?

Özellik olmadan kullanıcının ana işlemi tamamlayıp tamamlayamadığına bakın.

Bir ödeme uygulamasında ödeme işlemi zorunludur.

Profil fotoğrafı seçimi ise büyük olasılıkla zorunlu değildir.

Bir navigasyon uygulamasında rota oluşturmak temel işlevdir.

Gelişmiş avatar sistemi ise değildir.

2. Bu özellik olmadan ürünü test edebilir miyiz?

Bazı özellikler ana kullanım için zorunlu görünmeyebilir ancak test edilmek istenen iş modelinin parçası olabilir.

Örneğin ürünün temel varsayımı kullanıcıların uygulama üzerinden belirli bir hizmet için ödeme yapmaya hazır olmasıysa ödeme sistemi MVP'ye dahil edilmelidir.

İlk test yalnızca kullanıcıların hizmet talebi oluşturup oluşturmadığını anlamaksa ödeme özelliği sonraki sürüme bırakılabilir.

Bu nedenle "Bu özellik önemli mi?" yerine "Bu özellik olmadan hangi sorunun cevabını alamıyoruz?" sorusu daha kullanışlıdır.

3. Özelliğin gerçek geliştirme maliyeti nedir?

Ekranda küçük görünen bir özellik teknik tarafta büyük bir kapsam oluşturabilir.

Örneğin:

Kullanıcılar birbirine mesaj gönderebilsin.

Bu istek yalnızca bir sohbet ekranı hazırlamak anlamına gelmeyebilir.

Şunlar da gerekebilir:

• Gerçek zamanlı mesaj altyapısı
• Push bildirimleri
• Okundu bilgisi
• Çevrim içi durumu
• Görsel gönderme
• Dosya gönderme
• Kullanıcı engelleme
• Mesaj silme
• Şikâyet sistemi
• Moderasyon
• Veri saklama politikası
• Yönetim paneli

Bu nedenle özelliklerin kapsamını yalnızca kullanıcı arayüzünde kapladığı alana göre değerlendirmeyin.

4. Bu özellikten ne öğreneceğiz?

İlk sürüm yalnızca çalışan bir uygulama ortaya çıkarmamalı, ürün hakkında bilgi de üretmelidir.

Bir özelliğin geliştirilmesi ciddi zaman gerektiriyor ancak kullanıcı davranışı veya iş modeli hakkında önemli bir bilgi sağlamıyorsa sonraki sürüme bırakılabilir.

İlk sürümde özellikle test edilmek istenen varsayımlar belirlenmelidir.

Örneğin:

• Kullanıcı kayıt oluyor mu?
• İlk işlemini tamamlıyor mu?
• Tekrar geliyor mu?
• Ödeme yapıyor mu?
• İşletmeyle iletişime geçiyor mu?
• Belirli özelliği gerçekten kullanıyor mu?

Özellikleri üç gruba ayırın

Uzun özellik listelerinde tüm maddeleri "önemli" olarak görmek kolaydır.

Bunun yerine üç grup kullanılabilir.

Grup	Açıklama
İlk sürüm	Ana kullanıcı akışı veya kritik varsayım için gerekli
Sonraki sürüm	Faydalı ancak ilk ürün testini engellemiyor
Şimdilik kapsam dışı	İlk hedefle doğrudan ilişkili değil

Bir özelliği sonraki sürüme bırakmak özelliğin kötü olduğu anlamına gelmez.

Sadece geliştirme sırasının farklı olduğu anlamına gelir.

Varsayımsal bir MVP örneği

Aşağıdaki örnek gerçek bir DigiRise projesine ait değildir. MVP kapsamlandırma yöntemini göstermek amacıyla oluşturulmuş varsayımsal bir senaryodur.

Bir randevu uygulaması geliştirdiğimizi düşünelim.

İlk sürüm

Özellik	Karar	Gerekçe
İşletme listesi	İlk sürüm	Kullanıcının hizmet sağlayıcı seçmesi gerekiyor
Hizmet seçimi	İlk sürüm	Randevu sürecinin temel parçası
Uygun saatler	İlk sürüm	Ana kullanıcı akışının parçası
Randevu oluşturma	İlk sürüm	Ürünün temel işlevi
Randevularım	İlk sürüm	Kullanıcı oluşturduğu kaydı görebilmeli
Basit yönetim paneli	İlk sürüm	İşletme randevuları yönetebilmeli
Temel bildirim	Değerlendirilebilir	Randevu kullanımını doğrudan etkileyebilir

Sonraki sürüm

• Canlı sohbet
• Sadakat sistemi
• Kuponlar
• Gelişmiş yorum sistemi
• Arkadaş davet etme
• Sosyal medya paylaşımı
• Gelişmiş profil özelleştirmesi
• Çok sayıda giriş yöntemi
• Detaylı işletme analitiği
• Gelişmiş kampanya sistemi

Bu özellikler değerli olabilir ancak ilk sorumuz "Kullanıcı uygulama üzerinden başarılı şekilde randevu oluşturuyor mu?" ise çoğu ilk test için zorunlu değildir.

MVP kalitesiz ürün değildir

Kapsamı küçültmek ile kaliteyi düşürmek aynı şey değildir.

İlk sürümde on yerine beş ana özellik bulunabilir. Ancak bu beş özelliğin güvenilir şekilde çalışması gerekir.

Özellikle şu alanlar yalnızca MVP olduğu gerekçesiyle ihmal edilmemelidir:

• Kullanıcı verilerinin korunması
• Temel yetkilendirme
• Kritik güvenlik önlemleri
• Veri kaybını önleyen kontroller
• Ödeme güvenliği
• Ana kullanıcı akışını bozan hatalar
• Uygulama mağazalarının zorunlu gereksinimleri
• Gerekliyse hesap ve veri silme süreçleri

Eksik özellikli ancak çalışan bir uygulama test edilebilir.

Ana işlevi sürekli hata veren bir uygulama ise sağlıklı kullanıcı geri bildirimi üretmez.

Tasarım MVP kapsamının parçasıdır

MVP için onlarca animasyon, özel geçiş, çok sayıda tema veya kapsamlı görsel kişiselleştirme gerekli olmayabilir.

Ancak kullanıcı hangi butona basması gerektiğini anlayamıyorsa ürünün kendisini doğru şekilde test etmiş olmazsınız.

İlk sürüm tasarımında kullanıcı şu soruların cevaplarını kolayca görebilmelidir:

• Burada ne yapabilirim?
• Bir sonraki adım ne?
• İşlem tamamlandı mı?
• Hata oluştu mu?
• Geri dönebilir miyim?
• Kaydettiğim işlem nerede?

Görsel detaylar azaltılabilir ancak kullanılabilirlik azaltılmamalıdır.

Yönetim panelini unutmayın

Mobil uygulama projelerinde kapsam yalnızca iPhone veya Android ekranlarından oluşmaz.

Birçok uygulamanın arka tarafında yönetilmesi gereken veriler bulunur.

Örneğin:

• Kullanıcılar
• Ürünler
• Siparişler
• Randevular
• İçerikler
• Bildirimler
• Şikâyetler
• Kampanyalar

İşletmenin bu verileri değiştirmesi gerekiyorsa yönetim paneli de MVP kapsamının bir parçası olabilir.

Teklif karşılaştırırken yalnızca uygulama ekranlarına değil, backend ve yönetim ihtiyaçlarına da bakılmalıdır.

Üçüncü taraf servisleri baştan belirleyin

Bazı uygulama özellikleri dış servislere bağımlıdır.

Örneğin:

• Harita
• Ödeme
• SMS
• E-posta
• Push bildirim
• Yapay zekâ API'leri
• Video
• Depolama
• Kimlik doğrulama
• Analitik

Bu servislerin kullanım ücretleri ve teknik sınırları ilk kapsam planlamasında değerlendirilmelidir.

"Harita ekleyelim" gibi basit görünen bir karar, kullanım yoğunluğuna göre işletme maliyetine dönüşebilir.

İlk sürüm çok büyüdüğünde hangi işaretler görülür?

Bazı durumlar MVP kapsamının yeniden değerlendirilmesi gerektiğini gösterir.

Uygulama aynı anda birden fazla ürün olmaya çalışıyor

Ürün aynı anda sosyal ağ, pazar yeri, mesajlaşma sistemi, ödeme platformu ve rezervasyon uygulaması olmaya çalışıyorsa kapsam parçalanabilir.

İlk kullanıcı gelmeden aylarca özellik geliştiriliyor

Henüz doğrulanmamış varsayımların üzerine yeni özellikler ekleniyor olabilir.

Her özellik zorunlu olarak işaretleniyor

Önceliklendirme yapılamıyor olabilir.

İlk sürüm tek cümlede anlatılamıyor

Ürünün ana amacı yeterince net olmayabilir.

Her yeni fikir doğrudan mevcut geliştirmeye ekleniyor

Kapsam sürekli değişiyorsa geliştirme takvimi ve maliyet tahmini de güvenilirliğini kaybeder.

MVP kapsam dokümanında neler bulunmalı?

Geliştirme başlamadan önce kısa bir kapsam dokümanı hazırlanması faydalıdır.

Hedef kullanıcı

Ürünü ilk kim kullanacak?

Problem

Hangi somut sorun çözülüyor?

Temel değer

Kullanıcı neden bu uygulamayı kullanacak?

Ana kullanıcı akışı

Kullanıcı uygulamada hangi adımları tamamlayacak?

İlk sürüm özellikleri

İlk geliştirme kapsamında hangi özellikler bulunacak?

Kapsam dışı özellikler

Hangi özelliklerin bilinçli olarak sonraki sürüme bırakıldığı yazılmalıdır.

Kullanıcı rolleri

Normal kullanıcı, işletme, yönetici veya farklı roller varsa belirtilmelidir.

Teknik bağımlılıklar

Ödeme, harita, bildirim, kamera veya diğer servisler belirlenmelidir.

Yönetim ihtiyaçları

Yönetim panelinden hangi işlemlerin yapılacağı tanımlanmalıdır.

Ölçüm

İlk sürüm yayınlandıktan sonra hangi davranışların izleneceği belirlenmelidir.

Kopyalanabilir MVP kapsam şablonu

Bu kısa taslağı ürün ekibiyle doldurun. Cevaplanmamış alanları tahminle kapatmak yerine açık karar olarak bırakın.

Ürün fikri:
İlk hedef kullanıcı:
Kullanıcının yaşadığı problem:
Uygulamanın sunduğu temel değer:
İlk sürümde tamamlanacak ana kullanıcı akışı:
Test edilecek en önemli varsayım:
Başarıyı gösterecek ölçüm ve hedef:
Ölçümün veri kaynağı:
İlk sürüm özellikleri:
Sonraki sürüme bırakılanlar:
Kapsam dışı olanlar:
Gerekli kullanıcı rolleri ve yönetim işlemleri:
Üçüncü taraf servisler ve ücretleri:
Güvenlik, gizlilik ve hesap/veri silme gereksinimleri:
Yayın kabul koşulları:

Başarı hedefi, ürünün iş modeline göre belirlenmelidir. Örneğin ilk hedef kullanıcıların randevu akışını tamamlayıp tamamlamadığını öğrenmekse, yalnızca indirme sayısını ölçmek bu soruyu yanıtlamaz. Akışın başlangıç ve tamamlanma olaylarını, hata durumlarını ve test dönemini ürün yayına çıkmadan önce tanımlayın.

Özellikleri nasıl önceliklendirmeli?

Her özellik için üç kısa değerlendirme yapın:

1. Olmadan ana kullanıcı akışı tamamlanıyor mu?
2. Bu özellik hangi ürün varsayımını sınamamıza yardım ediyor?
3. Geliştirme, servis ücreti, bakım ve güvenlik kapsamı nedir?

Özelliği ilk sürüm, sonraki sürüm veya kapsam dışı olarak işaretleyin ve karar gerekçesini yazın. Bu yöntem evrensel bir puan formülü değildir; ekibin kapsamı gerekçesiz biçimde büyütmesini engelleyen ortak bir karar kaydıdır.

Her ilk sürüm özelliği için kabul koşulu da belirleyin. Örneğin “randevu ekranı hazır” yerine “kullanıcı uygun bir saati seçtiğinde kayıt oluşturulur, tekrar gönderimde çift randevu oluşmaz ve kullanıcıya başarı ya da hata durumu gösterilir” gibi test edilebilir bir koşul yazın.

İlk sürümden sonra ne yapılır?

MVP yayınlandığında ürün geliştirme süreci bitmez.

Gerçek kullanıcı davranışları incelenerek sonraki sürüm planlanır.

Bakılabilecek konular:

• Kullanıcı kayıt oluyor mu?
• Ana işlemi tamamlıyor mu?
• Hangi aşamada uygulamadan ayrılıyor?
• Hangi özellikler kullanılıyor?
• Hangi özellikler kullanılmıyor?
• Kullanıcılar hangi özellikleri istiyor?
• Teknik sorunlar nerede yoğunlaşıyor?
• Kullanıcı tekrar uygulamaya geliyor mu?

İlk sürümden çıkarılan her özellik ikinci sürüme otomatik olarak eklenmemelidir.

Öncelikler gerçek kullanım verilerine göre tekrar değerlendirilmelidir.

İyi belirlenmiş bir MVP, yalnızca küçük bir uygulama değildir. Ana kullanım senaryosu çalışan ve ürünle ilgili önemli soruları test edebilen ilk sürümdür.

Uygulama mağazalarının kalite ve yayın koşulları platforma göre değişebilir. Android uygulamalarında yayın öncesi test kanalları ve temel kararlılık kontrolleri için Google Play'in uygulama test rehberini ve Android temel uygulama kalitesi yönergelerini inceleyin. Bu kontroller ürün varsayımını test etmenin yerine geçmez; yayın öncesi teknik hazırlığı tamamlar.

Mobil uygulama geliştirmeye yeni başlıyorsanız, mobil uygulamanın ne olduğunu ve temel bileşenlerini açıklayan rehberimizi de okuyabilirsiniz.

Sık sorulan sorular

MVP yalnızca az özellikli bir uygulama mıdır?

Hayır. MVP, belirli bir kullanıcı problemini çözebilen ve önemli bir ürün varsayımını sınayabilen ilk sürümdür. Kapsamı küçük olabilir, ancak ana akış kullanılabilir ve güvenilir olmalıdır.

Mobil uygulama MVP'sinde yönetim paneli gerekir mi?

İşletmenin kullanıcı, sipariş, randevu, içerik veya şikâyetleri yönetmesi gerekiyorsa panel ya da eşdeğer bir operasyon aracı kapsamın parçası olabilir. Gerekli yönetim işlemlerini kullanıcı uygulamasından ayrı listeleyin.

İlk sürümde iOS ve Android birlikte çıkmalı mı?

Karar hedef kitlenin kullandığı cihazlara, teknik mimariye, bütçeye, dağıtım yöntemine ve test varsayımına bağlıdır. Hedef kullanıcıların platform dağılımını doğrulamadan tek bir platform seçmek veya ikisini zorunlu saymak doğru olmaz.

MVP ne kadar sürede geliştirilir?

Süre; kullanıcı akışlarının, platformların, tasarımın, backend'in, entegrasyonların ve güvenlik gereksinimlerinin kapsamına bağlıdır. Bu bilgiler netleşmeden verilen süre ancak kaba tahmin olabilir.

DigiRise'ın mobil uygulama geliştirme sürecinde geliştirme başlamadan önce ana kullanıcı akışının, özellik kapsamının, yönetim ihtiyaçlarının ve teknik bağımlılıkların netleştirilmesi projenin daha öngörülebilir şekilde ilerlemesine yardımcı olur.