30 saniyelik özet

MoSCoW, gereksinimleri belirli bir teslimat dönemi için dört grupta değerlendiren önceliklendirme yöntemidir. Must Have zorunlu, Should Have önemli, Could Have daha düşük öncelikli, Won’t Have this time ise bu dönemde yapılmayacak işleri ifade eder. Amaç, talepleri renklendirmek değil; kapasite daraldığında hangi sonucu koruyacağımızı önceden kararlaştırmaktır. İyi bir sınıflandırma, gerekçe ve açık kapsamla birlikte anlamlıdır. Her talebi zorunlu ilan etmek iş ihtiyacını güçlendirmez; hangi talepten vazgeçilebileceğini belirsiz bırakır. İş analisti, paydaşların önem verdiği özelliklerle teslimatın yaşaması için gereken koşulları ayırmalıdır.

Neden önemli?

Satış ekibi kurumsal müşterinin istediği raporu, operasyon ekibi toplu işlem özelliğini, pazarlama ekibi yeni görünümü öncelikli bulabilir. Taleplerin hepsi değerli olabilir; ancak ekip aynı dönemde hepsini tamamlayamayabilir. “Öncelikli” sözcüğü herkes için farklı anlam taşıdığında plan ortak bir karar olmaktan çıkar.

Sorun geliştirme sırasında beklenmeyen bir bağımlılık ortaya çıktığında belirginleşir. Hangi iş ertelenecek? Ertelemenin müşteri üzerindeki etkisini kim kabul edecek? Teslim tarihi mi değişecek, kapsam mı küçülecek? Bu soruların cevabı önceden konuşulmadıysa son karar, en çok baskı yapan paydaşın talebine göre şekillenebilir.

MoSCoW, bu görüşmeyi görünür hale getirir. Yönetici açısından değeri, teslimat taahhüdünün sınırını açıklamasıdır. Bununla birlikte yöntem bir kapasite hesabı değildir. Bir maddeyi Must olarak işaretlemek, o işi yapacak uzmanı veya zamanı sağlamaz. Sınıflandırmanın ardından efor, bağımlılık ve risk değerlendirmesi yapılmalı; taahhüt bu bilgilerle birlikte verilmelidir.

Terim nedir?

Agile Business Consortium’un tanımında Must Have, yokluğunda çözümün kullanılabilir veya kabul edilebilir olmayacağı gereksinimdir. Should Have önemlidir; eksikliği sorun yaratır, ancak uygulanabilir bir geçici yol bulunabilir. Could Have çıkarıldığında etkisi daha sınırlı kalan istektir. Won’t Have this time, belirtilen dönemde teslim edilmeyeceği kararlaştırılmış maddedir; kalıcı olarak değersiz bulunduğu anlamına gelmez.

Bu ayrımın temel sorusu, bir gereksinim teslim edilmediğinde ne olacağıdır. Should ile Could arasındaki değerlendirme, eksikliğin iş etkisine dayanır. Kategori belirlenirken hangi dönem için karar verildiği de açık olmalıdır. Projenin bütünü için gerekli bir özellik, ilk kullanıma açılışta gerekli olmayabilir.

Bu tanımları uygularken gereksinimi yeterince somutlaştırmak gerekir. “Raporlama zorunlu” ifadesi, bütün raporların zorunlu olduğunu söylemez. Kullanıcının karar vermesi için gereken temel rapor ile sunum seçenekleri ayrı değerlendirilebilir. Ancak maddeleri bölmek, zorunlu sonucun parçalarını görünmez biçimde kapsamdan çıkarmak için kullanılmamalıdır.

MoSCoW ayrıca aynı kategorideki işleri kendi içinde sıralamaz. Birkaç Must madde varsa geliştirme sırası teknik bağımlılıklara ve risklere göre değişebilir. Öncelik, işin neden önemli olduğunu; uygulama sırası ise ne zaman ele alınacağını açıklar. Bu ikisi aynı karar değildir.

Yöntem kaynağı: Agile Business Consortium, What is MoSCoW Prioritization?

Gerçek vaka: St. Marys bilgi sistemleri değerlendirmesi

Kanada’daki Town of St. Marys için hazırlanan, 22 Kasım 2021 tarihli bilgi sistemleri stratejik plan raporu, yazılım ve süreç iyileştirme ihtiyaçlarını ele alıyor. Pecunia House Consulting tarafından hazırlanan raporda, görüşmelerden elde edilen üst düzey iş gereksinimlerinin paydaşlarla incelendiği belirtiliyor.

Bu inceleme sonucunda 26 gereksinim MoSCoW yöntemiyle sınıflandırılmış: 13 Must, 6 Should, 4 Could ve 3 bu proje için öncelikli olmayan madde. Rapor, kategorilerin ne anlama geldiğini açıklıyor ve önceliklendirme listesini ayrıca sunuyor.

Bu sayıların gösterdiği şey, ihtiyaçların aynı öncelikte değerlendirilmediğidir. Ancak 13 Must madde bulunması, iş yükünün yarısının zorunlu olduğu anlamına gelmez. Maddelerin büyüklükleri farklı olabilir. Ayrıca rapor, bu sınıflandırmanın tek başına başarılı teslimata yol açtığını kanıtlamıyor.

Analitik açıdan vaka, öncelik kararlarının ortak bir belgede görünür tutulmasına örnektir. Kararın kalitesini değerlendirmek için kategori sayısının yanında gerekçeleri, bağımlılıkları ve uygulanabilirliği de incelemek gerekir.

Kaynak: Town of St. Marys, Information Systems Strategic Plan Project — Final Report, 22 Kasım 2021; önceliklendirme bölümü ve Ek B.

Varsayımsal örnek: Kurumsal ürünün ilk teslimatı

Bir yazılım şirketi ürününü kurumsal müşteriye açacak. İlk teslimat için erişim yönetimi, veri dışa aktarma, özel görünüm ve gelişmiş raporlama isteniyor. Analist, kategorileri seçmeden önce teslimatın hedefini yazıyor: Yetkili kullanıcılar kendi şirketlerinin verileri üzerinde temel görevlerini yerine getirebilecek.

Bu varsayımsal müşteri anlaşmasında tek oturum açma zorunlu olsun. Tek oturum açma, kullanıcının kurumsal kimliğiyle ürüne erişmesidir. Şirketler arasındaki veri erişimini ayıran yetki kontrolleri de ilk teslimatın koşulu olarak tanımlansın. Bu kapsamda ikisi Must olarak değerlendirilir. Karar, bütün kurumsal ürünlerde aynı özelliklerin zorunlu olacağı anlamına gelmez.

Veri dışa aktarma önemli olsun; ancak ilk dönemde yetkili destek ekibi kontrollü bir işlemle ihtiyacı karşılayabilsin. Analist bu geçici yolu otomatik olarak yeterli kabul etmez. Veri hacmini, bekleme süresini, erişim kurallarını ve destek ekibinin kapasitesini inceler. Uygulanabilirliği doğrulanırsa otomatik dışa aktarma Should olarak değerlendirilebilir.

Özel renk seçimi, temel görevi etkilemediği için Could olarak ele alınır. Gelişmiş raporlama ise ihtiyaçları henüz netleşmediğinden bu teslimat için Won’t olarak kaydedilir. Sonraki değerlendirme için gerekli kanıt da yazılır: Hangi kararların mevcut raporlarla verilemediği araştırılacaktır.

Geliştirme sırasında kimlik bağlantısının beklenenden fazla çalışma gerektirdiği anlaşılırsa ekip kapsamı yeniden değerlendirir. Could maddesini çıkarmak yeterli zaman kazandırmıyorsa başka bir karar gerekir. Zorunlu işin etiketini değiştirerek sorun gizlenmez; kapsam, tarih veya kaynak konusunda yetkili karar sahibine somut seçenekler sunulur.

Yaygın üç hata

  1. Paydaşın ısrarını zorunluluk sanmak

“Bu çok önemli” ifadesi sınıflandırma gerekçesi değildir. Eksiklikte hangi kullanıcı görevinin yapılamadığını, hangi taahhüdün karşılanmadığını veya hangi kabul koşulunun bozulduğunu sorun. Gerekçeyi karar sahibiyle birlikte kaydedin; anlaşmazlığı yalnızca oylamayla çözmeye çalışmayın.

  1. Geçici çözümün bedelini incelememek

Elle yapılabilen her iş sürdürülebilir değildir. Geçici yolun sorumlusunu, kapasitesini, hata riskini ve ne kadar süre kullanılabileceğini değerlendirin. İş yükünü başka ekibe aktarmak, ihtiyacı karşılamakla aynı şey olmayabilir. Bu koşullar değişirse öncelik kararı da yeniden incelenmelidir.

  1. Listeyi yaptıktan sonra kararları izlememek

Yeni müşteri koşulları veya ortaya çıkan bağımlılıklar sınıflandırmayı etkileyebilir. Bir madde yükseltildiğinde hangi işin yer değiştirdiğini gösterin. Won’t maddelerini toplantı sırasında sessizce kapsama geri almayın. Karar değişiklikleri, teslimat beklentisine etkileriyle birlikte kaydedilmelidir.

Mini uygulama / şablon

Yaklaşan bir teslimat için gereksinim listesini alın. Önce dönem ve hedefi yazın; ardından her madde için aşağıdaki alanları doldurun.

Gereksinim kimliği ve açıklaması
—
Değerlendirilen teslimat dönemi
—
Desteklediği kullanıcı görevi veya iş sonucu
—
Önerilen MoSCoW kategorisi
—
Teslim edilmezse oluşacak etki
—
Geçici çözüm ve uygulanabilirlik kanıtı
—
Bağımlı olduğu işler
—
Yaklaşık efor ve tahmin belirsizliği
—
Karar gerekçesi ve karar sahibi
—
Yeniden değerlendirme koşulu
—
Won’t ise sonraki incelemede aranacak kanıt
—

Sonra listeyi bütün olarak değerlendirin. Zorunlu işler için gerekli kapasite mevcut mu? Bir iş ertelendiğinde başka bir işin sonucu bozuluyor mu? Geçici yolları işletmek için sorumlular anlaşmış mı? Bu sorular yanıtlanmadan kategorileri teslimat sözüne dönüştürmeyin.

İncelemenin çıktısı yalnızca dört sütun olmamalıdır. Hangi kapsamın korunduğunu, hangi beklentinin ertelendiğini ve hangi kararın hâlâ açık olduğunu kısa bir notla paylaşın. Önceliklendirme, ekip ve paydaşlar aynı sınırları anladığında işe yarar.

İlgili terimler

Business Objective, Business Requirement, Scope ve Out of Scope, Acceptance Criteria, Backlog Refinement, Business Case, Feasibility Study, Change Request ve Impact Analysis, Requirements Traceability Matrix