این مطلب دارای
نسخه صوتی می‌باشد. کاربران ویژه به لینک نسخه صوتی دسترسی خواهند داشت.
هم‌اکنون عضو شوید.
همواره در مدیریت پروژه‌ها اولویت نیازمندی‌ها امری حیاتی می‌باشد. این مسئله با اولویت‌بندی ممکن است و آن را می‌توان برای نیازمندی‌ها،داستان کاربر(User Stories)، وظایف، محصولات، موارد مورد استفاده، معیارهای پذیرش و آزمون اعمال کرد.
این میان، مسکو یک روش قابل اعتماد برای کمک به درک و مدیریت اولویت‌ها است. عبارت مربوط به این اصل از مخفف کلمات زیر که همان مبانی اصلی این روش نیز محسوب می‌شوند، اخذ شده است.
- Must Have
- Should Have
- Could Have
- Won’t Have this time
قوانین تحلیل مسکو
اولویت‌های از نوع Must Have
این موارد حداقل نیاز قابل استفاده در پروژه را ارائه می‌دهند. اینها ممکن است با استفاده از برخی موارد زیر تعریف شوند:
- بدون این اولویت‌ها، زمانبندی و تلاش برای رساندن کار به نقطه پایانی بی‌نتیجه است.
- بدون این اولویت‌ها، قانونی وجود ندارد.
- بدون این اولویت‌ها، جریان عملکرد پروژه ناامن است.
- بدون آن نمی‌توان یک راه‌حل مناسب ارائه داد.
هموراه این سوال را در نظر داشته باشید که “اگر این شرط برآورده نشود، چه اتفاقی می‌افتد؟” اگر پاسخ “لغو پروژه” باشد و متوجه شوید اجرای راه‌حلی که این شرط را برآورده نکند، هیچ فایده‌ای ندارد، بنابراین شما به یک اولویت‌بندی Must Have نیاز دارید.
به طور مثال اگر کار و کسب شما با اینترنت سر و کار دارد و شما از مجموعه محتواهایی استفاده می‌کنید که مشتری را سردرگم و یا خسته می‌کند(استفاده از ویدئوهائی با حجم‌های بالا یا لینک دادن مکرر به مطالب دیگر)، در اولویت‌بندی‌های خود موفق نبوده‌اید.
اولویت‌های از نوع Should Have
این نوع اولویت‌بندی باید شرایط لازم را داشته باشند:
- این موارد مهم هستند اما حیاتی نیست
- کنارگذاشتن آنها ممکن است دردناک باشد، اما راه‌حل آن هنوز قابل استفاده است
- ممکن است به نوعی راه‌حل نیاز داشته باشد، به عنوان مثال مدیریت انتظارات، برخی از ناکارآمدی‌ها، مدیریت مدارک و غیره. (راه‌حل ممکن است فقط یک راه‌حل موقت باشد)
بررسی درجه درد ناشی از عدم تأمین نیاز، که از نظر ارزش تجاری یا تعداد افراد آسیب دیده اندازه‌گیری می‌شود، از موارد مهم در این روش از اولویت‌بندی می‌باشد. به طور مثال، مشخص کردن زمان مورد استفاده برای خوانده شدن یک محتوا توسط مشتری، مورد ضروری نیست اما به سهولت کار می‌افزاید.
اولویت‌های از نوع Could Have
این نوع اولویت‌ها به این صورت تعریف می‌شوند:
- مورد نظر یا مطلوب هستند اما از اهمیت کمتری برخورداراند.
- در صورت کنار گذاشتن تأثیر کمتری روی پروژه خواهند داشت.
اینها الزاماتی است که بستر اصلی شرایط احتمالی را فراهم می‌کند، زیرا فقط در بهترین حالت به طور ایده‌آل بررسی می‌شوند. به طور مثال محصول شما برنامه‌ایست که به مشتری کمک می‌کند تا برنامه‌ریزی دقیق روزانه خود را انجام دهد. استفاده از طیف‌های رنگی در فضای برنامه، ضرورت کار شما نیست، اما می‌تواند مورد پسند مشتری واقع شود.
اولویت‌های از نوع Won’t Have this time
این اولویت‌ها به راحتی قابل حذف و نادیده گرفته شدن هستند. بود و نبود آنها هیچ تاثیری در روند کار و یا بازه زمانی مورد نظر شما نخواهد داشت. حتی در مواردی با کنار گذاشتن این مسائل می‌تواند کار خود را سرعت بدهید.
اولویت‌بندی مسکو در یک بازه زمانی خاص
در یک پروژه سنتی، همه نیازمندی‌ها به عنوان Must Have در نظر گرفته می‌شوند، زیرا از ابتدا انتظار می‌رود که همه چیز تحویل داده خواهد شد و در صورت بروز مشکلات، زمان (تاریخ پایان) به طور معمول کمی لغزش خواهد داشت.
اما پروژه‌های چابک رویکرد کاملا متفاوتی دارند. در این نوع عملکرد باید تمام موارد سر جای خود و از قبل برنامه‌ریزی شده باشند. مواردی مانند مدیریت زمان، هزینه، کیفیت کار و حتی مذاکرات باید توسط تیم به بهترین نحو پیش بروند.
به منظور تحقق این تعهد تا پایان مهلت مقرر، پروژه‌های چابک نیاز به ایجاد شرایط احتمالی در اولویت‌های تعیین شده دارند. بنابراین تمرکز اصلی در ابتدا ایجاد اولویت‌های مسکو برای پروژه است. با این حال، هنگام تصمیم‌گیری در مورد اینکه چه چیزی به عنوان بخشی از افزایش قدرت پروژه ارائه شود، تمرکز بعدی توافق بر اولویت‌های مسکو خواهد بود.
بنابراین در این مرحله، یک نیاز ممکن است دارای دو اولویت باشد. مسکو برای پروژه و مسکو برای افزایش عملکرد آن پروژه. سرانجام، هنگام برنامه‌ریزی برای یک تایم باکسینگ (Time box: تعیین محدوده‌ی زمانی مشخص برای وظایف یا کارها) خاص فقط نیازمندی‌هایی که تیم توسعه قصد دارد راه‌حل‌های آن را نظر بگیرد، در جعبه اولویت‌ها قرار خواهند گرفت.
بنابراین نیازمندی‌ها ممکن است دارای سه سطح اولویت باشند:
- مسکو برای پروژه
- مسکو برای افزایش عملکرد پروژه
- مسکو برای تایم باکسینگ
طبیعتا مهم است که اهداف تصویر بزرگ کار ما (تکمیل و تحویل پروژه) هنگام کار در سطح تایم باکسینگ فراموش نشوند. یک راه ساده برای مقابله با این مسئله، ایجاد یک تایم باکسینگ جداگانه برای هر زیرمجموعه از پروژه اصلی است که به طور خاص با یک تایم باکسینگ منفرد مرتبط است و اولویت‌ها را روی فضای اصلی پروژه تغییر ندهد.
