تکنیک MoSCoW یک روش دستهبندی نیازمندیها در یک outcome و بازه مشخص است: Must Have، Should Have، Could Have و Won’t Have this time. این چهار برچسب باید انتظار تحویل را روشن کنند؛ اما بهتنهایی ترتیب اجرا، ارزش اقتصادی، هزینه، ریسک، dependency یا ظرفیت را محاسبه نمیکنند.
برای استفاده قابلدفاع، ابتدا هدف/نسخه/موعد و تعریف «قابلاستفاده» را ثابت کنید؛ بعد هر آیتم را با شاهد، پیامد حذف، workaround، dependency، برآورد و صاحب تصمیم ثبت کنید. در پایان نیز بررسی کنید Mustها واقعاً در ظرفیت جا میشوند و Won’tها مقصد/تاریخ بازبینی دارند. این راهنما یک پروتکل جلسه، جدول تصمیم و مثال کامل ارائه میکند.
پاسخ کوتاه: MoSCoW را در هشت گام اجرا کنید
- واحد تصمیم را مشخص کنید: محصول، release، increment، پروژه یا رویداد.
- outcome، کاربران/ذینفعان، deadline، ظرفیت و constraints را اعلام کنید.
- هر نیاز را کوچک، مستقل، قابلآزمون و متصل به evidence بنویسید.
- تعریف چهار دسته و اختیار تصمیم را پیش از رأیگیری توافق کنید.
- برای هر Must، test حذف و امکان workaround را اجرا کنید.
- dependency، ریسک، برآورد و acceptance criterion را کنترل کنید.
- Mustها را با ظرفیت و عدمقطعیت بسنجید؛ اگر جا نمیشوند، scope/time/resource/quality gate را آگاهانه مذاکره کنید.
- خروجی را تصویب، تاریخدار، نسخهدار و در checkpointهای تعیینشده بازبینی کنید.
MoSCoW چیست و چه مسئلهای را حل میکند؟
این روش به تیم اجازه میدهد میان «تحویل تضمینشونده برای این بازه»، «مهم اما قابلجبران»، «مطلوب و منبع انعطاف» و «عمداً خارج از بازه» فرق بگذارد. برای محصول، خدمت، مهاجرت، کمپین یا پروژه داخلی کاربرد دارد؛ به شرط اینکه آیتمها outcome و acceptance روشن داشته باشند. MoSCoW نام شهر نیست؛ حروف o برای خوانایی acronym آمدهاند.
راهنمای GOV.UK درباره تصمیم اولویتها MoSCoW را روشی برای ساخت اجماع معرفی میکند و میگوید تصمیمها باید منظم، با تحلیل عملکرد، پژوهش کاربر و ورودی ذینفعان بازبینی شوند. این توصیه برای خدمات دولت بریتانیاست و قانون/استاندارد جهانی نیست؛ اصل evidence و reprioritisation آن قابلاستفاده است.
پیششرطها: بدون مرز تصمیم، هر چیز Must میشود
| مرز | پرسش لازم | خروجی |
|---|---|---|
| Outcome | این بازه چه تغییر قابلمشاهدهای میسازد؟ | یک جمله outcome و سنجه موفقیت |
| Timebox | اولویت برای کدام release/تاریخ معتبر است؟ | نام بازه و deadline واقعی |
| کاربر/ذینفع | چه کسی اثر حذف یا تأخیر را تجربه میکند؟ | گروهها و نیاز/حق مرتبط |
| ظرفیت | ساعت/بودجه/مهارت/محیط در دسترس چقدر است؟ | range و منابع دارای محدودیت |
| Constraint | قانون، ایمنی، امنیت، قرارداد یا دسترسپذیری چه میخواهد؟ | فهرست gate با مالک تفسیر |
| کیفیت | حداقل قابلقبول و Definition of Done چیست؟ | acceptance و شواهد آزمون |
| اختیار | چه کسی category، trade-off و تغییر را تصویب میکند؟ | decision owner و escalation path |
اگر backlog ترکیبی از ایده، تعهد، reference، انتظار و کار فعال است، پیش از MoSCoW آن را با پروتکل پاکسازی لیست کارها تفکیک کنید. دستهبندی یک ورودی مبهم، فقط ابهام را رنگی میکند.
چهار دسته با آزمون قابلممیزی
| دسته | تعریف برای این بازه | آزمون | مدرک لازم |
|---|---|---|---|
| Must Have | بدون آن deployment/outcome این بازه غیرقابلاستفاده، غیرقانونی یا ناایمن است. | اگر حذف شود، آیا واقعاً release را متوقف میکنیم؟ | constraint، پیامد، acceptance و owner |
| Should Have | مهم است؛ نبودش درد/هزینه معنادار دارد اما راهحل همچنان قابلاستفاده است. | چه workaround موقت و با چه هزینه/ریسکی داریم؟ | اثر، افراد متاثر، workaround و expiry |
| Could Have | مطلوب و ارزشمند است اما نبودش اثر کمتری از Should دارد. | آیا حذفش به core outcome یا gate آسیب نمیزند؟ | ارزش احتمالی، effort و شرط pull |
| Won’t Have this time | عمداً در این بازه تحویل نمیشود. | کجا ثبت، چه زمانی بازبینی و چه triggerی آن را برمیگرداند؟ | reason، destination، review date و owner |
مهمترین واژه در W عبارت «این بار» است. بعضی آیتمها شاید never یا rejected باشند؛ آن تصمیم را جدا و با دلیل ثبت کنید. Won’t پارکینگ بینهایت نیست و نباید هنگام اجرا بیسروصدا به scope برگردد.
Must یعنی شرط قابلیت تحویل، نه «خیلی مهم»
اهمیت، ارزش بالا، صدای بلند ذینفع یا علاقه مدیر یک آیتم را Must نمیکند. سؤال اصلی counterfactual است: اگر این مورد تا پایان timebox نباشد، آیا راهحل موردنظر هنوز با حداقل مورد توافق قابلاستفاده/قانونی/ایمن است؟ اگر workaround واقعی وجود دارد، حتی اگر دردناک باشد، آیتم معمولاً Should یا Could است؛ هزینه workaround به تمایز آن دو کمک میکند.
Must باید acceptance قابلآزمون داشته باشد. «امن باشد»، «سریع باشد» یا «دسترسپذیر باشد» برچسب نیستند؛ threshold و context میخواهند. یک constraint حقوقی/ایمنی را صاحب محصول بهتنهایی تفسیر نکند؛ متخصص واجدصلاحیت scope الزام و شاهد compliance را روشن کند.
برای نمونه، راهنمای تدارکات وزارت دارایی ایرلند شمالی میگوید اگر فرایند خرید در نهایت بدون یک الزام پیش میرود، آن الزام Must نیست و هشدار میدهد Mustهای سخت ممکن است راهحلهای نوآورانه را کنار بزنند. این منبع به procurement عمومی همان قلمرو محدود است و قانون یا الگوی امتیازدهی خرید در ایران نیست؛ test حذف آن برای شفافکردن زبان مفید است.
نیازمندی را پیش از برچسب کوچک و قابلآزمون کنید
آیتم «سیستم پرداخت کامل» احتمالاً چند نیاز با اولویتهای متفاوت را پنهان میکند. آن را بر outcome و acceptance تجزیه کنید: پرداخت یک روش پایه، پیام خطای امن، ثبت تراکنش، refund، چند ارز، کیف پول و توصیه محصول. ممکن است برخی Must، برخی Should و برخی Won’t این release باشند.
راهنمای GOV.UK درباره user story میگوید story باید شخص استفادهکننده و دلیل نیاز را در خود داشته باشد تا برای تصمیم اهمیت داده کافی بسازد. این قالب برای همه requirements اجباری نیست؛ قرارداد، constraint غیرعملکردی و کار فنی ممکن است نمایش دیگری بخواهد، اما actor/need/outcome/evidence همچنان مفیدند.
برگه تصمیم هر آیتم
| فیلد | آنچه ثبت میشود | چرا لازم است؟ |
|---|---|---|
| ID / شرح | نیاز کوچک و outcomeمحور | جلوگیری از تعبیر چندگانه |
| Evidence | پژوهش کاربر، داده، قرارداد، incident یا فرض | تفکیک شاهد از نظر |
| Category / timeframe | M/S/C/W + release/date | اولویت بدون بازه بیمعناست. |
| Impact if absent | اثر بر کاربر، ایمنی، حق، درآمد یا عملیات | پایه Must/Should |
| Workaround | روش موقت، owner، هزینه، ریسک و expiry | کشف Must کاذب |
| Dependency | پیشنیاز/مصرفکننده و priority آن | سازگاری زنجیره تحویل |
| Estimate / uncertainty | range تلاش، مهارت و unknown | آزمون ظرفیت و risk |
| Acceptance / quality | threshold، test و reviewer | جلوگیری از Must اسمی |
| Decision record | owner، تاریخ، dissent و trigger بازبینی | قابلیت پاسخگویی و تغییر |
پنج دروازه پیش از اینکه آیتم را Must بنامید
- Outcome gate: به کدام outcome ضروری این timebox متصل است؟
- Consequence gate: پیامد حذف، مشخص و قابلتأیید است یا فقط «بد به نظر میرسد»؟
- Workaround gate: آیا راه موقت ایمن/قانونی وجود دارد و هزینه/انقضای آن چیست؟
- Dependency gate: آیا این Must به Should/Could تضمیننشده وابسته است؟ اگر بله، تجزیه یا دستهها را اصلاح کنید.
- Capacity gate: آیا همه Mustها با estimate range، کار پنهان، integration/test و buffer در ظرفیت قرار میگیرند؟
وقتی Mustها جا نمیشوند، تیم با نامگذاری مسئله را حل نکرده است. دامنه را بشکنید، threshold را با صاحب اختیار و متخصص بازتعریف کنید، موعد/منبع را مذاکره یا release را متوقف کنید. راهنمای تشخیص کمبود واقعی ظرفیت برای همین trade-off طراحی شده است.
قانون ۶۰/۲۰ را در زمینه DSDM نگه دارید
راهنمای Agile Business Consortium برای یک سناریوی معمول DSDM پیشنهاد میکند effort مربوط به Mustها معمولاً بیش از ۶۰٪ نباشد و حدود ۲۰٪ effort در Couldها منبع contingency باشد؛ خود همان راهنما تأکید میکند exact split را تیم و context تعیین میکنند. چون صفحه اصلی هنگام آزمون مستقیم از این محیط ۴۰۳ داد، آن را لینک منبع نهایی نکردیم و برای تعریفهای قابلدسترسی از راهنمای عمومی GOV.UK استفاده میکنیم.
۶۰٪ قانون طبیعت، KPI تیم یا دستور برای همه پروژهها نیست. denominator باید effort باشد، نه تعداد آیتم. پروژه regulated یا migration اجباری ممکن است توزیع دیگری داشته باشد، اما Must بسیار بالا ریسک پیشبینیپذیری را آشکار میکند. ارقام را بهانه حذف quality/safety/test نسازید.
MoSCoW ترتیب اجرا را تعیین نمیکند
دو Must ممکن است ارزش، risk، dependency و sequence متفاوت داشته باشند. Should پرریسکی که learning لازم برای طراحی Must میسازد شاید زودتر آزمایش شود. پس بعد از دستهبندی، backlog را با هدف، dependency، risk reduction، cost of delay، value و اندازه مرتب کنید.
Scrum Guide رسمی ۲۰۲۰ Product Backlog را emergent و ordered میداند و Product Owner را پاسخگوی ارتباط Product Goal، شفافیت و ordering معرفی میکند؛ MoSCoW بخشی اجباری از Scrum نیست. در Scrum، Developers کار Sprint Backlog را plan میکنند و Definition of Done کیفیت را شفاف میسازد؛ برچسب مدیر نباید estimate یا روش اجرا را دیکته کند.
برای مقایسه ارزش/ریسک/بازده درون یک category از سیستم امتیازدهی ارزش و بازدهی استفاده کنید، اما امتیاز نیز جای constraint، dependency یا judgment پاسخگو را نمیگیرد.
ریسکهای ایمنی و امنیت را به popularity نسپارید
همه ریسکها با «اگر نبود release را متوقف میکنیم؟» حل نمیشوند. threat، likelihood، impact، exposure، detection، legal duty و risk appetite نیاز به تخصص دارند. Developer Guide بنیاد OWASP درباره risk profile شناسایی ریسک، عوامل احتمال و اثر، severity، تصمیم رفع و سفارشیسازی مدل را جدا میکند. این راهنما برای امنیت نرمافزار است؛ به همه حوزهها یا الزام قانونی ایران تعمیم داده نمیشود.
کنترل امنیتی ممکن است Must، بخشی از acceptance یک Must، یا risk treatment بیرون feature backlog باشد. حذف test/monitoring/accessibility/privacy به نام «مشتری نمیبیند» خطاست. risk acceptance باید توسط صاحب اختیار و در چارچوب قانون/قرارداد ثبت شود.
پروتکل جلسه ۶۰دقیقهای
- پیش از جلسه: brief، آیتمهای refined، evidence، estimate range و constraints را بفرستید؛ آیتم تازه بزرگ را همانجا قطعی نکنید.
- دقیقه ۰–۱۰: outcome/timebox/capacity/definitions/decision right را مرور کنید.
- دقیقه ۱۰–۲۰: متخصصان user/technical/operations/legal/safety شکافهای evidence و dependency را علامت بزنند.
- دقیقه ۲۰–۴۵: آیتمها ابتدا فردی دستهبندی و سپس اختلافها با test حذف/workaround بررسی شوند.
- دقیقه ۴۵–۵۵: dependency graph، effort distribution، unknowns و contingency را کنترل کنید.
- دقیقه ۵۵–۶۰: decision owner دستهها، dissent، unresolved، owner اقدام و review trigger را ثبت کند.
اجماع هدف مفید است، اما unanimity اجباری نیست. رأی اکثریت قانون/ایمنی/نیاز کاربر را تعیین نمیکند. مشارکت asynchronous، فرمت قابلدسترسی، زمان آمادهسازی، ناشناسسازی محدود و مسیر اعتراض میتواند سلطه مقام/سرعت گفتار را کمتر کند.
مثال کامل: نسخه نخست سامانه نوبتدهی درمانگاه
فرض آموزشی: outcome «بیمار بتواند از خدمات منتخب وقت معتبر بگیرد و درمانگاه ظرفیت را بدون double booking مدیریت کند». بازه چهار هفته است؛ طبابت، تشخیص و نگهداری پرونده پزشکی خارج از scope این مثالاند و نیازهای قانونی/بالینی باید محلی بررسی شوند.
| نیاز | دسته این release | دلیل/شاهد | کنترل |
|---|---|---|---|
| نمایش slot معتبر و ثبت رزرو اتمیک | Must | بدون آن outcome اصلی رخ نمیدهد. | تست concurrency و عدم رزرو تکراری |
| تأیید رزرو با شماره پیگیری | Must | بیمار/پذیرش باید وضعیت را اثبات کنند. | acceptance برای delivery و fallback |
| لغو نوبت توسط کاربر | Should | اثر عملیاتی بالا؛ پذیرش تلفنی workaround موقت دارد. | هزینه تماس، owner و expiry workaround |
| یادآوری پیامکی | Should | ممکن است عدمحضور را کم کند؛ وابسته به provider/consent. | اندازهگیری، privacy و مسیر opt-out |
| افزودن به تقویم | Could | راحتی بیشتر؛ core booking بدون آن کار میکند. | pull پس از Must/Should و test timezone |
| پیشنهاد هوشمند پزشک | Won’t this time | داده/حاکمیت/ریسک کافی نیست. | discovery جدا با clinical/privacy review |
اگر لغو تلفنی از نظر staffing واقعاً قابلاجرا نباشد، category باید تغییر کند. اگر SMS در contract/قانون یا accessibility مسیر ضروری باشد، دیگر فقط «راحتی» نیست. MoSCoW به context و evidence حساس است؛ مثال، جواب جهانی نیست.
Dependencyها را بعد از دستهبندی فراموش نکنید
یک Must نباید برای کارکرد خود به Could تضمیننشده وابسته باشد. زنجیرهها را رسم کنید: data migration → validation → feature → test → training → rollout. dependency میتواند فنی، قراردادی، دانشی، تأمینکنندهای یا تصمیمی باشد. آیتم enabling کمارزشِ مستقیم ممکن است برای Must ضروری باشد.
برای پروژه چندنفره، مدیریت زمان پروژه گروهی owner، acceptance، dependency، handoff و integration buffer را به برنامه وصل میکند. category بدون این اجزا forecast تحویل نمیسازد.
MoSCoW و MVP را یکی ندانید
Minimum Usable Subset در context DSDM و MVP در product discovery اهداف یکسانی ندارند. MVP ممکن است آزمایشی برای یادگیری یک فرض باشد و لزوماً محصول کامل بازار یا مجموعه همه Mustهای release عملیاتی نیست. prototype نیز ممکن است اصلاً برای استفاده واقعی مجاز نباشد.
روی سند بنویسید منظور شما چیست: prototype، pilot، beta، minimum operational release یا contractual delivery. کیفیت، امنیت، دسترسپذیری و informed consent را بهدلیل واژه «minimum» حذف نکنید. برای هر stage، مخاطب و مجوز استفاده را روشن کنید.
چه زمانی MoSCoW انتخاب خوبی نیست؟
- وقتی باید میان دهها گزینه همرده ranking عددی/ترتیبی دقیق بسازید؛ MoSCoW چهار bucket میدهد.
- وقتی مسئله اصلی triage فوری حادثه یا کار ایمنی است؛ runbook و severity مقدماند.
- وقتی هزینه/منفعت/احتمال/پورتفولیو محور تصمیم است؛ MCDA یا مدل ارزش لازم میشود.
- وقتی backlog مبهم و بدون owner/evidence/estimate است؛ discovery/refinement مقدم است.
- وقتی همه کار قانونی و غیرقابلحذف است؛ اول time/resource/scope-of-compliance را با متخصص حل کنید.
- وقتی مسئله شخصی روزانه است و consequence/نسخه ندارد؛ ماتریس آیزنهاور یا triage ساده ممکن است کمهزینهتر باشد.
تفاوت MoSCoW با ابزارهای نزدیک
| ابزار | پرسش اصلی | خروجی | محدودیت |
|---|---|---|---|
| MoSCoW | انتظار تحویل این timebox چیست؟ | چهار category | ترتیب درون دسته را نمیدهد. |
| ماتریس آیزنهاور | مهم/فوری بودن کار چیست؟ | چهار ربع اقدام | scope محصول و acceptance را مدل نمیکند. |
| ۴D | با ورودی چه کنیم؟ | Do/Delegate/Defer/Delete | ارزش/ریسک release را محاسبه نمیکند. |
| Value scoring | کدام گزینه بازده/ارزش قابلدفاعتری دارد؟ | score/rank | Must حقوقی یا dependency را نباید با امتیاز حذف کند. |
| Kanban class of service | کار چگونه در جریان خدمت میگیرد؟ | policy و pull/expedite | جای discovery و اولویت محصول نیست. |
برای تبدیل دستهها به جریان واقعی، راهنمای کانبان و WIP start/finish، pull و class of service را تعریف میکند. MoSCoW بهتنهایی مجوز شروع همزمان همه Mustها نیست.
تغییر اولویت را کنترل کنید، نه ممنوع
اولویت با تغییر evidence، قانون، incident، market، capacity، dependency یا تاریخ ممکن است عوض شود. تغییر سالم چهار جزء دارد: trigger، تصمیمگیر، اثر بر scope/time/cost/risk و اطلاع به افراد متاثر. category پیشین و reason تغییر را نگه دارید تا تصمیم قابلفهم بماند.
ورودی تازه مستقیماً وارد WIP نشود. ابتدا triage، evidence و trade-off؛ سپس صاحب اختیار مشخص کند چه چیزی جابهجا یا خارج میشود. هزینه/اضافهکاری پنهان را با راهنمای مرزهای مالی و تغییر دامنه آشکار کنید.
پایش پس از جلسه: category را به outcome وصل کنید
- سهم effort هر دسته با range، نه تعداد کارت؛
- Mustهای فاقد acceptance/evidence/owner؛
- dependency ناسازگار و blocked time؛
- تغییر category و دلیل آن؛
- workaroundهای Should با هزینه و تاریخ انقضا؛
- Won’tهایی که بدون تصمیم وارد scope شدهاند؛
- تحویل واقعی outcome/quality، نه صرفاً تعداد Must بستهشده؛
- forecast و ظرفیت؛ نه utilization فردی یا ساعت اضافهکاری بهعنوان موفقیت.
سنجهها برای اصلاح سیستماند. از آنها برای رتبهبندی افراد، سرزنش تیم برآورد یا تشویق پنهان اضافهکاری استفاده نکنید. اگر درصد Must مزمن بالاست، outcome/timebox/governance و ورودی تقاضا را بررسی کنید.
سؤالات متداول
تفاوت Should و Could دقیقاً چیست؟
هر دو برای core outcome این timebox حیاتی نیستند. نبود Should درد/هزینه/ریسک معنادارتری دارد و معمولاً workaround موقت لازم میکند؛ نبود Could اثر کمتری دارد و منبع انعطاف است. معیار مقایسه را پیش از جلسه تعریف و اثر/افراد متاثر را ثبت کنید.
آیا Won’t Have یعنی هرگز انجام نمیدهیم؟
در کاربرد اصلی یعنی «این بار نه». reason، destination، owner، review date و trigger بازگشت را ثبت کنید. اگر تصمیم واقعاً never/rejected است، همان را صریح بنویسید تا backlog قبرستانی و انتظار کاذب ساخته نشود.
آیا باید حتماً Mustها کمتر از ۶۰٪ باشند؟
خیر؛ این عدد recommendation متداول DSDM برای effort و ایجاد contingency است، نه قانون جهانشمول. context، دقت estimate، ریسک و تیم اثر دارند. Must بالا هشدار انعطاف کم است؛ quality/safety را برای رسیدن مصنوعی به درصد حذف نکنید.
اگر همه ذینفعان آیتم خود را Must بدانند چه کنیم؟
رأی محبوبیت نگیرید. outcome، consequence حذف، workaround، dependency، acceptance، estimate و decision right را روی یک برگه بیاورید. آیتم بزرگ را تجزیه کنید. اگر همه Mustها در ظرفیت جا نمیشوند، صاحب اختیار باید trade-off یا تغییر زمان/منبع را تصویب کند.
آیا MoSCoW برای کار شخصی یا خارج از نرمافزار هم مناسب است؟
اگر outcome، بازه، محدودیت و پیامد حذف روشن باشد، بله؛ برای رویداد، مهاجرت، کمپین یا مطالعه کاربرد دارد. برای فهرست روزانه مبهم ممکن است overhead آن زیاد باشد. قانون/ایمنی/حق را با سلیقه bucket نکنید و ابزار سادهتر را در صورت کفایت انتخاب نمایید.
تاریخ بررسی منابع و صفحه: ۲۱ مرداد ۱۴۰۵ (۱۲ اوت ۲۰۲۶). این متن آموزشی است و جای مشاوره حقوقی، قراردادی، امنیتی، ایمنی، دسترسپذیری یا روش رسمی سازمان شما را نمیگیرد.
