بعضی اصطلاح‌های مربوط به PMI برای خیلی‌ها سوتفاهم ایجاد می‌کنه، به خصوص به خاطر بعضی از تبلیغات. به همین خاطر بعضی‌هاشون رو می‌خوام توضیح بدم.
PDU
PDU واحدهایی از تلاش حرفه‌ای شما تو یادگیری مدیریت پروژه یا یاد دادن اونه. این کار می‌تونه با شرکت تو دوره‌های آموزشی، سمینارها، مطالعه، تدریس و امثال اون‌ها باشه. کسایی که گواهی‌های PMI رو دارن باید چند وقت یه بار با ارائه تعداد مناسبی PDU اون‌ها رو تمدید کنن.
Contact Hour
Contact Hour به مدت زمانی گفته می‌شه که دوره آموزشی خاصی دیدین و پیش‌نیاز شرکت تو آزمون‌هایی مثل PMP هست. هر نوع آموزشی که شرایط مشخصی رو داشته باشه منجر به صدور Contact Hour می‌شه، حتی تعداد ساعتی که مثلا سرپرست کنترل پروژه‌ای که تو اولین تجربه کاری‌تون داشتین به شما آموزش داده. شرایط اینه که گستره مطلبش مطابق با آزمون باشه (مثلا برای آزمون PMP باید تمام حوزه‌های دانش رو پوشش داده باشه) و اگه حضوری نبوده حتما آزمون هم داشته بوده باشه.
R.E.P.
R.E.P، مخفف Registered Education Provider، به موسسه‌ای گفته می‌شه که حداقل‌هایی کیفی رو داشته باشه، دوره‌هاش مطابقت کافی با دستورالعمل‌های PMI داشته باشه و حداقل یک سال هم از فعالیتش گذشته باشه و در نهایت هم برای R.E.P شدن اقدام کرده باشه و پذیرفته شده باشه. ماجرای R.E.P. بودن اینه که PDUها و Contact Hourهاش بدون بررسی خاصی تایید …
بعد از برنامه‌ریزی‌ها و فکرهای زیاد تکلیف کتاب راهنمای جامع پراجکت ۲۰۱۳ مشخص شد و چند روزیه که کارش رو شروع کردم.
خبر خوب اینه که این کتاب به دو صورت منتشر می‌شه:
به صورت ایبوک، در کنار سایر کتاب‌های الکترونیکی مدیریت پروژه
به صورت چاپی، از طریق انتشارات دیباگران
حجم کتاب به خاطر قابلیت‌های جدید پراجکت تو ترسیم انواع نمودارها یه مقدار اضافه می‌شه و چون هزینه چاپ کتاب خیلی زیاد شده، برای این‌که نسخه چاپی زیاد از حد گرون نشه دو بخش رو از اون حذف می‌کنم:
مرجع فیلدهای پراجکت – این بخش بعد از به روز رسانی به صورت ایبوک رایگان منتشر می‌شه تا کسانی که بهش نیاز داشتن بتونن دریافتش کنن.
پروژه‌های نمونه – برای نسخه قبلی کتاب دو پروژه نمونه از ابتدا تا انتها توضیح داده شده بود که حجم زیادی هم برده بودن. این بخش هم از کتاب حذف می‌شه و در عوض در اولین فرصت یه کتاب مفصل‌تر که صرفا برای همین کار باشه و فایل‌ها هم تماما در کنارش وجود داشته باشن منتشر می‌کنم.
تغییر آخری که در نظر دارم اینه که مباحث مربوط به محاسبه پیشرفت رو مفصل‌تر کنم. قصد داشتم بخش مربوط به مدیریت هزینه رو هم مفصل‌تر کنم، ولی بعد دیدم که کامل‌تر شدنش مستلزم اینه که یه سری از اصول مدیریت هزینه هم توضیح داده بشه که دیگه قطعا جاش توی یه کتاب آموزش پراجکت نیست. احتمالا در آینده یه کتاب کامل در مورد مدیریت هزینه و پیاده‌سازیش تو …
شاید اسم ICB رو شنیده باشین؛ ICB یه مبنای شایستگی برای مدیریت پروژه‌س، که ممکنه بعضی‌ها بهش بگن استاندارد مدیریت پروژه (زیاد اصطلاح درستی نیست).
ICB مخفف اینه: IPMA Competence Baseline
و همونطوری که از اسمش هم پیداس، مالک و مولفش IPMA (انجمن بین‌المللی مدیریت پروژه، International Project Management Association) هست.
ICB مجموعه‌ای از ۴۶ عامله که برای شایستگی مدیران پروژه‌ها لازمه. این عوامل تو سه گروه دسته‌بندی شدن:
Technical Competences (شایستگی‌های فنی) – این گروه شامل ۲۰ عامله که همگی از جنس فرآیندهایی هستن که تو PMBOK توضیح داده می‌شه.
Behavioural Competences (شایستگی‌های رفتاری) – این گروه شامل ۱۵ عامل رفتاریه؛ ویژگی‌های رفتاری، اخلاقی و شخصیتی لازم برای مدیریت پروژه.
Contectual Competences (شایستگی‌های مربوط به شرایط محیطی پروژه) – این گروه شامل ۱۱ عامله که همگی برای هماهنگ شدن اقدامات پروژه با بستری که توش قرار داره انجام می‌شه. مسایل حقوقی، مالی، منابع انسانی، سازمانی و … این‌ها همگی عواملی هستن که هیچکدوم به طور کامل داخل پروژه قرار نمی‌گیرن و در عین حال فضای پروژه رو شکل می‌دن.
به‌روزرسانی: ساختار و دسته‌بندی شایستگی‌ها تو نسخه‌های جدید فرق کرده.
یه سوال رایج در مورد تاخیرهای مجاز اینه که وقتی هم پیمانکار و هم کارفرما تو بازه‌ای مشابه تاخیر دارن، آیا باید اون تاخیر رو مجاز حساب کرد یا نه. کسایی هم که با مجاز در نظر گرفتنش موافق نیستن عموما به این فکر می‌کنن که اگه کارفرما تاخیری ایجاد نکرده بود، باز هم چیزی تغییر نمی‌کرد و تو همون بازه تاخیرهای دیگه‌ای به خاطر پیمانکار به وجود می‌اومد.
وقتی تاخیر تو بازه‌ای خاص هم به دلیلی از طرف کارفرما برگرده و هم به دلیلی از طرف پیمانکار، یکی از این دو روش استفاده می‌شه:
روش کمابیش رایج‌تر: تاخیر به نفع پیمانکار محاسبه می‌شه، یعنی حق ادعای زمانی برای پیمانکار محفوظه. با این حال حق ادعای مالی اون دوره از پیمانکار گرفته می‌شه.
روش کمتر رایج: پیمانکار و کارفرما تو تاخیر شریک دونسته می‌شن و بر اساس معیارهای مختلف سهم اون‌ها رو تو تاخیر در نظر می‌گیرن. به این ترتیب قسمتی از حق پیمانکار در مورد اون تاخیر (مثلا نصفش) محفوظ می‌مونه، با این حال می‌تونه به اندازه همون سهم ادعای مالی هم داشته باشه.
منظورم از ادعای مالی هم اینه که پیمانکار بعدا claim کنه که به ازای تاخیر مجازی که ایجاد شده علاوه بر این‌که به زمانش اضافه می‌شه، فلان مقدار هم خسارت خرده و کارفرما باید بهش پرداخت کنه.
کلا هم به ندرت می‌شه که اون زمان رو کلا تاخیر پیمانکار در نظر نگیرن. با توجه به این‌که تو ایران پیمانکارها معمولا تو …
خیلی‌ها از من می‌پرسن که روش‌های متفاوتی برای محاسبه تاخیر مجاز وجود داره یا نه. برای همین اینجا به روش‌ها اشاره می‌کنم. البته الان دارم یه ایبوک درباره محاسبه تاخیر مجاز می‌نویسم که اون هم به زودی تموم می‌شه.
شیوه محاسبه تاخیر مجاز رو همیشه می‌شه تو یکی از این چهار گروه قرار داد:
روش‌های سرانگشتی: تو این روش‌ها یا از برنامه زمان‌بندی استفاده نمی‌شه، یا اگر هم بشه خیلی استفاده محدودیه و جنبه محاسباتی نداره. می‌شه با اصلاحات پم‌باک اینطوری گفت که به جای «مدل زمان‌بندی» از «زمان‌بندی» استفاده می‌کنه. روش‌های این خانواده خیلی تنوع دارن و خیلی‌هاشون هم ابتکاری هستن. از این روش‌ها عموما قدیم استفاده می‌شد که نرم‌افزارهای برنامه‌ریزی وجود نداشتن و نمی‌شد محاسبات کامل‌تر و پیچیده‌تر رو انجام داد. الان دیگه زیاد پذیرفته شده نیست که اینطوری تاخیرها رو محاسبه کنین.
روش‌های افزاینده با الگوی ثابت: این همون روشیه که معمولا استفاده می‌کنیم. عوامل تاخیر رو به نسخه اولیه برنامه زمان‌بندی اضافه می‌کنیم و نگاه می‌کنیم که ببینیم تاریخ پایان چقدر عوض شده. مقداری که عوض شده باشه می‌شه تاخیر مجاز. امتیاز این روش به اینه که اطلاعات ورودی خیلی کمی می‌خواد و اگه برنامه زمان‌بندی هم درست و حسابی باشه دوباره کاری برای تهیه برنامه نداریم.
روش‌های کاهنده با الگوی ثابت: تو این روش کار یه مقدار برعکسه. به جای …
این مطلب روند برنامه‌ریزی رو تو حالت پیش‌فرض، حالتی که پروژه چند فاز داره و همینطور حالتی که مجبوریم از rolling wave planning استفاده کنیم، بر اساس رویکرد پم‌باک، توضیح می‌ده.
چند وقت پیش قراردادی با انتشارات بریتانیایی ونتوس (bookboon) بسته بودم که براشون کتابی درباره استاندارد پم‌باک به زبان ساده تالیف کنم. این کتاب چند ساعت پیش به صورت الکترونیکی منتشر شد و اگه مایل باشین می‌تونین اون رو به رایگان از اینجا دریافت کنین.
اول قصد داشتم کتاب رو از ایبوک فارسی‌ای که قبلا با نام PMBOK به زبان ساده منتشر کرده بودم به انگلیسی برگردونم. با این حال بعد از تالیف اون کتاب ایده‌های جدیدی برای مفهومی‌تر کردن موضوع به ذهنم رسیده بود و به همین خاطر کتاب رو از اول نوشتم و فکر می‌کنم الان بیشتر از قبل به هدف اصلیم نزدیک شدم. هدف اصلی تو هر دو کتاب اینه که خواننده با ایده‌های محوری و گرایش و مفهوم استاندارد آشنا بشه، نه این‌که با حجم زیادی اطلاعات گسسته که به نظر خشک و حتی حفظ کردنی میان روبرو بشه.
بالاخره نسخه بتای پراجکت ۲۰۱۳ هم اومد و کسایی که علاقه‌مند باشن می‌تونن از سایت مایکروسافت دانلود و بعد نصبش کنن.
ظاهر نرم‌افزار کمی تغییر کرده و می‌شه نشونه‌های اینترفیس جدید مایکروسافت رو توش دید: اینترفیس مترو. این اینترفیس اولین بار تو ویندوز فون ۷ معرفی شد و ویندوز ۸ که قراره تا چند ماه دیگه بیاد هم همین اینترفیس رو داره. ظاهرا مایکروسافت داره تمام نرم‌افزارهاش رو هم به همین سمت می‌بره.
وقتی صحبت از اینترفیس می‌شه احتمالا اولین چیزی که به ذهن همه ما میاد پریماوراس و این آرزوی همیشگی که یه روزی اینترفیس اون هم به اندازه کافی خوب و حرفه‌ای بشه! بگذریم.
قابلیت‌های جدید پراجکت ۲۰۱۳
من هنوز فرصتی نداشتم که کامل نرم‌افزار رو بگردم و به تدریج که این کار رو بکنم مثل همیشه نتایج رو هم اینجا می‌نویسم. در حال حاضر با مرور توضیحات مایکروسافت در مورد قابلیت‌های جدید می‌شه نتیجه گرفت که این دوتا قابلیت جدید انتظارمون رو می‌کشن: گزارشهای بهتر، قابلیت قوی‌تر در رهگیری روابط.
رهگیری روابط
تو نسخه ۲۰۰۷ قابلیت جدیدی بود به اسم Task Driver (اگه اسمش رو اشتباه ننوشته باشم) که وقتی فعالش می‌کردیم یه کادر باز می‌شد و وقتی روی فعالیت‌ها کلیک می‌کردیم مشخص می‌کرد که driver اون فعالیت، یعنی سخت‌گیرانه‌ترین المانی که تاریخ شروعش رو مشخص می‌کنه چیه. این المان می‌تونه یکی از پیش‌نیازهای اون فعالیت، یکی …
خیلی‌ها که در حال آماده شدن برای آزمون PMP بودن نگرانن که با اومدن نسخه پنجم استاندارد پم‌باک چه اتفاقی برای آزمون می‌افته.
نسخه نهایی پم‌باک ۵ قراره که در آخر سال ۲۰۱۲ ارائه بشه و بعد از اون هم کمی بیشتر از ۶ ماه طول می‌کشه که آزمون PMP تغییر کنه. در نتیجه اگه می‌خواین قبل از نیمه سال ۲۰۱۳ امتحان بدین، نیازی نیست که کاری به نسخه پنجم داشته باشین.
دیروز ایمیلی از PMI دریافت کردم که گفته بود بررسی نظراتی که در مورد پیش‌نویس نسخه پنجم پم‌باک داده شده بود تموم شده. الان تصمیم‌هایی که به ازای هرکدوم از نظرات گرفته شده برای افراد فرستاده شده و یه مدتی هم وقت هست که اگه کسی خواست اعتراض بده.
نظرهایی که من داده بودم هم اکثرا با کمی تا قسمتی تغییر اعمال شده بودن (البته دوتاشون هم رد شده بودن)، ولی آیتمی که برام از همه مهم‌تر بود به نسخه بعدی موکول شده. ظاهرا به نظرشون اعمال کردنش نیاز به تغییرات عمده‌ای داره. موردی که می‌گم در مورد فرآیند Develop Schedule هست که به نظر من منطقیه که به جای Schedule روی Schedule Model متمرکز بشه و علاوه بر تغییر توضیحات فرآیند، اسمش هم به Develop Schedule Model تبدیل بشه. این تغییر با تمایزی که PMI بین زمان‌بندی و مدل زمان‌بندی قایله و تمایز خیلی کاربردی و مهمی هم هست مطابقه.
به‌روزرسانی: الان بعد از ۸ سال باز هم وقت بررسی نظرات در مورد نسخه جدید پم‌باکه، ولی این بار خودم جزو تیم تالیف هستم و از کسایی که نظرها رو بررسی می‌کنن :)
اگه کنجکاو باشین، نظری که در مورد اون تغییر داشتم رو هنوز هم دارم، ولی در نسخه فعلی که مسئولیت داشتم فرآیندها دیگه از بخش اصلی پم‌باک خارج شدن و ما کاری بهشون نداشتیم. در نتیجه، این نظر هیچوقت اعمال نشد!
خیلی از استانداردها و منابعی که در مورد زمان‌بندی نوشته شدن درباره شناوری‌های زیاد از حد نوشتن. این‌که شناوری‌ها نباید از حدی بیشتر باشه یکی از ۱۹ قاعده‌ایه که تو کتاب قواعد زمان‌بندی پروژه هم توضیح دادم.
بعد از انتشار کتاب، خیلی از خواننده‌های ایرانی و تعدادی از خواننده‌های غیر ایرانی از من درباره‌ش سوال کردن و به این نتیجه رسیدم که توضیحات بیشتری به ویرایش بعدی کتاب اضافه کنم؛ ولی تا اون زمان این مطلب رو نوشتم که برای همه توضیح داده باشم.
زیاد بودن شناوری به خودی خود هیچ مشکلی ایجاد نمی‌کنه. شناوری‌های زیاد از حد دلیل ایجاد مشکل نیستن، ولی نشونه‌ایه که به ما می‌گه احتمالا جای دیگه‌ای مشکلی وجود داره. مثل این می‌مونه که یه دکتر مثلا نشونه‌ای رو روی ناخن شما ببینه و مشکوک بشه. اون نشونه روی ناخن به خودی خود مشکلی برای شما ایجاد نمی‌کنه (مگر این‌که خیلی حساس به ظاهرتون باشین)، ولی ممکنه جای دیگه‌ای مشکل مهمی داشته باشین و به همین خاطر باید ماجرا رو بررسی کرد.
طبیعت اکثر پروژه‌ها اینه که فعالیت‌هاشون در عمل شناوری‌های خیلی زیاد ندارن و اگه داشته باشن هم تعدادشون از حدی بیشتر نمی‌شه. به همین خاطر انتظار داریم که فعالیت‌های برنامه هم همینطور باشن. اگه نباشن، باید شک کنیم و برنامه رو یه چک آپ کامل بکنیم. شاید واقعا طبیعت پروژه اینطور باشه و در این صورت نیازی نیست که چیزی رو اصلاح کنیم؛ …
خواننده‌های فارسی زبان از کتاب قواعد زمان‌بندی پروژه خیلی خوب استقبال کردن، ولی نکته مهم در اینه که استقبال خواننده‌های انگلیسی زبان به مراتب بیشتر بوده و به همین خاطر می‌خوام پیشنهاد کنم که اگه هنوز این کتاب رو مطالعه نکردین، حتما نگاهی بهش بندازین. نسخه فارسی رو می‌تونین از اینجا و نسخه رایگان انگلیسی رو از اینجا تهیه کنین. البته این دو نسخه دقیقا مشابه هم نیستن؛ توصیه‌هایی بومی که برای خواننده‌های ایرانی لازم بودن رو تو نسخه انگلیسی حذف کردم.
گذشته از وجود چند هزار نفری که نسخه انگلیسی رو دریافت کردن، چندین موسسه مدیریت پروژه با دریافت مجوز اون رو از طریق خبرنامه‌هاشون در اختیار مشتری‌هاشون گذاشتن، به دو نسخه پرتقالی و روسی ترجمه شده، یک مدرس مدیریت پروژه اون رو در آمریکا تدریس می‌کنه و تا حالا مجموعا ۸۰۰ پیام تشکر به دستم رسیده (بیشتر از پیام‌های تشکری که تو ده سال گذشته بابت کتاب‌های فارسیم گرفتم).
سیستم‌های مدیریت پروژه کلاسیک، مشابه اون چیزی که تو پم‌باک و پرینس۲ توضیح داده می‌شه، طوری طراحی شدن که برای همه نوع پروژه قابل استفاده باشن. با این حال پروژه‌های نرم‌افزاری تفاوت‌هایی با پروژه‌های دیگه دارن و احساس می‌شه که سیستم‌های کلاسیک برای مدیریت اون‌ها به اندازه کافی موفق نیستن. تلاش‌هایی که تو این زمینه شده، منجر شده به تدوین گروهی از سیستم‌های مدیریت پروژه مدرن که عموما تم و رویکرد مشابهی دارن و به همشون Agile (چابک) گفته می‌شه. موفق‌ترین و پر استفاده‌ترین سیستم اجایل هم Scrum (اسکرام) هست.
حالا بریم سراغ تفاوت‌های پروژه‌های نرم‌افزاری و غیر نرم‌افزاری. دلیل ریشه‌ای که باعث ایجاد این تفاوت شده، تغییرات خیلی زیاد تو پروژه‌های نرم‌افزاریه. مثلا وقتی یه پروژه ساخت کارخونه، بیمارستان یا راه دارین، از اول پروژه تعریف می‌شه و معمولا تا آخر کار تغییرات زیادی نمی‌کنه؛ ولی پروژه نرم‌افزاری اینطوری نیست. مشتری نرم‌افزاری رو سفارش می‌ده و به هر شکلی که هست محصول تعریف می‌شه، ولی با جلو رفتن کار انقدر نظرش عوض می‌شه و با دیدن قسمت‌های انجام شده انقدر ایده‌های جدید به نظرش میاد یا چیزهایی که از قلم افتادن یادش می‌افته، که عملا محصولی که در آخر کار به وجود میاد ربطی به محصولی که از اول تصور کرده بودیم نداره.
حالا چه دلیلی وجود داره که کسایی مثل من که تو پروژه‌های غیر نرم‌افزاری کار …
برنامه فعلی من تالیف تعدادی کتاب کاملا تخصصی در مورد پریماوراس و الان اولین جلد از این مجموعه کتاب، با عنوان ساختار مقادیر پیشرفت در Primavera P6 منتشر شد.
این کتاب شیوه محاسبه پیشرفت برنامه‌ریزی شده و واقعی رو به طور کامل تو پریماورا توضیح می‌ده. مفهوم و نوع ارتباطی که بین فیلدهایی مثل Schedule % Complete، Performance % Complete، Duration % Complete، Units % Complete و Physical % Complete هست رو به تفصیل آموزش می‌ده.
این کتاب زمینه کاملی فراهم می‌کنه تا دو مبحث مهم دیگه تو جلدهای بعدی آموزش داده بشن؛ یکی محاسبه پیشرفت فیزیکی (به سبک ایرانیش) و دیگری ارتباط بین مقادیر مدت زمان، کار و تخصیص.
تو این کتاب ۲۱ نوع از رایج‌ترین محتوایی که تو گزارشهای پیشرفت پروژه کاربرد داره معرفی شده، برای هرکدوم یک یا چند شیوه ارائه پیشنهاد شده و در نهایت به اینجا ختم می‌شه که با انتخاب انواع محتوا و شیوه نمایش، گزارش یا گزارشهای پیشرفت پروژه رو تهیه کنیم.
کتاب پیوستی هم داره که تکنیک‌های پیشرفته ترسیم نمودار رو تو اکسل توضیح می‌ده.