MVP Nedir? Dijital Ürünü En Küçük Çalışan Sürümle Doğrulamak

MVP (minimum viable product, minimum uygulanabilir ürün), bir fikrin gerçek kullanıcılarla sınanabilmesi için gereken en küçük çalışan ürün sürümüdür. Amaç eksik bir ürün çıkarmak değil, en riskli varsayımı en az kaynakla doğrulamaktır. MVP nedir diye aradığınızda sporda "en değerli oyuncu" (most valuable player), tıpta ise mitral kapak sarkması anlamları da çıkar; bu yazı ürün geliştirmedeki anlamı anlatıyor.

MVP ne demek?

Kısaltmadaki üç kelimenin her biri ayrı bir şey söyler. "Minimum", yalnız doğrulanmak istenen varsayım için gereken işlevleri kapsar. "Viable" yani uygulanabilir, sürümün gerçekten kullanılabilir ve kullanıcıya değer üreten bir şey olması gerektiğini anlatır. "Product" ise bunun bir sunum ya da çizim değil, çalışan bir ürün olduğunu vurgular.

MVP yaklaşımı girişim dünyasında yaygınlaştı, ama mantığı her dijital ürün için geçerlidir. Bir müşteri portalı, mobil uygulama ya da şirket içi bir iş uygulaması da önce en küçük çalışan haliyle kullanıma alınabilir. Ürün geliştirme süreci böylece "hepsini yap, sonra gör" yerine "küçük yap, ölç, öğren, büyüt" döngüsüne dönüşür.

MVP şunlar değildir:

• Yarım ürün: Temel akışı tamamlanmamış, kullanıcıyı yolun ortasında bırakan sürüm MVP sayılmaz.
• Kalitesiz ürün: Kapsam küçüktür, ama sunulan işlev güvenilir çalışmalıdır.
• Demo: Yalnız gösterim için hazırlanan, gerçek veriyle kullanılamayan sürüm bir prototiptir.

MVP, PoC ve prototip farkı

Üç kavram da riski erken azaltmak için kullanılır, ama farklı soruları cevaplar.

Kavram	Cevapladığı soru	Kim kullanır	Çıktı	Ne zaman
PoC (proof of concept, kavram kanıtı)	Bu teknik olarak yapılabilir mi?	Geliştirme ekibi	Küçük teknik deneme	Teknik belirsizlik varsa, en başta
Prototip	Kullanıcı akışı anlaşılıyor mu?	Tasarım ekibi ve test kullanıcıları	Tıklanabilir tasarım, çoğu zaman arka planı yok	Tasarım aşamasında
MVP	Gerçek kullanıcı bunu kullanıyor ve değer görüyor mu?	Gerçek kullanıcılar	Yayında çalışan ilk sürüm	Kullanıma çıkarken

Bir projenin bu üç adımın hepsinden geçmesi gerekmez. Örneğin yeni bir ödeme kuruluşuyla entegrasyonun mümkün olup olmadığından emin değilseniz önce bir proof of concept yapılır. Teknik risk yoksa doğrudan prototiple başlayıp MVP'ye geçilebilir.

MVP türleri

MVP her zaman küçültülmüş bir yazılım olmak zorunda değildir. Sınanacak varsayıma göre farklı biçimler alabilir:

• Tek akışlı ürün: Ana kullanım senaryosunu baştan sona çözen, geri kalan her şeyi dışarıda bırakan sürüm. Kurumsal projelerde en sık görülen biçimdir.
• Elle yürütülen MVP: Ürünün vaat ettiği iş bir süre ekip tarafından elle yapılır. Kullanıcı bunu bazen bilir (concierge MVP), bazen ön yüzde otomatik çalışan bir ürün görür (Wizard of Oz MVP). Talebin gerçekten var olup olmadığını otomasyona yatırım yapmadan gösterir.
• Talep testi: Ürün henüz yokken bir tanıtım sayfasıyla ilgi ölçülür. Ziyaretçinin kayıt olup olmadığı ya da bilgi isteyip istemediği, fikre olan talebin ilk işaretidir. Bu tür sayfaların nasıl kurgulandığını landing page nedir yazımızda anlattık.

Hangi biçimin seçileceği, en riskli varsayımın ne olduğuna bağlıdır. Risk "insanlar bunu ister mi" ise talep testi yeterli olabilir. Risk "süreç yazılımla gerçekten kısalır mı" ise çalışan bir akış gerekir.

MVP kapsamı nasıl belirlenir?

Kapsamı daraltmak MVP'nin en zor kısmıdır, çünkü her paydaşın "bu olmadan olmaz" dediği bir özellik vardır. Aşağıdaki sıra bu tartışmayı somutlaştırır:

1. En riskli varsayımı yazın. "Bayilerimiz telefonla sipariş vermek yerine portalı kullanır" gibi.
2. Tek bir ana akış seçin. Varsayımı sınamak için kullanıcının baştan sona tamamlaması gereken yolu belirleyin.
3. Özellikleri bu akışa göre ayırın. Akış için gerekmeyen her şey sonraki sürüme gider.
4. Başarı ölçütünü baştan yazın. Hangi sonucu görürseniz varsayımı doğrulanmış sayacağınızı geliştirmeye başlamadan kararlaştırın.

Bayi sipariş portalı örneğinde önceliklendirme şöyle görünebilir:

Özellik	Varsayımı sınamak için gerekli mi?	MVP kararı
Bayinin ürün ve fiyat listesini görmesi	Evet	İlk sürümde
Sipariş oluşturma ve onay e-postası	Evet	İlk sürümde
Siparişin ERP'ye otomatik aktarımı	Hayır, başlangıçta elle aktarım yeterli	İkinci sürümde
Kampanya ve kademeli iskonto kuralları	Hayır	Sonraki sürümlerde
Mobil uygulama	Hayır, mobil uyumlu web yeterli	Kullanım verisine göre
Gelişmiş raporlama	Hayır, sipariş listesi yeterli	İkinci sürümde

Seçilen kapsamı yazıya dökerken "bu sürümde yok" listesini de ekleyin. Teknik şartname hazırlama rehberimizdeki önceliklendirme tablosu bu iş için doğrudan kullanılabilir.

MVP'nin maliyet ve riske etkisi

MVP, bütün bütçeyi doğrulanmamış bir fikre bağlamayı önler. İlk sürümden gelen kullanım verisi, sonraki yatırımın nereye yapılacağını gösterir ve kimsenin kullanmayacağı özelliklere harcanacak emek baştan kurtarılır.

Bununla birlikte MVP her zaman ucuz değildir. Temel akışın güvenilir çalışması, güvenlik ve kişisel verilerin korunması küçültülemeyecek kalemlerdir. Erken çıkmak için alınan kestirme teknik kararlar da sonraki sürümlerde yeniden yazma maliyeti doğurabilir. Bu yüzden hangi parçanın kalıcı, hangisinin geçici olduğu baştan konuşulmalıdır.

Bazı durumlarda MVP için yazılım geliştirmek bile gerekmez; hazır bir araç ya da elle yürütülen bir süreç varsayımı sınamaya yeter. Bu kararı verirken hazır yazılım ile özel yazılım arasındaki farklara bakabilirsiniz.

MVP sonrası ölçüm ve ikinci sürüm

MVP'nin değeri, yayından sonra öğrenilenlerden gelir. Ölçülmeyen bir MVP yalnız küçük bir üründür. İlk sürümde takip edilebilecek başlıca göstergeler şunlardır:

• Ana akışı baştan sona tamamlayan kullanıcı sayısı
• Kullanıcıların ürüne geri dönüp dönmediği
• Akışın en çok hangi adımda yarım bırakıldığı
• Destek taleplerinde tekrar eden konular
• Kullanıcı görüşmelerinde duyulan istekler ve itirazlar

Bu göstergeleri izleyebilmek için ölçüm altyapısının ilk sürümle birlikte kurulması gerekir. Yayından sonra eklenen ölçüm, en değerli ilk haftaların verisini kaçırır.

Bu verilerle üç karardan biri verilir: aynı yönde büyütmek, yön değiştirmek ya da durdurmak. İkinci sürümün kapsamı, ilk listede "sonraki sürüm" diye bekleyen maddelerden değil, kullanıcı davranışından çıkarılmalıdır.

Kurumsal projelerde MVP

MVP yalnız girişimlere özgü değildir. Kurumsal bir yazılım projesinde MVP, tek bir departmanda ya da tek bir süreçte başlatılan pilot kullanım olabilir. Örneğin yeni bir teklif yönetim sistemi önce tek bir satış ekibinde, mevcut Excel dosyalarıyla paralel yürütülerek denenebilir.

Mobil uygulamalarda da aynı mantık işler: mağazaya ilk çıkan sürüm, ana kullanım senaryosunu çözen dar bir sürüm olabilir. Tasarım, test ve mağaza yayını adımlarını mobil uygulama geliştirme sürecini anlattığımız yazıda bulabilirsiniz.

Sık yapılan hatalar

• Her paydaşın isteğini ekleyip kapsamı yeniden büyütmek
• "Minimum" kelimesini düşük kalite olarak yorumlamak
• Başarı ölçütü belirlemeden yayına çıkmak
• Gerçek hedef kullanıcı yerine yalnız şirket içinden kişilerle test etmek
• Ölçüm sonuçları gelmeden ikinci sürümün kapsamını kesinleştirmek

Granobra'da nasıl çalışıyoruz

İstanbul merkezli ekibimizle özel yazılım ve dijital ürün projelerinde ilk sürümün kapsamını sizinle birlikte belirliyor, sonraki sürümlere kalan maddeleri yazılı hale getiriyoruz. İlk sürümün kaynak kod ve lisans koşulları da teklifte açıklanır, sözleşmede belirlenir. Bu projelerin kapsamını web yazılım ve özel yazılım geliştirme sayfamızda inceleyebilirsiniz.

Sık sorulan sorular

MVP ne demek, Türkçesi nedir?

MVP, İngilizce minimum viable product ifadesinin kısaltmasıdır. Türkçede minimum uygulanabilir ürün ya da en küçük uygulanabilir ürün olarak kullanılır. Bir fikri gerçek kullanıcılarla sınamaya yetecek en küçük çalışan sürümü anlatır.

MVP ile prototip arasındaki fark nedir?

Prototip, akışın ve tasarımın anlaşılıp anlaşılmadığını sınamak için hazırlanır ve çoğu zaman gerçek veriyle çalışmaz. MVP ise yayında olan, gerçek kullanıcıların gerçek işini gördüğü ilk sürümdür.

Her yazılım projesi MVP ile mi başlamalı?

Belirsizliğin yüksek olduğu projelerde MVP riski azaltır. Kapsamı yasal bir zorunluluk ya da mevcut bir sistemin birebir yenilenmesi gibi baştan belli olan projelerde ise aşamalı teslim daha uygun olabilir. İki durumda da kapsamı parçalara bölmek işe yarar.

MVP ne kadar sürede hazırlanır?

Süre; seçilen akışın genişliğine, entegrasyonlara ve karar alma hızına bağlıdır. Önce takvim belirleyip kapsamı ona sığdırmaya çalışmak yerine, kapsamı küçültüp takvimi kapsamdan türetmek daha sağlıklıdır. MVP'nin amacı öğrenmeye erken başlamak olduğu için geliştirme uzadıkça yaklaşımın faydası da azalır.

MVP yayına çıktıktan sonra ne olur?

Kullanım verisi ve kullanıcı görüşleri toplanır. Bu bulgulara göre ürün büyütülür, yönü değiştirilir ya da durdurulur. İkinci sürümün kapsamı bu öğrenmelerle belirlenir.

Fikrinizi en küçük çalışan sürümle sınamak istiyorsanız kapsamı Granobra ile birlikte daraltalım. Projenizi konuşalım: teklif alın.