یه مهندس حرفه‌ای چطوری می‌تونه با توانایی‌های ذهنیش (و نه با توانایی فیزیکیش) بر جهان تاثیر بذاره؟

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

برای شرکت تو مسابقه تا آخر اکتبر 2010 فرصت دارین.

خیلی‌ها درباره شیوه محاسبه تاخیر تو شرایط مختلف از من می‌پرسن. جواب هم همیشه بستگی داره به شیوه پایش، نوع فعالیت‌ها و …

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

در کنار این مسئله، باز هم از همه یه درخواست تکراری دارم: لطفا از عبارت “تاخیر” فقط برای اشاره به زمان استفاده کنین، بهتره به اختلاف پیشرفت واقعی و برنامه‌ریزی شده بگیم “انحراف”، نه “تاخیر”. این توصیه صرفا به این خاطره که سوتفاهم به وجود نیاد و منظور به خوبی منتقل بشه.

عده‌ای از همکارانمون برای من برنامه‌ای (پراجکتی) فرستاده بودن که دیدم توش تاریخ‌ها با فرمول محاسبه می‌شه. چون این روش ممکنه برای بعضی‌ها به درد بخوره، فرمول‌هاش رو می‌ذارم اینجا. از اون همکاران پرسیدم که فرمول‌ها رو چه کسی تهیه کرده تا اینجا ازش نام ببرم، که متاسفانه اسمش رو نمی‌دونستن. در هر حال با تشکر از این فردی که نمی‌شناسیم.

فرمول تاریخ شروع:

(Int((Int([Start]-DateValue("21/3/1997 00:00:00"))-Int(Int([Start]-DateValue("21/3/1997 00:00:00"))/1461))/365)+76) & "/" & (IIf(((((Int([Start]-DateValue("21/3/1997 00:00:00")))-Int((Int([Start]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))<=186,Int(((((Int([Start]-DateValue("21/3/1997 00:00:00")))-Int((Int([Start]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))/31)+1,Int((((((Int([Start]-DateValue("21/3/1997 00:00:00")))-Int((Int([Start]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))-186)/30)+7)) & "/" & (IIf(((((Int([Start]-DateValue("21/3/1997 00:00:00")))-Int((Int([Start]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))<=186,Int(((((Int([Start]-DateValue("21/3/1997 00:00:00")))-Int((Int([Start]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365)) Mod 31)+1,Int((((((Int([Start]-DateValue("21/3/1997 00:00:00")))-Int((Int([Start]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))-186) Mod 30)+1+(IIf((Int([Start]-DateValue("21/3/1997 00:00:00"))) Mod 1461=0,1,0))))

فرمول تاریخ پایان:

(Int((Int([Finish]-DateValue("21/3/1997 00:00:00"))-Int(Int([Finish]-DateValue("21/3/1997 00:00:00"))/1461))/365)+76) & "/" & (IIf(((((Int([Finish]-DateValue("21/3/1997 00:00:00")))-Int((Int([Finish]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))<=186,Int(((((Int([Finish]-DateValue("21/3/1997 00:00:00")))-Int((Int([Finish]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))/31)+1,Int((((((Int([Finish]-DateValue("21/3/1997 00:00:00")))-Int((Int([Finish]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))-186)/30)+7)) & "/" & (IIf(((((Int([Finish]-DateValue("21/3/1997 00:00:00")))-Int((Int([Finish]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))<=186,Int(((((Int([Finish]-DateValue("21/3/1997 00:00:00")))-Int((Int([Finish]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365)) Mod 31)+1,Int((((((Int([Finish]-DateValue("21/3/1997 00:00:00")))-Int((Int([Finish]-DateValue("21/3/1997 00:00:00")))/1461)) Mod 365))-186) Mod 30)+1+(IIf((Int([Finish]-DateValue("21/3/1997 00:00:00"))) Mod 1461=0,1,0))))

فرمول‌ها رو تو یکی از فیلدهای Text وارد کنین و یادتون هم نره که برای خلاصه فعالیت‌ها گزینه Use Formulas رو انتخاب کنین.

اگه خواستین از چنین روشی استفاده کنین این مسایل رو در نظر داشته باشین:

1. برنامه به شدت کند می‌شه، چون بعد از هر تغییر نتیجه این فرمول‌ها دوباره محاسبه می‌شن. من خودم وقتی قراره با برنامه اون‌ها کار کنم مجبورم محاسبه رو غیر فعال کنم، چون اصلا نمی‌تونم با برنامه‌ای که کند باشه کار کنم و عصبی نشم.
2. محور گانت و کادرهای انتخاب تاریخ و … شمسی نمی‌شن دیگه… بدیهیه.

کلا پیشنهاد می‌کنم برای شمسی کردن تاریخ‌ها از برنامه‌های تجاری مثل پرنیان و ادسافت استفاده کنین.

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

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

در هر حال چنین روش‌هایی این محدودیت‌ها رو دارن:

1. خودکار به‌روز نمی‌شن
2. انجامشون زمان و انرژی زیادی می‌بره
3. تو جاهایی مثل محور گانت به کار نمی‌رن

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

چون کتاب راهنمای جامع Microsoft Project 2010 رو آماده کرده بودم، کتاب قبلی تجدید چاپ نشد. ولی چاپ کتاب جدید هم بیشتر از انتظار طول کشید، چون انتشارات دیباگران تعداد زیادی کتاب داشت که به دلایلی اولویت بالایی داشتن و روند عادی کتاب‌های دیگه رو به هم زدن.

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

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

تعاریف:

تاخيرات پروژه: تقاضل زمان پايان واقعی و پايان قراردادی پروژه

تاخيرات = تاخيرات مجاز + تاخيرات غير مجاز

تأخيرات غير مجاز: تأخيرات ناشی از قصور پيمانكار، مانند تعلل در انجام فعاليت‌ها در زمان برنامه‌ريزی شده يا تاخير در شروع يا پايان فعاليت‌ها.

تأخيرات مجاز: تأخيرات ناشی از قصور كارفرما، مانند تغيير نقشه‌های اجرايی و ابلاغ دستوركارهای جديد.

در خصوص عواملی مانند شرايط نامناسب جوی و تعطيلات رسمی كه خارج از اختيارات طرفين می‌باشد، لازم است در قرارداد تمهيدی شده باشد كه آيا جزو تاخيرات مجاز محسوب خواهد شد يا اينكه لازم است پيمانكار برنامه‌اش را با ملاحظه اين موارد تنظيم كرده باشد.

تسهيم تاخيرات مجاز و غير مجاز هم در خلال پروژه و هم در پايان پروژه اهميت دارد. از آنجا كه پيشرفت پروژه در حين اجرا هميشه با توجه به برنامه پروژه محاسبه شده و با مبنای برنامه زمانبندی قياس می‌شود و معيار تسريع و تأخير پيمانكار جلو يا عقب بودن از برنامه زمانبندي است، دقيق و معتبر بودن اين مبنا اهميت ويژه‌اي دارد. تسهيم تأخيرات و اعمال تأثير تآخير مجاز در برنامه موجب اصلاح مبنای محاسبه پيشرفت خواهد شد.

تأخیرات غیرمجاز از کسر تأخیرات مجاز از کل تأخیرات به دست می‌آید و آنچه محل بحث میان کارفرما و پیمانکار است میزان و تأثیر تأخیرات مجاز در برنامه زمانبندی می‌باشد.

طبقه‌بندی‌های تاخیرات مجاز:

تاخیرات مجاز را می‌توان بر حسب نوع به گروه‌های زیر تقسیم کرد:

1. افزايش احجام كارهای موجود در برنامه زمانبندی؛ مانند افزايش حجم خاكبرداری يا خاكريزی.
2. افزايش فعاليت‌های جديد به برنامه؛ مانند اضافه شدن فضای جديد به فضاهای قبلی پروژه
3. تاخير در ابلاغ نقشه‌ها و تعيين تكليف ديتيل‌های اجرايی از جانب كارفرما.
4. تامين نشدن پيش‌نياز‌هايی كه بر عهده كارفرما است.

می‌توان تاخیرهای مجاز را بر حسب زمان بروز تاخیر به گروه‌های زیر تقسیم کرد:

1. تاخيرهایی كه تاريخ تأثيرشان مستقل از زمان وقوع آنهاست؛ مانند افزايش احجام. تأثير اين‌گونه تأخيرات در آخرين برنامه زمانبندي مبنا ملاحظه می‌شود؛ به طور مثال به نسبت افزايش حجم كار، زمان افزايش پيدا می‌كند.
2. تاخيراتی كه تاريخ تاثيرشان وابسته به زمان وقوع آنهاست؛ مانند تغيير نقشه‌های اجرايی. تاثير اين‌گونه تاخيرات با توجه به واقعيت اجرا ملاحظه می‌شود. به طور مثال شرايط نامناسب جوی با توجه به اينكه كار در كدام مرحله اجرا است ممكن است جزو تأخيرات مجاز يا غير مجاز درنظر گرفته شود. مثال ديگر تاخير در تعيين تكليف ديتيل‌های اجرايی است كه هم‌اكنون استعلام شده، زمان تاخير جواب كارفرما از زمان استعلام پيمانكار  (با احتساب فرجه زمانی پاسخ) محاسبه می‌شود نه از زمان شروع آيتم در برنامه زمانبندی مبنا.

می‌توان تاخیرها را بر حسب قرار داشتن یا نداشتن در مسیر بحرانی نیز گروه‌بندی کرد:

1. تاخیراتی که مسیر بحرانی پروژه را متاثر می‌کنند.
2. تاخیراتی که مسیر بحرانی را تحت تاثیر قرار نمی‌دهند.

مسأله ما تعیین تاخیرات مجاز و غیر مجاز نیست، بلکه تعیین نحوه تاثیر تاخیرات مجاز در برنامه زمانبندی و تاثیر زمانی آن در مدت پروژه است.

علی القاعده برنامه زمانبندی هر پروژه از اسناد منضم به پیمان است. لذا هر تغییری در مدت پیمان باید بر مبنای برنامه زمانبندی اولیه باشد.

نحوه تاثیر تاخیرات مجاز در برنامه

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

کارفرما تا چه حد می تواند انتظار افزایش منابع و انجام کار جدید در موعد قبلی را داشته باشد؟

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

آیا بخش‌نامه، آئین‌نامه یا قانون مدونی برای محاسبه تاثیر تاخیرات مجاز وجود دارد یا خیر؟ من بجز دستورالعمل 5090 سازمان برنامه كه البته آن هم در مورد تمديد زمان پروژه در مقابل تاخير پرداخت‌های كارفرما است، چيزي نديده‌ام.

پایان متن آقای بیگلر

یه توضیح کوچیک…

توجه داشته باشین که تو این متن هم گفته شده “فعالیت‌هایی که بر مسیر بحرانی تاثیر می‌ذارن”، نه “فعالیت‌هایی که تو مسیر بحرانی هستن”، چون ممکنه فعالیتی تو مسیر بحرانی نباشه، ولی تاخیرش باعث بشه که مسیر بحرانی جابجا بشه و اون فعالیت روی تاریخ پایان اثر بذاره. راه پیدا کردنش چیه؟ ساده‌ترین راه اینه که تمام فعالیت‌هایی که تاخیر دارن رو وارد کنین.

پی‌نوشت:

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

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

در مورد سوال دوم، هر افزایش کاری به منزله افزایش مدت زمانه، مگر این‌که طرفین توافق دیگه‌ای بکنن. مثلا ممکنه زمان پایان تو پروژه‌ای اهمیت زیادی داشته باشه و در نتیجه کارفرما به جای این‌که زمان پیمانکار رو به تناظر کارهای اضافه بالا ببره، باهاش توافق کنه که تسهیلات دیگه‌ای به اون بده؛ مثلا پول بیشتری بده که پیمانکار بتونه باهاش شیفت شب راه بندازه و کارهای اضافه رو تو همون بازه قبلی انجام بده.

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

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

بعد از انتشار این مطلب آقای صادق‌فر به من ایمیل دادن و این مطلب خودشون رو که در این خصوص بود معرفی کردن:

محاسبه تاخیر واقعی پروژه

راستش من وقتی ایشون این مطلب رو نوشتن خواستم براشون کامنت بذارم و نظر خودم رو بگم، ولی سایتشون مثل مال خودم کامنت نداره. نظر من این بود:

1. استفاده از عبارت “تاخیر” برای اشاره به تفاضل پیشرفت برنامه‌ریزی شده و واقعی مناسب نیست و سوتفاهم ایجاد می‌کنه. بهتره “تاخیر” برای مدت زمان به کار بره و برای اشاره به تفاضل پیشرفت واقعی و برنامه‌ریزی شده بگیم “انحراف پیشرفت” یا “انحراف پروژه”.
2. ملاحظاتی که مبنای متن ایشون قرار گرفته کاملا به‌جاس، ولی راه حل، همون‌طوری که خودشون هم گفتن، زیاد دقیق نیست، چون پیشرفت برنامه‌ریزی شده رو خطی فرض می‌کنه و در عمل این‌طور نیست؛ به خصوص که معمولا وقتی از تاریخ پایان برنامه‌ریزی گذشته باشیم معمولا واقعیت هم در یک سوم یا یا چهارم پایانیِ برنامه‌ریزیه، یعنی جایی که دیگه شیب پیشرفت داره کم می‌شه، در نتیجه جواب‌های روشی که توضیح دادن خوشبینانه‌تر از اون چیزی می‌شه که باید باشه. روش رایج اینه که زمان کسب شده (earned schedule) رو محاسبه کنیم. مثلا پروژه‌ای رو فرض کنین که 10 ماهه بوده، الان ماه 12 هستیم و پیشرفت 80٪ شده. زمانی که صرف کردیم 12 ماهه. حالا می‌ریم ببینیم کجا پیشرفت برنامه‌ریزی شده 80٪ بوده؛ مثلا ماه 7. تو این حالت زمان کسب شده 7 ماهه و زمان واقعی 12 ماه، یعنی ما تو 12 ماه کاری رو کردیم که می‌بایست تو 7 ماه کرده باشیم. در نتیجه عملا به اندازه 5 ماه عقب افتادیم. از طرف دیگه می‌شه حساب کرد که وقتی ما کار 7 ماه رو تو 12 ماه انجام دادیم، اگه تناسب بگیریم کار 10 ماه رو (یعنی کل پروژه) در 17 ماه انجام خواهیم داد. به عبارت دیگه احتمالا پروژه با 7 ماه تاخیر تموم خواهد شد.

ترجمه کتاب راهنمای آزمون PMP تموم شد، اون هم سر وقت. خیلی سخت بود که به موقع تمومش کنم، چون خیلی دیرتر از برنامه شروعش کرده بودم. مجبور شدم دو ماه تمام پنجشنبه‌ها و جمعه‌هامو کار کنم (من پنجشنبه‌ها و جمعه‌ها به ندرت کار می‌کنم) و 16 روز هم علاوه بر اون‌ها از خونه بیرون نرم و صرفا به کتاب برسم. کارهایی که برای به موقع تموم کردن کتاب کردم برام هزینه‌ای حدودا به اندازه 65٪ درآمد کتاب داشتن.

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

حالا احتمالا دو هفته استراحت می‌دم و بعد می‌رسم سراغ کارای بعدی. الان تقریبا برای تالیف‌ها و ترجمه‌های دو سال آیندم برنامه ریختم. کتاب بعدی درباره مدیریت ارزش کسب شده‌س. یه کتاب بی‌نظیره از انتشارات Springer. من از زمانی که فوق لیسانس فلسفه علم می‌خوندم با این انتشارات آشنا شدم. کتاب‌های خیلی دقیق، جامع و معتبری داره. کتاب تحلیل ارزش کسب شده‌ش تمام این نکات مثبت رو داره، به اضافه این که توش جنبه‌های کاربردی رو هم در نظر گرفتن. کتاب کاملا جامع و به‌روزه (چاپ اواخر 2009)، طوری که حتی یه فصل درباره تحلیل زمان کسب شده (earned schedule) هم داره.

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

تا حالا شده فایل پراجکتی به دستتون برسه که توش قالب‌بندی تمام عناصر نمای گانت (یا نمایی دیگه) رو عوض کرده باشن و قالب‌بندیشون هم به نظرتون جالب نباشه؟

منظورم فونت‌هاییه که هرکدوم یه اندازه‌ای هستن، رنگ‌های عجیب و غریب، بولد بودن‌های بی‌دلیل و …

اگه سعی کرده باشین قالب‌بندی رو به حالت معمولی برگردونین قطعا می‌دونین که کار وقت‌گیر و سختیه. راه ساده؟

بله، راه ساده هم داره؛ امروز اتفاقی وقتی می‌خواستم قالب‌بندی یه برنامه‌ای رو درست کنم به نظرم رسید.

منطق قالب‌بندی در پراجکت:

قبلش باید این رو توضیح بدم. پراجکت تمپلیتی داره به اسم global.mpt و تمام قالب‌بندی‌ها توی اون ذخیره می‌شن. اون نمای گانتی که تو فایل‌های جدید می‌بینین از اون تمپلیت میاد.

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

شیوه بازیابی قالب‌بندی پیش‌فرض:

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

برای این کار Tools| Organizer رو اجرا کنین. تو این پنجره دو قسمت هست که یکیش global.mpt رو نشون می‌ده و اونیکی فایلی که باز شده. اسم‌ها رو پایین کادر ببینین.

زبانه Views رو انتخاب کنین و Gantt رو از کادر global.mpt کپی کنین تو کادر فایل. حالا برین تو زبانه Tables و entry رو هم کپی کنین تو فایل.

با این کار نمای گانتتون می‌شه مثل همونی که تو فایل‌های جدید باز می‌شه.

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

با همین روش می‌تونین هر نمایی که دوست داشتین رو بازیابی کنین.

اخطار مهم!

وقتی می‌خواین نما رو کپی کنین مراقب باشین که از global.mpt کپی بشه تو فایل، اگه برعکس نما رو از فایل کپی کنین به global.mpt، قالب‌بندی پیش‌فرض تغییر می‌کنه و نه تنها این فایل درست نمی‌شه، که هر فایل جدیدی هم که بخواین بسازین با همون قالب‌بندی‌ای که دوست نداشتین ساخته می‌شه!

راه حل؟ یه راه اینه که global.mpt یه کامپیوتر دیگه رو کپی کنین به جای این. یه راه دیگه هم اینه که یه فایل جدید تو کامپیوتر دیگه‌ای بسازین و بیارینش تو کامپیوتری که به هم ریختین، با همین روشی که گفته شد دوباره کپی کنینش روی global.mpt.

نکته:

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

مثلا اگه برنامه منبع داشته باشه، همیشه نگاه می‌کنم ببینم کسایی که فایل رو تهیه کردن از نمای Resource Graph هم استفاده کردن یا نه. اگه نکرده باشن به نظر من معنیش اینه که درست و حسابی به منابع توجه نکردن.

تا حالا اصطلاح Halo Effect رو شنیدین؟ می‌شه ترجمه‌ش کرد به اثر هاله نور.

قبلش یه سوال می‌پرسم. به نظر شما مدیر پروژه چه تخصصی‌هایی باید داشته باشه؟

جواب خیلی ساده‌س، تخصص در مدیری پروژه؛ همین.

کسی می‌تونه مدیر پروژه باشه که در مدیریت پروژه تخصص داشته باشه. ساده‌تر از این؟

تخصص فنی تو حوزه پروژه چطور؟ خوب، اگه باشه بهتره، ولی نبود هم نبود. مثلا اگه پروژه ساختمانیه، اجباری نیست که مدیر پروژه متخصص ساخت و ساز باشه، ولی حتما باید مدیریت پروژه بدونه.

این می‌شه گرایش PMI و همه سیستم‌های حرفه‌ای دیگه‌ای که من تا حالا دیدم.

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

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

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

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

Halo Effect خیلی جاها وجود داره. یه چیزیه نزدیک به اونی که تو فارسی می‌گیم فرافکنی. کسی تو یه حوزه کاری وارده، اونوقت فکر می‌کنیم که تو چیزهای دیگه هم تخصص داره. مثلا یه نفر برنامه‌نویس خیلی خوبیه، بعد فکر می‌کنیم اگه عکاسی کنه عکاس خیلی خوبی هم خواهد بود، بدون این‌که عکاسی اون آدم رو بررسی کنیم. انگار وقتی کسی تو یه حوزه خوب بود، هاله‌ای از نور (halo) اون رو احاطه می‌کنه و باعث می‌شه که به همه چیزهای دیگه هم مسلط باشه.

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

2. تو جلسه‌ای که دستور جلسه مشخصی نداره شرکت نکنین.