Xəbərlər

MoSCoW metodu nədir? - Bəxtiyar Nəsibov

MoSCoW – Mo (Must be), S(Should be), Co(Could be), W(Won’t be)

Bizi Telegramdan izləyin

Tələblərin çox, deadline -ların qısa, maraqlı tərəflərin sərt olduğu İT dünyasında tələbləri prioritetləşdirməmiş işə başlamaq xaosla dolu sonda uğursuz olacaq bir layihəyəyə başlamaq deməkdir.

Aydındır ki, bütün maraqlı tərəflər (stakeholder) öz istəklərini daha vacib hesab edir və tez olmasını tələb edir. Bu xaotik vəziyyətdə tələbləri prioritetləşdirmək üçün MoSCoW metodundan geniş istifadə edilir.

MoSCoW metodu nədir?

MoSCoW metodu maraqlı tərəflərin tələblərinin prioritetləşdirilməsi üçün yaradılmış metoddur. Bu metoda əsasən tələbləri  4 kateqoriyaya ayırmaq olar:

 

1. Must Have: bu kateqoriyaya daxil olan tələblər yerinə yetirilmədiyi təqdirdə layihə bitmiş hesab edilmir. Bu kateqoriyaya daxil olan istənilən bir tələbin yerinə yetirilməməyinə baxmayaraq layihə istifadəyə (prod-a) verilərsə, onda layihə uğursuz, lazımsız və ya illeqal hesab edilir. Hədəflənən tarixdə təhvil verilməyən “Must Have” kateqoriyasında olan bir tələb daha sonrakı bir zamanda təhvil verilərsədə heç bir məna kəsb etməyəcəkdir.

2. Should Have: Layihə üçün önəmlidir amma layihənin tamamlanmasında həyati önəm daşımayan taskları bu kateqoriyaya aid edə bilərik. Should Have bir task yerinə yetirilməsə belə layihəni tamamlanmış saymaq (layihə tamalandıqdan sonra etmək) olar. Nəzərə almaq lazımdır ki, bu tələblərin yerinə yetirilməməsi uzaq gələcəkdə “baş ağrısı” yaratması ehtimalı vardır.

3. Could Have: Bu sinifdən olan  tələblərə “Nice-to-Have” tələblər aid edilir. Nice-to-Have tələblər o tələblərdir ki, bu tələblərin edilməsi istifadəçinin işini daha da optimal edir. Bu tələblərin edilməsi yaxşı hal kimi hesab edilir, lakin bu sinifdən olan tələblərin edilməməsi layihənin dayanmasına və yaxud uğursuz olmasına gətirib çıxartmır.

4. Won’t Have: Bu kateqoriyaya daxil olan tələblər layihədə bir o qədər əhəmiyyət daşımayan tələblərdir.  Layihə təhvil verildikdən sonra - support (dəstək) mərhələsində bu tələblərin icra olunub-olunmaması yenidən müzakirə edilərək yekun qərar verilir. Bu kateqoriyaya aid olan tələbləri layihənin əvvəlindən planlamaq layihənin ümumi scope -nu (iş yükünü) başa düşülməsi üçün vacibdir.

 

Aşağıda verilmiş nümunə üzərindən MoSCoW metodunun izahına baxaq:

Layihə Jurnalı - İş dəftəri

Fərz edək ki, sizin Biznes analtik (Product Owner) kimi fəaliyyət göstərdiyiniz şirkət rəqəmsal transformasiya prosesinə keçid edib və İnsan resurslarının idarə edilməsi (HR) departamenti üçün proqram təminatın hazırlanması layihəsinə başlamaq istəyir. Layihədə HR, Maliyyə, İT, Təhlükəsizlik və s. kimi müxtəlif departamentlər maraqlı tərəf (stakeholder) kimi iştirak edir. Biznes analitik (Product Owner) kimi siz işi öhtənizə götürübsüz və bütün tələbləri analiz etməlisiz. Hər bir departament öz tələbini daha vacib sayır və tez yerinə yetirilməsini tələb edir.

Belə situasiyada bir biznes analitik (Product Owner) kimi iş bizə düşür. Bütün maraqlı tərəfləri (stakeholder-ləri) bir araya yığırıq və MoSCoW metodunu tətbiq etməyə başlayırıq.

Departamentlərdən bu layihə üçün aşağıdakı kimi tələblər topladığımızı fərz edək:

1. İşçilərin bonusları avtomatik 1 C proqram təminatında görünsün (Maliyyə departamentinin tələbi);

2. İşçilər işdən azad olunduqda giriş-çıxış kartları avtomatik bloklansın (Təhlükəsislik departamenti)

3. İşçilər işdən azad olunduqda avtomatik IT sistemlərə olan icazələri bloklansın (İT departamenti)

4. İşçilərin mobil nömrəsinə sistemdən kütləvi mesaj göndərmək olsun (HR departamenti)

5. Yeni işçiləri qeydiyyata almaq imkanı (HR departamenti) və s.

Layihə idarəedilməsi istiqamətində karyera qurmaq istəyənlər üçün

Bütün bu xaotik tələbləri müxtəlif maraqlı tərəflər irəli sürmüşdür və hər biri öz tələbini vacib sayır.

1. İlk öncə bütün tələbləri yazırıq və hamısını “Won’t Have” kateqoriyasına aid edirik. Maraqlı tərəflərə istədikləri müvafiq tələbi icra etməsək layihə uğursuzmu olacaq, həmin tələbi yerinə yetirməmiş layihəni bitmiş hesab edə bilərikmi deyə suallar verməyə başlayırıq. Əgər həmin task ın yerinə yetirilmədiyi təqdirdə layihə uğursuz hesab edilirsə, layihəni ləvğ edirlərsə, onda həmin tələbi “Must Have” kateqoriyasına keçiririk. Əgər həmin tələbin layihədə əhəmiyyət daşıdığını tələbi irəli sürən maraqlı tərəf əsaslandıra bilmirsə onda həmin tələb “Won’t Have” kateqoriyasında qalır.

2. Must Have statusuna keçirilmiş tələbləri yenidən nəzərdən keçiririk. Maraqlı tərəfə sual veririk: əgər sizə gəlib desək ki, sabah layihə real mühitə (prod-a) keçirilir amma sizin dediyiniz bu tələbi realda yerinə yetirə bilmirik. Cavabınız nə olar? Prod-a keçməyi dayandırıb tələbin tam yerinə yetirilməsinimi gözləyəcəksiniz? Əgər cavabı “hə” olarsa, onda tələb “Must Have” statusunda qalır. Əgər cavab “yox” layihənin prod-a keçməyini ləngitmərəm layihə prod a keçdikdən sonra da bu tələbi yerinə yetirə bilərsiz olarsa, onda tələbi “Should Have” statusuna keçiririk.

3. Should Have statusunda olan tələbləri yenidən gözdən keçiririk. Bu tələbləri hal-hazırda qarşılamaq üçün manual bir proses varmı, bu prosesin icrası nə qədər maliyyət qarşılığında başa gəlməsini araşdırırıq. Əgər məlum olarsa ki, hal hazırda bu tələbi qarşılayan proses var və normal qaydada manual icra edilir, onda bu task “Could Have” (Nice-to-Have) kateqoriyasına daxil edilir. “Could Have” kateqoriyasına daxil edilən tələblər sonradan yenidən analiz edilir və artıq zaman olduqca bu tipdə olan tələblər icra edilir.

Sonda belə bir matris alırıq:

	Must Have	Should Have	Could Have	Won’t Have
İşçilərin bonusları avtomatik 1 C proqram təminatında görünsün (Maliyyə departamentinin tələbi)		X
İşçilər işdən azad olunduqda giriş-çıxış kartları avtomatik bloklansın (Təhlükəsislik departamenti)			X
İşçilər işdən azad olunduqda avtomatik sistemlərə olan icazələri bloklansın (İT departamenti)		X
Yeni işçiləri qeydiyyata almaq imkanı (HR departamenti)	X
İşçilərin mobil nömrəsinə sistemdən kütləvi mesaj göndərmək olsun (HR departamenti)				X

 

 Yuxarıda göstərilən misalda tələblər nümunə üçün verilmişdir. Təbii ki, real layihə üzərində bu tələblər dəyişə bilər və matris başqa formada qurula bilər.

MoSCoW metodu ilə tələbləri prioritetləşdirdikdə əsas diqqət edilməli məqamlardan biri də odur ki, hansısa bir maraqlı tərəfin digər maraqlı tərəflər üzərində öz ağırlığını qoymamaı, öz tələbini qeyri-obyektiv olaraq “Must Have” kateqoriyasına daxil etmək istəməməsidir. Belə hal olarsa, onda MoSCoW metodologiyası öz aktuallığını itirəcəkdir.

 

Bəxtiyar Nəsibov

Bakı Mühəndislik Universiteti, müəllim || Cybernet MMC, Biznes analitik

 

06.07.2021