کتاب جدیدم، PMBOK به زبان ساده، منتشر شد.

کتاب کم حجمیه درباره استاندارد مدیریت پروژه پم‌باک، که مفاهیم و کلیات استاندارد رو به سادگی توضیح می‌ده. کتاب رو بر اساس بازخوردهایی که از خواننده‌های کتاب‌های قبلیم دریافت کردم و برای کسایی نوشتم که می‌خوان سریع و ساده با استاندارد آشنا بشن و کتاب‌های حجیمی که وارد تمام جزئیات می‌شن براشون جذاب نیست. البته من امیدوارم که با خوندن این کتاب علاقه‌مند به مطالعه بیشتر و حتی گرفتن مدرک PMP بشن. ولی در هر حال، کسایی که می‌خوان فقط بفهمن که کل ماجرای پم‌باک که روز به روز داره بیشتر سر زبون‌ها می‌افته چیه، جواب تمام سوال‌هاشون رو همونجا می‌گیرن.
همراه کتاب یه آزمون آنلاین هم هست. آزمون به زبان فارسیه، ۶۳ سوال داره و ۸۰ دقیقه زمان برای پاسخ‌گویی. می‌تونین بعد از مطالعه کتاب تو آزمون شرکت کنین و دانشی که به دست آوردین رو ارزیابی کنین. میزان سختی سوال‌های آزمون مشابه آزمون PMP هست، ولی فقط درباره کلیات استاندارد و مطابق با موضوعات کتابه. نمره قبولی آزمون PMP قبلا ۶۱ درصد بود (الان ماجرای شیوه قبولی یه مقدار پیچیده شده) و این آزمون رو هم طوری طراحی کردم که حد مناسب نمره همون ۶۱ درصد باشه. در نتیجه، اگه نمره بالاتر از ۶۱ درصد گرفتین، خیالتون راحت باشه.

کتاب ۱۵۷ صفحه‌س و قیمتش ۵ هزار تومن. می‌تونین اون رو از این آدرس آنلاین خریداری و بلافاصله نسخه PDF رو دریافت کنین.

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

مشکلی که من دارم تو این مسئله می‌بینم، اینه که هرکس یه مقدار در مورد مدیریت پروژه مطالعه می‌کنه شروع می‌کنه به ایراد گرفتن از کارها و تصمیم‌های هر مدیر پروژه‌ای که می‌بینه. این درسته؟ نه. همیشه این گفته یادتون باشه:

Little Knowledge is a dangerous thing

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

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

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

بنابراین توصیه من اینه: به دانشی که فکر می‌کنین دارین مغرور نشین و اتفاقات رو بدون پیش‌داوری درک و تحلیل کنین، تا بیشترین استفاده رو ازشون ببرین.

آرش میلانی به تازگی داره پادکست‌هایی درباره مدیریت پروژه چابک (agile) ارائه می‌کنه. امروز برای اولین بار فرصت شد که گوش بدم؛ به نظرم خیلی خوب اومد.

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

1. آشنایی با اجایل
2. اسکرام، روشی برای شکست در سی روز یا کمتر

چهار نوع رابطه برای زمان‌بندی وجود داره و اکثر برنامه‌ریزها آزادانه از این چهار نوع استفاده می‌کنن (اشتباه!).

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

مدتی بعد که مشغول خوندن استانداردها شدم، دیدم که PMBOK، استاندارد زمان‌بندی PMI و PRINCE2 همگی تاکید می‌کنن که باید تا جای ممکن از FS استفاده کرد. این ماجرا رویکرد من رو به این ماجرا تاکید کرد.

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

نکته جالب اینه که مدتی بعد یکی از دستورالعمل‌های وزارت دفاع آمریکا رو می‌خوندم که به پیمانکارانشون ابلاغ می‌شه. جایی تو اون دستورالعمل گفته بود که اگه تعداد روابط FS یه برنامه‌ای کمتر از ۹۰ درصد باشه، اون برنامه از نظرشون مردوده.

با این حساب الان خیلی در مورد این رویکرد جدی‌تر از قبل هستم. حالا از شما می‌خوام که چند سناریو تو ذهنتون بیارین که توش از رابطه‌ای غیر از FS استفاده می‌کنین. حالا ماجرا رو تحلیل کنین و به این دو سوال جواب بدین:

1. اون رابطه رو چطوری می‌شه FS پیاده‌سازی کرد؟
2. به لحاظ مفهومی و عملکردی رابطه FS تو اون شرایط مناسب‌تره یا رابطه‌ای که قبلا انتخاب کرده بودین؟

می‌تونیم یه سناریوی رایج رو برای SS با هم مرور کنیم. این رایج‌ترین چیزیه که من تا حالا دیدم.

فعالیت S1 دوازده‌تا پیش‌نیاز داره؛ فعالیت‌های P1 تا P12. برای اون‌ها دوازده‌ها رابطه FS می‌سازین.

فعالیت S2 همزمان با S1 شروع می‌شه. بین اون‌ها یه رابطه SS می‌سازین.

به نظرتون این کار درسته؟

برای جواب دادن به این ماجرا باید به این سوال جواب بدیم که اگه S1 شروع نشده باشه، S2 رو هم نمی‌شه شروع کرد؟

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

برنامه‌ریزها خیلی وقت‌ها از این نوع SSها برای ساده کردن روابط استفاده می‌کنن و عملا برنامه رو ضعیف می‌کنن. مثلا اگه ده‌تا فعالیت با اسم‌های S1 تا S10 داشته باشیم که هرکدوم دوازده‌تا پیش‌نیاز P1 تا P12 داشته باشن و بخوایم روابط رو FS پیاده‌سازی کنیم، باید به اندازه حاصل‌ضرب ۱۰ در ۱۲، یعنی ۱۲۰ رابطه تعریف کنیم. این در حالیه که اگه روابط رو برای اولی تعریف کنیم و بقیه Sها رو باهاش SS کنیم، تعداد روابط ۲۱ خواهد بود، که به مراتب کمتره. می‌دونیم که تو این حالت شبکه رو خراب کردیم، ولی آیا واقعا لازمه که این همه رابطه تعریف کنیم؟

نه. می‌تونین یه مایل‌ستون بسازین و دوازده‌ها پیش‌نیاز رو به اون بدین، بعد اون رو پیش‌نیاز Sها بکنین. به این ترتیب به جای ۱۲۰ رابطه فقط ۲۲ رابطه ایجاد می‌کنین و این واقعا از ۲۱ رابطه خیلی بیشتر نیست. در عوض برنامه سالم‌تری هم به وجود آوردین.

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

پس تو سناریوی قبلی نیازی نیست که به جای FS از SS استفاده کنیم. حالا یه سناریوی دیگه که اون هم رایجه.

فعالیت S با فعالیت P همپوشانی ۵۰ درصد داره.

خیلی‌ها این رابطه رو SS+50% تعریف می‌کنن. آیا این درسته؟

تو این حالت اگه P شروع بشه و بلافاصله متوقف بشه یا مشخص بشه که مدت زمان لازم برای اون مثلا ۵ برابر برآورد اولیه‌س، S باز هم تو تاریخ قدیمی شروع می‌شه، چون فقط با شروع P ارتباط داره.

رابطه صحیح تو چنین مواردی، FS-50% هست، که مشکلات رابطه قبلی رو نداره.

پس، این توصیه رو همیشه در نظر داشته باشین که باید بیشتر از ۹۰ درصد فعالیت‌های برنامه‌تون از نوع FS باشن.

نسخه ۱/۱ کتاب راهنمای تدوین ساختار شکست کار بر اساس استانداردهای PMBOK و PRINCE2 منتشر شد.

می‌تونین اون رو به رایگان از آدرس www.khorramirad.com/wbs دانلود کنین.

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

الان در حال تدوین یه مجموعه آموزشی مالتی‌مدیای نرم‌افزار پراجکت برای سازمان فنی و حرفه‌ای هستم. این مجموعه آموزشی نرم‌افزار پراجکت رو همراه با اصول و مفاهیم برنامه‌ریزی و کنترل پروژه توضیح می‌ده. عملا دوره آموزشی رو طوری دارم تنظیم می‌کنم که مخاطب تا پایان دوره دانش و مهارت‌های کافی برای برنامه‌ریزی و کنترل تمام جنبه‌های رایج در پروژه‌های ساده رو داشته باشه.

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

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

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

کتاب تدوین ساختار شکست کار بر اساس استانداردهای PMBOK و PRINCE2 که چند وقت پیش به صورت الکترونیکی و رایگان منتشر کرده بودم رو تو کمتر از یک ماه نزدیک به ۲۰۰۰ نفر دریافت کردن، که واقعا استقبال امیدوار کننده‌ای بود.

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

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

• کتاب خیلی سریع‌تر به دست خواننده می‌رسه. هر کتابی که بعد از تالیف تحویل ناشر می‌شه بین ۶ ماه تا یک سال طول می‌کشه که به دست مخاطب‌هاش برسه. این مدت زمان برای بعضی کتاب‌ها خیلی مضره.
• کتاب ارزون‌تر به دست خواننده می‌رسه. خوب واضحه که برای من مقرون به صرفه نیست که تمام کتاب‌هام رو رایگان ارائه کنم. کتاب‌های بعدی به صورت الکترونیکی فروخته می‌شن، ولی با قیمتی که بین ۳۰ درصد تا ۷۰ درصد ارزون‌تر از نسخه چاپیه و این استفاده رو برای مخاطب خیلی راحت‌تر می‌کنه، چون حقیقتا کتاب تو سال‌های اخیر خیلی گرون شده.
• کتاب خیلی راحت‌تر به دست مخاطب می‌رسه؛ به جای این‌که تو این ترافیک و آلودگی هوا به کتاب‌فروشی‌ها مراجعه کنین، به سادگی از طریق اینترنت کتاب رو می‌خرین و بلافاصله به دستتون می‌رسه.
• ویرایش‌های جدید کتاب خیلی ساده‌تر تهیه می‌شن. کتاب‌های کاغذی رو به این سادگی نمی‌شه تغییر داد، ولی نسخه‌های الکترونیکی رو خیلی راحت می‌شه چند وقت یک بار بر اساس بازخورد خواننده‌ها تکمیل‌تر کرد.

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

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

تو اکثر نرم‌افزارهای برنامه‌ریزی دو جور هزینه وجود داره:

1. هزینه‌ای که بر اساس کارکرد منابع تعریف می‌شه
2. هزینه مستقل از منبع

هزینه مستقل از منبع پراجکت تو فیلد Fixed Cost وارد می‌شه. اگه مقداری تو فیلد Cost وارد کنین هم عملا مابه‌التفاوتش با هزینه منابع (اگه وجود داشته باشه) می‌ره تو همون فیلد Fixed Cost.

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

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

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

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

تو پراجکت دوتا فیلد Fixed Cost Accrual برای هزینه‌های مستقل از منبع و Accrue At برای هزینه‌های منابع وجود داره که مشخص می‌کنه هزینه اون‌ها چه موقع خرج می‌شه و هرکدوم از اون‌ها سه‌تا گزینه دارن، هزینه در ابتدای کار، هزینه در انتهای کار و هزینه به طور یکدست در طول مدت کار (این آخری پیش‌فرضه).

خیلی‌ها با دیدن این گزینه‌ها نا امید می‌شن. دلشون می‌خواد ترکیب‌های متنوع‌تری از هزینه داشته باشن… مثلا:

حالا این‌ها رو از کجا بیاریم؟

می‌شه شیوه توزیع کار منبع در مدت زمان اجرای فعالیت رو به این شکل و با چنین الگوهایی تعیین کرد. این مشخصه تو فیلد Work Contour وارد می‌شه.

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

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

برای هزینه‌های مستقل از منبع چطوری می‌شه الگو تعریف کرد؟ نمی‌شه!