3 Saatte Bir MVP Kapsamı Nasıl Tanımlanır

Erken aşamadaki bir ödeme işleme şirketi tarafından ürün müdürü olarak getirildiğimde, işletme zamanında bir envanter yönetim sistemi oluşturmak ve teslim etmek için mücadele ediyordu. Çözüm, kullanıcı dostu olmayan ve sonuç olarak önemli müşteri kaybına neden olan basit bir tuş takımı uygulamasıydı. Benim işim, uygulamanın yeteneklerini tuş takımı işlevinin ötesine taşıyacak envanter sistemini oluşturmakla görevli bir ekibe liderlik etmekti.

Kesik bir zaman çizelgesi üzerinde çalışmak zorunda olduğumuz için, kullanıcılarımızın aradığıyla eşleşen temel özelliklere sahip minimum uygulanabilir bir ürünü (MVP) tasarlamak, tasarlamak ve oluşturmak için basit ama radikal olarak verimli bir yaklaşım oluşturdum. Süreç, bir MVP'nin kapsamını günler veya haftalar yerine üç saatlik yoğun bir oturumda yoğunlaştırdı ve ekibimize geliştirme için aylarca zaman kazandırdı.

Bu hızlandırılmış MVP kapsam belirleme süreci, herhangi bir ürün ekibine rehberlik etmek için kullanılabilir ve herhangi bir sıfıra bir ürünün oluşturulmasına uygulanabilir.

Kullanım Durumuna Genel Bakış

Sorun: Uygulamanın basit tuş takımı işlevi, satıcı olan kullanıcılara envanteri yönetme veya bir müşterinin siparişine eklenecek öğeleri seçme olanağı sağlamıyordu.

Kısıtlamalar: Şirket liderliği, sekiz hafta içinde teslim edilen bir çözüm istedi; Potansiyel bir bağış toplama turu, kısmen ürünün geliştirilmiş bir versiyonunun başarısına bağlıydı.

Bağlam: Pazarın analizinden ve birçok kullanıcımızla zaman geçirdikten sonra, bu satıcıların satış akışlarını düzene sokmak için bir envanter yönetim sistemine ihtiyaçları olduğunu belirledim. Müşterilerin siparişlerini işlemelerini izledim: Önce, istenen öğeleri kağıt parçalarına yazdılar, öğeleri hesaplamak için hesap makinesi kullandılar ve ardından siparişleri uygulamaya girdiler. Sadece bir tanesine ihtiyaç duymaları gerekirken üç alet kullanıyorlardı.

Çözüm: Kullanıcıların envanterlerini dijital bir kataloğa yüklemesine, bu envanterleri yönetmesine ve seçilen öğelere dokunarak müşterinin alışveriş sepetine eklemesine olanak tanıyan bir çözüm geliştirmemiz gerekiyordu.

Tasarım Sprint Kararı

Hangi ürünü geliştirmemiz gerektiğini zaten bildiğimiz için, tipik bir tasarım sprintinden vazgeçmeyi seçtim - ekiplerin büyük bir iş sorununu belirlemek için işbirliği yaptığı, sorunun nasıl çözüleceği hakkında müşterilerden fikirler topladığı dört ila beş günlük bir atölye çalışması. bir ürün için bir konsept geliştirin, bir prototip tasarlayın ve test etmeye başlayın.

Tasarım sprintleri, MVP'ler oluşturmak için etkili bir yöntemdir - temel sorunları belirlemesi gerekenler ve çözümler geliştirmek için kayda değer zamanı olanlar için. Bununla birlikte, erken aşamadaki şirketlerde veya mevcut organizasyonlardaki yeni iş birimlerinde, temel sorunlar tipik olarak açıktır: Kavramlar geliştirildi ve ürün/pazar uyumu genellikle ürün yöneticileri, mühendisler ve tasarımcılar getirilmeden önce belirlendi.

Aşağıdaki akış şeması, bu projeye devam etmenin en iyi yolunun tasarım sprintini atlamak ve takım başlangıcı olarak da bilinen üç saatlik oturumla başlamak olduğuna karar verirken attığım adımları özetlemektedir. Bu toplantıda, katılımcılar beyin fırtınası yapacak ve özellikler için düzinelerce fikir üretecek ve ardından listeyi yalnızca MVP için gerekli olana indirecekti.

MVP Geliştirme Süreci

Hazırlık

Üç saatlik oturumdan önce, mevcut veya potansiyel müşterilerle konuşarak ve bunları gözlemleyerek ve pazar araştırması yaparak kullanıcı kişilikleriniz hakkında bilgi toplamak isteyeceksiniz.

Ardından tasarımcılar ve mühendisler için bir sunum oluşturun. Açıklamalıdır:

• Çözmeye çalıştığınız sorun.
• İnşa ettiğiniz ürün.
• Ürünün bu sorunu hem metrik hem de UX açısından nasıl çözeceği.
• Ürünün sizin ve müşterinizin işletmeleri üzerindeki tahmini etkisi.
• Şirket ve ekip düzeyindeki görevler ve hedefler ve kilit sonuçlar (OKR'ler) ve ayrıca ürünün bu görevlerin yerine getirilmesine ve bu OKR'lere ulaşmasına nasıl yardımcı olduğu.

Sunum, tasarımcılara ve mühendislere MVP'nin kapsamını belirlemeye devam etmek için ürün hakkında sağlam bir anlayış vermelidir.

Üç Saatlik Başlangıç ​​Toplantısı

Başlangıç, geliştirme ekibinin tamamını içermeli ve fikir oluşturma ve hikaye oluşturmadan MVP konsept geliştirmeye kadar sürecin her aşamasına katılmalarına izin vermelidir. Buna kıdemli, ast ve yardımcı ürün yöneticileri dahildir; ürün sahipleri; ürün yönlendirmeleri (varsa); UX tasarımcıları; Yazılım mühendisleri; ve QA mühendisleri.

Hızlı ipucu: Alışılmışın dışında olmasına rağmen, inşaat aşamasından önce mühendisleri dahil etmenizi öneririm. Genellikle harika fikirler sunarlar ve geliştirmeye çalıştıkları ürün için bir tutkuları vardır. Çoğu, MVP'nin kapsamının belirlenmesine dahil olmaktan hoşlanır; projeye daha fazla yatırım yapmalarına ve diğer ekipler tarafından değer görmelerine yardımcı olur.

Herkesi bir konferans odasında veya sanal çalışma alanında toplayın. Bizim durumumuzda 10 kişiydik. Üç saati kapat.

Ürün ve kullanıcı yolculukları (60 dakika)

1. Sunumu teslim edin. (15 dakika)

2. Ürününüz için tüm kullanıcı karakterlerini tanımlamaya başlayın. Henüz herhangi bir akış veya özellik çalışması tanımlamamış olsanız bile, oluşturulması gereken akış sayısını tanımlayabilirsiniz. (10 dakika)

   Hızlı ipucu: Gerekenden daha fazla kişi ekleyerek aşırı mühendislik yapmayın. MVP'nin yayınlanmasından sonra, müşteri geri bildirimi, ek rollere ihtiyacınız olup olmadığını ortaya çıkaracaktır.

   Kullanım örneği: Üç kişimiz vardı: mağaza müdürü (veya yönetici), kasiyer ve son müşteri. Mağaza sahibi gibi başka potansiyel üst düzey kişiler de vardı, ancak bir MVP'nin amaçları doğrultusunda, bunlar yönetici tarafından kapsanabilirdi.

3. Kullanıcı yolculuğunu baştan sona haritalayın. Bir kullanıcının karşılaşacağı akışın her adımını tanımlamaya yardımcı olması için her bir kişiye bir renk atayın. Yüz yüze toplantılar için duvara yapışkan notlar yapıştırın veya beyaz tahta kullanın. Sanal toplantılar için FigJam panosu veya benzeri bir şey kullanın. (35 dakika)

   Hızlı ipucu: Ekibin tüm fikirlerini paylaşmasını sağlayın ve ayrıntılı bilgi edinin. Akışın her adımı oluşturulacak bir özellik haline gelecek ve her kullanıcının ayrı bir akışı olacaktır, ancak adımların ana hatlarını çizme süreci aynı olacaktır.

   Kullanım durumu örneği: Kasiyer personelimiz için özellik listesi:

   • Satış noktası uygulamasını açın.
   • PIN kullanarak oturum açın.
   • Müşterinin satın alacağı ilk öğeyi tanımlayın.
   • Öğe için miktarı tanımlayın.
   • Müşterinin satın alması için ek öğeleri tanımlayın.
   • Bir öğeye indirim ekleyin (varsa).
   • Alışveriş sepetindeki tüm öğelerin toplam maliyeti (bu noktada, satış vergisi dahil tam satın alma fiyatı görüntülenir).
   • Ödeme ve ödeme işlemlerini tamamlayın.
   • Satın almayı onaylayın.
   • Müşterinin bir ipucu eklemesine izin verin.
   • Satışı kapatın.
   • Tüm günlük satışların toplamını göster.
   • Önceden belirlenmiş bir hareketsizlik süresinden sonra (örneğin, beş dakika) zaman aşımına uğrayın.

   Not: Bu liste, bu kişi için düşündüğümüz özelliklerin çoğunu detaylandırmaktadır. Bir kasiyer, mağaza müdürü ve son müşteri olarak uygulamayla farklı şekillerde etkileşime giren minimum örtüşme ile tüm personelde yaklaşık 60 toplam özellik bulduk. Geliştirmekte olduğunuz ürünün türüne bağlı olarak, kullanıcı türleri arasında önemli ölçüde daha fazla özellik çakışması olabilir.

   

Kullanıcı yolculuklarının temel özellikleri (45 dakika)

1. Her kullanıcı türü için özellikleri, gerçek veya sanal bir beyaz tahta üzerinde her kullanıcı yolculuğunun ayrı bölümlerine gruplayın. Ardından tahtaya yatay bir çizgi çizin. Çizginin üstünde, ürünün çalışması için gerekli olan setleri tanımlayın. Çizginin altına, olması güzel olan ancak sonraki sürümlere kadar bekleyebilecek özellikleri yerleştirin. (30 dakika)

   Hızlı ipucu: Bu adımı tamamlamak için tasarımcıları ve mühendisleri gruplara ayırın, ardından notları karşılaştırmak için yeniden bir araya gelin. Bu özellikle 10 veya daha fazla kişinin katıldığı toplantılarda faydalıdır.

   Kullanım örneği: Uygulamamız için bu noktada, öğeleri envanter kataloğuna yükleme, bunları fiyatlandırma, bir müşterinin sepetine eklenecek öğeleri seçme, teslim alma ve satışı kapatma, düşük envanteri yeniden sipariş etme gibi konuları kapsayan 12 özellik setimiz vardı. ve dahası. Sonunda özellik setlerinin sayısını dörde indirdik.

   Bu eleme işlemi, uygulamanın ilk yinelemesinde bir kullanıcının güvenlik oturum açmasının gerekli olmadığını belirlememize yardımcı oldu. Ne bir indirim ne de bahşiş ekleniyordu. Ayrıca, mağaza müdürü veya sahibi gösterebilse de, kasiyerin bir MVP'nin parçası olarak tüm günlük satışların toplamını göstermesi gerekmediğine karar verdik.

2. Özellikler listesini hassaslaştırın. “Bu atlansaydı, ürün yine de çalışır mı?” Diye sorun. Cevabınız evet ise, bu özelliği MVP'nin dışında bırakın; ürünün daha sonraki bir yinelemesi için saklayın. Cevap hayır ise, bu özelliği MVP'ye eklemelisiniz. Bu sürecin sonunda, ürününüzü işlevsel hale getirmek için gerçekten neyin gerekli olduğunu bileceksiniz. Genellikle bu, her set için yalnızca üç veya dört özellikten oluşur. (15 dakika)

   Not: MVP'ye çok fazla özellik seti oluşturmaktan kaçının. Neyin dahil edilmesinin en önemli olduğu konusunda farklı görüşleri önceden tahmin etmeniz gerekirken, aramayı yapmak ürün müdürü olarak sizin işinizdir. Araştırmanızı yaptınız ve kararlarınızı destekleyecek verileriniz var. Deneyimlerime göre, birçok ürün başlangıçta olması gerekenden daha sağlam bir şekilde üretilir ve çoğu şirket, test ve geri bildirim için kullanıcıların eline mümkün olduğunca çabuk bir şeyler almayı tercih eder.

Ürün tasarımı, testi ve mühendisliği (75 dakika)

1. Tasarımcıların, temel özellikleri, mühendislerin ürünün mimarisini oluşturmak için kullanacakları MVP'nin tel kafes tasarımına entegre etmelerini sağlayın. (45 dakika)

2. Ürün uzmanlarının ve tasarımcıların, tel kafes tasarımının bazı hafif UX testleri üzerinde birlikte çalışmasına izin verin. (15 dakika)

   Not: Son müşteriyi dahil etmeden oluşturmanız gereken çok az ürün yönetimi senaryosu vardır, ancak hızlı test ve geliştirme durumunda, bir tasarım prototipini dahili olarak veya ürününüzü bilmeyen arkadaşlarınız ve ailenizle test edebilirsiniz. Kafaları karışırsa, bazı kullanıcılarınız da karışacaktır.

3. MVP'nin mimarisini oluşturmaya başlamaları için tasarlanan tel kafesleri mühendislere verin. Tam bir çözüm oluşturmak için ihtiyaç duydukları her şeye veya zamana sahip olmayacaklar, ancak başlayabilirler ve oluşturdukları mimari MVP'yi tamamlarken kullanılacaktır. Bu arada, ürün ve tasarım ekipleri, dahili ekip üyeleri veya kullanıcı olarak hareket eden arkadaşlar ve aile ile tel çerçeveleri üzerinde test etmeye devam edebilir. Bu adımda ekiplerin aynı anda çalışması zaman kazandırır. (15 dakika)

Bu süreci kullanma konusunda daha ustalaştıkça, hangi özelliklerin bir MVP'nin temel bileşenleri olduğunu ve hangilerinin daha sonra oluşturulabileceğini belirlemek kolaylaşacaktır. Uygulama aynı zamanda sizi yanlış şeyler yapmaktan da alıkoyacaktır: Aklınızda "sonraki" liste için bir şeyler olabilir, ancak daha sonra hiçbir müşterinin bunu istemediğini öğrenebilirsiniz.

Sonuçlar ve Önemli Çıkarımlar

Çabalarımızdan önce, uygulamamız 0'dan 9'a kadar sayılar, ondalık nokta ve şarj düğmesi olan bir tuş takımıydı. Bu sınırlama ve yarattığı verimsiz iş akışı nedeniyle, bir yıl boyunca elde tutma oranımız düşüktü - yaklaşık %20. Rakiplerimizden daha hızlı yeni kullanıcılar kazanmamıza rağmen, onları neredeyse aynı hızla kaybediyorduk.

MVP'yi oluşturma süreci boyunca, tümü kapsam olarak minimal ancak yüksek kalitede olan dört temel özellik seti oluşturduk. Bir kullanıcı artık şunları yapabilir:

1. Öğeleri doğrudan bir mobil cihazdan, yalnızca bir kamera kullanarak, bir ad girerek ve bir fiyat girerek envantere yükleyin.
2. Bu öğeleri seçin ve bir müşterinin alışveriş sepetine ekleyin.
3. Satılan ürünleri görüntülerken satışı kapatın.
4. Belirli bir zaman diliminde satılan ürün sayısını görün.

Müşteriler geliştirilmiş ürünü sevdi. Öğeleri yüklemenin ilk haftasında en az beş kez ödeme yapmak için katalog işlevinden yararlanan yeni kullanıcılar arasında elde tutma oranı %45'ti.

MVP kapsam belirleme sürecimizin verimliliği sayesinde, tamamen bitmiş uygulamamızı yaklaşık iki ayda oluşturduk ve teslim ettik. Bu süreç, geleneksel bir geliştirme yaklaşımıyla, eğer ürün hiç inşa edilmiş olsaydı, muhtemelen dört ay veya daha uzun sürerdi.

Bu hızlandırılmış süreç zamandan ve paradan tasarruf sağlar. Tam bir tasarım sürat koşusu pahalı olabilir. Başlangıç ​​toplantısıyla başlamak, sürecimi en başından daha ekonomik kılıyor ve bu tasarruflar çok daha kısa genel geliştirme zaman çizelgesiyle daha da artıyor.

Bununla birlikte, iki süreç birlikte de çalışabilir: Ekibiniz bir temel iş problemini ve yaratmanız gereken çözümü tanımlamak için bir tasarım sprintini tamamladıysa, MVP kapsamınızı daha verimli bir şekilde tanımlamak için benim sürecimi kullanabilirsiniz.

Bu sürecin sadece bir başlangıç ​​olduğunu unutmayın: Bir MVP, sonraki sürümlerde daha da geliştirilecek olan, devam eden bir çalışmadır. Tamamen oluşturulduktan ve teslim edilmeye hazır olduğunda, kullanıcıların eski uygulama deneyimine geri dönmek için kapatabilecekleri bir beta anahtarı eklemenizi öneririm. Bu seçeneği kaç kullanıcının kullandığını izlemek için Heap gibi davranış yazılımlarından yararlanmak, bir sonraki yinelemede ürününüzü geliştirmek için nelerin eklenmesi veya değiştirilmesi gerektiği konusunda size iyi bir fikir verecektir.