MVP nedir, ne değildir?
MVP (minimum viable product; Türkçede minimum uygulanabilir ürün), bir ürün fikrinin en önemli varsayımını gerçek kullanıcılarla sınamaya yetecek en küçük sürümdür. Tanımı basittir; uygulamada en çok yanlış anlaşılan kavramlardan biridir.
B2B tarafında MVP yarım bir ürün değildir. Her ekranın biraz yapıldığı ama hiçbir işin baştan sona tamamlanamadığı bir sürüm kimsenin işine yaramaz: kullanıcı eski yöntemine döner, geri bildirim de gelmez. İyi bir ilk sürüm dar ama derindir. Bir kullanıcı grubu için bir iş akışını uçtan uca, gerçek veriyle ve günlük işte kullanılabilecek kalitede çözer.
MVP bir prototip de değildir. Prototip, bir fikri hızlıca görmek ve test etmek için hazırlanan tıklanabilir ekranlardır; işini yaptıktan sonra bir kenara bırakılabilir. İlk sürüm ise canlıdadır, gerçek veriyle çalışır, yetkilendirme ve güvenlik gibi temel gereklilikleri karşılar. Kapsamı küçük olabilir; kalitesi düşük olamaz.
Dar ama derin: bir kullanıcı grubu, bir akış, uçtan uca.
Önce başarı ölçütünü yazın
Kapsam tartışması genellikle bir özellik listesiyle başlar. Daha verimli olan, listeden önce tek bir soruyu yanıtlamaktır: İlk sürüm canlıya çıktıktan birkaç ay sonra ne değişmiş olmalı?
Yanıt tek cümlelik ve ölçülebilir olmalı. “Bayi deneyimini iyileştirmek” bir ölçüt değildir. “Pilot bayi grubunun tekrar siparişlerini telefon yerine portaldan vermesi” bir ölçüttür; kimin, hangi işi, hangi kanaldan yapacağını söyler. Ölçütü yazdıktan sonra her özellik için aynı soruyu sorarsınız: Bu özellik, ölçüte ulaşmak için gerekli mi?
Ölçüt, hangi verinin toplanacağını da belirler. Bu karar ilk sürümün tasarımında verilmelidir; ürün canlıya çıktıktan sonra geriye dönük ölçüm yapmak çoğu zaman mümkün olmaz.
Tek kullanıcı grubu, tek ana akış
B2B ürünlerin çoğunda birden fazla kullanıcı grubu vardır: bayi, saha temsilcisi, operasyon ekibi, finans, yönetim. Hepsine ilk günden hizmet etmeye çalışmak kapsamı katlar, çünkü her grubun kendi ekranları, yetkileri ve istisnaları vardır.
İlk sürüm için tek bir birincil kullanıcı grubu seçin. Seçimde iki soru işe yarar: Problemi en sık kim yaşıyor? Ürünü kullanıp kullanmamaya kim kendisi karar veriyor? Ardından bu grubun en sık yaptığı ve en çok zaman kaybettiği işi bulun ve uçtan uca yazın: işin nerede başladığını, hangi adımlardan geçtiğini, nerede bittiğini.
Diyelim ki 300 bayiyle çalışan bir distribütör bir bayi portalı planlıyor. Birincil kullanıcı bayidir; ana akış da tekrar siparişidir. Bayi giriş yapar, geçmiş siparişinden sepetini hazırlar, kendi fiyatını ve stok durumunu görür, siparişi onaylar ve durumunu takip eder. Saha temsilcisinin paneli, yönetim raporları ve iade süreci değerlidir ama ikinci sıradadır.
Özellikleri üçe ayırın: ilk sürümde, sonra, hiç
Ölçüt ve ana akış netleşince özellik listesini üç gruba ayırın. Bu, MoSCoW gibi önceliklendirme yöntemlerinin sadeleştirilmiş bir hâlidir:
- İlk sürümde: ana akışın uçtan uca çalışması için vazgeçilmez olanlar.
- Sonra: değerli ama ilk sürümün ölçütünü değiştirmeyenler. Yol haritasına sırasıyla yazılır.
- Hiç: toplantılarda sık geçen ama hiçbir kullanıcı ihtiyacına bağlanamayanlar. Bunu açıkça yazmak, aynı tartışmanın her toplantıda yeniden açılmasını önler.
Örnek: varsayımsal bir bayi portalı
| Özellik | Karar | Gerekçe |
|---|---|---|
| Giriş ve bayiye özel fiyat | İlk sürümde | Bayi kendi fiyatını göremezse siparişi portaldan vermez. |
| Geçmiş siparişten sepet | İlk sürümde | Ana akışın kendisi; tekrar siparişini hızlandırır. |
| Sipariş durumu takibi | İlk sürümde | “Siparişim nerede?” sorusu telefonda kalırsa kanal değişmez. |
| Cari hesap özeti (salt okunur) | İlk sürümde | Bayi, bakiyesini görmeden sipariş kararı vermekte zorlanır. |
| Portaldan ödeme | Sonra | Ödeme altyapısı ve mutabakat ayrı bir iştir; ana akış onsuz da çalışır. |
| Kampanya yönetimi | Sonra | İlk aşamada kampanyalar fiyat listesine yansıtılabilir. |
| Saha temsilcisi paneli | Sonra | Ayrı bir kullanıcı grubu; ikinci aşamanın konusu. |
| Bayiler arası mesajlaşma | Hiç | Ne ölçüte ne de ana akışa katkısı var. |
Bayi portalında hangi özelliklerin temel kabul edildiğini B2B portal nedir? yazısında ayrıca ele alıyoruz.
Entegrasyonları önce elle köprüleyin
İlk sürümü en çok geciktiren işlerden biri entegrasyondur. ERP ile çift yönlü, anlık bir bağlantı kurmak haftalar sürebilir; ana akışı sınamak için buna her zaman gerek yoktur. Fiyat ve stok verisi ilk aşamada günde birkaç kez dosya aktarımıyla alınabilir, gelen siparişler operasyon ekibinin ekranından ERP’ye aktarılabilir. Bu geçici çözüm bilerek seçilir ve yol haritasına yazılır: sipariş hacmi elle yönetilemeyecek düzeye geldiğinde tam entegrasyon sıradaki iştir.
Raporları ve istisnai durumları erteleyin
Yönetim panelleri ilk sürümde cazip görünür ama ölçülecek veri henüz yoktur. İlk haftalarda basit bir dışa aktarım ya da haftalık bir tablo yeterlidir; hangi raporların gerçekten okunduğu kullanım başladıktan sonra anlaşılır. Aynı mantık istisnai durumlar için de geçerlidir. Kısmi teslimat, özel vade ya da farklı para birimiyle fatura gibi seyrek durumlar ilk sürümde mevcut yöntemle yürütülebilir. Önemli olan bunların listelenmesi ve kullanıcıya açıkça söylenmesidir.
En riskli varsayımı öne alın
Her ilk sürüm birkaç varsayıma dayanır: kullanıcılar yeni kanalı benimser, veri beklenen kalitededir, entegrasyon öngörülen sürede kurulur. Kapsamı belirlerken bu varsayımları yazın ve her biri için iki soru sorun: Yanlış çıkarsa ne olur? Bunu ne kadar erken öğrenebiliriz?
En riskli varsayım takvimin başına alınır. Bayi portalı örneğinde bu, bayilerin telefonu bırakıp portaldan sipariş vermeye istekli olup olmadığıdır. Bunu öğrenmek için ilk sürümü beklemek gerekmez: tıklanabilir prototip 3. haftada birkaç bayiyle denenir, sipariş adımlarında nerede takıldıkları görülür. Teknik bir belirsizlik varsa, örneğin ERP’den fiyat verisinin hangi biçimde alınabileceği bilinmiyorsa, ilk sprintte bu konuda küçük bir teknik deneme yapılır.
Riskli işi sona bırakmak, sürprizleri projenin en pahalı haftalarına taşır.
6–12 haftalık ilk sürüm takvimi
Kapsam bu şekilde daraltıldığında, birlikte belirlenen ilk sürüm 6–12 haftada canlıya çıkabilir. Tipik bir takvim şöyle ilerler:
- Keşif (1–2 hafta): Kullanıcılar işlerinin başında gözlemlenir; ana akış, veri kaynakları ve riskler çıkarılır. Başarı ölçütü ve “ilk sürümde / sonra / hiç” listesi burada netleşir.
- Tanım ve prototip (2–3 hafta): Ana akışın ekranları tasarlanır; tıklanabilir prototip 3. haftada gerçek kullanıcılarla test edilir.
- İnşa (2 haftalık sprintler): Her hafta çalışan yazılım gösterilir. İlk sürüm 6–12. haftada, genellikle önce bir pilot grupla canlıya çıkar.
- Büyüt ve işlet (sürekli): Ölçüt izlenir; “sonra” grubundaki özellikler sırayla yol haritasına girer.
6 ile 12 hafta arasındaki fark, ana akışın ve entegrasyonların büyüklüğünden gelir. Çekirdek bir sistemin modernizasyonu ya da birçok kullanıcı grubunu aynı anda etkileyen bir platform gibi büyük programlarda bu süre programın tamamının değil, ilk aşamanın süresidir; sonraki aşamalar yol haritasında sırayla canlıya çıkar.
Başarı ölçütü, MVP tanımı ve önceliklendirilmiş yol haritası, ürün stratejisi çalışmasının temel çıktılarıdır. Keşif aşamasının içeriğini ve çıktılarını keşif sprinti nedir? yazısında ayrıntılı olarak bulabilirsiniz.
Kapsam büyüyorsa: uyarı işaretleri
Kapsam çoğu zaman tek bir kararla değil, küçük eklemelerle büyür. Aşağıdaki işaretler ilk sürümün fazla yüklendiğini gösterir:
- İlk sürümün birden fazla birincil kullanıcı grubu var.
- Başarı ölçütü tek cümleye sığmıyor ya da hiç yazılmamış.
- “Sonra” grubu boş; her şey ilk sürümde.
- Ana akış, tam entegrasyon bitmeden test edilemiyor.
- Yönetim raporları ana akıştan önce konuşuluyor.
- Tahmini süre 12 haftayı aşıyor ve bu süre boyunca gerçek kullanıcıya hiçbir şey ulaşmıyor.
Bu işaretlerden birkaçını görüyorsanız, kapsamı küçültmenin en etkili yolu kullanıcı grubunu daraltmaktır: tüm bayiler yerine bir bölgenin bayileri, tüm ürün grupları yerine en sık sipariş edilenler.
Kontrol listesi: ilk sürüm kapsamı
- Başarı ölçütü tek cümleyle yazıldı ve nasıl ölçüleceği belli.
- Tek bir birincil kullanıcı grubu seçildi.
- Ana akış başından sonuna kadar adım adım yazıldı.
- Her özellik “ilk sürümde”, “sonra” veya “hiç” gruplarından birinde.
- Elle köprülenecek entegrasyonlar ve bunları kimin yürüteceği belli.
- Ertelenen raporlar ve istisnai durumlar listelendi, kullanıcılara bildirildi.
- En riskli varsayım ve onu ilk sınayacak adım belli.
- Prototipin 3. haftada hangi kullanıcılarla test edileceği belli.
- Pilot grup ve hedeflenen canlıya çıkış haftası belli.
Bu yaklaşımın bir bayi portalında nasıl görünebileceğini, kurgusal X Dağıtım için hazırladığımız Bayi Sipariş Platformu ürün konseptinde inceleyebilirsiniz: ilk aşama akıllı sepet ve cari hesapla bir pilot bayi grubuna açılır; diğer bayilere yaygınlaştırma ve saha satış paneli sonraki aşamalara kalır. Kendi ürününüzün ilk sürümünü birlikte netleştirmek isterseniz keşif sprinti veya pilot için bir görüşme planlayabilirsiniz.