Tek müşteri sorununu kanıtla tanımlayın
Kurucular için MVP geliştirme hazırlığında problemi bir teknoloji talebi olarak değil kullanıcı işi olarak yazın. Örnek: “bayiler sipariş durumunu öğrenmek için her gün mesaj atıyor” sınanabilir bir problemdir; “bir mobil uygulama istiyoruz” çözüm tercihidir. Sorunun kimde, ne zaman ve hangi mevcut yöntemle ortaya çıktığını belirtin. Kurucunun tahmini ile kullanıcı görüşmesinden gelen gözlemi ayrı kaydedin.
BTM’nin Türkçe MVP açıklaması erken geri bildirimi ve özellik önceliğini tartışıyor. Kendi projenizde görüşme notu, mevcut iş akışı ve destek kayıtları gibi kanıtları kullanın. Yakın çevrenin beğenisi bütün pazarın talebi sayılmaz. Çözüm gerektiren tek ana sorunu seçin; diğer sorunları sonraki araştırma listesine alın. Kanıt zayıfsa yazılım taahhüdünden önce görüşme veya prototip denemesi planlayın.
Ana kullanıcıyı ve ilk değer anını ayırın
Teknik partner görüşmesinde satın alan kişi ile ürünü kullanan kişiyi ayırın. B2B üründe yönetici ödeme yapabilir, saha çalışanı günlük işi tamamlayabilir ve operasyon ekibi kaydı düzeltebilir. İlk sürümün ana kullanıcı rolünü açık seçin. “Herkes kullanacak” tanımı, farklı ihtiyaçları tek akışta karıştırır ve erişim kurallarını belirsiz bırakır.
İlk değer anını gözlenebilir bir sonuç olarak yazın: örneğin bayi, hesabına girdikten sonra kendi siparişinin güncel durumunu ve bekleyen adımı görebilir. Başarılı giriş tek başına bu değeri sağlamaz. Kullanıcının bu ana ulaşması için gereken veri, yetki ve açıklamaları listeleyin. Davet veya hesap doğrulama zorunluysa akışa dahil edin. Destek personelinin elle yaptığı işi de kullanıcıya vaat edilen sonuçla birlikte görünür tutun.
Ana kullanıcı
İlk sürümde bir belirli görevi tamamlayan rol. Cihaz, çalışma ortamı, mevcut alışkanlık ve erişim yetkisi bu role göre sınanır.
İlk değer
Kullanıcının işini ilerleten gözlenebilir sonuç. Kaydolma veya düğmeye basma gibi ara adımlar sonucun yerine kabul edilmez.
OKUMADAN SONRAKİ ADIMA
MVP kapsamını birlikte sınayalım
Problemi, hedef kullanıcıyı ve ilk değer akışını paylaşın.
Zorunlu akışı ve sonraki sürümü açıkça yazın
Web uygulaması kapsamını çizerken başlangıç, normal sonuç, boş durum ve hatadan toparlanma adımlarını aynı akışta gösterin. İyi çalışan bir mutlu yol, veri bulunamadığında kullanıcıyı çıkmazda bırakıyorsa tamamlanmış değildir. Örnek sipariş ekranında kayıt yok, yetki yok ve servis erişilemiyor durumları farklı mesaj ve sonraki adım gerektirir.
Özelliklerin ilk değere nasıl hizmet ettiğini açıklayın. Ana sonuç için zorunlu olmayan gelişmiş rapor, özel tema, çok sayıda entegrasyon veya sadakat kurgusu sonraki sürüme alınabilir. Ancak erişim kontrolü, kritik hata açıklaması ve gerekli yönetim işlemi “sonra” diye çıkarılamaz. Kapsam değişikliğinde hangi kabul kriterinin etkilendiğini kaydedin. Yeni istek ekleniyorsa başka bir işi çıkarmak veya takvim ve maliyet etkisini yeniden değerlendirmek gerekir.
Veri kaynaklarını ve yönetim işlerini unutmayın
API ve veri kapsamı için her alanın nereden geldiğini, kim tarafından güncellendiğini ve ne kadar güncel olması gerektiğini yazın. Demo verisi ile kullanıcının gerçek kararına temel olan veri farklıdır. Harici sisteme erişim henüz yoksa bu bağımlılığı açık tutun. Yanlış kaydı düzeltme, iptal ve destek işlemleri için yetkili kişinin ne yapacağını tanımlayın.
Yönetim paneli bütünüyle gerekmeyebilir; kontrollü bir operasyon yöntemi yeterli olabilir. Fakat bu yöntem kimin eriştiği, neyi değiştirdiği ve hatayı nasıl fark ettiğiyle birlikte yazılır. Kullanıcı verilerini gerçek gereksinim olmadan toplamayın. Testte sentetik veya izin verilmiş veri kullanın; erişim ve silme sorumluluğunu kaydedin. Entegrasyon gecikirse hangi alternatifin kullanıcıya aynı ilk değeri sağlayacağını sınayın; elle güncellemeyi otomatikmiş gibi tanıtmayın.
| Kapsam alanı | Kanıt | Karar ve sahibi |
|---|---|---|
| Sipariş durumu | Kaynak alanı ve güncelleme örneği | Operasyon; kabul edilen veri gecikmesi |
| Yetki | İki farklı role ait test | Ürün sahibi; görülebilen kayıt sınırı |
| Düzeltme işlemi | Yanlış kaydın geri alınması | Destek; işlem ve denetim kaydı |
Kabul kriterini sonuç ve hata davranışıyla tanımlayın
MVP kabulünde “ekran hazır” yerine başlangıç koşulu, kullanıcı eylemi ve gözlenebilir sonucu kullanın. Örnek: yetkili bayi sipariş listesini açtığında yalnızca kendi kayıtlarını görür; servis yanıt vermezse yeniden deneme bilgisi gösterilir. Bu cümle tasarım, geliştirme ve kontrol ekibinin aynı işi sınamasını sağlar. Kabul ölçütü, henüz kanıtlanmamış gelir hedefiyle karıştırılmamalıdır.
GOV.UK’nin keşif rehberi geliştirme öncesinde problem ve kısıtların anlaşılmasını önerir. Projenize uyarlarken her kriterin kanıtını belirleyin: örnek kayıt, ekran sonucu veya görev gözlemi. Başarılı testin tarihini ve uygulama sürümünü yazın. Açık bulgular için ürün sahibi kabul, düzeltme veya yeniden araştırma kararı verir. “Şimdilik çalışıyor” ifadesi yeniden test koşulunun yerine geçmez.
Kullanıcı denemesini ve bakım sahibini planlayın
Kurucu ve teknik ekip iş birliğinde ilk denemenin amacı “ürün sevildi mi” sorusundan daha açık olmalıdır. Kullanıcı belirli görevi yardım almadan tamamlayabiliyor mu, veri yeterli mi, sonuç işine yarıyor mu? Görevleri ve gözlem biçimini önceden yazın. Katılımcıların bütün hedef kitleyi temsil ettiğini varsaymayın; örneklemenin sınırını belirtin.
Deneme sonrası devam, daralt, değiştir veya durdur seçeneklerini kanıta göre değerlendirin. Kayıtlı kullanıcı sayısı tek başına düzenli değer üretimini göstermez. Canlı kullanım başlayacaksa hata bildirimi, erişim kaldırma, bağımlılık güncellemesi ve veri düzeltme sahibini atayın. Her açık risk için sorumlu ve sonraki değerlendirme tarihi bulunmalıdır. Bu kontrol listesi kapsam kararını düzenler; ürünün pazar uyumunu, yatırım almasını veya belirli sürede tamamlanmasını garanti etmez.
Kontrol listesini al ve kapsamını değerlendir
E-posta ve telefon bu taleple ilgili iletişim içindir. Bülten aboneliği oluşturmaz.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
MVP mutlaka yazılım olmak zorunda mı?
Hayır. Riskli varsayımı sınamak için prototip, görüşme veya kontrollü manuel süreç yeterli olabilir. Kullanıcıya hangi kısmın gerçek ve hangi kısmın deneme olduğunu açıklayın. Yazılım geliştirme kararı, kanıt toplamak için gerçekten gerekli olduğunda verilir.
Minimum kapsam nasıl belirlenir?
İlk değer anına giden zorunlu yolu çıkarın. Bir iş çıkarıldığında kullanıcı sonucu alamıyor, yanlış veri görüyor veya ekip temel destek veremiyorsa o iş minimum kapsamın parçasıdır. Yalnızca ekran sayısını azaltmak doğru sınırı belirlemez.
İlk sürümde yönetim paneli gerekir mi?
İşlem hacmi ve yetki ihtiyacına bağlıdır. Kontrollü bir iç süreç geçici olarak yeterli olabilir. Kayıt düzeltme, erişim değişikliği ve işlem izinin nasıl tutulacağını belirtin. Her değişikliği geliştiricinin elle yapması kalıcı işletme planı değildir.
Kullanıcı denemesinde kaç kişi olmalı?
Tek bir sayı her ürün için doğru değildir. Farklı kritik rolleri ve koşulları kapsayın; bulguların tekrarını ve açık soruları izleyin. Küçük bir denemeyi istatistiksel pazar kanıtı diye sunmayın. Sonraki araştırma ihtiyacını kayıtla açıklayın.
Yeni özellik talebi geldiğinde ne yapılır?
Talebi problem ve ilk değerle ilişkilendirin. Kabul kriterini değiştirmiyorsa sonraki sürüme alınabilir. İlk kapsamı değiştiriyorsa iş yükü, bağımlılıklar ve test planını yeniden değerlendirin; yazılı karar olmadan listeyi sessizce büyütmeyin.
KAPSAMI BİRLİKTE BELİRLEYELİM
MVP kapsamını birlikte sınayalım
Problemi, hedef kullanıcıyı ve ilk değer akışını paylaşın.
MVP kapsamını görüş