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

Canonical URL: https://nixeny.com/tr/blog/mobil-mvp-kapsam-rehberi
Published: 2026-08-13
Language: tr
Author: Fatih Muhammed Gök
Category: Mobil Uygulama
Publisher: Nixeny Dijital

> İlk mobil sürümü özellik listesiyle değil, kanıtlanacak davranış ve yayın riskleriyle sınırlandırın; zorunlu, gerekli ve ertelenebilir işleri açık bir karar sistemiyle yönetin.

MVP, eksik bir uygulamayı aceleyle mağazaya göndermek değildir. En küçük ama güvenilir ürün döngüsünü kurarak kritik bir iş varsayımını gerçek kullanımda sınamaktır. “En küçük” kısmı kapsamı sınırlar; “uygulanabilir ürün” kısmı ise verinin, güvenliğin, temel deneyimin ve yayın kalitesinin pazarlığa açık olmadığını hatırlatır.

Kapsam yanlış kurulduğunda ekip iki uçtan birine savrulur: Her paydaşın isteğini ilk sürüme doldurup aylarca öğrenemez ya da yalnızca birkaç ekran çıkarıp kullanıcıya anlamlı sonuç sunamaz. Bu rehber, tek bir çekirdek sonucu seçmekten mağaza yayın kapılarına kadar uygulanabilir bir karar sistemi sunar. Amaç daha az iş yapmak değil; öğrenmeye katkısı olmayan işi bilinçli biçimde ertelemektir.

## 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.

> **Bir cümlelik kapsam testi** (action)
>
> Hedef kullanıcı, kritik durum, ana görev ve görünür sonucu tek cümlede anlatamıyorsanız kapsam henüz özellik seçmeye hazır değildir.

## 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.

**MVP kapsam karar matrisi**

| Sınıf | Karar ölçütü | Örnek | Yayın yaklaşımı |
| --- | --- | --- | --- |
| Must | Çekirdek sonucu veya güvenli kullanımı mümkün kılar | Ana görevi tamamlama, veri silme yolu | İlk sürümden önce tamamla ve test et |
| Should | Doğrulanmış sürtünmeyi azaltır, döngü onsuz çalışır | Kaydedilmiş filtre, daha hızlı tekrar giriş | İlk ölçüm dönemine planla |
| Defer | Değeri belirsiz veya maliyeti öğrenme katkısından yüksek | Sosyal akış, gelişmiş kişiselleştirme | Tetikleyici ve sahip belirle |
| Reject | Ana probleme hizmet etmez ya da kabul edilemez risk taşır | Sırf rakipte var diye eklenen özellik | Gerekçeyi kaydet, yol haritasından çıkar |

## 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. [1]

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. [2][3]

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.

**İlk sürüm yayın kapıları**

| Kapı | Geçiş ölçütü | Kanıt | Sahip |
| --- | --- | --- | --- |
| Değer | Hedef kullanıcı ana sonucu tamamlayabiliyor | Görev testi ve olay akışı | Ürün |
| Kararlılık | Kritik çökme, veri kaybı ve engelleyici hata yok | Release test raporu | Mühendislik |
| Güven ve mahremiyet | İzin, veri kullanımı, silme ve politika akışları hazır | Kontrol listesi ve uzman incelemesi | Ürün + hukuk/güvenlik |
| Operasyon | Destek, olay müdahalesi ve içerik sahipleri belli | Çalışma talimatı ve iletişim yolu | Operasyon |
| Mağaza | Metadata doğru, erişimler ve canlı servisler hazır | TestFlight/kapalı test ve gönderim dosyası | Yayın yöneticisi |

## 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.

> **Kapsam kesmek kalite kesmek değildir** (insight)
>
> Bir özelliği ertelemek çekirdek akışı daha güvenilir kılabilir. Güvenlik, veri bütünlüğü, hata kurtarma ve temel erişilebilirlik ise “sonraki sürüm” kalemleri değildir.

## 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. [4]

İ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.

## Sonuç

İyi MVP az özellikli olduğu için değil, tek bir sonucu güvenilir biçimde sınadığı için küçüktür. Öğrenme sözleşmesini yazın, kapsamı risk ve değerle sınıflandırın, görünmeyen ürün işini hesaba katın ve mağaza yayınını ölçülebilir kapılara bağlayın. Böylece ilk sürüm bir demo değil; sonraki yatırımı daha bilgili yapmanızı sağlayan gerçek bir ürün olur.

## Sıkça sorulan sorular

### MVP yalnızca tek platformda yayınlanabilir mi?

Evet, hedef kitleniz ve öğrenme sorunuz bunu destekliyorsa tek platform kapsamı azaltabilir. Ancak diğer platformdaki kritik kullanıcıyı dışlamanın etkisini ve daha sonra genişlemenin teknik maliyetini karar kaydına ekleyin.

### MVP'de kullanıcı hesabı zorunlu mudur?

Hayır. Çekirdek sonuç hesap gerektirmiyorsa misafir akışı daha hızlı değer gösterebilir. Veri senkronizasyonu, ödeme, güvenlik veya cihazlar arası kullanım hesabı zorunlu kılıyorsa gerekçeyi ve hesap yaşam döngüsünü planlayın.

### Kaç özellikle MVP olur?

Sabit sayı yoktur. Ölçüt; hedef kullanıcının uçtan uca ana sonucu güvenli biçimde tamamlaması ve ekibin temel varsayımı ölçebilmesidir. Bazı ürünlerde üç yetenek, bazılarında daha geniş bir operasyon akışı gerekir.

### İlk sürüm başarısız olursa proje bitmeli mi?

Otomatik olarak değil. Sorunun değer varsayımı, kullanılabilirlik, dağıtım veya teknik güvenilirlikten hangisinde olduğunu ayırın. Önceden yazılmış değiştir ve durdur ölçütleri, yalnızca sevdiğiniz fikri savunma riskini azaltır.

## Kaynaklar

1. [Apple Developer — App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/) — Uygulama bütünlüğü, doğru metadata, test, inceleme erişimi ve minimum işlev gereksinimleri
2. [Android Developers — Core app quality guidelines](https://developer.android.com/docs/quality-guidelines/core-app-quality) — Kullanıcı akışları, cihaz durumları, ağ değişimleri ve temel kalite testleri
3. [Android Developers — Prepare your app for release](https://developer.android.com/studio/publish/preparing) — Release yapılandırması, derleme ve yayın öncesi test hazırlığı
4. [Apple Human Interface Guidelines — Onboarding](https://developer.apple.com/design/human-interface-guidelines/onboarding) — Hızlı, isteğe bağlı, etkileşimli onboarding ve bağlamsal izin yaklaşımı