# İlk sürümde her şey değil, doğru şey olsun.

Kaynak: https://www.globya.com.tr/blog/mob-mobil-uygulama-kapsami-nasil-belirlenir
Tarih: 2026-06-26

> Mobil uygulama projelerinin çoğu kötü kod yüzünden değil, fazla geniş kapsam yüzünden gecikir. İlk sürüme her fikri sığdırmaya çalışmak, uygulamanın hiç yayına çıkmamasının en kısa yoludur.

Mobil uygulama kapsamı, uygulamanın ilk sürümde hangi işleri yapacağının ve hangilerini sonraya bırakacağının yazılı hâlidir. Kapsam net değilse bütçe, süre ve beklenti sürekli kayar; ekip "neredeyse bitti" dediği bir projeyi aylarca sürdürür. Bu yazıda kapsamı belirlerken kullanabileceğiniz basit bir yöntemi, MVP kavramını ve sık düşülen tuzakları anlatıyoruz.

## MVP ne demek, ne demek değil?

MVP (Minimum Viable Product), "kullanılabilir en küçük ürün" demektir. Yani asıl işi gerçekten yapan, gerçek kullanıcıya verilebilecek kadar olgun, ama gereksiz her şeyden arındırılmış ilk sürüm.

MVP yarım yamalak bir uygulama değildir. Az özelliği vardır, ama o özellikler eksiksiz ve güvenilir çalışır. Bir bayi sipariş uygulamasının MVP'si, "sipariş verilebiliyor ama fiyat yanlış görünüyor" olamaz; "yalnızca sipariş verilebiliyor, ama fiyat, stok ve sepet kusursuz" olmalıdır.

## Kapsamı belirlemenin dört adımı

**1. Tek cümlelik amaç yazın.** "Bu uygulama, ... kişisinin ... işini ... sayesinde kolaylaştırır." Örneğin: "Servis teknisyeninin iş emrini kapatmasını kağıt form olmadan, sahada yapmasını sağlar." Bu cümleye hizmet etmeyen her özellik, ilk sürüm için sorgulanmalıdır.

**2. Kullanıcının bir gününü yazın.** Uygulamayı kullanacak kişi sabah ne yapıyor, gün içinde nerede takılıyor, akşam ne teslim ediyor? Bu hikâye, gerçekten gerekli ekranları ortaya çıkarır.

**3. Özellik listesini çıkarın, sonra ayırın.** Aklınıza gelen her özelliği yazın, sonra her birini dört gruptan birine koyun:

| Grup | Anlamı | Örnek (saha uygulaması) |
|---|---|---|
| Olmazsa olmaz | Bu olmadan uygulama amacına hizmet etmez | İş emri listesi, kapanış, fotoğraf |
| Olmalı | Önemli, ama geçici bir yolla idare edilebilir | Müşteri imzası |
| Olsa iyi olur | Değer katar, ama bekleyebilir | Rota optimizasyonu |
| Şimdilik değil | Başka bir projenin konusu | Personel izin talepleri |

İlk sürüm, olmazsa olmazlarla ve olmalıların bir kısmıyla sınırlı kalmalıdır.

**4. Neyin dışarıda kaldığını da yazın.** Kapsam belgesinde "bu sürümde olmayanlar" başlığı, kapsam kadar önemlidir. Aylar sonra "bunu da konuşmuştuk" tartışmasının önüne geçer.

## İlk sürümde çoğu zaman gereksiz olanlar

Deneyimimize göre ilk sürüme girip az kullanılan özellikler genelde şunlardır:

- Ayrıntılı raporlama ekranları (raporlar çoğu zaman masaüstünde, yönetim panelinde daha iyi okunur)
- Uygulama içi mesajlaşma ya da sohbet
- Karmaşık kişiselleştirme ve tema seçenekleri
- Sosyal medya paylaşımı
- Çok dilli yapı (tek dil yetiyorsa)
- Her olay için bildirim

Bunların hiçbiri kötü fikir değil; yalnızca ilk sürümde asıl işin önüne geçme riski taşırlar.

## Görünmeyen kapsamı unutmayın

Kapsam yalnızca kullanıcının gördüğü ekranlardan oluşmaz. Genellikle unutulan ama bütçe ve süreyi belirleyen işler:

- **Yönetim paneli.** Uygulamadaki içeriği, kullanıcıları, yetkileri kim, nereden yönetecek?
- **Entegrasyonlar.** Veri ERP'den, muhasebe programından ya da mevcut portaldan mı gelecek? Bu bağlantılar çoğu zaman uygulamanın kendisi kadar emek ister; [entegrasyon](https://www.globya.com.tr/hizmetler/entegrasyon) çalışması baştan kapsamda olmalıdır.
- **Kullanıcı yönetimi.** Giriş, şifre sıfırlama, hesap kapatma, rol ve yetki.
- **Mağaza süreci.** Hesap açılışı, gizlilik beyanı, inceleme. Ayrıntısı [mağaza yayın süreci](https://www.globya.com.tr/blog/mob-uygulama-magazasi-yayin-sureci) yazımızda.
- **Bakım.** Yayından sonra işletim sistemi güncellemelerine uyum.

## Kapsam kaymasını nasıl önlersiniz?

Proje sürerken yeni fikir gelmesi doğaldır; önemli olan bunların nasıl ele alınacağıdır.

- Yeni istekleri reddetmeyin, bir "sonraki sürüm" listesine yazın.
- Mevcut sürüme mutlaka girmesi gereken bir değişiklik varsa, karşılığında neyin çıkacağını ya da sürenin ne kadar uzayacağını açıkça konuşun.
- Kısa aralıklarla çalışan bir ara sürüm görün. Elle tutulur bir şey görmek, kâğıt üzerinde tartışmaktan çok daha net karar verdirir.

## Kontrol listesi

- Tek cümlelik amaç yazıldı mı?
- Birincil kullanıcı ve onun bir günü tarif edildi mi?
- Özellikler dört gruba ayrıldı mı?
- "Bu sürümde olmayanlar" listesi var mı?
- Yönetim paneli, entegrasyon ve mağaza işleri kapsamda mı?
- İlk sürümün başarısı neyle ölçülecek belli mi?

## Globya'da nasıl yapıyoruz

Kapsamı sizinle birlikte, kullanıcının gününden yola çıkarak yazıyoruz. Belgede hem yapılacakları hem bu sürümde yapılmayacakları açıkça listeliyor, fiyatı ve süreyi bu yazılı kapsam üzerinden veriyoruz. Proje boyunca kısa aralıklarla çalışan sürüm gösteriyoruz; nasıl çalıştığımızı [çalışma şeklimiz](https://www.globya.com.tr/kurumsal/calisma-sekli) sayfasında anlattık. 2000'den beri yürüttüğümüz projelerde en çok işe yarayan şey, küçük başlayıp kullanıcıyla birlikte büyütmek oldu.

## Sık sorulan sorular

**Soru: MVP ile yayına çıkarsak kullanıcı eksik bulmaz mı?**
Asıl işi eksiksiz yapan bir uygulama eksik bulunmaz. Kullanıcı az özellikten değil, çalışmayan özellikten rahatsız olur.

**Soru: Kapsam belgesini biz mi hazırlamalıyız?**
Hayır. Elinizdeki fikirleri, mevcut formları ve süreç bilgisini paylaşmanız yeterli; belgeyi birlikte çıkarıyoruz.

**Soru: İkinci sürümün kapsamı ne zaman belirlenir?**
İlk sürüm birkaç hafta gerçek kullanıcılarla kullanıldıktan sonra. Kullanım verisi ve geri bildirim, masa başında yapılan tahminden çok daha iyi yol gösterir.

**Soru: Fiyatı nasıl belirliyorsunuz?**
Yazılı kapsam netleştikten sonra. Fiyat, keşif görüşmesinden sonra yazılı teklifle verilir.