MVP Kapsamı: İlk Sürümden Ne Çıkarılmalı, Ne Kalmalı?

Köpek kuaförlerinden randevu almak için bir uygulama yapmak isteyen bir kurucu düşünün. İlk şartname kırk ekran tutuyor: müşteriler, kuaförler, salon yöneticileri ve bir yönetici rolü; bir sadakat programı; üç ödeme yöntemi; bir sohbet; salon sahipleri için raporlar; her bildirim için ayarlar. Bütçe bunun belki yarısını karşılıyor. Olağan cevap, tahmin bütçeye sığana kadar listenin sonundan özellik silmek.

Bu yaklaşım parayı yanlış yerden kısar. Görünmeyen işler genellikle özellik listesinin sonunda durur, çünkü kimse "sadakat programı"nın yanına "hata raporlama" ya da "yanlış bir randevuyu düzeltmenin yolu" yazmaz. Böylece görünen özellikler kalır, alttaki tesisat kesilir ve yayından sonraki ilk haftalar öğrenmek yerine yangın söndürmekle geçer.

Daha iyi bir yol, listeyi iki yığına ayırmaktır. Birinci yığında bugün yapması pahalı, sonradan eklemesi ucuz özellikler durur. İkincisinde bugün yapması ucuz, gerçek kullanıcılar ve gerçek veri oluştuktan sonra eklemesi zahmetli olan şeyler. Kesintiyi birinci yığından yaparsınız. İkinciyi korursunuz.

1. Çıkarın: ihtiyacınız olan ikisi dışındaki tüm roller

Çoğu üründe onu kullanan bir kişi ve o kişiye hizmet veren bir kişi vardır. Kuaför uygulamasında bunlar müşteri ve kuafördür. Salon yöneticileri, bölge yöneticileri ve ayrıntılı yetkiler bekleyebilir. Her ek rol ekranları, test senaryolarını ve kimin neyi görebileceğine dair soruları katlar.

İlk aylarda bir yöneticinin bir şey görmesi gerekiyorsa, haftalık bir dışa aktarım ya da aynı ekranlar üzerine kurulmuş salt okunur bir görünüm çoğu zaman yeter. Rolleri sonradan eklediğinizde, bir atölyede birinin hayal ettiği yetkileri değil, insanların gerçekten istediği yetkileri bilirsiniz.

2. Çıkarın: ayarlar ve tercihler

Her biri yalnızca bir anahtar olduğu için ayarlar ucuz görünür. Uygulamada her anahtar koddaki yolları ikiye katlar. Onun yerine makul varsayılanlarla çıkın ve insanların istediği ayarları kısa bir notta toplayın. Üç müşteri hatırlatma mesajlarını kapatmak istiyorsa o anahtar yerini hak etmiştir. Kimse istemiyorsa o işten tamamen kurtulmuşsunuzdur.

3. Çıkarın: şimdilik bir kişinin elle yapabileceği otomasyonlar

İadeler ayda iki kez oluyorsa ilk sürümün otomatik bir iade akışına ihtiyacı yoktur. Biri cuma günü beş faturayı kopyalayabiliyorsa salonun muhasebe aracıyla bir eşitlemeye de ihtiyacı yoktur. Elle yapılan adımlar yavaştır ama süreci koda dökmeden önce nasıl işlediğini size tam olarak gösterir. Bir işi, elle yapmak gerçek zaman kaybettirecek kadar sık olduğunda ve kuralları değişmeyi bıraktığında otomatikleştirin.

4. Çıkarın: nadir yolları, ama yazıya dökün

Hediye kartları, grup randevuları, son bir saat içindeki iptaller. Gerçek ürünlerde bu durumlardan onlarca vardır. İlk sürüm için her birinde ne olacağına karar verin, cevap "destek ekibi telefonla halleder" olsa bile, ve bu kararı yazın. Yazılı bir cevabı olan nadir bir yol bilinçli bir boşluktur. Cevabı olmayan ise ilk yaşandığı gün bir hata kaydına dönüşür.

5. Koruyun: neyin ters gittiğini görmenin bir yolu

Kullanıcılar hataları nadiren bildirir. Uygulamayı kapatır, sonra yeniden dener ya da sessizce giderler. Mobilde çökme raporlaması ve sunucuda hata kaydı yoksa sorunları, öğrenirseniz, yorumlardan öğrenirsiniz. Bunu geliştirmenin ilk haftalarında kurmak bir iki gün sürer. Yayından sonra eklemek ise geçen ayın şikâyetlerinden hangilerinin gerçek olduğunu tahmin etmek demektir.

Kayıtları büyük değil, işe yarar tutun: ekran ya da uç nokta, uygulama sürümü, arayıp bulabileceğiniz bir kullanıcı kimliği ve hatanın kendisi. Bir sorunu yeniden üretmek için bu genellikle yeterlidir.

6. Koruyun: veritabanına dokunmadan bir kullanıcının verisini düzeltmenin bir yolu

İlk hafta bir randevuda bir şey ters gidecek: çift ödeme, yanlış saat, iki kez atanmış bir kuaför. Bunu düzeltmenin tek yolu bir yazılımcının canlı veritabanında sorgu yazmasıysa her küçük destek talebi bir mühendislik işine, hem de riskli bir işe dönüşür.

Cevabın özenle cilalanmış bir yönetim paneli olması gerekmez. Güvenilir bir kişinin bir müşteriyi aramasını, randevularını görmesini ve birini değiştirmesini ya da iptal etmesini sağlayan sade bir iç sayfa yeter. Kimin neyi değiştirdiğini de kaydeder; bunu ileride isteyeceksiniz.

7. Koruyun: hesap kurtarma ve onu taşıyan e-postalar

Şifre sıfırlama, e-posta doğrulama ve randevu onayları küçük özellikler gibi görünür. Ama unutulması kolay bir şeye bağlıdırlar: gerçekten ulaşan e-postaya. Doğru yapılandırılmış bir alan adından, e-posta sağlayıcılarının kontrol ettiği kayıtlarla göndermek, bu mesajların gelen kutusuna mı yoksa spam klasörüne mi düşeceğini belirler. İlk gün hesabına geri giremeyen bir müşterinin ikinci kez denemesi pek olası değildir.

Uygulama insanların hesap açmasına izin veriyorsa hesabı nasıl sileceklerini de planlayın. Apple'ın App Store'u, hesap oluşturmayı destekleyen uygulamaların uygulama içinde hesap silme sunmasını şart koşar; GDPR ve KVKK gibi gizlilik yasaları da insanlara verilerinin silinmesini isteme hakkı verir. Bunu başta yapmak küçük bir iştir; canlı bir sisteme eklemek ise bir müşterinin verisini tutan her tabloyu bulmak demektir.

8. Koruyun: sonraki sürümü güvenle çıkarmanın bir yolu

İlk sürüm hiçbir zaman son sürüm değildir ve mobilde insanların ne zaman güncelleyeceğini siz belirlemezsiniz. Bazı kullanıcılar ilk derlemenizi aylarca kullanacaktır. Erken verilen iki karar çok zahmetten kurtarır: siz bir şeyleri değiştirirken eski uygulama derlemelerinin çalışmaya devam etmesi için API'yi sürümleyin ve bir değişiklik gerçekten uyumlu kalamadığında eski bir uygulamaya güncelleme yapmasını söyleyebilen basit bir kontrol ekleyin.

Sunucu tarafındaki karşılığı, bir düzeltmeyi dakikalar içinde yayına alabilmek ve aynı hızla geri alabilmektir. Bir yayın bir günlük elle yapılan adımlar gerektiriyorsa küçük düzeltmeler bekler, küçük sorunlar büyür.

Herhangi bir özellik için hızlı bir test

Bir şeyin hangi yığına ait olduğundan emin değilseniz iki soru sorun. Bunu dışarıda bırakırsak bir kişi boşluğu üç ay boyunca elle kapatabilir mi? Ve sonradan eklersek mevcut veriye ya da mevcut kullanıcıların uygulamalarına dokunmamız gerekecek mi? Birinci sorudan geçip ikincide kalan bir özellik bekleyebilir. Birinci sorudan kalan ya da ikinciden geçen bir tesisat parçası ilk sürüme aittir.

Kısaca

İlk sürümün kullanıcıların gördüğü ama nadiren ihtiyaç duyduğu kısımlarını kırpın: ek roller, ayarlar, otomasyonlar ve her biri için yazılı bir geçici çözümü olan nadir yollar. Görmedikleri ama hissedecekleri kısımları koruyun: hata raporlama, veriyi güvenle düzeltmenin bir yolu, hesap kurtarma ve silme, ve sonraki sürümü çıkarmanın bir yolu. Birinci yığını sonradan eklemek daha ucuzdur; ikincisi ise yalnızca pahalanır.

MVP geliştirirken iki yığın üzerinde de geliştirme başlamadan anlaşıyoruz; böylece bütçe ana akışa ve o akışı yayından sonra ayakta tutan tesisata gidiyor.