MVP Nedir? İlk Sürümde Neyi Dışarıda Bırakacağınıza Nasıl Karar Verirsiniz?

MVP, yazılım dünyasının en çok kullanılan ve en çok yanlış anlaşılan terimlerinden biri. Ucuz ürün demek değil, yarım ürün de değil. Bir soruyu cevaplamak için kurulmuş en küçük düzenek demek. Bu yazı, o sorunun nasıl seçileceğini ve ilk sürümde neyin dışarıda bırakılacağına nasıl karar verileceğini anlatıyor.

MVP nedir, açılımı ne? MVP, İngilizce minimum viable product ifadesinin kısaltmasıdır; Türkçede minimum uygulanabilir ürün (asgari uygulanabilir ürün) olarak geçer. Bir ürün fikrinin en kritik varsayımını gerçek kullanıcılarla test etmeye yetecek en küçük ama çalışan sürümdür. Amaç eksik bir ürün çıkarmak değil, en az geliştirme maliyetiyle “insanlar bunu gerçekten kullanacak mı?” sorusuna veriyle cevap almaktır.

MVP nedir, ne değildir?

MVP (minimum viable product / asgari uygulanabilir ürün), ürününüzün bir varsayımı test etmeye yetecek en küçük halidir. Buradaki kritik kelime “uygulanabilir”dir: yaptığı işi gerçekten yapar, sadece az iş yapar.

• MVP değildir: Yarım kalmış, hatalı çalışan, güvenliği zayıf bir ürün. Kullanıcı “eksik” hisseder ve bir daha dönmez; üstelik bu bir sonuç da vermez, çünkü ürünün mü fikrin mi tutmadığını ayırt edemezsiniz.
• MVP’dir: Tek bir işi baştan sona, düzgün yapan bir ürün. Kullanıcı “bunda şu da olsaydı” der — istenen tepki budur.

Önce şunu yazın: hangi varsayımı test ediyorsunuz?

MVP bir deneydir ve her deneyin bir hipotezi olur. Kapsamı daraltmadan önce şu cümleyi tamamlayın: “İnsanların … yapacağına inanıyorum; bunu … sayısına bakarak anlayacağım.”

Örnekler:

• “Esnafın stok takibini telefondan yapacağına inanıyorum; kayıt olan 20 işletmeden en az 8’inin iki hafta boyunca haftada üç kez giriş yapmasına bakarak anlayacağım.”
• “Müşterilerin randevuyu telefon yerine uygulamadan alacağına inanıyorum; bir ay sonunda randevuların en az dörtte birinin uygulamadan gelmesine bakarak anlayacağım.”

Bu cümleyi yazamıyorsanız, MVP’yi neye göre değerlendireceğinizi de bilmiyorsunuz demektir. “İnsanlar beğendi” bir sonuç değildir; kullandılar mı, tekrar geldiler mi, para ödediler mi — ölçüt bunlardan biri olmalı.

Kapsamı daraltma yöntemi

Üç soruyla listeyi kısaltabilirsiniz:

• Tek kullanıcı tipi: Birden fazla taraf varsa (alıcı–satıcı, müşteri–işletme) ilk sürümde hangisinin sorununu çözeceğinize karar verin. Diğer tarafın işini geçici olarak siz elle yapabilirsiniz.
• Tek akış: Uygulamanın omurgası olan tek bir işlem. “Sipariş verme” varsa, ilk sürümde kampanya, favoriler ve öneri motoru yoktur.
• Tek sonuç: Kullanıcı bu ürünü kullandığında elinde ne kalıyor? O sonucu üretmeyen her şey ilk sürüm dışıdır.

Özellik listesine bakıp “bunu çıkarırsak ürün işe yaramaz mı?” diye sorun. Cevap “yine de işe yarar” ise, çıkarın.

MVP’de kesinlikle kısılmayacak üç şey

Kapsam kısılır, kalite kısılmaz. Şu üçü ilk sürümde de tam olmalıdır:

• Ana akışın düzgün çalışması: Az iş yapın, ama yaptığınız iş hatasız olsun.
• Veri güvenliği: Kullanıcı verisi topluyorsanız, “şimdilik basit tutalım” denecek yer burası değildir.
• Yönetim ekranı: İşletme tarafında olan biteni görebileceğiniz, müdahale edebileceğiniz bir arayüz. Bu unutulduğunda ürün yayına girer ama yönetilemez.

Kod yazmadan test etmenin yolları

Bazı varsayımlar yazılım yapmadan da test edilebilir ve bu en ucuz yoldur:

• Tek sayfalık tanıtım: Ürünü anlatan bir sayfa ve kayıt formu. Kaç kişi bilgi bırakıyor? Bu, talebin ilk sinyalidir.
• Perde arkasında elle yürütmek: Kullanıcıya otomatik görünen işi arka planda siz yapın. Randevu eşleştirmeyi, öneri hazırlamayı, siparişi ileri iletmeyi başta elle yapabilirsiniz. Hangi kuralların gerektiğini de böyle öğrenirsiniz.
• Hazır araçlarla kurmak: Form, tablo ve mesajlaşma araçlarıyla akışı kurup birkaç gerçek kullanıcıyla deneyin.
• Tıklanabilir tasarım: Çalışmayan ama gezilebilen bir arayüzle kullanıcıya “şunu yapın” deyip nerede takıldığını izleyin.

Bu yöntemlerden çıkan bilgi, geliştirmeye başladığınızda doğrudan kapsamı belirler.

Sonucu nasıl okursunuz?

MVP üç sonuçtan birini verir ve üçü de değerlidir:

• Tuttu: Kullanım hedeflediğiniz ölçütü karşıladı. Sıradaki özellikleri artık tahminle değil, kullanıcıların takıldığı yerlere bakarak seçersiniz.
• Kısmen tuttu: Beklediğiniz kitle değil, başka bir kitle kullandı ya da beklemediğiniz bir özellik öne çıktı. Bu genellikle en öğretici sonuçtur; yönü değiştirmek için gerekçeniz olur.
• Tutmadı: Acı ama ucuz. Aynı fikri tam kapsamla yaptırmış olsaydınız aynı sonucu çok daha pahalıya öğrenecektiniz.

Üçüncü sonucu baştan kabul edebiliyor olmak, MVP yaklaşımının asıl faydasıdır.

Sık yapılan hatalar

• Ölçüt belirlemeden yayına almak: Sonuç yorumu tartışmaya kalır.
• Kullanıcı bulmadan geliştirmek: MVP’yi kimin deneyeceğini geliştirme bitmeden planlamalısınız. Ürün hazır, kullanıcı yok — sık görülen durum budur.
• “Bir de şu olsun” döngüsü: Kapsam yayın öncesinde büyümeye başladıysa, MVP olmaktan çıkmıştır.
• Çok erken vazgeçmek: İlk hafta az kullanım, çoğu zaman ürünün değil duyurunun sorunudur.
• Geçici çözümleri kalıcı yapmak: Elle yürüttüğünüz adımlar işe yaradıysa, ölçek büyümeden otomatikleştirilmeli.

Sık sorulan sorular

MVP ne kadar sürede çıkar?

Kapsamın darlığına ve içeriğin hazır olmasına bağlıdır; peşin bir süre vermek doğru olmaz. Süreyi kısaltan asıl şey özellik listesini kısaltmaktır. Kapsam netleştiğinde takvimi yazılı olarak veririz.

MVP’yi sonra genişletebilir miyim, yoksa baştan mı yazılır?

Bu bir teknik tercih meselesidir ve baştan konuşulmalıdır. “Hızlı çıkalım, sonra atarız” yaklaşımıyla kurulan bir MVP, tuttuğunda yeniden yazılmak zorunda kalabilir. Büyümeye açık kurulacaksa ilk maliyet biraz artar — hangisini tercih edeceğinizi proje başında birlikte kararlaştırırız.

Yatırımcıya MVP yeterli mi?

Yatırımcı genelde fikir değil kanıt arar: kullanan insanlar, tekrar kullanım, ödeme. MVP bu kanıtı üretmenin yoludur, ama kanıtı üreten MVP’nin kendisi değil, topladığı kullanım verisidir.

Rakibim tam özellikli, ben eksik ürünle nasıl yarışırım?

Yarışmazsınız — dar bir grubun bir sorununu onlardan iyi çözersiniz. MVP’nin hedefi pazarın tamamı değil, ilk kullanıcı grubudur.

MVP ucuz demek mi?

Daha ucuz demek, ucuz demek değil. Kapsam küçülür ama işin kalitesi küçülmez; sunucu, güvenlik ve test hâlâ gerekir.

Fikrinizin ilk sürümünü birlikte çıkaralım

Fikrinizi, kimin kullanacağını ve “tuttu” diyebilmek için görmeniz gereken sonucu paylaşın; ilk sürümde neyin kalacağına ve neyin bekleyeceğine birlikte karar verelim. Mobil uygulama geliştirme ve özel yazılım geliştirme hizmetlerimizi inceleyebilir, bize ulaşabilirsiniz. Bütçe tarafı için mobil uygulama maliyeti yazımıza bakabilirsiniz.