MVP Kapsamı Nasıl Belirlenir: İlk Sürümünüzü Gerçekten Önemli Olana İndirin

Bize bir uygulama fikriyle gelen hemen herkes, onun tam sürümünü zaten kafasında inşa etmiş oluyor. Gösterge panosunu, ayarlar sayfasını, davet programını, karanlık modu anlatabiliyorlar. Genellikle söyleyemedikleri şeyse, o tablonun hangi tek parçasının çalışırsa tüm işi yapmaya değer kılacağı. Bir MVP'nin kapsamını belirlemek, o tek parçayı bulmanın ve geri kalanı sonraya bırakacak kadar cesur olmanın gösterişsiz, biraz da acı veren işidir.

Birçok ilk ürünün inşa edildiğini gördüm ve zorlananlar neredeyse hiçbir zaman ekip tembel olduğu için başarısız olmaz. Kapsam ilk haftadan yanlış olduğu için başarısız olurlar. Birinci sürüme çok fazla şey tıkıştırılır, kimse bir şey öğrenemeden bütçe biter ve lansman geldiğinde ekip yalnızca başlangıç çizgisine ulaşmak için her şeyi harcamış olur; gerçek kullanıcıların aslında ne yaptığına tepki verecek para kalmaz.

İşte bu, tek satır kod yazılmadan önce insanlara verdiğim rehber. Agile ritüelleriyle ya da süslü çerçevelerle ilgili değil. Tek bir dürüst soruyla ilgili — bu fikrin gerçek olup olmadığını bize söyleyecek en küçük şeyi nasıl inşa edebiliriz? — ve 'sadece bir özellik daha' eklemenin cazibesi geri sızdıkça bu soruyu yanıtlamayı sürdürecek disiplinle. Çünkü o cazibe her zaman geri sızar.

Bir MVP gerçekte nedir (ve ne değildir)

İfade aşırı kullanımdan aşınmış, o yüzden net olalım. Bir minimum uygulanabilir ürün, fikrinizin gerçek bir kullanıcıya gerçek değer sunan ve bir sunumdan öğrenemeyeceğiniz bir şeyi size öğreten en küçük sürümüdür. İnsanların unuttuğu anahtar kelime uygulanabilir. Yalnızca tek bir şey yapsa bile, baştan sona birileri için gerçekten çalışmalı.

İşte bir MVP'nin ne olmadığı. Her yanı kırık köşelerle dolu, yarım kalmış bir tam ürün değildir. Atıp gideceğiniz bir prototip değildir. Ve kesinlikle 'ucuz sürüm' değildir — ucuzluk, iyi kapsam belirlemenin bir yan etkisidir, amacı değil. Amaç öğrenmektir. Sahip olduğunuz en pahalı soruyu yanıtlamak için mümkün olan en az parayı harcıyorsunuz: bunu birileri kullanacak mı ve düşündüğüm gibi mi kullanacak?

Bu ayrım göründüğünden daha önemli. 'İlk %20' zihniyeti, her yönden kırık ve hiçbir yönden işe yaramayan bir şeye götürür. 'Tek şey, hakkıyla yapılmış' ise bir insanın eline alıp gerçekten kullanabileceği ve hakkında bir fikir edinebileceği bir şeye götürür. Fikirler tüm meselenin ta kendisidir. Sessizlik üzerinde yineleme yapamazsınız.

Fazla-inşa tuzağı ve içine düşmenin neden bu kadar kolay olduğu

Kimse kapsamı aşırı genişletmeye niyetlenmez. Bu, her seferinde makul bir kararla olur. Giriş ekliyorsunuz, çünkü elbette hesaplara ihtiyacınız var. Hesaplar bir parola sıfırlama akışı, bir e-posta doğrulama ve bir ayarlar sayfası demek. Ayarlar bir profil demek, o da görsel yükleme, o da bunları saklayacak bir yer demek. Her adım tek başına mantıklı. Üst üste yığıldığında ise, fikrinizi özel kılan parça daha başlamadan iki ay ve bütçenin bir kısmını harcamış olursunuz.

Tuzağın diğer yarısı duygusal. Özellikleri kesmek, fikrinizin küçük olduğunu kabul etmek gibi gelir. Değildir — hangi özelliklerin önemli olduğunu henüz bilmediğinizi kabul etmektir ki bu da sadece gerçektir. Kullanıcılarınız olmadan inşa ettiğiniz her özellik kör atılan bir bahistir. O bahislerin bazıları yanlış çıkacak ve MVP'den kestikleriniz, yanılmanın en ucuza geleceği bahislerdir, çünkü onları hiç oynamadınız.

MVP'nizin yapması gereken tek işi bulun

Sonunda ne kadar büyürse büyüsün her ürünün bir çekirdek döngüsü vardır — kullanıcının değeri yaratmak için tekrarladığı tek dizilim. Bir rezervasyon uygulaması için bu bir slot bul, rezerve et, hatırlatma al'dır. Bir pazar yeri için bir şey listele, biri bulsun, para el değiştirsin'dir. Bir iç araç için veriyi bir kez yakala, her yerde kullan'dır. Üründeki diğer her şey o döngüyü desteklemek, süslemek ya da genişletmek için vardır. MVP'niz döngüdür. Yalnızca döngü.

Kendi döngünüzü bulmak için şu cümleyi yüksek sesle tamamlayın: “Bir kullanıcı ürünüme ______ için gelir ve ______ olursa mutlu olur.” İlk boşluk iştir. İkincisi, işin tuttuğunu nasıl anlayacağınızdır. İki boşluğu tek nefeste dolduramıyorsanız, çekirdeği henüz bulamadınız — ve inşa etmek bir yana, kapsam belirlemeye bile hazır değilsiniz.

Çekirdek döngü ile gerekli gibi hissettiren ama olmayan şeyler arasındaki farkta acımasız olun. Giriş gerekli gibi hisseder. Birinci sürümde genellikle değildir — birçok MVP tek bir paylaşılan bağlantıyla, elle gönderilen bir davetle ya da hiç hesap olmadan başlar ve kimlik doğrulama mekanizmasını inşa etmeden önce ihtiyaç duydukları her şeyi öğrenir. Analitik panoları gerekli gibi hisseder. Değildir; on bir kullanıcınız varken veritabanını elle okuyabilirsiniz. Döngüye kadar sadeleştirin, ne kadar çok şeyin döküldüğüne şaşıracaksınız.

Her özelliği şuna ayırın: olmalı, olsa iyi olur, olmayacak

Çekirdek döngüyü adlandırdıktan sonra, büyük özellik listenizi alıp her birini üç kovaya ayırın. Kovalar bilinçli olarak kabadır, çünkü bitmek bilmeyen 'ama belki' konuşmalarını durduran şey kabalıktır.

• Olmalı: çekirdek döngü onsuz kelimenin tam anlamıyla çalışmaz. Onu kaldırırsanız ortada ürün kalmaz. Bu listeyi şaşırtıcı derecede kısa tutun — genellikle üç ila altı madde.
• Olsa iyi olur: ürünü daha iyi yapar ama döngü onsuz da çalışır. Buradaki her şey ikinci sürümü bekler. İlk inşada istisna yok.
• Olmayacak (şimdilik): şimdi inşa etmemeyi bilinçli olarak seçtiğiniz özellikler. Bunları yazmak önemlidir — fikrin terk edilmediğini, yalnızca sıraya konduğunu kendinize ve ekibinize böyle güvence verirsiniz.

Bunu işe yarar kılan numara üçüncü kovadır. Çoğu insan yalnızca 'olmalı' ile 'olsa iyi olur' arasında tartışır ki bu yorucu ve hiç bitmeyen bir şeydir. 'Şimdilik olmayacak' listesi rahatlamanın yaşadığı yerdir — gelecekteki kendinize, harika fikrin güvende ve planlı olduğuna, sadece şimdi olmadığına dair bir sözdür. İnsanlar hiçbir şeyin çöpe atılmadığına güvenince, her şeyi birinci sürümde tutmak için savaşmayı bırakırlar.

Kapsamı özellik listesine göre değil, zamana ve paraya göre belirleyin

İşte her şeyi değiştiren sessiz bir kayma: kapsamı 'ne istiyoruz' diye belirlemeyi bırakın, 'bütçeye ve son tarihe ne sığar' diye belirlemeye başlayın. Önce çekirdek sorunuzu yanıtlamak için ne kadar para ve kaç hafta harcamaya razı olduğunuza karar verin. Sonra özellik listesini o kutunun içine sığdırın. Tersmiş gibi gelir ama kendinize verebileceğiniz en yararlı tek kısıtlamadır, çünkü aksi halde kaçınacağınız önceliklendirmeyi zorunlu kılar.

Sabit bir kutu psikolojik olarak da bir şey yapar. Bütçe açık uçluyken her özellik tartışmalıdır ve liste yalnızca büyür. Kutu sabitken — diyelim sekiz hafta ve belli bir tutar — konuşma tersine döner. 'Bunu ekleyelim mi?' olmaktan çıkar, 'Bu girerse ne çıkar?' olur. İyi MVP'leri inşa eden işte bu ikinci sorudur. Ödünleşimler gizli kalmak yerine görünür olur ve ekip onları bilerek yapar.

Gerçek bir örnek: bir saha iş yönetimi fikrinin kapsamını daraltmak

Bunu üzerinde çalıştığımız bir vakayla somutlaştırayım — kimliği gizlenmiş ama bu işlerin nasıl gittiğine sadık. Küçük bir ısıtma-sıhhi tesisat firması, saha ekibi için bir uygulama isteyerek bize geldi. Kâğıt üzerindeki brief devasaydı: canlı iş çizelgeleme, araçların GPS takibi, bir müşteri portalı, otomatik faturalama, her araçtaki parça envanteri, bir teklif oluşturucu, fotoğrafla belgeleme ve patron için bir raporlama paketi. Sonunda gerçekten yararlı bir ürün. Ama ilk inşa olarak, bir şey öğrenmeden bir yıllık bütçeyi harcamanın garantili yolu.

Biz de o egzersizi yaptık. Patrona şu cümleyi sorduk: 'Bir kullanıcı buna ______ için gelir ve ______ olursa mutlu olur.' Biraz gidip geldikten sonra gerçek cevap yüzeye çıktı. Teknisyenlerin en büyük günlük derdi çizelgeleme ya da faturalama değildi — kâğıdın gidiş-dönüş yolculuğuydu. Bir işi bitiriyorlar, saatleri ve parçaları bir kâğıda karalıyorlar, geri sürüyorlar, sonra ofisteki biri tüm bunları muhasebe sistemine yeniden yazıyordu, çoğu zaman günler sonra, çoğu zaman hatalarla. Çekirdek döngü basitçe şuydu: işte ne olduğunu, sahada, bir kez yakala ki kimse yeniden yazmasın.

Kapsama gireni — ve girmeyeni

Her şey ayrıştırıldı. Olmalı kovası dört şeye indi: her teknisyen için günün işleri listesi, iş başına çalışılan saatleri ve kullanılan parçaları kaydetmek için basit bir form, bir fotoğraf eki ve ofisin bu veriyi gönderildiği anda görmesini sağlayan bir yol. Tüm MVP buydu. GPS yok, müşteri portalı yok, teklif oluşturucu yok, süslü raporlama yok — hepsi açıkça, 'şimdilik olmayacak' listesine, geleceği notuyla park edildi.

O çekirdeği neredeyse bir yıl yerine birkaç haftada inşa ettik. İşte tüm yaklaşımı haklı çıkaran kısım: yayına girer girmez, ekibin gerçek öncelikleri brief'ten farklı çıktı. Patron sıradakinin GPS takibi olacağını varsaymıştı; teknisyenler ondan neredeyse hiç söz etmedi. Yüksek sesle istedikleri şey, uygulamanın içinden müşteriye varış zaman aralığı mesajı atabilmekti — orijinal listede hiç bulunmayan bir özellik. MVP küçük ve ucuz olduğu için, aylar önce tahmin ettikleri şey yerine gerçekten istedikleri şeyi inşa edecek bütçe kalmıştı.

Bir MVP kapsamını sessizce mahveden hatalar

'Küçük tutalım' fikrini benimseyen ekipler bile aynı birkaç şeyde tökezler. Hiçbiri dramatik değildir. Hepsi, siz bakmazken kapsamı yeniden şişiren yavaş sızıntılardır; ta ki bir gün 'minimum' ürün yine otuz ekran ve altı aylık bir takvim olana kadar.

• Kenarları altın kaplamak: yalnızca sizin göreceğiniz bir yönetici panosunu mükemmelleştirmek için günler harcarken çekirdek döngünün hâlâ pürüzlü olması. Kullanıcının dokunduğu şeyi cilalayın; arka ofisi çirkin ama işlevsel bırakın.
• Sahip olmadığınız ölçek için inşa etmek: ilk onun geri döneceğini kanıtlamanız gerekirken bir milyon kullanıcı için mimari kurmak. Ölçek sorununu, o güzel ölçek sorununa sahip olduğunuzda çözün.
• 'Olmazsa olmaz' ile 'sektör standardı'nı karıştırmak: her rakipte X özelliği var diye MVP'nizin çekirdek fikrinizi test etmek için ona ihtiyacı olduğu anlamına gelmez. Bitmiş bir ürün başlatmıyorsunuz, bir deney yürütüyorsunuz.
• Her uç durumu baştan tasarlamak: yaygın, normal yolu birinin kullanıp kullanmadığını bilmeden nadir, tuhaf girdileri ele almak. Hangi uç durumların gerçekte var olduğunu size gerçek kullanım söylesin.
• Bitti tanımının olmaması: 'bitmiş'in neye benzediğini anlatan yazılı bir satır olmadan inşa hiç bitmez. Kapsam kayması, bitiş çizgisi olmayan bir projeye bayılır.

Bunlardan yalnızca birine karşı korunacaksanız, sonuncusu olsun. Açık, yazılı bir bitti tanımı — 'bir teknisyen telefonunda bir işin saatlerini ve parçalarını kaydedebilir ve ofis bunu anında görür' — kapsamı dürüst tutmanın en güçlü tek aracıdır. Önerilen her ekleme o cümleye karşı tutulur. O cümleye hizmet etmiyorsa, ne kadar iyi olursa olsun, ikinci sürüm fikridir.

MVP'nizin kapsamını belirlemek için basit bir süreç

Hepsini bir araya getirirsek, ilk inşaya başlamadan önce herkesle birlikte yürüteceğim sıra şu. Bilinçli olarak düşük teknoloji — çoğunu bir belge ve dürüst bir konuşmayla, odada bir geliştiriciye ihtiyaç duymadan çok önce yapabilirsiniz.

1. 1
   Çekirdek döngüyü adlandırın

   Cümleyi tamamlayın: 'Bir kullanıcı ___ yapmaya gelir ve ___ olursa mutlu olur.' Yapamıyorsanız, kapsam belirlemeye hazır değilsiniz — gerçek iş yüzeye çıkana dek konuşmayı sürdürün.
2. 2
   Her özelliği dökün, sonra ayırın

   Tüm istek listesini kafanızdan kâğıda boşaltın. Her maddeyi olmalı, olsa iyi olur ya da şimdilik olmayacak olarak ayırın. 'Olmalı' listesini acımasızca kısa tutun.
3. 3
   Kutuyu sabitleyin

   Özellik listesini kesinleştirmeden önce bütçeye ve son tarihe karar verin. Listeyi kutuya sığdırın, tersini değil.
4. 4
   Bitti tanımını yazın

   Çalışan çekirdek döngüyü anlatan tek bir somut cümle. Bu, projenin geri kalanı boyunca kapsam kaymasına karşı kalkanınızdır.
5. 5
   İnşa edin, yayınlayın, izleyin, sonra karar verin

   Çekirdeği gerçek kullanıcılara gönderin. Gerçekte ne yaptıklarını izleyin. Sıradaki 'olsa iyi olur' maddesini, önceki tahminlerinizin değil, onların davranışının seçmesine izin verin.

Son adımın sizi başa döndürdüğüne dikkat edin. İyi bir MVP tek seferlik bir olay değil, bir çarkın ilk dönüşüdür. Küçük kapsam belirlersiniz, yayınlarsınız, öğrenirsiniz ve öğrendiğiniz şey sıradaki inşanın kapsamını yeniden belirler. Kazanan ekipler mükemmel ürünü baştan planlayanlar değildir — kimse bunu yapamaz. Onlar, gerçek bir şeyi kullanıcıların önüne, gerçekliğin onları hâlâ yönlendirebileceği kadar hızlı koyanlardır.

Sık sorulan sorular