İlk Mobil Uygulama Sürümünde Hangi Özellikler Olmalı? MVP Rehberi

Mobil uygulama fikriniz büyüdükçe özellik listesi de uzar: üyelik, ödeme, kampanya, mesajlaşma, puan sistemi ve gelişmiş raporlar. Hepsini ilk sürüme almak, müşterinin asıl işini öğrenmeden büyük bir kapsamı üstlenmenize yol açabilir. Bu rehber, ilk çalışan sürümde hangi özelliklerin bulunması gerektiğini ve hangilerinin ertelenebileceğini belirlemenize yardımcı olur.

MVP nedir, ilk sürümde neyi kanıtlamalıdır?

MVP, bir ürünün temel varsayımını gerçek kullanımda sınayacak kadar işlevli ilk sürümü olarak düşünülebilir. Buradaki amaç, yarım çalışan bir uygulamayı erken yayınlamak değildir. Sınırlı fakat tamamlanabilir bir müşteri yolculuğu sunmak ve bundan öğrenmektir.

Bir atölye için randevu uygulaması hazırladığınızı varsayalım. Müşteri hizmet seçiyor, uygun saati buluyor ve randevusunu oluşturuyor; işletme de kaydı görüp yönetebiliyor. Bu zincir çalışmıyorsa profil fotoğrafı, puan sistemi veya kampanya ekranının hazır olması temel sorunu çözmez.

Ürünün ilk sorusunu net yazın: “Müşterilerimiz telefonla aramadan kendilerine uygun randevuyu oluşturabiliyor mu?” Bu soru sizi işlevli bir deneyim tasarlamaya yönlendirir. “Kaç özellik yaptık?” sorusu ise tamamlanan iş sayısını gösterir, müşteriye sağlanan değeri tek başına açıklamaz.

Özellik listesini kullanıcı yolculuğundan çıkarın

Önce müşterinin uygulamayı açtığı andan işini bitirdiği ana kadar geçtiği adımları yazın. Her adımın yanında ihtiyaç duyduğu bilgi, vereceği karar ve görebileceği hata bulunsun. Ardından aynı işlemin çalışan tarafındaki karşılığını ekleyin.

1. Hizmeti anlama: Müşteri hizmetin kapsamını ve gereken süreyi görür.
2. Uygunluk seçimi: Gerçekten kullanılabilir tarih ve saatler gösterilir.
3. Bilgi verme: İşlem için gereken iletişim ve açıklama bilgileri alınır.
4. Onay alma: Talebin alındığı veya randevunun kesinleştiği açıkça söylenir.
5. İşletmede yönetme: Yetkili çalışan kaydı görür, günceller ve gerektiğinde iptal eder.

Bu liste üzerinden üyeliğin gerekli olup olmadığını tartışabilirsiniz. Müşteri geçmiş kayıtlarını yönetmek zorundaysa hesap gerekebilir. Tek seferlik talep için ise her bilgiyi en başta istemek yerine daha sade bir akış değerlendirilebilir; karar, doğrulama ve güvenlik ihtiyaçlarıyla birlikte verilmelidir.

Yönetim tarafını atlamak sık yapılan bir hatadır. Takvimde değişen çalışma saatleri uygulamaya yansımıyorsa müşteri ekranı ne kadar düzgün görünürse görünsün operasyon aksar. Ürünün ilk sürümünü hem müşterinin hem işletmenin tamamladığı işler üzerinden tanımlayın.

Özellikleri üç grupta nasıl ayırırsınız?

Her özellik için temel akışa etkisini, iş yükünü ve sınadığı varsayımı yazın. “Herkeste var” gerekçesiyle listeye alınan özellikleri yeniden değerlendirin. Bir özelliğin ertelenmesi, hiçbir zaman yapılmayacağı anlamına gelmez.

Özelliğin iş yükü ile etkisini aynı toplantıda konuşun. Küçük görünen bir “kupon alanı”, kampanya geçerliliği, kullanım sınırı ve iptal sonrası iade kuralları gerektirebilir. Buna karşılık sık sorulan bir hizmet açıklamasını iyileştirmek daha sınırlı bir işle müşterinin kararını kolaylaştırabilir.

Küçük sürümde de ertelenmemesi gerekenler nelerdir?

Veri doğruluğu ve erişim yetkileri

Bir müşteri başka müşterinin randevusuna erişememelidir. Çalışan yetkileri de işletmenin yapısına uygun olmalıdır. Bu koşullar görsel tasarımdan bağımsızdır; ekranın bir düğmeyi gizlemesi, sunucudaki erişim kontrolünün yerini tutmaz.

OWASP'ın yetkilendirme rehberi, izinlerin her istekte denetlenmesini önerir; erişim 28 Ekim 2026. Teklif belgesinde bunu anlaşılır kabul koşullarına çevirin. Örneğin “başka hesaba ait kayıt kimliğiyle yapılan istek reddedilir” koşulu test edilebilir bir beklentidir.

Hata durumları ve doğru durum bilgisi

Bağlantı kesildiğinde müşteri işleminin tamamlanıp tamamlanmadığını anlamalıdır. Randevu talebi ile kesinleşmiş randevu farklıysa bu ayrımı açıkça gösterin. Başarısız işlemde aynı düğmeye yeniden basılması mükerrer kayıt oluşturmamalıdır.

İlk sürümde ayrıntılı rapor paneli ertelenebilir, ancak temel hataları izleyebilmek için bir düzen kurulmalıdır. İşletmenin sorun bildireceği kanal ve kayıtların incelenmesinden sorumlu kişi belirli olsun. Aksi durumda pilot kullanıcıların yaşadığı güçlükleri zamanında fark edemeyebilirsiniz.

Kod yazılmadan önce neyi test edebilirsiniz?

Tıklanabilir prototip, ekranlar arasındaki geçişi ve bilgi düzenini denemenizi sağlar. Müşterinin gerçek veriyle işlem yaptığı çalışan ürünün yerini tutmaz. Yine de anlaşılmayan düğmeleri, gereksiz adımları ve eksik açıklamaları geliştirme öncesinde görmenize yardımcı olabilir.

Katılımcıya uygulamayı anlatmak yerine görev verin: “Perşembe öğleden sonra bakım randevusu alın.” Siz açıklama yapmadan nerede durduğunu gözlemleyin. Kendi müşterilerinizin kullandığı dil ve beklentiler, ekip içindeki varsayımlardan farklı olabilir.

Planlama örneği olarak ilk hafta görüşme ve taslak, ikinci hafta deneme ve revizyon ayırabilirsiniz. Bu bir süre garantisi değildir; kullanıcıların erişilebilirliği ve iş akışına göre değişir. Deneme sonunda yalnızca yorumları değil, hangi kararın neden değiştiğini de kaydedin.

Kapsamı azaltmak bütçeyi nasıl etkiler?

Özellik elemek, yalnızca ekran çizimini azaltmaz. Sunucu kuralları, testler, yönetim ekranları ve destek senaryoları da kapsamdan çıkabilir. Buna karşılık bazı ortak işler, az sayıda özellikte de gerekir; kullanıcı yetkileri ve yayın hazırlığı buna örnektir.

Hesap yöntemini açıklayan varsayımsal bir örnekte ilk sürüm 40 kişi-gün, ek paket özellikleri 15 kişi-gün olarak tahmin edilmiş olsun. Tamamen varsayımsal 6.000 TL kişi-gün bedeliyle ilk sürüm 240.000 TL, ek paket 90.000 TL eder. Bu tutarlar piyasa ortalaması veya Navdion fiyatı değildir; KDV, altyapı ve dış hizmetler dahil değildir.

Bu hesabı tedarikçinizin gerçek iş kırılımıyla değiştirin. Ayrıca bir özellik çıkarıldığında hangi ortak işlerin devam ettiğini sorun. “Listeyi yarıya indirdik, bedel de yarıya iner” varsayımı her projede geçerli olmayabilir.

Platform kararı bütçeyi etkiliyorsa mobil web seçeneğini de değerlendirin. Kullanım amacınız için önce bağlantıyla açılan bir akış yeterli olabilir. Hangi çözümle başlanırsa başlansın, kapsamı ve kabul koşullarını yazılı tutun.

İlk kullanıcılarla hangi verileri takip etmelisiniz?

Önce temel hedefi seçin: Müşteri randevu oluşturabiliyor mu ve işletme bu kaydı yönetebiliyor mu? Ardından süreci anlamanıza yardım eden göstergeleri belirleyin. İndirme sayısı tek başına, müşterinin işini tamamladığını göstermez.

• Başlama ve bitirme: Temel işlemi başlatanların nerede durduğunu inceleyin.
• Operasyon karşılığı: Oluşan kayıtların çalışanlar tarafından işlenip işlenmediğini kontrol edin.
• Destek ihtiyacı: Aynı sorunun tekrarlandığı ekranları ve açıklamaları not edin.
• Tekrar kullanım: Kullanıcıların aynı işi yeniden yaparken zorlandığı adımları izleyin.

Örnek pilot planında küçük bir kullanıcı grubuyla iki haftalık gözlem dönemi ayırabilirsiniz. Bu süre bir araştırma standardı değildir; seyrek kullanılan hizmetlerde daha uzun gözlem gerekebilir. Sonuçları gerçek kullanıcı sayısı ve kullanım bağlamıyla birlikte yorumlayın, genellenmiş başarı yüzdeleri üretmeyin.

Sonraki sürüme hangi özellik geçmeli?

Yeni isteği üç soruyla değerlendirin: Hangi kullanıcı sorununu çözüyor, bunu hangi gözlem destekliyor ve beklenen sonuç nasıl anlaşılacak? Yalnızca ekip içindeki beğeniye dayanan özellikleri önceliklendirmeyin. Mevcut akıştaki bir engeli kaldırmak, yeni bir bölüm eklemekten daha yararlı olabilir.

Örneğin müşteriler sürekli aynı randevuyu tekrarlıyorsa kısayol değerlendirilebilir. Ancak talepler çalışan panelinde bekliyorsa önce görev atama ve bilgilendirmeyi düzeltmek gerekebilir. Dönüşüm optimizasyonu rehberindeki akış yaklaşımını da bu değerlendirmeye uyarlayabilirsiniz.

Her sürüm için kısa değişiklik listesi ve kabul senaryoları hazırlayın. İşletme ekibine yeni davranışları gösterin; müşterinin bildirdiği sorunun giderilip giderilmediğini tekrar kontrol edin. Böylece ürününüz varsayılan ihtiyaçlar yerine gerçek kullanım üzerinden gelişir.

İlk sürüm belgesinde hangi kararlar yazmalı?

Tek sayfalık kapsam belgenizin başına hedef kullanıcıyı ve tamamlanacak işi yazın. Altına dahil olan akışları, özellikle ertelenen özellikleri ve kabul koşullarını ekleyin. Bu belge tasarım sırasında yeni fikirler çıktığında hangi kararın geçerli olduğunu hatırlatır.

Her özellik için bir sorumlu ve bir sonuç tanımı bulunması yararlıdır. “Bildirim yapılacak” yerine “işletme randevuyu iptal ettiğinde müşteriye iptal durumu gösterilecek” yazın. Kullanılacak kanal ve başarısız gönderimde yapılacak işlem de konuşulmalıdır; belirsiz bir ifade farklı ekiplerde farklı beklenti yaratabilir.

Pilot kullanıcıların destek alacağı kişiyi ve gözlemleri kimin toplayacağını da belirleyin. Ürün ekibine gelen her isteği hemen geliştirmeye çevirmeyin; önce hangi sorunun tekrarlandığını ve temel akışı etkileyip etkilemediğini inceleyin. Böylece ilk sürüm, yayına çıktığı gün kontrolsüz biçimde genişlemez.

Kapsam belgesini ekip için kolay erişilen tek yerde tutun. Tarih ve sürüm bilgisi ekleyerek önemli kararları güncelleyin. Aynı uygulama için farklı kişilerde farklı listeler bulunması, küçük başlama kararının günlük çalışmada korunmasını zorlaştırır.

Sonuç: Küçük ama tamamlanan bir işle başlayın

İlk sürümde müşterinin temel işini, işletmenin yönetim ihtiyacını ve güvenilir çalışma koşullarını birlikte sağlayın. Ek özellikleri gözlemlerle önceliklendirin ve her sürümde neyi öğrenmek istediğinizi belirtin. Navdion ile ilk sürüm kapsamınızı netleştirmek için ücretsiz proje analizi talep edebilirsiniz.