MVP nedir? Küçük bütçeyle yazılım ürünü başlatmak

MVP nedir?

MVP, İngilizce “minimum viable product” ifadesinin kısaltmasıdır; Türkçede minimum uygulanabilir ürün ya da en küçük işe yarar ürün denir. Bir yazılım fikrinin, gerçek kullanıcıların eline verilebilecek kadar çalışan ama yalnızca en temel işi yapan ilk sürümüdür. Kavram 2001’de Frank Robinson tarafından ortaya atıldı; Steve Blank ve özellikle Eric Ries’in “Yalın Girişim” (The Lean Startup) yaklaşımıyla yaygınlaştı.

Ries’in tanımı kavramın özünü iyi anlatır: MVP, bir ekibin müşteriler hakkında en az emekle en fazla doğrulanmış bilgiyi toplamasını sağlayan ürün sürümüdür. Buradaki kilit kelime “öğrenmek”tir. MVP’nin işi satış rekoru kırmak ya da rakiplerle özellik yarışına girmek değil, “bu fikir tutar mı?” sorusuna tahminle değil kullanıcı davranışıyla cevap vermektir.

Bu yüzden MVP yalnızca girişimlerin konusu değildir. İç süreçleri için yazılım yaptırmak isteyen bir işletme de aynı mantıkla ilerleyebilir: bütün departmanları kapsayan büyük bir sistem yerine, en çok sıkıntı yaratan tek süreci çözen küçük bir ilk sürümle başlamak.

MVP ne işe yarar?

• Riski küçültür: Aylarca geliştirilen bir ürünün kimsenin işine yaramadığını en sonda öğrenmek yerine, bunu birkaç haftada ve sınırlı bütçeyle görürsünüz.
• Varsayımları sınar: “Müşteriler bunu ister” cümlesini bir tahmin olmaktan çıkarıp ölçülebilir bir soruya dönüştürür.
• Önceliği netleştirir: Gerçek kullanım verisi, hangi özelliğin önce geliştirilmesi gerektiğini toplantı odasındaki tartışmadan daha iyi gösterir.
• Erken geri bildirim getirir: İlk kullanıcıların şikâyetleri ve istekleri, ikinci sürümün yol haritası olur.
• Yatırım ve iç onay için kanıt üretir: Çalışan bir ürün ve kullanım verisi, sunum dosyasından daha ikna edicidir.

MVP, prototip ve POC arasındaki fark nedir?

Bu üç kavram sık karıştırılır; hepsi “erken sürüm” gibi görünse de farklı sorulara cevap verir:

Kısacası prototip “nasıl görünmeli”, MVP ise “kullanılıyor mu” sorusunun aracıdır. Bir prototip birkaç günde hazırlanıp kullanıcıya gösterilebilir ama sipariş almaz, veri kaydetmez. MVP ise küçük de olsa gerçek bir iş yapar. Sağlıklı bir projede sıra genellikle şöyledir: önce prototiple akış doğrulanır, sonra MVP ile kullanım ölçülür, ardından ürün büyütülür.

MVP türleri nelerdir?

MVP her zaman kodlanmış bir uygulama olmak zorunda değildir. Öğrenmek istediğiniz şeye göre çok daha hafif bir deney de MVP sayılır:

• Tanıtım sayfası (landing page): Ürün henüz yokken onu anlatan bir sayfa yayınlanır; kayıt veya ön talep sayısı ilgiyi ölçer.
• Concierge MVP: Hizmet tamamen elle verilir. Kullanıcı sistemle değil, arkadaki kişiyle çalışır; amaç süreci yazılıma dökmeden önce öğrenmektir.
• Wizard of Oz MVP: Kullanıcı otomatik bir sistem gördüğünü düşünür, arka planda işi bir insan yapar. Otomasyonun kendisine yatırım yapmadan önce talebi sınar.
• Tek özellikli MVP: Ürünün yalnızca en kritik tek işini yapan, gerçekten kodlanmış ilk sürüm.
• Hazır araçlarla MVP: Form, tablo ve otomasyon araçları birleştirilerek kurulan geçici çözüm; talep kanıtlanınca yerini özel yazılıma bırakır.

Bir işletme için en sık karşılaşılan durum, tek özellikli MVP’dir: örneğin bayilerin telefonla verdiği siparişleri toplayan basit bir ekran. Fiyat listeleri, cari hesap, raporlama ve stok bağlantısı daha sonraki sürümlere bırakılır.

MVP nasıl yapılır? Adım adım

1. Sorunu tek cümleyle yazın: Kimin, hangi işinde, neyi kaybettiğini anlatın. “Bayiler sipariş verirken bizi arıyor ve siparişler karışıyor” iyi bir başlangıçtır.
2. Varsayımları listeleyin: Ürünün başarılı olması için doğru olması gereken şeyleri yazın. En riskli olanı MVP’nin sınayacağı varsayımdır.
3. Başarı ölçütünü baştan belirleyin: Kaç kullanıcı, hangi davranış, ne kadar sürede? Ölçüt sonradan konulursa her sonuç “başarı” gibi görünür.
4. Kullanıcı yolunu çizin: Kullanıcının ilk girişten asıl işi tamamlamasına kadar geçtiği adımları sıralayın.
5. Kapsamı daraltın: O yolda olmayan her özelliği sonraki sürüme yazın (aşağıdaki MoSCoW tablosu bu adım içindir).
6. Prototiple doğrulayın: Tıklanabilir bir taslağı birkaç gerçek kullanıcıya gösterin; akış anlaşılmıyorsa kod yazmadan düzeltin.
7. Geliştirin ve yayınlayın: Az ama sağlam özellik. Kalitesiz bir MVP, fikrin değil uygulamanın başarısızlığını ölçer.
8. Ölçün, öğrenin, karar verin: Belirlenen süre sonunda veriye bakın ve büyütmeye, değiştirmeye (pivot) ya da bırakmaya karar verin.

Bu döngüye Yalın Girişim literatüründe “inşa et – ölç – öğren” denir. Önemli olan döngünün kısa olmasıdır; her tur ne kadar hızlı tamamlanırsa aynı bütçeyle o kadar çok şey öğrenilir.

MVP’nin başarısı nasıl ölçülür?

“Kullanıcılar beğendi” bir ölçü değildir; insanlar nazik davranır, beğendiklerini söyleyip ürünü bir daha açmayabilir. MVP’de bakılacak şey söylenen değil yapılandır. Ürünün türüne göre şu göstergelerden ikisi ya da üçü seçilip baştan yazılmalıdır:

• Etkinleşme: Kayıt olan kullanıcıların ne kadarı asıl işi en az bir kez tamamladı (ilk sipariş, ilk randevu, ilk rapor)?
• Geri dönüş: Aynı kullanıcılar bir hafta ya da bir ay sonra ürünü yeniden kullanıyor mu?
• Ödeme isteği: Ücretli bir sürüm veya ön sipariş teklif edildiğinde kaç kişi kabul ediyor?
• Eski yönteme dönüş: Kullanıcılar sistem varken hâlâ telefona, e-postaya ya da tabloya geri dönüyor mu?
• Zaman kazancı: İç süreç yazılımlarında, aynı işin önceki yönteme göre ne kadar sürede yapıldığı.

Bu göstergelerin ölçülebilmesi için kayıt mekanizması MVP’nin içinde kurulmalıdır. Basit bir olay kaydı ya da yönetim panelindeki birkaç sayaç çoğu zaman yeterlidir; ayrı bir analiz sistemi ilk sürüm için şart değildir.

MVP’de hangi özellikler olmalı?

MVP’nin en zor kısmı teknik değil, “hayır” demektir. Her paydaşın vazgeçilmez gördüğü bir özellik vardır ve listeyi kısa tutmak disiplin ister. Yaygın yöntem MoSCoW sınıflandırmasıdır:

Pratik bir ölçü: Bir özelliği çıkardığınızda kullanıcı asıl işini yine de tamamlayabiliyorsa, o özellik MVP’ye girmez. Elle yapılabilen işler (ör. raporu haftada bir Excel’e almak) ilk sürümde elle yapılabilir; otomasyon, ihtiyaç kanıtlandığında eklenir.

MVP ne kadar sürede hazırlanır ve ne kadara mal olur?

Süre ve bütçe tamamen kapsama bağlıdır; bu yüzden “MVP şu kadar tutar” diye tek bir rakam vermek yanıltıcı olur. Belirleyici kalemler kullanıcı rolü sayısı (yalnız müşteri mi, müşteri + yönetici + bayi mi), ekran sayısı, entegrasyonlar (ödeme, e-fatura, SMS), web mi yoksa mobil mağaza uygulaması mı olacağı ve yönetim paneli ihtiyacıdır.

Kendi fiyat listemizden bir çerçeve verelim: tek bir süreci çözen web tabanlı özel yazılım 60.000 TL’den başlıyor ve ilk modül 4–6 haftada teslim ediliyor; çapraz platform bir mobil uygulama MVP’si ise 90.000 TL’den başlıyor (KDV hariç, başlangıç fiyatları). Piyasadaki genel aralıkları ve mobil tarafın ek giderlerini mobil uygulama yaptırma fiyatları yazısında ayrıntılı anlattık.

Bütçeyi düşüren en etkili karar çoğu zaman “önce web” demektir. Kullanıcıların uygulamayı mağazadan indirmesi şart değilse, mobil uyumlu bir web uygulaması hem daha hızlı hazırlanır hem de iki ayrı mağaza sürecini ortadan kaldırır. Mobil uygulama, kullanım kanıtlandıktan sonra aynı arka uç (backend) üzerine eklenebilir.

MVP için hazır yazılım mı, özel geliştirme mi?

Fikri sınamak için her zaman sıfırdan kod yazmak gerekmez. Talep henüz belirsizse hazır araçlarla kurulan bir deney yeterli olabilir. Ancak fikrin değeri işin kendine özgü akışındaysa (ör. bayiye özel fiyat mantığı, sektöre özgü onay adımları) hazır araçlar kısa sürede dar gelir ve MVP yanlış şeyi ölçmeye başlar. İki yolun maliyet, süre ve veri kontrolü açısından karşılaştırmasını hazır yazılım mı, özel yazılım mı yazısında yaptık.

Özel geliştirmede dikkat edilmesi gereken nokta, MVP’nin “atılacak kod” gibi yazılmamasıdır. Kapsam küçük olabilir ama veri yapısı, kullanıcı yetkileri ve güvenlik ilk günden doğru kurulursa ikinci sürüm sıfırdan değil, aynı temelin üzerine eklenerek yapılır. Bu yaklaşımla nasıl çalıştığımızı özel yazılım sayfasında anlattık.

MVP’de en sık yapılan hatalar

• “Minimum”u kalitesizlik sanmak: Hatalı, yavaş ya da kafa karıştıran bir ürün, fikrin değil uygulamanın kötü olduğunu ölçer. Az özellik olabilir, kötü özellik olmamalı.
• Özellik listesini sürekli büyütmek: “Bunu da ekleyelim, yoksa kullanıcı beğenmez” cümlesi MVP’yi tam ürüne çevirir; süre ve bütçe kaçar.
• Başarı ölçütü koymamak: Neyin başarı sayılacağı baştan yazılmazsa veri ne gösterirse göstersin karar çıkmaz.
• Yanlış kullanıcıyla test etmek: Arkadaşların ve ekip üyelerinin nazik geri bildirimi gerçek talep yerine geçmez.
• Geri bildirimi uygulamamak: MVP yayınlanıp öğrenilenlere göre değişiklik yapılmıyorsa döngü yarım kalır.
• Ölçümü sonraya bırakmak: Kullanım verisi toplanmıyorsa “kullanılıyor mu” sorusu yine tahminle cevaplanır.

MVP sonrası ne yapılır?

Belirlenen süre dolduğunda üç yoldan biri seçilir. Kullanım ve geri bildirim beklentiyi karşılıyorsa ürün büyütülür: “Should have” listesindeki özellikler sırayla eklenir, ölçüm sürer. Kullanıcılar ürünü beklenenden farklı bir amaçla kullanıyorsa yön değiştirilir (pivot); bu bir başarısızlık değil, MVP’nin tam olarak yapması gereken işi yapmasıdır. Hiç ilgi yoksa fikir bırakılır ve bütçenin büyük kısmı korunmuş olur.

Büyütme aşamasında sık yapılan hata, MVP’de bilinçli olarak dışarıda bırakılan her şeyi aynı anda eklemeye çalışmaktır. Sağlıklı yol, ikinci sürümü de küçük tutmak ve her eklemeyi bir öncekinin verisine dayandırmaktır. Böylece ürün, toplantıda konuşulan değil gerçekten kullanılan özelliklerle büyür.

MVP’ye başlamadan önce kontrol listesi

• Çözülecek sorun tek cümleyle yazıldı mı?
• İlk kullanıcı grubu belli mi ve onlara ulaşabiliyor musunuz?
• Sınanacak en riskli varsayım belirlendi mi?
• Başarı ölçütü ve değerlendirme tarihi yazıldı mı?
• Özellik listesi “olmazsa olmaz” ve “sonra” diye ikiye ayrıldı mı?
• Kullanım verisi nasıl toplanacak, kim bakacak?
• Kaynak kod, alan adı ve sunucu (hosting) hesapları kimin adına olacak?