MVP kapsamı nasıl belirlenir? İlk sürüme hangi özellikler girer, hangileri bekler

MVP kapsamı, özellik listesini kısaltarak değil, cevabını aradığınız tek soruyu seçerek belirlenir. İlk sürüme giren şey, bir kullanıcının baştan sona gerçek bir işi bitirebildiği en dar dikey dilimdir: tek kullanıcı tipi, tek senaryo, tek kanal. Dışarıda kalan şey ise aynı işin varyasyonları, kenar durumlar, yönetim panelleri, raporlar ve "nasılsa ileride lazım olur" diye eklenen ayarlar. Her madde için tek bir soru yeterli: bu özelliği çıkardığımızda ilk kullanıcı işini yine de bitirebiliyor mu? Bitirebiliyorsa ilk sürümde yeri yok.

MVP kelimesi neden bu kadar yanlış anlaşılıyor

Terimi 2001'de SyncDev'in kurucusu Frank Robinson ortaya attı ve tanımı ilginç biçimde "minimum" üzerine değildi: hem satıcı hem müşteri için riske karşı getiriyi en yükseğe çıkaran ürün. Eric Ries popülerleştirdiğinde vurgu öğrenmeye kaydı, yani en az çabayla müşteri hakkında en fazla doğrulanmış öğrenmeyi toplayan sürüm. Ries'in kendisi de "adına rağmen MVP mümkün olan en az şeyi üretmekle ilgili değildir" diye not düşme ihtiyacı duymuş.

Pratikte kelime iki yöne birden çekiliyor. Henrik Kniberg 2016'daki yazısında bazı müşteriler için MVP'nin fiilen "yayına verilebilir asgari döküntü" anlamına geldiğini söylüyor ve terimi bırakıp üç aşama öneriyor: en erken test edilebilir, en erken kullanılabilir, en erken sevilebilir sürüm. Marty Cagan da benzer bir ayrım yapıyor. Bir hipotezi sınamak için ürettiğiniz şey "MVP testi"dir; ürün dediğinizde ise insanların kullanmayı seçtiği, nasıl kullanılacağını kendi başına çözebildiği ve zamanında teslim edebildiğiniz bir şeyden söz ediyorsunuzdur. İkisini aynı kelimeyle anmak, toplantıdaki iki kişinin farklı şeyi kabul etmesine yol açıyor.

Şirket içi yazılımda MVP başka bir işe yarar

Bir girişimde temel soru "bunu isteyen var mı" olur. Kurumsal özel yazılımda talep zaten bellidir, iş yapılmasına karar verilmiştir. Orada MVP'nin görevi talebi doğrulamak değil, teslim riskini erkene çekmektir: ERP'nin o alanı gerçekten beklediğiniz formatta verdiğini, veri modelinin gerçek kayıtlar altında tuttuğunu, depodaki kullanıcının o akışı gerçekten benimsediğini altıncı ayda değil altıncı haftada görmek.

Bu yüzden ilk toplantıda bir ayrım yapın ve yazıya geçirin. Bu bir MVP mi (öğrenip yön değiştirebiliriz) yoksa Faz 1 mi (yön belli, sadece kapsamı kesiyoruz)? İkisi farklı kabul kriteri, farklı bütçe ve çoğu zaman farklı sözleşme demek. Riskin taraflar arasında nasıl paylaşıldığı için sabit fiyat mı zaman-malzeme mi yazısına bakabilirsiniz.

Doğru kesme ekseni: dikey dilim, yatay katman değil

Kapsam tartışması çoğu zaman yanlış eksende yapılır. "Önce veri modelini ve yönetim panelini bitirelim, kullanıcı ekranları sonra gelir" cümlesi yatay bir kesmedir ve sonunda kimsenin kullanamadığı bir yarım sistem üretir. Alistair Cockburn'ün 90'larda adlandırdığı yürüyen iskelet tam tersini söyler: sistemin uçtan uca küçük bir işi yapan minik bir uygulamasını çıkarın, nihai mimariyi kullanmasa bile ana bileşenleri birbirine bağlasın. Kniberg'in kaykaydan arabaya giden meşhur çizimi de aynı fikrin resmi.

Sipariş yönetimi örneğinde bu şuna benzer. Yanlış birinci sürüm: bütün sipariş tiplerini kapsayan veri modeli, tam yetkilendirme matrisi, yönetici raporları, henüz hiçbir siparişin geçmediği bir sistem. Doğru birinci sürüm: tek sipariş tipi, tek satış kanalı, tek para birimi, ama girişten onaya ve faturaya kadar akışın tamamı çalışıyor. İade, kısmi sevkiyat, ikinci depo ve diğer kanallar sonraki dilimlerdir. Aradaki fark, ikinci sürümde altıncı haftada gerçek bir siparişin sistemden geçmiş olmasıdır.

Kesilenler listesi somut olsun

Şunlar neredeyse her projede ilk sürümün dışında bırakılabilir: rol ve yetki matrisinin tamamı yerine iki rol, raporlama ekranları yerine CSV dışa aktarma, toplu içe aktarma, çoklu dil, bildirim tercihleri ekranı, ayarlar sayfası (ilk sürümde değerler kodda sabit durabilir), tema ve görünüm özelleştirmesi.

Bir de ilk sürümde yazılmaması gereken otomasyonlar var. Dropbox'ın ürün hazır değilken çektiği tanıtım videosu bunun bilinen örneği, ama kurumsal karşılığı çok daha sıradan görünür: gerçek zamanlı entegrasyon yerine günde bir kez CSV aktarımı, otomatik onay akışı yerine operasyondan bir kişinin onaylaması, akıllı eşleştirme algoritması yerine elle eşleştirme ekranı. Manuel adım ilk bakışta ilkel durur. Yanlış kuralları öğrenmiş bir otomasyonu sonradan sökmek daha pahalıdır, üstelik o kuralları ancak elle çalışırken öğrenirsiniz.

Özelliklerin çoğu gerçekten kullanılmıyor, ama hangi rakama güvenmeli

Pendo'nun 2019 tarihli Feature Adoption raporu, bir yıldan uzun süredir müşterisi olan 615 aboneliğin üç aylık anonim kullanım verisine bakmış. İki bulgu net: ortalama bir üründe özelliklerin yüzde 80'i nadiren ya da hiç kullanılmıyor ve günlük kullanımın yüzde 80'ini özelliklerin yaklaşık yüzde 12'si üretiyor. Aynı raporun 29,5 milyar dolarlık sektörel israf hesabı ise ölçülmüş bir sayı değil, halka açık şirketlerin Ar-Ge giderleri üzerinden yapılmış bir tahmin. İlk iki oran doğrudan veriden geliyor, üçüncüsü yorumdur.

Bir de sık paylaşılan "özelliklerin yüzde 45'i hiç kullanılmıyor" rakamına dikkat edin. Standish Group'tan Jim Johnson'ın XP 2002 konferansında sunduğu bu veri toplam dört uygulamaya dayanıyor ve dördü de şirket içi kullanım uygulaması, ticari ürün değil. Mike Cohn bunu yıllar önce ayrıntısıyla yazdı. Sonuç muhtemelen yanlış değil, ama üzerine bütçe kararı kurulacak bir örneklem de değil. Kendi ürününüz canlıdaysa bu tartışmayı bitirmenin yolu basit: özellik bazında kullanım ölçün, üç ay boyunca kimsenin açmadığı ekranların listesini çıkarın.

Kapsamı kesmenin mekanizması: zamanı sabitleyin

Basecamp'in Shape Up yönteminde geçen "iştah" kavramı burada işe yarıyor. Tahmin tasarımla başlar ve bir süre çıkarır; iştah tersini yapar, bir sayıyla başlar ve tasarımı o sayının içinde şekillendirir. Yani "bu problem için altı haftamız var, çözüm buna göre kurulacak" dersiniz. Yöntemde iki standart boy var: bir iki haftalık küçük işler ve tam altı haftalık büyük işler. Kapsam altı haftaya sığmıyorsa iştahı büyütmezsiniz, problemi daraltır ya da ikiye bölersiniz.

Asıl dişli ise devre kesici kuralı: döngü içinde bitmeyen proje varsayılan olarak uzatılmaz, iptal edilir. Kulağa sert geliyor, ama yaptığı şey kapsamı kesme kararını yazılım ekibinin inisiyatifinden alıp bir kurala bağlamak. Uzatmanın varsayılan olduğu her yerde ilk sürüm sessizce büyümeye devam eder ve kimse tek tek "hayır" demek zorunda kalmadığı için kimse demez.

Öncelik listeleri neden tek başına yetmiyor

MoSCoW tablosu yapıldığında herkes kendi maddesini "Must" sütununa taşır, çünkü kimse kendi ihtiyacını "Could" diye işaretlemek istemez. RICE gibi puanlama modelleri de girdileri uydurulduğu anda uydurma bir sıralama üretir. Bu araçlar tartışmayı düzenlemek için iyidir, kararı vermek için değil.

Kararı veren iki soru daha keskin. Birincisi: bu özelliği çıkarırsak ilk kullanıcı grubu işini baştan sona bitirebilir mi? İkincisi: bu özelliği ilk sürümde yazmazsak öğrenmemiz gereken şeyi öğrenemez miyiz? "Evet bitirir" ve "hayır, engel değil" cevabı gelen her madde ikinci dilime gider. Bir de yetki meselesi var. Kesme kararını verecek tek bir isim olmalı ve o kişi işi yaptıran taraftan olmalı. Komiteler kapsam kesmez, komiteler kapsam ekler.

MVP'de kesilmeyecek dört şey

Kapsam kesmenin bir sınırı var. Şu dördü ilk sürümün dışında bırakılırsa geri eklenmesi kat kat pahalıya gelir, çünkü bunlar özellik değil mimari kararlardır.

Kimlik doğrulama ve yetkilendirme. "Şimdilik herkes her şeyi görsün, yetkiyi ikinci fazda ekleriz" cümlesi üretimde yıllarca yaşayan bir geçicilik üretir. OWASP listesinin açılış maddesinin hâlâ bozuk erişim kontrolü olmasının sebebi de bu: yetki kontrolü sonradan ekranlara serpiştirilen bir şey değil, her isteğin üzerinden geçtiği yolda duran bir katmandır.

Sırların yönetimi. İlk sürümde kimse ortam değişkeni ve kasa altyapısı kurmak istemez, anahtar kod içine girer ve orada kalır. O anahtar sonradan sızdığında dosyayı temizlemek yetmez, geçmiş sürümlerde durmaya devam eder. Ayrıntısı koda gömülü sır yönetimi yazısında.

Yedek ve geri dönüş. Pilot kullanıcıların ürettiği veri "deneme verisi" değildir. İlk dört haftada girilen gerçek kayıtları kaybederseniz kaybettiğiniz şey MVP değil, o ekibin projeye olan güvenidir.

En basit haliyle log ve hata takibi. İlk sürümün asıl çıktısı öğrenmekse, ne olup bittiğini göremediğiniz bir sistemden öğrenemezsiniz. Hangi adımda kaç kullanıcının düştüğünü göremiyorsanız elinizde yalnızca izlenim kalır. Ölçüm tarafı için izlenebilirlik, SLO ve hata bütçesi yazısı iyi bir başlangıç.

MVP'nin bitişi bir tarih değil, bir karar

En sık atlanan adım bu. Canlıya çıkmak MVP'yi bitirmez; MVP, bakıp bir karar verdiğinizde biter. Kararı baştan yazın: hangi metrik, hangi eşikte, hangi tarihte, hangi kararı verdirecek. Şuna benzer bir cümle yeterli: "Pilot depodaki 20 kullanıcının en az 12'si dört hafta boyunca haftada bir kez akışı baştan sona bitirirse ikinci dilime geçeriz, bitiremezse akışı yeniden tasarlarız." Bu cümle yoksa MVP sessizce Faz 1'e dönüşür, kimse durup bakmaz ve kesilen özellikler sırayla geri gelir.

Yapay zekayla prototip hızlandı, karar aynı kaldı

Bir ekran taslağını ya da çalışır bir akışı birkaç saatte çıkarmak artık mümkün ve bu, MVP'nin keşif aşamasını gerçekten ucuzlattı. Bir hafta tartışılacak bir tasarım kararı, iki farklı prototip yapılıp kullanıcıya gösterilerek yarım günde kapanabiliyor. Değişmeyen şey, prototiple üretim kodunun farklı amaçlarla yazıldığı. Prototip bir sorunun cevabını bulmak için yazılır ve büyük kısmı atılır. Üretim kodu beş yıl yaşamak, değiştirilmek ve devredilmek için yazılır.

Risk de tam burada. Hızlı çıkan prototip demoda beğenilir, "madem çalışıyor" denir ve üretime alınır. Testi yoktur, yetkilendirmesi yarımdır, bağımlılıkları denetimden geçmemiştir. O noktada MVP'yle kazandığınız haftaları teknik borç olarak geri ödemeye başlarsınız. Baştan tek cümlelik bir kural koymak yeterli: prototip hangi depoda duruyorsa orada kalır, üretime giden her şey normal kod incelemesinden ve dağıtım hattından geçer.

Bu hafta yapılabilecek dört şey

Bir: ilk sürümün tek kullanıcı tipini ve tek senaryosunu tek cümleyle yazın. "Depo sorumlusu, tek kanaldan gelen standart siparişi sisteme girip onaylayabilir ve faturasını üretebilir" gibi. Cümle iki satırı geçiyorsa kapsam hâlâ büyüktür.

İki: elinizdeki özellik listesini alın ve her maddenin yanına "bu olmadan o cümledeki iş biter mi" sorusunun cevabını yazın. Biten her madde ikinci dilime gider, tartışma bu sütun üzerinden yürür.

Üç: iştahı belirleyin. Bu iş için kaç hafta ayırıyorsunuz ve süre dolduğunda ne olacak? Uzatma varsayılansa kapsam kesme kararı hiç verilmeyecek demektir.

Dört: karar cümlesini yazın ve takvime bir tarih koyun. Ne ölçeceğiniz, eşiğin ne olduğu ve eşik tutmazsa ne yapacağınız baştan belli olsun. Kararın öncesindeki soru hazır ürünle çözülüp çözülemeyeceğiyse, hazır paket mi özel yazılım mı yazısı ilk sürüme başlamadan okunacak yazıdır.