MoSCoW Metotu Nedir?

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 (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ştir¹. Genellikle, bir zaman yönetim tekniği olan Timeboxing ile birlikte kullanılır².

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 belirlenir³. 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 (Olmayacak / Dördüncü Öncelik)

Paydaşlar tarafından aktif olarak değerlendirme kapsamına alınmamış, ürün veya projenin akışını doğrudan etkilemeyen, bir sonraki geliştirme planı için değerlendirilebilir durumda olan ve/veya çıkarılması durumunda proje başarısını tehlikeye sokmayacak düşük faydaya sahip (genellikle, estetik iyileştirmeler, vb.) öğeler bu öncelik kapsamında ele alınabilir. Burada yer alan istekler genelde projenin veya ürünün teslimat kapsamı dışındadır.

E-Ticaret Sitesi Örneği

Tüm bu anlatılanları bir örnek bağlamında değerlendirelim^{4 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?

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)⁶, Story Mapping⁷, 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}.