Mobil MVP* belirlenirken dikkat edilmesi gereken maddeler nelerdir?
Minimum Viable Product (MVP): Geliştirdiğiniz bir ürünün olabilecek en az ve kritik özellikleri barındıran versiyonuna verilen isimdir. Sadece mobil uygulamalar için değil, tüm yazılım projeleri, hatta fiziksel servislerin bile tasarımında bir kullanıcı veya tüketicinin ihtiyaç duyduğu ve test edilmesi istenen en temel değerlerin belirlenerek geliştirilmesi pratiği olan MVP’ler, özellikle startup ekosisteminde, yeni bir uygulama fikrinin test edilmesi için de tercih edilir.
Merhaba
Paraşüt, Mikro Yazılım ve Zirve Yazılım’ın tüm mobil ihtiyaçlarına çözüm üretmek için 2020 Ocak ayında grup seviyesinde kurulan ve bir yıldır çalışmalarını sürdüren Team Kraken adına herkese merhaba.
2021 senesinin başında, ekip içerisinde yaptığımız görüşmeler sonucunda, bir sene boyunca yaptığımız çalışmalar başta olmak üzere, ürün geliştirme, tasarım ve ürün yönetimi ile ilgili tecrübelerimizi bu yayın üzerinden paylaşmaya karar verdik.
Yazılarımız içerisinde geliştirme ekibinin mobil ürün geliştirme ilgili yazıları ve UX Design çalışmaları ile ilgili yazılarımıza ek olarak, birden fazla grup şirketine aynı anda destek verirken dikkat ettiğimiz, ürün yönetimi ile ilgili konuları da ben kaleme almaya gayret edeceğim.
Yazmak ile ilgili ufak teşebbüsler dışında ciddi bir tecrübem olmadığı için, yazıların içeriği kadar, anlatım ve stili ile ilgili dikkatinizi çeken tüm yorum ve önerilerinizi paylaşmanızı rica ediyorum.
Team Kraken olarak üzerine çalıştığımız mobil ürünleri, hali hazırda yayında olan ürünler ve henüz bir mobil varlığı olmayan (sıfırdan geliştirilecek) ürünler olarak iki ana kategoriye ayırıyoruz. Bu iki kategori dışında arada ve özel bir yeri olan bir üçüncü kategori de yer alıyor; Hali hazırda native (yani iOS/Swift ve Android/Java-Kotlin ile) ile geliştirilmiş uygulamaların zaman içerisinde farklı bir dile taşınmsını kapsayan çalışmaları da kendi kategorisinde değerlendiriyoruz.
Grup şirketleri seviyesinde, mobil ekip kaynağının farklı grup şirketleri ihtiyaçlarını nasıl önceliklendirdiğimiz kendi başına ayrı bir konu. Bu nedenle tüm ürün portföyü içerisinde hangi ürüne nasıl öncelik verdiğimize ayrı bir yazıda yer vereceğim. Bu yazıda, 3. Kategoride yer alan bir ürünümüzün farklı bir dilde yazılarak nasıl tekrar ele alındığını ve yeni ürünün özellik listesine karar verirken nelere dikkat ettiğimizden bahsetmeye çalışacağım.
Az önce bahsettiğim, mobil varlığı olan ama codebase’i değişecek ürünler kendine özel bir üçüncü kategori olduğu için bu yazıda da bu kategoriden bir ürüne yer vermeye karar verdim.
Mikro Yazılım’ın 2018’de yayınladığı bir mobil uygulaması için Team Kraken olarak farklı bir dil ile uygulamanın feature set’inin de tekrar değerlendirileceği bir MVP talebi bize iletildikten sonra, bu projenin gerçek MVP’sinin belirlenmesi için bir dizi çalışma gerçekleştirdik.
1. Özellik listesinin ve Zaman Planının Alınması
Bir ürün ortaya çıkarırken özellik listesi, kaynak ve zaman olmak üzere üç ana parametreyi dikkate alarak ilerliyoruz:
Kaynak: Ekipten kaç kişi, proje süresi boyunca bu projede yer alacak. Hali hazırda yayında olan ürünlerin kritik update çalışmaları için nasıl bir görev dağılımı yapmamız gerekiyor. Diğer ürünlerin release takvimi doğrultusunda en fazla kaç kişilik kaynak bu projeye bakabilir gibi sorular sorarak, proje için proje süresi boyunca kaç kişilik bir ekip olacağını belirlemeye çalışıyoruz.
Zaman: Proje için bize ne kadar süre veriliyor. Eğer ürün, web ürün lansmanı ile paralel bir tarihte yayınlanacaksa, bu parametre bizim için en belirleyici sabit oluyor. Eğer ürünün geliştirilmesi için bir zaman aralığı varsa kaynak veya yapılacak işin miktarını bu doğrultuda değiştirebiliyoruz. Bir zaman sınırı olmayan projelerde yer almayı herkes kadar biz de seviyoruz fakat sahanın ihtiyaçları, rekabet ve mevzuat gibi nedenlerle tüm projeler için dikkate almamız gereken bir zaman veya zaman aralığı çoğu zaman mevcut oluyor.
Özellik Listesi: Bu liste, yapılan tüm masaüstü araştırma, saha araştırmaları, kullanıcı görüşmeleri, kullanıcı dönüşleri, rekabet, ürünün vizyonu, iş biriminin hedefleri doğrultusunda belirlenmektedir. Bu yazının ana konusu olan MVP’nin belirlenmesindeki en önemli parametre, ürünün sahip olması zorunlu özellik listesinin doğru şekilde belirlenmesi, tasarlanması ve zaman içerisinde geliştirilmesidir. Bu nedenle yazımda, kaynak ve zaman planını sabit değişkenler olarak tutacağım ve ideal özellik listesine nasıl ulaşacağımızı anlatmaya çalışacağım.
2. Özellik listesi üzerinden kullanıcıların temel “iş”lerinin belirlenmesi
İş; Bir kullanıcının, problemini çözmek için, mobil uygulama üzerinden aldığı adımlar toplamına verdiğimiz bir isimdir. Örneğin; bir kobinin mobilden efatura oluşturması, ürünlerinin stok bilgisini görmesi, o gün yapacağı tahsilatları görmesi farklı işlerdir. Ulaşılması hedeflenen iş listesi, Kullanıcıların sık yaptıkları, talep ettikleri ve iyileştirme istedikleri işler ile iş biriminin ürün vizyonu ile ilgili hedeflerinin kesişim kümesini oluşturmaktadır. Bu nedenle iş biriminin bir araya getirdiği özellik listesi mutlaka kullanıcının bir problemini çözmeli veya bir ihtiyacını daha etkili bir şekilde çözmesini sağlamalıdır.
3. Özellik listesinin sadeleştirilmesi ve önceliklendirilmesi
İş birimin paylaştığı özellik listesi üzerinden, birlikte yapılacak toplantılar ile özellik listesi, **olmazsa olmaz özelliklerin belirleneceği şekilde sadeleştirilir. Bu çalışma, üründen daha fazla özellik çıkartılmayacak kadar sadeleşene kadar devam eder. MVP aşamasında zaman ve kaynak çok değerli olduğu için çıkan ürünün, kullanıcıların sadece en kritik ihtiyaçlarını en iyi şekilde yerine getirdiğine emin olmak ve diğer özellikleri daha sonra kontrollü bir şekilde eklemek gerekir. Eğer zamanımız varsa belirlenen sadeleştirilmiş özellik seti üzerinden kullanıcılarla ufak görüşmeler yaparak kullanıcı ihtiyaçları doğrulanarak bir sonraki adıma geçilir.
4. Sadeleştirilmiş özellikler üzerinden proje süresi tahmin çalışmalarının yapılması
Olmazsa olmaz özelliklerin belirlenmesinin ardından high-level bir proje süresi tahmini yapılır. bu tahmin çalışması sırasında ürün yöneticisi, teknik lead, UX tarasımcı ve toplantıya katılmak isteyecek ürün ekibinden diğer katılımcılar ile birlikte Epic ismi verilen her proje öbeği ve bu proje öbeğinde yer alan alt işler için süre ve efor tahmini yapılır. Bu tahmin çalışması, MVP’de karar verilen özellik listesinin proje süresinin içinde kalıp kalmayacağına emin olmaktır.
Süre tahmini yapmak için çok farklı teknikler mevcut olmakla birlikte biz genellikle high-level tahmin çalışmalarında, daha önce benzer modüller için harcadığımız süre için harcadığımız vakti baz alarak bir tahminde bulunuyoruz. Tahmin çalışmalarında en kısa sürede — kabaca — en yakın sonucu verdiği için bu metodu tercih ediyoruz. Bizim izlediğimiz bu tekniğe Analogous Estimating adı veriliyor. Ekip içerisinde daha uzun süren ama daha isabetli tahminler yapılmasını sağlayan farklı teknikleri de ekip olarak ilerleyen tarihlerde denemeyi planlıyoruz. Yaygın olarak kullanılan bazı diğer teknikler: 3 Point Estimation, Bottom-up, Parametric Estimation olarak sıralanabilir.
Bu işlemin ardından proje süresinin aşılması durumunda ürün sadeleştirmesi üzerinden bir tur daha çalışılması gerekir. (Kaynağın ve zamanın sabit olduğu durumda) Eğer tahmin sonucunda projeye hala alınabilecek bir ek süre yer alıyorsa, backlog’dan MVP’ye ek modül alınarak devam edilir.
Yukarıdaki maddeler, MVP belirlenmesi sırasında izlenen adımlar ile ilgili çok yüzeysel bilgiler içermektedir. İlerleyen yazılarda her bir başlık için daha detaylı yazılara ayrı ayrı yer vermeyi düşünüyorum. İlgilendiğiniz konular ve yorumlarınız için yorumlarınızı rica ediyorum.
Herkese Covid’siz bir 2021 diliyorum 🦠 🙏
