MVP nedir? Yazılımda en küçük işe yarar sürümü kapsamak

Yazılım projelerinin çoğu kod yüzünden değil, kapsam yüzünden zorlanır. MVP bu sorunun en bilinen cevabıdır, ama aynı zamanda en sık yanlış anlaşılan cevabıdır.

PNZ Medya'da müşteri projelerini, Entrobase'de kendi ürünümüzü yönetiyorum. MVP nedir sorusunu bu yüzden sözlükten değil, iki taraftan gördüğüm hatalardan cevaplamak istiyorum. Yazılımda üç hata öne çıkıyor: MVP'yi küçük bir ürün sanmak, prototiple karıştırmak ve ölçmeden yayınlamak.

MVP nedir, yazılımda ne anlama gelir?

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 sürüm" diye geçer. Kısaltma tıpta ve sporda başka anlamlar da taşır; yazılımda ve girişimcilikte anlamı budur.

Kavramı geniş kitleye Eric Ries, The Lean Startup kitabıyla taşıdı. Ries'in tanımında ağırlık üründe değil, öğrenmededir.

Minimum uygulanabilir ürün, bir ekibin müşterileri hakkında en az çabayla en çok doğrulanmış bilgiyi toplamasını sağlayan sürümdür.

Benim işte kullandığım tanım daha sade: hedef kullanıcının asıl sorununu çözen ve kullanıldığını ölçebildiğiniz en küçük sürüm. İki koşul da önemlidir. Sorunu çözmüyorsa kimse kullanmaz; ölçemiyorsanız kullanılıp kullanılmadığını bilemezsiniz.

Bu tanımda "küçük" kelimesi özellik sayısını değil, odağı anlatır. MVP, büyük ürünün her parçasından biraz içeren bir kopya değildir; tek bir sorunu baştan sona çözen dar bir yoldur.

MVP, prototip ve tam ürün arasındaki fark

Bu üç kavram toplantılarda sık karışır. Karıştığında da yanlış şey yayına çıkar ya da doğru şey hiç çıkmaz. Aradaki farkı amacına ve kimin elinde olduğuna göre ayırmak işe yarıyor.

PNZ Medya'da çalışan bir prototip göstermeden yazılıma başlamıyoruz. Bu ilke, kapsamı erken netleştirmenin en etkili yolu oldu. İnsanlar karar vermeden önce çalışan bir şey görmek istiyor; ekranda gördüklerinde neyin gerekmediğini de kendileri söylüyor.

Yine de prototip MVP'nin yerini tutmaz. Prototip karar vermenize yardım eder, MVP ise o kararın doğru olup olmadığını gerçek kullanımla gösterir.

MVP için ne kadar özellik yeterli?

Hedef kullanıcının asıl sorununu çözen ve kullanıldığını ölçebildiğiniz en küçük sürüm yeterlidir. Kapsam görüşmesinde her özelliği bu ölçüte göre eliyoruz. Bunun için tek bir soru yeterli: bu özellik olmadan kullanıcı asıl sorununu çözebilir mi?

Cevap evetse özellik sonraki sürüme kalır. Bu soruyu dürüstçe sorduğunuzda çoğu zaman şu işler sonraya düşer:

• Yönetim panelinin ayrıntılı raporları ve dışa aktarma seçenekleri.
• Birden fazla dil ve para birimi desteği.
• Asıl akış dışında kalan rol ve yetki çeşitleri.
• Her kullanıcı tipine özel ayarlar ve bildirim tercihleri.
• Henüz kimsenin istemediği entegrasyonlar.

Önceliklendirme için hazır yöntemler var; MoSCoW bunların en bilinenidir. Yöntem işe yarar, ama listeyi tek bir soruya bağlamadığınızda her özellik "mutlaka olmalı" sütununa kayar. Liste uzadıkça MVP, adı MVP olan büyük bir projeye dönüşür.

MVP kapsam belgesi: ne var, ne yok, neden

Kapsam her toplantıda büyüyorsa ve teslim tarihi sürekli kayıyorsa, sorun çoğu zaman yazılı bir kapsamın olmamasıdır. Konuşulan her şey kapsama girmiş sayılır; bunu önlemenin yolu kısa ama açık bir belgedir.

1. Hedef kullanıcı ve çözülen sorun: tek cümle.
2. İlk sürümde olanlar: her biri bir kullanıcı hikayesi ve kabul ölçütüyle.
3. Bilerek dışarıda bırakılanlar: her birinin yanında kısa bir gerekçe.
4. Ölçülecek göstergeler: en fazla üç tane.
5. Sonraki sürüm kararının ne zaman ve hangi veriye bakılarak verileceği.

Bu belgede en çok işe yarayan bölüm "ne yok" listesidir. Dışarıda bırakılan bir özellik yeniden gündeme geldiğinde tartışma baştan açılmaz; belgeye ve gerekçeye bakılır. Yazmadığınız kararı her hafta yeniden tartışırsınız.

MVP kapsamını daraltmak için hazır prompt

Elinizde uzun bir özellik listesi varsa, aşağıdaki promptu bir yapay zeka asistanında kullanabilirsiniz. Çıktıyı karar olarak değil, kapsam görüşmesine götüreceğiniz ilk taslak olarak kullanın.

Bir yazılım fikrinin MVP kapsamını daraltmak istiyorum. Aşağıda hedef kullanıcıyı, çözmek istediğim sorunu ve aklımdaki özellik listesini veriyorum.

Görevin:
1. Hedef kullanıcının asıl sorununu tek cümleyle yeniden yaz. Emin olmadığın yerde bana soru sor.
2. Her özelliği şu soruya göre değerlendir: Bu özellik olmadan kullanıcı asıl sorununu çözebilir mi? Cevabı evetse özelliği "sonraki sürüm" listesine koy.
3. Kalan özelliklerle kullanıcının baştan sona izleyeceği tek bir akışı adım adım yaz.
4. Bu akışın gerçekten kullanıldığını gösterecek en fazla üç ölçülebilir gösterge öner.
5. Sonucu üç başlıkta ver: ilk sürümde olanlar, bilerek dışarıda bırakılanlar (gerekçesiyle), ölçülecekler.

Listede olmayan özellik ekleme. Kısa ve madde madde yaz.

Hedef kullanıcı: [buraya yazın]
Çözülecek sorun: [buraya yazın]
Özellik listesi: [buraya yapıştırın]

Yayından önce neyi ölçeceğinizi yazın

Ürün ekiplerinde en sık gördüğüm tablo şudur: MVP yayına çıkar, ama hangi özelliğin işe yaradığı ölçülmez ve sonraki karar yine sezgiyle verilir. Bu durumda MVP'nin asıl amacı olan öğrenme hiç gerçekleşmemiş olur.

Göstergeleri yayından önce yazın ve az tutun. Çoğu MVP için şu üç soru yeterli bir başlangıçtır:

• Kullanıcılar asıl akışı baştan sona tamamlıyor mu?
• Bir kez deneyenler geri geliyor mu?
• Kullanıcıdan gelen geri bildirim düzenli bir yere toplanıyor mu?

Yazılımı bir ajansa yaptırıyorsanız MVP'yi nasıl korursunuz?

Bu yazıyı iki tarafı da gören biri olarak yazıyorum. Ajansın saati müşterinin takvimine göre işler: teslim tarihi bellidir, kapsam sözleşmeyle çizilir. Ürünün saati ise belirsizdir; neyin işe yarayacağını kullanıcı gelene kadar bilemezsiniz.

Bu iki saati buluşturan şey yine kapsam belgesidir. Teklif istemeden önce belgeyi hazırlarsanız gelen teklifler aynı işi fiyatlar ve karşılaştırılabilir olur. Geliştirme sürecinde de haftalık bir demo isteyin: biten iş çalışırken gösterilsin, belgeyle karşılaştırılsın.

Sizin tarafınızda kapsamı, öncelikleri ve teslimi takip eden biri olmalı. Şirket içinde bu rolü üstlenecek kimse yoksa, bu işi dışarıdan bir ürün sahibi ya da teknik yönetici de yapabilir.

MVP'den sonra: sonraki sürümü kullanıcı verisi belirler

MVP'si çıkmış ama sonraki adımda tıkanan ekiplerin çoğunda yol haritası, MVP'den önce yazılmış listenin devamıdır. Oysa o liste kullanıcı gelmeden önce yazılmıştı.

Sonraki sürümün önceliğini ilk kullanıcı verisine bakarak belirleyin. Ölçtüğünüz göstergeler, topladığınız geri bildirim ve dışarıda bıraktığınız özelliklerin gerekçeleri burada birlikte okunur. Bazen eski listedeki bir özellik öne çıkar, bazen hiç düşünmediğiniz bir ihtiyaç.

MVP'yi küçük bir ürün olarak değil, bir soruya verilmiş dar bir cevap olarak düşünün. Soruyu tek cümleyle yazın, cevabı en küçük sürümle verin ve sonucu ölçün. Fikrinizi böyle bir plana çevirmek istiyorsanız bu konuda birlikte çalışabiliriz.