Mobil MVP: İlk Sürümde Ne Yapmalı, Neyi Bilerek Ertelemeli?

1. Özellik Listesinden Önce Öğrenme Sözleşmesini Yazın

İlk soru “Uygulamada ne olacak?” değil, “Hangi belirsizliği azaltacağız?” olmalıdır. Hedef kullanıcıyı, tekrar eden problemi, uygulamanın sağlayacağı tek çekirdek sonucu ve bu sonucun gerçekleştiğini gösterecek davranışı bir sayfada tanımlayın. Örneğin “kişisel finans uygulaması” bir kapsam değildir; “kullanıcının bir haftalık harcamasını üç dakikadan kısa sürede sınıflandırıp sonraki kararını görmesi” sınanabilir bir döngüdür.

Başarı ölçütünü indirme sayısına bağlamayın. İndirme dağıtımı gösterir; ürün değerini değil. Çekirdek görevin tamamlanması, ilk anlamlı sonuca ulaşma, tekrar kullanım nedeni, hata oranı ve nitel geri bildirim birlikte ele alınmalıdır. Hangi sonuç yeterli olursa devam edeceğinizi, hangi sinyal değişiklik isteyeceğini ve hangi durumda varsayımı bırakacağınızı geliştirme başlamadan yazın.

MVP sözleşmesi paydaş pazarlığını da kolaylaştırır. Yeni bir özellik önerildiğinde “iyi fikir mi?” tartışması yerine “bu özellik çekirdek sonucu mümkün kılıyor mu, riski azaltıyor mu, yoksa sonraki varsayımı mı test ediyor?” diye sorarsınız. Cevap üçüncüyse fikir kaybolmaz; açık bir ertelenenler havuzuna gider.

2. Must–Should–Defer Matrisini Riskle Birlikte Kullanın

“Must” en çok istenen değil, çekirdek döngü olmadan çalışmayan veya yayınlanması güvenli olmayan iştir. Kimlik doğrulama gerçekten zorunlu mu, yoksa misafir akışı ilk değeri daha hızlı mı gösterir? Gerçek zamanlı sohbet değer önerisinin kendisi mi, yoksa ilk sürümde yapılandırılmış talep formu yeterli mi? Her özelliğe kullanıcı değeri, öğrenme katkısı, operasyon yükü, teknik bağımlılık ve geri dönüş maliyeti açısından bakın.

“Should” ilk sürümden hemen sonraki kanıtlı sürtünmeyi azaltır; fakat çekirdek döngünün varlığına engel değildir. “Defer” ise belirsiz değere rağmen yüksek maliyet, ağır moderasyon, çoklu platform bağımlılığı veya ölçek gerektirir. Ertelemek, belirsiz bir “sonra” kutusu değildir. Yeniden değerlendirme tetikleyicisini yazın: belirli destek konusu, görev başarısızlığı, kurumsal müşteri gereksinimi veya operasyon kapasitesi gibi.

Matris bir kez doldurulup kilitlenmez. Prototip, teknik keşif veya mağaza politikası yeni bilgi getirdikçe karar değişebilir. Değişen öğenin nedenini, etkilediği yayın tarihini ve karşılığında kapsamdan ne çıktığını kaydedin. Kapsama ekleme için takvim değil takas gerekir.

3. Görünmeyen Ürün İşini Kapsama Dahil Edin

Kapsam tabloları çoğu zaman yalnızca görünen ekranları sayar. Oysa hesap yaşam döngüsü, veri modeli, izinler, çevrimdışı durum, hata mesajları, destek, analitik, erişilebilirlik, içerik yönetimi ve üçüncü taraf arızaları da üründür. Bir ödeme ekranı tasarlamak kolay; başarısız ödeme, tekrar deneme, iade ve destek sahipliğini kurmak daha fazla karar ister.

Mimariyi varsayımsal milyonlar için aşırı büyütmeyin; fakat geri dönüşü pahalı kararları erken keşfedin. Sağlık veya finans verisi, çoklu organizasyon yapısı, çevrimdışı senkronizasyon, abonelik, konum ve kullanıcı üretimli içerik gibi alanlar veri, güvenlik ve operasyon modelini değiştirir. Kısa bir teknik keşif; kod yazmadan veri akışını, bağımlılıkları, tehditleri ve hizmet kesintisi davranışını görünür kılmalıdır.

Teknoloji seçimini “native mi cross-platform mu?” sloganına indirgemeyin. Ekip deneyimi, cihaz özelliği ihtiyacı, erişilebilirlik, performans hedefi, sürüm desteği ve uzun vadeli bakım sahibini birlikte değerlendirin. İlk sürümde iki platform zorunlu değilse tek platformla varsayım sınamak mantıklı olabilir; fakat hedef kitle verisi bu kararı desteklemelidir.

4. Demo Değil, Yayınlanabilir Ürün İçin Kapılar Kurun

Apple, incelemeye gönderilen sürümün tamamlanmış olmasını; çökme ve belirgin teknik sorunlar açısından cihazda test edilmesini, metadata ve bağlantıların doğru olmasını, hesaplı akışlarda inceleme erişimi sağlanmasını ve arka uç servislerinin çalışır durumda tutulmasını ister. App Store ayrıca yalnızca yeniden paketlenmiş bir web deneyiminin ötesinde yeterli işlev ve kalıcı fayda bekler. Bu nedenle “MVP” etiketi; yer tutucu içerik, bozuk bağlantı veya tamamlanmamış ana akış için mazeret değildir.Apple Developer — App Review Guidelines

Android'in güncel temel kalite rehberi; tüm ekran ve akışların, kesintilerin, ağ değişimlerinin, uyku-dönüşün ve temsilî cihazların test edilmesini vurgular. Android yayın hazırlığı da release sürümünün ayrıca yapılandırılıp oluşturulmasını ve test edilmesini gerektirir. Geliştirici cihazında çalışan debug paketi, yayın kanıtı sayılmaz.Android Developers — Core app quality guidelinesAndroid Developers — Prepare your app for release

Her kapı geçer-kalır ölçütü taşımalıdır. “QA tamamlandı” yerine “P0/P1 hata yok; ana görev desteklenen cihazlarda tamamlandı; çevrimdışı ve servis hatası davranışı doğrulandı” yazın. Ürün sahibi değer kapısını, teknik lider kararlılık ve güvenlik kapısını, operasyon sahibi destek kapısını, yayın sahibi mağaza ve metadata kapısını onaylasın.

5. Örnek Senaryo: Kurgusal Randevu Uygulamasında Kapsam Takası

Örnek senaryo — bu bir müşteri projesi değildir: Küçük hizmet işletmeleri için randevu uygulaması tasarlayan kurgusal ekip; takvim, mesajlaşma, sadakat puanı, kampanya, çoklu şube ve yapay zekâ önerilerini ilk sürüme koymak istiyor. Öğrenme sözleşmesi ise daha dar: “Yeni müşteri uygun saati bulup doğrulanmış randevu oluşturabiliyor mu; işletme bu talebi karışıklık olmadan yönetebiliyor mu?”

Must kapsamına hizmet ve saat seçimi, iletişim bilgisi, randevu onayı, işletme panelinde durum yönetimi, iptal yolu, temel analitik ve hata durumları giriyor. Hatırlatma bildirimi ilk no-show riskini azaltacağı için Should olarak ilk ölçüm dönemine yerleşiyor. Sadakat, sosyal giriş, gelişmiş kampanya ve yapay zekâ önerileri Defer oluyor. Çoklu şube ise ilk pilot kullanıcıların ihtiyacı olmadığı için kapsam dışına çıkıyor.

Teknik keşif, takvim çakışmasının yalnızca arayüzde değil sunucuda engellenmesi gerektiğini gösteriyor. Ekip animasyonlu onboarding yerine bu veri bütünlüğü işine zaman ayırıyor. Yayın kapısında iki görev testi başarısız olduğunda tarihi korumak için doğrulama e-postasını çıkarmak yerine akışı düzeltmeyi seçiyor; çünkü ana döngü tamamlanmadan edinilen indirme öğrenme üretmeyecek.

6. İlk Oturumu Sunumdan Değere Kısaltın

Apple'ın onboarding rehberi, mümkünse uygulamanın deneyim yoluyla anlaşılmasını; onboarding gerekiyorsa hızlı, isteğe bağlı ve etkileşimli olmasını önerir. Temel olmayan kurulumların ertelenmesini ve izinlerin ilgili özelliğin bağlamında istenmesini vurgular. Bu yaklaşım MVP için değerlidir: ilk oturum ürün turunu tamamlama yarışı değil, ilk anlamlı sonuca giden görev olmalıdır.Apple Human Interface Guidelines — Onboarding

İlk sürüm olay haritasını kurun: uygulama açılışı, ana göreve başlama, kritik adımlar, hata, görev tamamlama ve ilk sonucu görme. Olay adını yalnızca ekran adına bağlamak yerine kullanıcı niyetini yansıtın. Nitel görüşmelerde “beğendiniz mi?” yerine nerede durduklarını, ne beklediklerini, hangi bilgiyi aradıklarını ve uygulama olmadan işi nasıl yaptıklarını sorun.

Pilot grubunuzu yalnızca ekip arkadaşlarından oluşturmayın. Gerçek hedef kullanıcı, farklı cihaz ve bağlantı koşulları, yeni ve tekrar gelen davranışları temsil edilmelidir. Pilotun süresini takvimle değil öğrenme fırsatıyla belirleyin. Kritik davranış az tekrarlanıyorsa daha uzun dönem veya farklı bir test tasarımı gerekebilir.

7. Yaygın Hatalar, Sınırlar ve Uygulama Kontrol Listesi

Yaygın hatalar; MVP'yi “ucuz sürüm” sanmak, kapsamı ekran sayısıyla ölçmek, mağaza incelemesini son güne bırakmak, analitiği yayından sonra eklemek, her paydaş talebini Must saymak ve ertelenen işler için tetikleyici yazmamaktır. Bir başka hata, hızlı yayın baskısıyla üçüncü taraf SDK'ların veri kullanımını ve bakım riskini incelememektir.

MVP her bağlamda uygun değildir. Tıbbi karar, finansal işlem, fiziksel güvenlik veya kritik altyapı gibi yüksek riskli alanlarda daha geniş doğrulama, düzenleyici inceleme ve kontrollü dağıtım gerekir. “Küçük kitle” düşük risk anlamına gelmez. Bu rehber ürün kapsamı sağlar; hukuki, güvenlik veya sektörel onayın yerine geçmez.

• Hedef kullanıcı, kritik problem, çekirdek görev ve görünür sonuç tek cümlede tanımlı.
• Devam, değiştir ve durdur kararları için ölçüm eşikleri geliştirmeden önce yazıldı.
• Her özellik Must, Should, Defer veya Reject olarak gerekçesiyle sınıflandırıldı.
• Yeni kapsam yalnızca eşdeğer bir takas ve karar kaydıyla kabul ediliyor.
• Veri, izin, güvenlik, hata, çevrimdışı durum, destek ve analitik görünmeyen iş olarak planlandı.
• Release paketi temsilî cihaz, ağ kesintisi, uyku-dönüş ve ana görevlerle test edildi.
• Mağaza metadata, inceleme hesabı, canlı servis, gizlilik ve destek bağlantıları hazır.
• İlk oturum ölçümü, pilot grubu ve öğrenme sonrası karar toplantısı sahipli.