MVP Nedir? Minimum Uygulanabilir Ürün Nasıl Belirlenir, Kapsam Nasıl Puanlanır?

Bir yazılım fikrini baştan sona yapıp piyasaya sürdükten sonra kullanıcının onu istemediğini öğrenmek, bir projenin yaşayabileceği en pahalı sürprizdir. MVP (minimum uygulanabilir ürün, minimum viable product), bu sürprizi küçük bir yatırımla erkene çekmenin yoludur: önce en riskli varsayımı sınayacak en küçük gerçek ürünü yayınlar, kullanıcıdan öğrenir, sonra büyütürsünüz.

Bu rehberde MVP nedir, prototip ve tam üründen nasıl ayrılır, hipotezle başlayan kapsam belirleme nasıl yapılır, 12 özelliği tek bir formülle nasıl puanlarsınız, başarı ölçütleri neden yapımdan önce yazılır, maliyet ve süre ne kadar değişir, MVP'nin neden düşük kalite anlamına gelmediği ve sonrasında yol haritası nasıl kurulur sorularını yanıtlıyoruz. Tüm rakamlar temsilîdir; gerçek bir proje fiyatı ya da sektör ortalaması değildir.

MVP Nedir?

MVP, bir ürün hipotezini sınayacak çekirdek özellikleri taşıyan, gerçek kullanıcıların gerçek işte kullanabildiği ilk sürümdür. "Minimum" özellik sayısını, "uygulanabilir" ise ürünün çalışır ve güvenilir olmasını anlatır. Yani eksik olan şey kalite değil, kapsamdır.

MVP'nin üç unsuru vardır: sınanacak bir hipotez, o hipotezi sınamaya yetecek en küçük özellik kümesi ve sonucu okuyacak ölçütler. Bunlardan biri eksikse elinizdeki şey MVP değil, sadece yarım kalmış bir üründür. Özel yazılımın tanımını ve katmanlarını özel yazılım nedir rehberimizde anlattık; MVP, bu yaklaşımın riski küçülten bir yürütme biçimidir.

Okumanızı öneririz: Özel yazılım hizmetimiz

MVP, Prototip ve Tam Ürün Arasındaki Fark Nedir?

Prototip fikri göstermek için, MVP fikri sınamak için, tam ürün ise sınanmış fikri ölçeklemek için yapılır. Üçü farklı soruya cevap verir ve birbirinin yerini tutmaz.

Prototipin ekran akışları ve doğruluk düzeyleri UX tasarımı rehberimizde anlatılıyor; çoğu zaman MVP'den önce kısa bir prototip turu atmak iyi bir sigortadır.

MVP'ye Neden İhtiyaç Duyulur?

Çünkü yazılım projelerinde en büyük risk teknik değil, varsayımdır: kullanıcı bu özelliği isteyecek mi, süreç gerçekten böyle işliyor mu, ücret ödenir mi? Varsayımlar yapımdan sonra sınanırsa yanlış çıktıklarında tüm bütçe gitmiş olur.

• Erken öğrenme: Yanlış varsayım haftalar içinde, küçük bütçeyle ortaya çıkar.
• Para ve zaman tasarrufu: Kullanılmayacak özelliğe yatırım yapılmaz.
• Gerçek veri: Kararlar toplantı tahminiyle değil kullanım sayılarıyla alınır.
• İç destek: Çalışan bir sürüm, yöneticileri ve kullanıcıları ikna etmenin en iyi yoludur.

Bunun karşılığı, tam kapsamı hemen alamamanızdır. Ürünün ilk gün her şeyi yapması şart olan nadir durumlarda (örneğin yasal zorunluluk) MVP yaklaşımı yerine tam kapsamlı bir plan gerekir.

MVP Hipotezle Nasıl Başlar?

Önce özellik listesi değil, bir cümlelik hipotez yazılır: "Bayiler, telefonla sipariş vermek yerine portaldan sipariş vermeyi tercih eder." Bu cümle MVP'nin neden var olduğunu söyler ve kapsamı belirler.

İyi bir hipotez üç özelliğe sahiptir: tek bir kullanıcı grubunu anlatır, davranışı ölçülebilir kılar ve yanlış çıkabilir. "Kullanıcılar ürünümüzü sevecek" sınanamaz; "10 pilot bayinin en az yarısı ilk iki hafta içinde portaldan sipariş verecek" sınanır.

1. Sorunu yazın: Kim, hangi işte, ne yüzden zorlanıyor?
2. Varsayımları sıralayın: Hangi varsayım yanlışsa proje çöker? En riskli olanı seçin.
3. Tek hipotez kurun: Davranış ve sayı içersin.
4. Sınamaya yetecek akışı çizin: Kullanıcı hipotezi doğrulayan davranışı yapabilmek için hangi adımlardan geçer?

Sorunun ve kullanıcının nasıl net yazılacağı gereksinim analizi rehberimizin konusudur; MVP hipotezi, o analizin en riskli satırını seçmektir.

MVP Kapsamı Nasıl Belirlenir? Değer × Risk ÷ Efor Yöntemi

Her aday özelliğe üç puan verilir ve tek bir sayıya çevrilir: Puan = değer × risk ÷ efor. En yüksek puanlı özellikler MVP'ye girer.

• Değer (1–5): Hipotezi sınamak için bu özellik ne kadar gerekli?
• Risk (1–5): Bu özellik hakkında ne kadar belirsizlik var, yani ondan ne kadar çok şey öğreneceğiz? Bilinen, standart bir özellik düşük; sonucu merak edilen yüksek puan alır.
• Efor (kişi-gün): Geliştirmenin tahmini iş günü.

Mantık şudur: değerli ve belirsiz olan, ucuza yapılabiliyorsa önce yapılmalıdır. Bayi sipariş portalı örneğinde 12 aday özellik şöyle puanlanır (puan = değer × risk ÷ efor):

İlk beş özellik MVP'ye girer: 3 + 8 + 7 + 4 + 6 = 28 kişi-gün. Tüm liste 74 kişi-gündür (4 + 6 + 8 + 3 + 6 + 7 + 5 + 10 + 8 + 8 + 5 + 4). Beşinci ve altıncı özellik arasında belirgin bir basamak vardır (2,50 ile 2,00); bu, kesme noktasını sezgiyle değil sayıyla göstermenin yararıdır. Puanlar tartışmayı yok etmez ama tartışmayı ortak bir dile taşır; iki kişi aynı özelliğe farklı puan veriyorsa fark, varsayımınızın henüz net olmadığını gösterir.

Bu yöntem, gereksinim analizinde kullanılan Must, Should, Could sınıflamasını tamamlar: sınıflama neyin zorunlu olduğunu, puanlama ise önce neyin yapılacağını söyler.

MVP'nin Başarısı Nasıl Ölçülür?

Başarı ölçütleri yapımdan önce yazılır, çünkü sonuç geldikten sonra konan hedef, sonucu savunmaya dönüşür. Her ölçüt için bir eşik ve o eşiğe göre verilecek karar baştan belirlenir.

Karar kuralı da önceden yazılır: aktif bayi oranı %50 ve üzerindeyse devam, %25 ile %50 arasındaysa kullanım engelini bulup değiştir, %25'in altındaysa hipotezi gözden geçir ya da dur. Böylece "biraz kullanılıyor, devam edelim" gibi belirsiz bir sonuç kalmaz. Bu sayılar temsilîdir; kendi eşiklerinizi sürecinizin gerçek durumuna göre koyun.

Üret, Ölç, Öğren Döngüsü Nasıl İşler?

MVP tek seferlik bir teslimat değil, bir döngünün ilk turudur. Her tur hipotezi netleştirir, kapsamı günceller ve bir sonraki kararı sayıya bağlar.

1. Hipotez: Sınanacak tek cümleyi yazın.
2. Ölçüt: Başarı sayılarını ve karar eşiklerini kurmadan önce belirleyin.
3. Kapsam: Özellikleri puanlayın, ilk beşi seçin, gerisini listede bekletin.
4. Kur ve yayınla: Çekirdek akışı gerçek kalitede yapın ve sınırlı bir kullanıcı grubuna açın.
5. Ölç: Önceden yazdığınız sayıları toplayın; yorumdan önce veri.
6. Karar: Sürdür, değiştir ya da dur. Öğrendiklerinizle listeyi yeniden puanlayın.

Yayın planlama ve takvim kurma ayrıntıları için proje planı rehberimize bakabilirsiniz; MVP'nin kısa takvimi de aynı yöntemle (iş kırılımı, bağımlılık, kritik yol) kurulur.

MVP ile Tam Kapsamlı Geliştirmenin Maliyeti Nasıl Karşılaştırılır?

MVP, toplam proje maliyetini otomatik düşürmez; harcamayı öğrenmeyle sıraya koyar. Bayi portalı örneğinde günlük ekip ücreti ₺9.000 ve yüzde 20 belirsizlik payı (×1,2) alalım.

İlk sürümde ₺799.200 − ₺302.400 = ₺496.800 daha az harcanır; bu oran ₺496.800 ÷ ₺799.200 ≈ %62,2'dir. Süre (12 − 5) ÷ 12 ≈ %58,3 kısalır. Kalan 7 özellik silinmez, 46 kişi-gün (74 − 28) olarak listede bekler ve öğrenmeye göre yapılır. Gerçek tutar yine ₺496.800'dür; ancak bu para ürünün işe yaradığı kanıtlandıktan sonra harcanır.

Asıl kazanç yanlış varsayım riskinde görünür. Hipotezin yanlış çıkma olasılığını %40 kabul ederseniz beklenen kayıp tam kapsamda 0,40 × ₺799.200 = ₺319.680, MVP'de 0,40 × ₺302.400 = ₺120.960'tır; fark ₺198.720'dir. Olasılık sizin için farklıysa hesabı yenileyin. Maliyet kalemlerinin ayrıntısını yazılım projesi maliyeti rehberimizde, mobil uygulamaya özel hesabı mobil uygulama maliyeti rehberimizde bulabilirsiniz.

MVP Düşük Kalite Demek midir?

Hayır. MVP'de özellik azdır, ama olan her özellik çalışır, güvenlidir ve doğru sonuç verir. Kullanıcıya yarım hesaplayan bir sipariş ekranı vermek MVP değil, hatalı üründür ve hipotezi sınamaz; kullanıcı fikri değil hatayı reddeder.

Teknik olarak da MVP'yi tek kullanımlık yazmak yanlıştır: büyüyecek bir çekirdeğin üstüne inşa edilmelidir. Kodun üzerine ileride bina yapılacaksa temel baştan sağlam atılır; ertelenen şey ek katlardır.

MVP'den Sonra Yol Haritası Nasıl Kurulur?

MVP sonuçları geldikten sonra bekleyen özellikler öğrendiklerinize göre yeniden puanlanır ve fazlara bölünür. Örnekte 46 kişi-günlük kalan işi iki faza ayıralım.

• Faz 2 (21 kişi-gün): Stok görünürlüğü (6), cari bakiye (5), online ödeme (10); MVP'de bayilerin en çok sorduğu şeylere göre öncelik değişebilir.
• Faz 3 (25 kişi-gün): Mobil bildirimler (5), kampanya (8), raporlar (8), çok dilli arayüz (4).

Kontrol: 21 + 25 = 46 kişi-gün, yani ₺496.800 (46 × 1,2 × ₺9.000). Her fazın sonunda yeni bir ölçüm ve karar noktası olur. Mobil uygulama gibi daha pahalı bir kanal gerekiyorsa MVP'yi önce web üzerinde sınamak çoğu kez doğru sıradır. Büyük resimde bu akış, yazılım geliştirme süreci rehberimizdeki çevik döngülerle uyumludur.

MVP'de Sık Yapılan Hatalar Nelerdir?

• Hipotezsiz özellik listesi: "Şunlar da olsun" dendikçe MVP tam ürüne döner.
• Ölçütleri sonradan koymak: Sonuç görüldükten sonra konan hedef karardan çok bahane üretir.
• Kaliteyi kısmak: Hatalı ilk sürüm hipotezi değil, güveni sınar.
• Yanlış kullanıcıyla sınamak: Hedef kitleden olmayan pilot grup yanıltıcı sonuç verir.
• Öğrenmeyi karara çevirmemek: Sayılar toplanır ama kimse sürdür, değiştir ya da dur demez.
• MVP'yi bitmiş ürün sanmak: MVP bir başlangıçtır; yol haritasız bırakılırsa yarım kalır.
• Mimariyi hiç düşünmemek: Atılacak kodla büyüyecek kod arasında bilinçli bir seçim yapılmalı.

Okumanızı öneririz: Özel yazılım nasıl yaptırılır? Brief, teklif ve sözleşme rehberi

Okumanızı öneririz: B2B e-ticaret nedir? Bayi portalı ve kapsam rehberi

İnovabil ile MVP ve Kademeli Özel Yazılım

İnovabil olarak ağırlığımız sıfırdan, firmaya özel yazılım geliştirmektir: özel yazılım, ERP, CRM, e-ticaret, web, mobil ve entegrasyon. Büyük bir kapsamı tek seferde teslim etmek yerine, önce çekirdek akışı çıkarıp sonra büyütmeyi gereksinim analizi sırasında öneri olarak masaya koyuyoruz; süreç sayfamızda anlattığımız analiz, tasarım, geliştirme, test, yayın, bakım ve destek adımları buna uygundur.

Avcılar İnşaat için CRM, satın alma ve mobil; İZBAN için satın alma sistemi; Karyak için lojistik ve sevkiyat planlama ile toptan sipariş yönetimi; Sleepy için depo yönetimi ile şikâyet ve destek yönetim sistemi geliştirdik. Fikrinizi ve hedef kullanıcınızı kısaca anlatın; hipotezi birlikte yazalım, adayları puanlayalım ve hangi kapsamın ilk sürüme yeteceğini yazılı bir değerlendirmeyle çıkaralım.

Okumanızı öneririz: Yazılım geliştirme sürecimiz: analizden yayına adım adım

Sık Sorulan Sorular