MoSCoW Metotu Nedir?

Kaynakların efektif bir şekilde yönetilebilmesi ve süreç içerisinde karşılaşılabilecek olumsuzlukların asgariye indirilebilmesi amacıyla, afaik kategorisi altında çeşitli konu başlıklarına yer veriyorum.

AA

Daha önce müşteri ile yüklenici arasındaki iletişimin önemli bir parçası olan brief sürecine ve hedeflere kısaca değinmiştim. Bu yazıda ise, RICE yöntemine benzer bir şekilde, iş ve kaynak yönetimi problemlerine çözüm olarak kullanılan, görevlerin ve proje ve/veya ürün gereksinimlerinin önceliklendirilmesi sürecinin etkin bir şekilde yürütülebilmesini sağlayan MoSCoW metotundan bahsedeceğim.

MoSCoW Medotu

MoSCoW Medotu

MoSCoW medotu (tekniği ya da matrisi de diyebiliriz), bir olay örgüsü içerisinde önceliklendirmelerin belirli başlıklar aracılığı ile gruplandırılması esasına dayanır. Proje planı, iş akışı, ürün özellikleri ve daha pek çok amaç doğruktusunda gereksinimler en çokta en aza doğru sıralanır. Bu metot Hızlı Uygulama Geliştirme (RAD) sürecinde kullanılmak üzere, Oracle danışmanı olan Dai Clegg tarafından 1994 yılında geliştirilmiş, 2002 yılından itibaren Dinamik Sistem Geliştirme Yöntemi (DSDM) ile daha kapsamlı hale getirilmiştir1. Genellikle, bir zaman yönetim tekniği olan Timeboxing ile birlikte kullanılır2.

Kaynakların sınırlı, ihtiyaçların belirsizlik taşıdığı ve paydaşların farklı yükümlülüklere sahip olduğu süreçlerde MoSCoW medotu ile proje planlama, iş analizi, ürün geliştirme gibi kapsamın net bir şekilde ortaya koyulabilmesi ve taraflarca (yüklenici, müşteri, kullanıcı, vb.) net bir şekilde anlaşılabilmesi sağlanabilmekte. Alınan bir brief içerisindeki konular da bu tablo içerisindeki uygun 4 alana yerleştirilerek daha net bir hale getirilebilir.

Gereksinimlerin MoSCoW düzenine aktarılmadan önce ibr ön değerlendirilmeden geçirilmesi konuların daha isabetli bir şekilde organize edilebilmesi için tasiye edilir.

  • Proje hedefleri, ürün veya servisin temel fonksiyonları ve bu proje, ürün veya servis için ayrılan kaynaklar konusunda herkes bilgi sahibi?
  • İlgili özellikler paydaşların istekleri mi ihtiyaçları mı?
  • Projenin, ürün veya servisin teslimini etkileyecek riskler nelerdir?
  • Belirlenen kesin ihtiyaçlar için sorumlu(lar)/karar verici(ler) mevcut mu?

Bu değerlendirmenin ardından, gereksinimler şu 4 başlık altında değerlendirilir;

Must Have (Gerekli / İlk Öncelik)

Projenin kapsamı, ürünün temel özellikleri bu başlık altında belirlenir3. Belirtilen alt başlıklar projenin ve/veya ürünün belirtilen zaman içerisinde (deadline) tamamlanması için ilk önceliğe ve kesinliğe sahiptir. Aksi durumda, iş tamamlanmamış kabul edilir. Alt başlıkların birbiri ile ve diğer önceliklerle çelişmemesi gerekir. Genellikle toplam eforun %60'dan fazlasını gerektirir.

Should Have (Önemli / İkinci Öncelik)

Projenin ve/veya ürünün temel özelliklerinin tamamlanmasının ardından kalan kaynakların aktarılabileceği, paydaşların kritik olarak nitelendirmediği ikincil işlemler bu başlık altında yer alır. Tamamlanmaması durumu ürün/proje başarısını etkilemez. Genellikle toplam çabanın yaklaşık %20'ini gerektirir.

Could Have (Olmalı / Üçüncü Öncelik)

Müşteri memnuniyetini artıracağı, projenin etkinliğini ve/veya ürünün kullanımını olumlu etkileyeceği düşünülen olsa/yapılsa iyi olur denebilecek işlemler bu başlık altında listelenir. Bu başlık altındaki işlemler ikincil önceliğe sahip işlemler tamamlandıktan sonra kalan kaynaklara göre ele alınır. Bu işlemler proje ve/veya ürünün teslimini etkilemez. Şayet, bu başlık altında yer alan işlemlerin ilk ve ikinci öncelikli işlemlerle çelişmemesi gerekir.

Won't Have (Olabilir / Dördüncü Öncelik)

Sahip olmak isterim ama şimdi değil şeklinde ifade edilebilir. Burada yer alan istekler projenin veya ürünün teslimat kapsamı dışındadır ve bir kaynağa sahip değildir. Ürün veya projenin akışını doğrudan etkilemeyen, bir sonraki geliştirme planına dahil edilmesi muhtemel olan ve/veya en düşük faydaya sahip (genellikle, estetik iyileştirmeler, vb.) işlemler bu başlık altında listelenir.

MoSCoW Medotu

E-Ticaret Sitesi Örneği

Tüm bu anlatılanları bir örnek bağlamında değerlendirelim4 5.

Sıklıkla karşılaştığım konulardan biri, e-ticaret ile çevrimiçi satış yapmayı planlayan markaların kullanılacak sistem konusunda yaşadıkları kararsızlığı ele alabiliriz. Yerli e-ticaret platformları, WooCommerce, Shopify gibi seçenekleri gerekli özellikler bağlamında ele alabiliriz.

  • Ürünlerin listelenmesi
  • Ürünler için özelliklerin (renk, boyut, varyasyon, vb.) yer aldığı detay sayfalarının oluşturulması
  • Ürünlerin sepete atılması
  • Kredi kartı ile ödeme opsiyonu
  • Tedarikçi entegrasyonu
  • Ürün ve/veya sipariş özelinde indirim kuponu kullanımı
  • Sipariş hazırlanma sürecinin takibi
  • Sipariş özelinde kargo takibi
  • Farklı tedarikçi entegrasyonları
  • Ürünlerin favorilere alınması
  • Farklı ödeme yöntemi opsiyonları (kapıda ödeme, PayPal, vb.)
  • Sipariş özelinde destek talebi oluşturabilme

Çevrimiçi ürün saabilmek için gerekli olduğunu düşündüğümüz özellikleri listeledik. Peki, kaynaklarımız ne durumda? Ne kadar zamanımız ve ne kadat bütçemiz var? Satacağımız ürün adedi nedir? Günlük ne kadar satış gerçekleştirmeyi planlıyoruz? Bu sorulara verilecek cevaplar geliştirici, tedarik ve operasyon sürecinin göz önünde bulundurulmasını sağlayacaktır. Kaynakların kısıtlı, zamanın az ve paydaşların hemfikri olmadığı durumlarda işlerin kontrolden çıkması an meselesi.

Yukarıda bahsi geçen özellikle temel bir e-ticaret sitesinde bulunabilecek özellikler. Dolayısıyla, özelleştirilmiş bir çözüm için daha farklı ya da bu yönde zorunluluk oluşturan nedenlere sahip olmamız gerekir. Aksi durumda, kaynakların etkin bir şekilde kullanılabilmesi için hazır çözümler daha mantıklı olacaktır. Peki, hazır çözümlerin getirdiği; abonelik ücretleri, sunucu yanıt süresi, tema performansı, teknik destek vb. artı ve eksiler (pros and cons) neler?

Gereksinimler Must Should Could Won't
Ürünlerin listelenmesi X
Ürünler için özelliklerin (renk, boyut, varyasyon, vb.) yer aldığı detay sayfalarının oluşturulması X
Ürünlerin sepete atılması X
Ziyaretçi olarak ödeme gerçekleştirebilme opsiyonu X
Kredi kartı ile ödeme opsiyonu X
Farklı ödeme yöntemi opsiyonları (kapıda ödeme, PayPal, vb.) X
Tedarikçi entegrasyonu X
Ürün ve/veya sipariş özelinde indirim kuponu kullanımı X
Müşterilere doğum günü mesajı ve indirim kodu iletilmesi X
Sipariş hazırlanma sürecinin takibi X
Sipariş özelinde kargo takibi X
Farklı tedarikçi entegrasyonları X
Ürünlerin favorilere alınması X
Sipariş özelinde destek talebi oluşturabilme X
Şubeden teslimat opsiyonu X
Abonelik ile ödeme opsiyonu X
Tarayıcı bildirimlerinin gönderilmesi X
Görüntü Tanıma (Image Recognition) ile ürünlerin listelenmesi X

Tüm bu soruların paralel olarak paydaşlarca değerlendirilmesi gerekmekte. Dolayısıyla, özelliklerin önceliklendirilmesi eldeki kaynaklarla ilişkili olarak düzenlenmeli. Elbette değerlendirme sürecinde ilk aşamada fark edilmeyen ek konu başlıkları ve/veya özellikler de önceliklendirmeye dahil edilebilir. Ancak, önceliklendirme paydaşlarca onaylandıktan sonra yeniden düzenlenemez ve önceliklendirmenin takip edildiği süreçte maddeler ve/veya başlıklar arasında geçiş yapılamaz.

Elbette MoSCoW dışında farklı çözümler de mevcut; RICE (Reach-Impact-Confidence-Effort)6, Story Mapping7, PRiX ve MoSCoW metotundan ilham alınarak gündelik kullanıma yönelik olarak geliştirilen ToToTo (Today-Tomorrow-Tonight) metotları bunlardan bazıları8 9 10.