اون ماجرای مثلث پروژه و محدودیت‌های سه‌گانه رو که حتما می‌شناسین: گستره، زمان، هزینه… کیفیت رو هم خیلی وقت‌ها بهش اضافه می‌کنن و در عین حال بازم سعی می‌کنن مثلث نگهش دارن.

به هر حال، یکی از تفاوت‌های عمده‌ای که تو رویکرد چابک Atern به پروژه هست رو می‌شه روی همین مثلث توضیح داد:

تو پروژه‌های کلاسیک گستره رو ثابت نگه می‌داریم. مثلا قراره یه بیمارستان بسازیم، گستره‌ش ثابته… یه بیمارستان کامله، با تعداد طبقه و زیربنای مشخص و مصالح تعیین شده و امثال اون‌ها. با هزینه و زمان طوری بازی می‌کنیم که به اون گستره برسیم. سعی می‌کنیم هزینه و زمان رو محدود نگه داریم، ولی اگه ببینیم مثلا وقت کم داریم، معمولا گستره رو کوچیک نمی‌کنیم (مثلا یه طبقه بیمارستان رو حذف کنیم، یا تاسیسات مکانیکیش رو بذاریم کنار)، یا بیشتر هزینه می‌کنیم، یا زمان بیشتر مصرف می‌کنیم. کیفیت رو سعی می‌کنیم ثابت نگه داریم، ولی خیلی وقت‌ها مجبور می‌شیم برای رسیدن به گستره کیفیت رو هم قربانی کنیم.

تو رویکرد چابک اترن (DSDM Aten) برعکس عمل می‌کنیم، یعنی هزینه و زمان و کیفیت رو از ابتدا مشخص و ثابت می‌کنیم و گستره رو کم و زیاد می‌کنیم.

به نظرتون عجیب میاد، نه؟ مثلا یه پیمانکار با کارفرماش قراردادی می‌بنده که توش مدت زمان و هزینه و کیفیت کار به دقت مشخص شده، ولی گستره کار اجازه داره که تغییر کنه!

کاری که با گستره می‌کنیم اینه که با تکنیک اولویت‌بندی مسکو مدیریتش می‌کنیم:

MoSCoW Prioritization

حروفی که تو مسکو (MoSCoW) هستن ابتدای این عبارت‌هان:

• Must have – اون بخش‌هایی از گستره که حتما باید تولید بشن و اگه نباشن محصول نهایی پروژه اصلا به درد نمی‌خوره.
• Should have – اون بخش‌هایی از گستره که واقعا بودنشون لازمه، ولی اگه نباشن باز هم می‌تونیم از محصول نهایی پروژه استفاده کنیم، فقط ممکنه لازم باشه یه راه حل‌های جانبی برای بعضی کمبودها در نظر بگیریم.
• Could have – اون بخشی از گستره که خیلی خوشمون میاد تو محصول نهایی باشه، ولی نباشه هم اتفاقی نمی‌افته.
• Won’t have this time – اون چیزهایی که فعلا قصد نداریم تو محصول نهایی پروژه باشه؛ هرچند که ممکنه به نظر مرتبط بیاد.

پس محصول ما به هر حال باید همه Mustها رو داشته باشه. اگه متوجه بشیم که نمی‌تونیم همه Mustها رو تو زمان و با هزینه و کیفیت مشخص شده تکمیل کنیم، پروژه رو لغو می‌کنیم. اگه محصول نهایی فقط Mustها رو داشته باشه، می‌شه محصولی حداقلی که نیازهای اصلی رو برآورده می‌کنه (minimum viable product).

برعکسش، اگه محصول همه Mustها و Shouldها و Couldها رو داشته باشه، می‌شه محصول ایده‌ال.

انتظار ما اینه که محصول نهایی همه Mustها و همه Shouldها رو داشته باشه؛ یعنی از ابتدا که گستره رو تعیین می‌کنیم و عناصرش رو علامت‌گذاری می‌کنیم، انتظارمون رو می‌ذاریم روی انجام این بخش و بر این اساس هزینه و زمان رو مشخص می‌کنیم. اگه وقتی کار پیش می‌ره بتونیم، اون رو از این انتظار اولیه می‌بریم به سمت ایده‌ال و تمام گستره رو کامل می‌کنیم و اگر هم برعکس به مشکل بخوریم، اون رو از این انتظار اولیه می‌بریم به سمت نسخه حداقلی که فقط Mustها رو تولید می‌کنه. ولی به هر حال زمان و هزینه و کیفیت ثابته.

از این روش تو پروژه‌هایی استفاده می‌شه که:

• تغییرات و عدم قطعیت زیاد باشه
• و تا وقتی کارفرما بخش‌هایی از کار رو ندیده باشه نتونه انتظارهای خودش رو به روشنی مشخص کنه

که عمدتا می‌شه:

• پروژه‌های نرم‌افزاری
• پروژه‌های تحقیقاتی
• پروژه‌های تغییر سازمانی

پروژه‌های تغییر سازمانی چیزهایی مثل راه‌اندازی سیستم مدیریت اسناد تو یه سازمانن. اگه زمانی مسئول بودین چنین پروژه‌ای رو رهبری یا مدیریت کنین حتما به استفاده از تکنیک مسکو فکر کنین، چون یه مشکل اساسی تو اینجور پروژه‌ها اینه که قسمت زیادی از وقت رو صرف قابلیت‌های بامزه‌ای که حیاتی نیستن می‌کنیم و در عوض قابلیت‌های حیاتی دچار مشکل می‌شن.

ایده‌ای که پشت همه این‌ها هست همون قاعده ۲۰/۸۰ هست؛ این‌که حدود ۸۰ درصد ارزش محصول نهایی پروژه با حدود ۲۰ درصد گستره اون ایجاد می‌شه. پس چرا:

1. زیاد از حد زمان و هزینه رو صرف گستره‌ای کنیم که ارزش خیلی زیاد تولید نمی‌کنه؛ خصوصا تو پروژه‌های نرم‌افزاری که چرخه عمر محصولش خیلی کوتاهه.
2. حواسمون باشه که توجهی که باید صرف عناصر پر ارزش بشن رو صرف عناصر کم ارزشی که جلب توجه می‌کنن نکنیم.

البته خوب، شکی نیست که تو هر نوع پروژه‌ای نمی‌شه این کار رو کرد، یا حداقل خیلی سخت می‌شه. مثلا تو پروژه احداث یه بیمارستان به این راحتی نمی‌شه گستره رو با تکنیک مسکو دسته‌بندی کرد.