İhtiyaçların sınırsız, kaynakların limitli, paydaşların sert ve çetin, deadlineların neredeyse yarın olduğu IT dünyasında, yapılacakları önceliklendirmeden işe girişmek “Ben kaosu seviyorum.” demenin diğer adı olacaktır. Ancak bir projedeki temel görevi kaostan düzeni ortaya çıkarmak olan iş analistlerinin en önemli aktivitelerinden birisi de hiç şüphesiz farklı paydaşlardan topladığı gereksinimleri önceliklendirmektir. Peki ama nasıl?

İş analistlerinin başucu eseri olan BABOK’un da bu konuda önerdiği ve proje yönetimi süreçlerinde sıklıkla kullanılan bir çözüm var: MoSCoW metodu. MoSCoW tekniğinin Rusya’nın başkenti Moscow ile kelime benzerliği dışında herhangi bir ilgisi olmadığını ve bir akrostiş olduğunu belirttikten sonra kelimeyi şu şekilde açabiliriz:

  • Must Have: Tamamlanmadığı takdirde projenin de bitmesinin mümkün olmadığı maddelerdir. Bir tanesi bile dahil edilmediğinde projeyi başarısız, güvensiz veya illegal yapacak maddeler ‘Must Have’ olarak değerlendirilebilir. Hedeflenen tarihte teslim edilemeyen Must Have bir maddeyi daha sonraki bir zamanda teslim etmek anlam ifade etmeyecektir.
  • Should Have: Proje için çok önemli olmakla birlikte, projenin tamamlanmasında hayati önem taşımayan taskları bu kategoride sınıflandırabiliriz. Should Have bir task tamamlanmamış olarak bırakılsa dahi proje tamamlanabilir; ancak bu durum başınızı ağrıtacak, canınızı sıkacak sorunlara neden olabilir. 
  • Could Have: Nice-to-Have özellikler olarak da adlandırabileceğimiz, yapıldıklarında müşteri memnuniyetini artıran, kullanıcı deneyimine pozitif katkıda bulunan maddeleri bu kategoride sınıflandırabiliriz. Bu maddeleri ancak ve ancak zamanımız ve kaynağımız varsa değerlendirmek önerilir. Yine de bu maddeler tamamlanmadığında, projeye bir zarar verecek, projeyi başarısız yapacak maddeler değillerdir.
  • Won’t Have: Paydaşlar tarafından kritik olmadıkları ve faydası en düşük oldukları üzerinde mutabık kalınan gereksinimlerdir. Hatta sonraki geliştirme dönemlerinde dahi proje için direkt bir fayda sağlayıp sağlamayacakları tartışmalı maddeler demek yanlış olmaz. Aslında paydaşlar tarafından bu maddelerin ortaya konması, projenin de kapsamını netleştirmesi açısından önemli olacak maddelerdir.

Dilerseniz bir senaryo üzerinden yöntemimizi açıklayalım. Bir e-ticaret sitesi projesinin backlog’unda farklı paydaşlar tarafından aşağıdaki gibi gereksinimler olduğunu varsayalım:

  • Ürün görseline zoom-in ve zoom-out özelliği
  • ‘Favori Ürünlerim’ menüsü
  • Farklı ödeme yöntemleri opsiyonları (Kredi Kartı, Paypal, Kapıda ödeme vs.)
  • Beğenilen ürünlerin sosyal medyada paylaşılması
  • Yaklaşan anneler günü kampanyası için ana sayfa tasarımında yapılacak değişiklikler
  • Siparişin hangi aşamada olduğunu gösteren bir widget
  • Anlık mesajlaşma özelliği
  • İndirim kodlarının kullanılması
  • ‘Image Recognition’ teknolojisi ile ürün listeleme

Projede gereksinim olarak önünüzde duran maddeler bunlar. Bir iş analisti olarak iki haftalık bir sprint’te ne kadar puanlık madde alabileceğinizi, yazılımcı kapasitenizi biliyorsunuz. Yukarıda sıralanan bütün maddeleri aynı sprint’te alamayacağınız için bir önceliklendirme yapmanız şart. Öncelik konusunda belki bir fikriniz var ancak emin değilsiniz. Kaynaklar kısıtlı, zaman az, önünüzdeki tablo net değil ve bütün paydaşların gereksinimi kendilerine göre en önemlisi. İşte bu noktada üzerinize sorumluluk alarak, bütün paydaşları toplayıp bir önceliklendirme toplantısı yapmalısınız. O kadar kişiyi topladınız, peki nasıl bir yöntemle öncelikleri belirleyeceksiniz? Bütün maddelere sayı mı vereceksiniz (1,2,3 şeklinde)? Hiçbir paydaşın kendi gereksiniminin 2 numara olduğunu söylemeyeceğini içinizden geçirdiğinizi duyar gibiyim. Çok önemli, Önemli, Az Önemli mi diyeceksiniz? Bu da olmaz.

Neyse ki böyle problemler için bir iş analisti olarak çözüme hazırlıklısınız ve heybenizde MosCoW metodu var. Metodu aşağıdaki gibi işletebilirsiniz:

  • Her bir gereksinim Won’t Have’miş gibi davranın ve neden bir üst seviye öneme çıkması gerektiği konusunda doğrulama yapın.
  • İlgili paydaşa şunu sorun “Eğer bu gereksinim karşılanmazsa ne olur?” Eğer cevap “Projeyi iptal ederiz, hayır olamaz. Bu yapılmazsa geliştirme yapmamızın bir anlamı yok” gibi cümleler olursa bunun bir Must Have madde olduğu açıktır.
  • Şunu da sorun: “Canlıya geçişten bir gün önce size gelip bu maddeyi canlıya geçiremeyeceğinizi söylesem, geçişi durdurur muydunuz?” Eğer cevap “Evet” ise Must Have’dir.
  • Şunu da sorun: “Mevcut durum için sürecinizde manuel de olsa bir çözümünüz var mı?” Eğer varsa ve manuel yapmanın zaman maliyeti yüksek değilse bu madde Must Have değil Should Have’dir.
  • Şunu da sorun: “Bu proje bu gereksinimin gerçekleştirilmesine neden ihtiyaç duyuyor?”
  • Bir gereksinim içerisinde birden fazla ihtiyaç varsa onları ayrıştırın ve ayrı ayrı sorgulayın.
  • Herhangi bir gereksinimin başka bir gereksinime bağımlılığı var mı?
  • Dikkat ettiğiniz noktalardan biri de, gereksinimin önceliğinin zamana göre değişkenlik gösterip göstermediği olmalıdır.

Yukarıdaki tabloda bulunan önceliklendirmeyi kendime göre yaptım. Ancak farklı paydaşların, farklı zamanlarda, farklı gereksinimlerine göre bu tablo tabii ki değişebilir. Bu tamamen ihtiyaçlara ve projenin o zamanki dinamiklerine bağlı olarak değişen subjektif bir durumdur. Örneğin, paydaşlardan biri olan Pazarlama Departmanı’nın Anneler Günü için kampanya planladığı görülüyor. İlgili paydaşlarla yapılacak önceliklendirme toplantısında Pazarlama Departmanı’nın Anneler Gününde yaptırmayı planladığı geliştirmenin, o zaman için Must Have kategorisinde olması gayet doğaldır. Diğer paydaşların da hak vereceği üzere Anneler Günü geçtikten sonra yapılacak geliştirmenin kıymeti kampanya dönemi açısından geçmiş olacaktır. Diğer bir örnekte de, rakibiniz olan şirketin Image Recognition teknolojisini kullanarak ürün listeleme özelliği geliştireceği duyumunu aldınız. Üst yönetim, pazarda öncü olma fırsatını rakip firmaya kaptırmamak için en kısa zamanda bu teknolojiyi kullanan bir geliştirme yapmanızı istiyor. Normalde gündeminizde olamayan bir maddenin, stratejik bir kararla Must Have statüsüne geçebileceği ihtimaline karşı her zaman hazırlıklı olmakta fayda var.

Paydaşlarla yapacağınız toplantıda dikkat edilmesi gereken bir noktada şu ki, paydaşlardan birinin toplantıya kendi ağırlığını koyarak, önceliklendirmeyi kendi önceliklerine göre yönlendirmesine fırsat vermemek gerektiğidir. Bu noktada iş analistleri uyanık davranıp ilgili paydaşı stratejik hedefler doğrultusunda yönlendirmeli ve gerçekten hayati önemi olmayan bir maddenin MUST kategorisine sokulup eforu dağıtmasının önüne geçebilmelidir. Önceliklerin ortaya çıkarılması konusunda paydaşlar arasında tartışmalar yaşanması doğal bir durumdur, önemli olan paydaşların projedeki kazanımların neler olduğu konusunda fikir birliğine varmaları ve görüş farklılıklarının üstesinden gelebilmek için bir sisteme sahip olmalarıdır.

Sonuç olarak, MoSCoW önceliklendirme tekniğini hayatınızın her alanında uygulayabileceğiniz gibi iş analisti olarak görev aldığınız projede de kolaylıkla uygulayabilirsiniz. Bunun için;

  • Gereksinimleri ortaya çıkarın.
  • Paydaşları toplayın.
  • Tamamen kaos içindeki gereksinim listesini, paydaşlara doğru soruları yönlendirerek 4 kategoriye ayırın.
  • Paydaşlarla mutabık kalın. 

Samet Şimşek
BA-Works