پروفایل برنامه ریزی و کنترل پروژه

نادر خرمی راد

ایراد زیاد بودن شناوری چیه؟

خیلی از استانداردها و منابعی که در مورد زمان‌بندی نوشته شدن درباره شناوری‌های زیاد از حد نوشتن. این‌که شناوری‌ها نباید از حدی بیشتر باشه یکی از ۱۹ قاعده‌ایه که تو کتاب قواعد زمان‌بندی پروژه هم توضیح دادم.

بعد از انتشار کتاب، خیلی از خواننده‌های ایرانی و تعدادی از خواننده‌های غیر ایرانی از من درباره‌ش سوال کردن و به این نتیجه رسیدم که توضیحات بیشتری به ویرایش بعدی کتاب اضافه کنم؛ ولی تا اون زمان این مطلب رو نوشتم که برای همه توضیح داده باشم.

 

زیاد بودن شناوری به خودی خود هیچ مشکلی ایجاد نمی‌کنه. شناوری‌های زیاد از حد دلیل ایجاد مشکل نیستن، ولی نشونه‌ایه که به ما می‌گه احتمالا جای دیگه‌ای مشکلی وجود داره. مثل این می‌مونه که یه دکتر مثلا نشونه‌ای رو روی ناخن شما ببینه و مشکوک بشه. اون نشونه روی ناخن به خودی خود مشکلی برای شما ایجاد نمی‌کنه (مگر این‌که خیلی حساس به ظاهرتون باشین)، ولی ممکنه جای دیگه‌ای مشکل مهمی داشته باشین و به همین خاطر باید ماجرا رو بررسی کرد.

 

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

 

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

نوشته نادر خرمی راد (Nader Khorrami Rad)

تاریخ‌های موثر در شناوری

همیشه می‌گیم شناوری کل مدت زمانیه که اگه فعالیت به اون اندازه به تاخیر بیفته تاریخ پایان پروژه رو به تاخیر نمیندازه. این تعریف خیلی قدیمیه و باید تعریف کامل‌تری به جاش به کار ببریم.

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

 

تاریخ‌های مهم این‌ها هستن:

  1. تاریخ پایان پروژه
  2. تاریخ پایان فعالیت‌هایی که پس‌نیاز ندارن (توضیح 1)
  3. فرجه‌ها
  4. تاریخ قیدهایی که انعطاف‌پذیر نیستن

 

توضیح 1: وقتی تاریخ پایان فعالیت‌هایی که پس‌نیاز ندارن در تعیین شناوری‌ها مبنا قرار می‌گیره که گزینه Calculate Multiple Critical Tasks رو تو Tools| Options| Calculation فعال کرده باشین.

حالا ماجرا رو با هم مرور می‌کنیم. برنامه شکل زیر رو ببینین:

image

تو این برنامه سه گروه فعالیت تعریف کردم. هر گروه دو فعالیت داره که با هم لینک هستن. می‌شد مسئله رو روی فعالیت‌های تکی هم نشون داد، ولی من گروه‌های دوتایی استفاده کردم تا سرایت کردن شناوری‌ها رو به عقب هم نشون بدم. برای هرکدوم از این سه گروه نقشه‌هایی کشیدم.

گروه اول طولانی‌ترین مدت زمان‌ها رو دارن و به همین خاطر بحرانی شدن. فعالیت‌های بحرانی تو این نما با رنگ قرمز دیده می‌شن. شناوری کل فعالیت‌ها هم با خط‌های سبز رنگ باریک نشون داده شدن. الان چهارتا فعالیت آخر شناوری کل دارن. مقدار شناوری کل رو می‌تونین تو جدول هم ببینین.

برای فعالیت چهارم فرجه‌ای در پایان روز 9 قرار می‌دم. وضعیت اینطوری می‌شه:

image

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

حالا به فعالیت ششم قید Finish No Later Than برای پایان روز نهم می‌دم:

image

تو این حالت هم شناوری فعالیت ششم و پیش‌نیازش به طور متناسب کم شد. واقعیت اینه که چنین قیدی تفاوت چندانی با فرجه نداشت.

حالا به شکل بالایی نگاه کنین و تصور کنین که وقتی فرجه رو به پایان روز هشتم بکشیم. شناوری فعالت چهارم چقدر می‌شه؟ اگه اون رو به پایان روز هفتم بکشیم چطور؟ بله، در این حالت شناوری کل فعالیت صفر می‌شه و اون فعالیت همراه با پیش‌نیازش بحرانی می‌شن.

حالا باز هم تصور کنین که فرجه رو عقب‌تر بکشیم، مثلا پایان روز ششم. در این حالت شناوری فعالیت چقدر می‌شه؟

image

این هم همون شناوری منفیه که هر هفته چند نفر با جستجوی اون به سایت من می‌رسن! مفهوم پیچیده‌ای نیست، هست؟

تو این وضعیت فعالیت چهارم اگه طبق برنامه پیش بره هم یکی از تاریخ‌های مهم پروژه یک روز به تاخیر می‌افته، یعنی فعالیت باید یک روز کمتر از برنامه وقت ببره تا تاریخ حفظ بشه. یک روز کمتر، یعنی شناوری منفی یک.

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

image

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

وقتی بین قید و روابط تناقض وجود داشته باشه تکلیف چیه؟

پیش‌فرض اینه که قید مبنا قرار بگیره.

حالا می‌تونین برین تو Tools| Options| Schedule و گزینه Tasks will always honor their constraint dates رو غیر فعال کنین. حالا اگه تناقضی بین قید و روابط وجود داشته باشه اولویت به روابط داده می‌شه. این هم می‌شه وضعیت همون برنامه قبلی، بعد از تغییر تنظیم:

image

خوب، حالا من قید و فرجه رو برمی‌دارم، یعنی وضعیت برنامه می‌شه مثل اولین شکلی که دیدین (بد نیست الان برگردین بالا و نگاهی بهش بندازین). حالا می‌رم به Tools| Options| Calculate و گزینه Calculate multiple critical paths رو فعال می‌کنم. نتیجه این می‌شه:

image

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

به هر حال؛ اگه بیشتر از یک فعالیت پس‌نیاز مستقیم یا غیر مستقیم داشته باشن، در حالت معمول به جز یکیشون همه شناوری می‌گیرن. حالا فرض کنین پروژه‌ای داریم از 10 بلوک ساختمانی. تاریخ پایان هرکدوم از بلوک‌ها پس‌نیازی نداره، و در عین حال ترجیح می‌دیم که هر بلوک در زودترین زمان ممکن تموم بشه و شناوری براشون نذاریم. در این صورت می‌تونیم این گزینه رو فعال کنیم، در نتیجه شناوری فعالیت‌های آزاد حذف می‌شه و به پیش‌نیازهاشون هم منتقل می‌شه. به این ترتیب احتمالا مسیرهای بحرانی جدیدی هم ایجاد می‌شه. خوب، این وضعیت رو می‌تونین تو شکل بالا هم ببینین.

خوب، من امیدوارم این مطالب رو به شما منتقل کرده باشم:

  • تنها تاریخ مقدسی که برای محاسبه شناوری‌ها به کار می‌ره تاریخ پایان پروژه نیست.
  • شناوری منفی با ……. به وجود میاد. با چی؟
  • مسیرهای بحرانی متعدد با مقید کردن فعالیت‌های آزاد به وجود میاد.
نوشته نادر خرمی راد (Nader Khorrami Rad)

قالب‌بندی سریع در پراجکت 2010

یه ابزارهایی هم اضافه شدن که نتیجه‌شون چیز جدیدی نیست، قبلا هم بوده، ولی الان با یه کلیک می‌شه به اون نتیجه رسید و قبلا با مثلا 20تا کلیک.

Bar Formatting

اون Format همون کادر محاوره قدیمی رو باز می‌کنه؛ کادر محاوره‌ای که باهاش نمودار گانت رو قالب‌بندی می‌کردیم.
اون سه‌تا گزینه این‌طوری‌ان:
Critical Task: فعالیت‌های بحرانی رو با میله‌های قرمر نشون می‌ده
Slack: شناوری کل فعالیت‌ها رو با میله‌های باریکی که در ادامشون کشیده می‌شه نشون می‌ده
Late Tasks: فعالیت‌های به تاخیر افتاده رو با رنگ متمایز نشون می‌ده

اون گزینه Slack خیلی کاربردیه. بهتره در مراحل نهایی برنامه‌ریزی اون رو فعال کرد و شناوری‌های فعالیت‌ها رو کنترل کرد. فعالیت‌هایی که شناوری‌های خیلی زیاد دارن مشکوکن؛ ممکنه یه نقصی تو روابطشون باشه.

اون دوتا دکمه آخر هم اینا هستن:
Baseline: مقادیر خط‌مبنا رو با میله‌های باریک‌تری که روی میله‌های زمان‌بندی ترسیم می‌شن نشون می‌ده؛ خیلی با سلیقه و خوب.
Slippage: خطی از شروع خط‌مبنا (شروع برنامه‌ریزی شده) تا شروع زمان‌بندی شده، یعنی شروع فعلی، رسم می‌کنه. با این کار تاخیرهایی که به وجود اومده مشخص می‌شه.

نوشته نادر خرمی راد (Nader Khorrami Rad)

شناوری منفی

خیلی‌ها با مفهوم شناوری منفی مشکل دارن. به‌تازگی ایمیلی گرفتم که در این مورد پرسیده بود و چون قصد دارم از این به بعد جواب سوال‌هایی که با ایمیل ازم پرسیده می‌شه و فکر می‌کنم که به درد بقیه می‌خوره رو ایجا بذارم، متن پاسخ رو کپی می‌کنم:

شناوری منفی یه جور تناقض برنامه‌ریزیه که به خاطر محدود کننده‌های متناقض به وجود میاد. مثلا رابطه‌ای وجود داره که ایجاب می‌کنه فعالیت در تاریخی تموم بشه، ولی یه فرجه برای تاریخی جلوتر تنظیم شده یا قید سختی هست که ایجاب می‌کنه فعالیت قبل از اون تاریخ تموم بشه. تو این حالت شناوری فعالیت منفی می‌شه و این شناوری منفی می‌تونه به وابسته‌هاش هم منتقل بشه.

(برای کسب اطلاعات بیشتر به فصل 9 کتاب راهنمای جامع Microsoft Project 2007 مراجعه کنید).

نوشته نادر خرمی راد (Nader Khorrami Rad)
اشتراک مطالب سایت

با اشتراک در فرم زیر مطالب جدید برایتان ایمیل می‌شوند:

اشتراک مطالب در تلگرام