Önceliklerimizi Belirleyelim: MOSCOW Metodu Nedir?

Maşide Leyla Tilki 8 Temmuz 2020 Genel bir bakış 0 5103 1619 kelime - 11 dakika51

---

Bu yazıya puan ver

(1 votes, average: 4,00 out of 5)

Loading...

---

VBO ailesindeki ilk yazımdan merhabalar! Bu yazımda kişisel çalışmalarınızda veya takımınızla geliştirdiğiniz projelerde kullanabileceğiniz basit ama etkili bir özellik önceliklendirme metodundan bahsetmek istiyorum.

Önceliklendirme problemleri genellikle ürüne ilk başlarken zorlayıcı olur. Üreteceğiniz ürün hakkında ortaklarınızın, ekibinizin, müşterilerinizin ya da sizin yığınla özellik fikriniz olur ve herkes ürünün gideceği nihai noktadan konuşur. Bu durum hem demotive edici hem de kargaşaya sebep olur. Eğer ürününüzün birinci versiyonunu hızlıca çıkarmak istiyorsanız ama hangi özelliklere öncelik vereceğinizi bilmiyorsanız sizi şöyle alalım;

MoSCoW metodu olarak da bilinen MoSCoW analizi gereksinimleri yönetmek için popüler ve pratik bir önceliklendirme tekniğidir. Metot, ortakların projenin ve özelliklerin önemini anlamalarına yardımcı olur. Dai Clegg tarafından geliştirilen yöntem daha sonra Dinamik Sistem Geliştirme Metodu (DDSM)’na bağışlandı. Başlangıçta zamana bağlı projeler için geliştirilen yöntem özellikle sürümler şeklinde geliştirilen yazılımlar için uygundu. Çeşitli projelerde kullanılan yöntemin bugün kullanım alanı daha geniştir ve birçok kullanım şekli mevcuttur.

MoSCoW, 4 farklı kategoriyi temsil eder:

• Must-haves (olmazsa olmazlar)
• Should-haves (olması gerekenler) 
• Could-haves (olabilirler)
• Will not have at this time ya da Wish (şu anda olmayacaklar ya da istekler)

MoSCoW analizine başlamadan önce ilk olarak paydaşların ve geliştirici ekibinin hedefler ve önceliklendirme faktörleri ile uyumlu hale getirilmesi gerekmektedir. Tüm katılımcılar hangi özelliklerin önceliklendirileceği konusunda anlaşmalıdır.

Son olarak, her bir kategoriye ayırmak istediğiniz kaynakların yüzdesi konusunda fikir birliğine varmanız gerekir. Bunlar tamamlandığında her özellik için hangi kategorinin en uygun olduğunu belirlemeye başlayabilirsiniz.

Must have : 

• Projenin ihtiyaçlarıyla birebir eşleşen ihtiyaçlar için nitelendirilir.
• Projenin başarılı olması için gereken pazarlık edilemez ihtiyaçları temsil eder. ( Projeyi başarısız, illegal, güvenliksiz yapabilecek özellikler)

Bir özelliğin bu kategoride olması gerektiğinden emin değilseniz şu soruları sorun;

• Bu özellik olmadan yayınlarsak ne olur?
• Bunu yapmanın bir çözümü ya da daha basit bir yolu var mı?
• Versiyon / Proje / Ürün bu özellik olmadan çalışır mı?

Should have :

• Versiyon/ Proje / Ürün için önemlidir ama hayati değildir.
• Özellik çıkartıldığında proje hala çalışır.
• Projeye dahil edildiğinde önemli bir değer katar.
• Mevcut versiyonu etkilemeden gelecekteki versiyon için ayrılabilir.
• Zaman kısıtı bulunmayan özelliklerdir.

Could have :

• Ürünün temel işlevi için gerekli değildir ama olursa iyi olan özelliklerdir.
• Should have özelliklerine kıyasla dışarıda bırakıldığında daha az etkiye sahiptir.
• Düşük maliyetle müşteri memnuniyetini arttıracak özellikler bu gruba alınabilir.
• Ekstra zaman / bütçe varsa değerlendirilebilecek özelliklerdir.

Will not have / Wish :

• Bahsedilen versiyona ve ya önceliklendirdiğiniz zaman dilimine dahil edilmeyecek özellikler eklenir.
• Beklentilerin ( özellikle satış pazarlama tarafında ) yönetilmesinde yardımcı olur.
• Ekipler alt kategori oluşturarak bu zaman diliminde olmayacak ama ileride önceliklendirileceği kesin olan özelliklerle, asla söz konusu olmayan özelliklerin ayrımı yapabilir.

Moscow Önceliklerinin Dengelenmesi

Must Have için ayrılan efora karar verirken Must Have özellikleri çıkmadığı takdirde herhangi bir özelliğin değerinin kalmadığını unutmayın. Çünkü Must Have’lerin teslim edileceği garanti edilen MVP ( Minimum Valuable Product )’yi temsil eder. DDSM önerisine göre;

• Projeyi teslim etme güvenini ekip için yüksek seviyeye getirmek önemlidir. Genellikle %60’dan fazla çaba sarf etmek gerekir.
• Could have genellikle yaklaşık %20 lik bir çaba gerektirir.
• Mantıklı bir Could have özellik havuzu işe başlarken doğru beklentilerle ilerlememize ve beklentilerimizin şekillenmesine yardımcı olur fakat proje odağı her zaman must have ve should have kategorilerindeki özellikler olmalıdır.
• Projeye başlarken will not have kategorisi ve wish kategorisi bu efor dengeleme değerlendirmesinin dışında tutulur.

DDSM in önerileri tipik bir proje üzerinden olsa da MoSCoW’un asıl amacı teslim edilen ilk proje versiyonunda özelliklerin önceliklendirmesinde takıma ve paydaşlara esneklik sağlamaktır.

Tabi ki önceliklendirilen özelliklerin geliştirilmesi ve eforlandırılması geliştirici ekibinin teknik ve domain bilgisine, tecrübesine göre değişebilir. Burada bahsedilen %60 lık eforun dengelenmesi sürecinde referans ideal ekip modelinde;

• Değerlendirmelerin doğru olduğu biliniyor ve iyi anlaşılmış.
• Yaklaşımlar ve yollar iyi anlaşılmış.
• Ekip “performing” aşamasında ( Tuckman Modeline göre).
• Geliştirme ortamı iyi anlaşılmış, beklenmedik hataların sebep olacağı gecikmelere karşı düşük risklidir.

Not: Tuckman Modelinde “Performing“ aşamasındaki ekip tanımı kısaca;

• Ekip kendi başına çalışabilecek organize yeteneğine ve motivasyonuna sahiptir.
• Takım olarak hareket ederler ve takımın olgunluk seviyesiyle her türlü zorlu görevin üstesinden gelebilirler.
• Takım olarak ve birey olarak güçlü ve zayıf yönlerinin farkındadırlar.
• Kendilerinden ne beklendiğini bilirler ve birlikte hedef odaklı çalışırlar.
• Sürekli iyileştirmeyi temel alarak Kaizen hedeflerini hem proje hem de kişisel gelişim için belirlerler.

Bu kadar teoriden sonra örnek bir projeyle inceleyelim;

Bir e-ticaret uygulamasında cüzdan projesi hayata geçireceğimizi düşünelim. Bu proje için ekibimizle ve paydaşlarımızla oturup yığın halde özellikleri de belirlediğimizi varsayalım. Sıra bu özellikleri belirlemeye geldiğinde proje için olmazsa olmazlar kısmı MUST HAVE;

( Bu kategorinin özellikleri; olmazsa olmazlar, güvenlikli, legal)

• Kullanıcının cüzdanını yapacağımız işlemler için ve para yüklendiğinde ona haber verebilmek için telefon numarası ile ilişkilendirdik
• Kullanıcının kredi kartından cüzdana para aktarması ve ya parasını kartına aktarması süreçlerini gerçekleştirdik
• Kullanıcının parasının güvenliğini sağladık ve olabilecek fraud senaryolarını belirleyip testlerini yaptık

Tebrikler! Artık bu haliyle projenizi en temel fonksiyonları çalışır hale getirdiniz. Sırada işi biraz renklendirip diğer olmazsa olmazlarımıza geçiyoruz ( projeyi biraz satılabilir hale getiriyoruz 😉)

SHOULD HAVE;

• Kullanıcımız 2 türlü ödeme yapıyor kredi kartı ve cüzdan. Burada artık kredi kartından da yapılan ödemelerin iadelerini banka işlemlerini beklemeden cüzdanına ekleyebilme özelliği katıyoruz ki cüzdanımız biraz canlansın.
• Kullanıcı ödeme yaparken ops! Uygulamanın kendisinde çıkan bir bug sebebiyle cüzdan çalışmıyor. İşte bunların testlerini yapıyoruz bakalım uygulamayla ne kadar ilintili, nelerden etkileniyor.
• Alışveriş yaparken gözü dönen tatlı müşterilerimiz nerede ne harcamış görmek isteyecektir. Burada onlara bir cüzdan harcama geçmişi ekranı sunarak müşteri hizmetlerini taciz etmelerini engelleyebiliriz.

Evet, artık uygulama bu haliyle kullanıma açılabilir. Bu noktaya kadar takım ruhuyla ilerledik, en az %60lık azmettik ve sunuyoruz artık. Sırada “olursa iyi olur”, “hımm keşke bu da olsaydı” dediklerimiz var. Burada ilk test eden müşterilerinizin arkadaşlarınızın geri bildirimleri de çok önemlidir ve bu kategoriyi onlar da renklendireceklerdir.

COULD HAVE;

• Kazanmayı seven kullanıcımız harcamalarından parapuan kazanmak isteyebilir
• Harcamayı bol tutup belirlediğiniz limite ulaşan kullanıcılara özel kuponlar ya da kargo bedava hediyeleri verilebilir

Kısacası müşteriyi mutlu edecek ve kullanıcı deneyimini geliştirecek her şey yapılaBİLİR!

Gelelim son aşamaya; burada W kullanımı ekibe göre değişiyor tabi ki, ikisini de küçük örneklerle anlatmak istedim. WİSH kısmı ekibin uzun vadede yapmak istediklerini gösterir ama buna yönelik adımları atmak için çok erkendir;

• Cüzdanınız öyle güzeldir ki “neden diğer alışveriş siteleri bunu en baştan yapmakla uğraşsın ki” diyip pazarlığa açıp diğer sitelere de entegre edebilirsiniz.

Ya da diğer W olan  WON’T şeklinde kullanımı vardır ki, başta güzel gelir fakat daha sonra hukuki ve ya güvenlik problemler sebebiyle iptal edilir;

• Cüzdandaki parayı kayıtlı kredi kartı yerine ibandan aktarırsanız, hop parasını nakite çevirmek isteyen müşterileriniz olur ve bankalar sizden pek hoşlanmaz..
• Bitcoinin yükselişinden etkilenip kendi coininizi yaratma sürecinize girebilirsiniz ama müşteri kitleniz buna pek uygun değildir.. gibi gibi bir sürü sebep var.

Son olarak bunları derli toplu görmenizi sağlayacak özet bir tablo hazırladım;

Bu aşamaya gelindiğinde takıma şeffaf olunması çok değerlidir. Ürünün nereye gideceği, hangi özelliklere başlangıçta kafa yorulması gerektiği konularında herkesle paylaşacağınız ve ya ofisinize asacağınız tablo hem kafa karışıklığını önler hem de efor israfının önüne geçer.

Son olarak; Moscow’un her aşamasının satılabilir ve kullanılabilir bir ürün çıkarması gerektiğini özellikle belirtmek isterim. “Nereden başlayacağız?” sorunuza çözüm getirebilecek ve ürününüzün her aşamasında kullanabileceğiniz bir metottan bahsettik. Projeye ve çalışma tarzınıza bağlı olarak önceliklendirme metodunuz değişkenlik gösterebilir, etkili ve pratik kullanabileceğiniz önceliklendirme metodlarından ilerleyen yazılarımda bahsedeceğim. Sorularınız, yorumlarınız ve geri bildirimleriniz olursa çok memnun olurum. Görüşmek dileğiyle.