تقریبا ۴ ماه پیش تمرین ویژهای برای کسایی که اون زمان دوره آشنایی با مفهوم چابکی در پروژه رو تموم کرده بودن فرستاده شد و ازشون خواسته شد که جوابهاشون رو ارسال کنن. سوال این بود:
آبراهام لینکلن یه جمله داره که خیلی ازش خوشم میاد و خیلی قدیم هم تو سایت نوشته بودمش. میگه: اگه به من ۶ ساعت وقت بدین که درختی رو قطع کنم، چهار ساعت اولش رو صرف تیز کردن تبرم میکنم.
این حرف برای کسایی مثل ما که تو پروژهها کار میکنن یادآور اهمیت برنامهریزیه. اینکه اول درست و کامل برنامهریزی کنیم و بعد بریم سراغ اجرا، نه اینکه بریم جلو ببینیم چی میشه. حالا نکتهای که هست اینه که این توصیه به نظر با رویکرد چابک متضاد میاد؛ تو پروژههای چابک برنامهریزی اولیه به این شکل نمیکنیم. یعنی اگه فرض کنیم میخوایم تو ۶ ساعت یه درخت رو قطع کنیم، فقط دو دقیقه اول رو صرف تیز کردن تبرمون میکنیم.
نظرتون در مورد این تضاد چیه؟
جوابها تو یه فرم گوگل دریافت میشدن که هم کار برای من راحت بشه و هم برای کسایی که جواب میدن. این همون روش مناسب پرسشنامه فرستادنه که قبلا هم توضیح داده بودم.
تو فرم سه سوال وجود داشت…
سوال ۱: کلا چقدر با حرف لینکلن موافقین؟
جوابهایی که تو فرمهای گوگل وارد میشن تو یه فایل spreadsheet (مشابه فایلهای اکسل) ذخیره میشن. تو همون فایل به سادگی میشه با دو کلیک نمودار هیستوگرام جوابها رو …
GAO (سازمان مسئول بازرسی تو دولت فدرال آمریکا) به تازگی کتاب راهنمایی در مورد ارزیابی برنامههای زمانبندی منتشر کرده که به نظرم مطالعهش میتونه براتون مفید باشه.
یه دوره ایمیلی جدید منتشر کردیم در مورد مدیریت ریسک پروژه، که مثل دوره مفهوم چابکی مبتنی بر ایمیله. هر روز یه درس کوتاه و ساده براتون ایمیل میشه و بعد از ۶ هفته آشنایی کافی با مدیریت ریسک پیدا میکنین.
این دوره اولین محصولیه که در همکاری مشترک جامعه مهندسان مشاور ایران و شرکت ما، یعنی Management Plaza تهیه شده و قراره که در آینده نزدیک دورههای مقدماتی و جامع متعددی تو این طرح تدوین بشه.
یه دوره ایمیلی جدید منتشر کردیم در مورد مدیریت ریسک پروژه، که مثل دوره مفهوم چابکی مبتنی بر ایمیله. هر روز یه درس کوتاه و ساده براتون ایمیل میشه و بعد از ۶ هفته آشنایی کافی با مدیریت ریسک پیدا میکنین.
متاسفانه دوره فعلا به خاطر مشکلهای فنی ارائه نمیشه.
یکی از بهترین انجمنهای آنلاین برای برنامهریزی و کنترل پروژه سایت Planning Planet هست. چند سال پیش طرحی با پشتیبانی این سایت راهاندازی شد که مجموعهای از استانداردها برای برنامهریزی پروژه تهیه کنه. تفاوت اصلی این استاندارد با نمونههای دیگهای که میشناسین، مثل پمباک و پرینس۲، اینه که بر خلاف بستر کلان مدیریت پروژه، روی برنامهریزی و کنترل پروژه متمرکزه؛ یعنی همون چیزهایی که اکثر شماها باهاش سر و کار دارین.
تیم مرکزی استاندارد لطف داشت و نظر من رو هم در خلال کار جویا شد و باعث خوشوقتیه که خیلی از پیشنهادهام، که عموما برای مطابقت بیشتر استاندارد با نیازهای روزمره متخصصان برنامهریزی بود، تو پیشنویس اعمال شده.
در هر حال، پیشنویس استاندارد الان در دسترسه و میتونین تو این آدرس به رایگان مطالعهش کنین. فکر میکنم برای دسترسی به مطالب باید اول عضو انجمن بشین، که اون هم رایگان و سادهس.
چند روز پیش قرار بود جایی درباره بهبود سیستمهای مدیریت پروژه صحبت کنم که یه دفعهای مثالی به ذهنم رسید و براشون تعریف کردم. یادم نمیاد این داستان رو کجا شنیده بودم، یا حتی اینکه جک بوده یا یه داستان برای رسوندن مفهوم مشابه؛ ولی به هر حال اینطوریه:
یه بیمار روانی ادعا میکرده که حالش خوب شده و میتونه از بیمارستان مرخص بشه. پزشکها صحت این ادعا رو اینطوری آزمایش میکنن: بیمار رو میبرن تو یه اتاق که وانی پر از آب توش بوده. به بیمار یه چنگال، یه قاشق و یه سطل میدن و میگن آب وان رو خالی کن.
شما باشین چیکار میکنین؟
اون بیمار چنگال، قاشق و سطل رو میندازه کنار و میره درپوش دریچه وان رو برمیداره. تو چند ثانیه آب وان خالی میشه.
گزینهها
یه مشکل بزرگ تو تصمیمگیریهامون، چه مربوط به پروژه باشه و چه مربوط به زندگی شخصی، اینه که بیدلیل گزینههای خودمون رو محدود میکنیم. درسته که یه چنگال و یه قاشق و یه سطل آب بهمون دادن و میتونیم یکیشون رو که از همه بهتره انتخاب کنیم، ولی همیشه جا داره به این فکر کنیم که گزینههای دیگهای هم وجود داره یا نه.
خیلی از شرکتهایی که برای بهبود سیستمهاشون به من مراجعه میکنن از این گلایه میکنن که سیستم مدیریت پروژهشون کارآمد نیست و مشکلهای خیلی زیادی تو تخصیص نیرو و تکمیل به موقع پروژهها دارن. وقتی وضعیت رو از نزدیک میبینم، متوجه میشم که یه شرکت …
پروژه تدوین نسخه جدید PRINCE2 از حدودا سه هفته دیگه با جلسهای در لندن رسما شروع میشه. نسخه قبلی سال ۲۰۰۹ منتشر شده بود و به این ترتیب اگه حدودا یک سال برای پروژه در نظر بگیریم، ۷ سال بین دو نسخه فاصله میافته. مدت کم نیست و قطعا انتظارها به همون تناسب بالا میره.
برای تیم این پروژه از من هم دعوت شده، که خیلی باعث خوشوقتیه. البته متاسفانه با خیلی از مواردی که تو mandate (جرقه پروژه) ذکر شده مخالفم و امیدوارم بر خلاف پروژه تدوین PRINCE2 Agile بتونم نظرهام رو به تایید گروه برسونم.
در هر حال، اعضا علاوه بر نظر کارشناسی خودشون قراره گزیدهای از نظرهای دستاندرکاران محدوده جغرافیاییشون رو هم منعکس کنن. من قصد دارم علاوه بر دیدگاههای متخصصهای بلژیکی که قراره به اونجا ببرم، دیدگاههای ایرانیها رو هم ببرم. البته دومی قاعدتا تو برنامه نیست، ولی فکر میکنم جای مطرح کردنش وجود داشته باشه. در نتیجه اگه با پرینس۲ آشنایی کامل دارین و خصوصا اگه ازش تو پروژههاتون استفاده کردین و نظر خاصی دارین که میخواین منعکس بشه به من ایمیل بزنین.
وقتی لیستی از کارها داریم که پیشنیازی چندانی ندارن، انتخاب ترتیب مناسب خیلی مهمه. حالا اینکه ترتیب مناسب چیه بحث داره. مثلا یه پیشنهاد که تو کتاب پرفروش و عامهپسند «قورباغه را قورت بده» هست اینه که سختترین کار رو اول انجام بده که خیالت راحت بشه و بعد بری سراغ بقیه چیزها.
من با این توصیه موافق نیستم. حالا میخوام چراییش رو توضیح بدم.
جنبه منطقی
دلیل اول اینه که ترتیب مناسب تو شرایط ایدهآل اینه که به ترتیب ارزش کارها رو انجام بدیم؛ هرچی کاری با ارزشتره زودتر انجام بشه. دلیلش هم اینه که خیلی از کارها رو وقت نمیکنیم به موقع انجام بدیم و قطعا تو این شرایط بهتره که کارهای کمارزشتر به آینده موکول بشن (قانون ۲۰/۸۰ هم که یادتون هست). توجه هم داشته باشین که فوریت و ضرورت کارها، در صورتی که واقعی باشن، تو «ارزش» کار منعکس میشن و اگه ارزش رو درست در نظر گرفته باشیم دیگه نیازی نیست که در کنارش عامل دیگهای هم بذاریم.
«ارزش» هر چیز میشه منافعی که ازش حاصل میشه، تقسیم بر هزینهای که انجامش داره. هزینه خیلی وقتها ممکنه صرفا تبدیل بشه به زمانی که برای کارها میذاریم. هرچقدر که کاری سادهتر باشه، عملا سریعتر (کمهزینهتر) انجام میشه و احتمالا ارزشش میره بالاتر. به عبارت دقیقتر، اگه دو کار داشته باشیم با منافع یکسان، اونی که سادهتره «ارزش» بالاتری داره. در نتیجه تو این حالت باید کار …
یکی از کارهایی که قدیم تو پروژههامون با علاقه زیاد انجام میدادم عکاسی بود. در کنار عکسهای معمولی که از روند کار میگرفتم، نقطههایی رو هم در خارج محیط پروژه در نظر میگرفتم که میدونستم تا پایان کار دید خوبی به محصول دارن و مثلا ماهی یه بار از همون نقطه ثابت و با زاویه مشابه عکسی میگرفتم. در کنار اینکه چنین چیزی میتونه روند پیشرفت رو به شکل جالبی نشون بده، همیشه دلم میخواست بتونم با کنار هم گذاشتنشون یه جور فیلم هم درست بکنم که توش محصول پروژه تو کمتر از یک دقیقه از روز اول تا آخر نشون داده بشه و بشه کامل شدنش رو دید. خوب، این ایده زیاد عملی نشد، چون لازمهش اینه که زاویه عکسها دقیقا مثل هم باشه و این در عمل خیلی سخته.
به هر حال، یکی دیگه از کارها این بود که یه نقطه نسبتا بلند پیدا کنم و از اونها عکسهایی بگیرم که به همه کارگاه مسلط باشه. این کار خیلی سخت بود، ولی وقتهایی که موفق میشدم نتیجه واقعا عالی میشد.
الان که droneها رایج شدن، اولین چیزی که همیشه به ذهنم میرسه اینه که داشتن اینها چقدر برای تهیه عکس و فیلم از پروژهها عالیه.
اگه یکی از این موجودات کوچیک داشته باشین راحت میتونین چند وقت یه بار بالای کارگاه پروازش بدین و باهاش از وضعیت فیلم و عکس بگیرین. حتی تو مراحل نهایی که پیشرفت بیشتر شده باشه میتونین باهاش به فضاهای داخلی هم برین.
موسسه AXELOS که مالک PRINCE2 و استانداردهای همخانوادهش هست از سال پیش پروژه جدیدی شروع کرد برای تدوین استانداردی جدید که پرینس۲ رو تبدیل به سیستمی کاملا چابک بکنه. من هم افتخار داشتم که عضوی از این تیم باشم و سهمی تو شادی روزهای اخیر که ناشی از انتشار رسمی استاندارد بود داشته باشم.
چه چیزی تو استاندارد تغییر کرده؟
هیچی. ماجرا اینه که پرینس۲ استانداردی تو لایه مدیریت پروژهس و چابک بودن یا نبودن تو لایه تولیده. همپوشانیهای این دو هم به اندازه کافی کم بوده که بتونیم ادعا کنیم پرینس۲ رو هم میشه تو فضای چابک استفاده کرد و هم فضای متعین.
منابع: اگه علاقهمندین که در مورد مفهوم چابکی بیشتر بدونین میتونین از دوره رایگانی که در مورد مفهوم چابکی تهیه کردم استفاده کنین. برای پرینس۲ هم دوره مشابهی تهیه کردم که رایگان هم هست، ولی به زبان انگلیسیه. در کنار اون به کتاب الکترونیکی متودولوژی پرینس۲ به زبان ساده هم میتونین مراجعه کنین.
اکثر استانداردها رو باید اختصاصیسازی (tailor) کرد. اتفاقی که این استاندارد جدید افتاده اینه که نسخهای اختصاصیسازی شده از استاندارد اصلی پرینس۲ تهیه کردیم که با چابکی لایه تولید تا جای ممکن هماهنگ باشه. به عبارت دقیق، این سیستم کاملا پرینس۲ هست و هیچی توش «عوض» نشده، فقط اختصاصیسازی شده. وقتی میگیم چیزی «عوض» شده که دیگه مطابق نسخه اصل نباشه.
به تازگی تصمیم گرفته تغییرهایی تو سیستم تمدید گواهیها بده. ماجرای کلی (اگه احیانا نمیدونین) اینه که وقتی کسی گواهیای مثل PMP میگیره باید هر سه سال یه بار (یا تو بازههای دیگه، بسته به نوع گواهی) اون رو با ارائه تعداد کافی PDU تمدید کنه. هر PDU معادل یک ساعت تلاش برای بهبود دانش و مهارت مدیریت پروژه خود فرد، یا کمک اون فرد به بهبود دانش و مهارت دیگرانه.
در مورد سیستم ثبت و گزارشدهی اون قبلا مطلبهایی نوشته بودم و کلا هم این ماجرا به تفصیل تو هندبوک PMP توضیح داده شده که میتونین از سایت PMI دانلود کنین.
تغییرهای سیستم PDU
تغییرها تو قیدهایی بودن که برای انواع منابع PDU در نظر گرفته شده. قبلا میشد حداکثر ۴۵ واحد از طریق استفاده از دانش یا کمک به دیگران برای یادگیری دریافت کرد، که الان شده ۲۵ واحد. معنیش اینه که الان تمدید گواهیها بیشتر متمرکزه روی یادگیری تا یاد دادن.
قبلا حداقلی برای یادگیری وجود نداشت، ولی الان قراره حداقل ۳۵ واحد برای یادگیری لازم باشه. یادگیری هم به سه حوزه تقسیم شده و لازمه که فرد حداقل ۸ واحد از هر حوزه بگیره، به این خاطر که مطمئن باشیم یادگیری فراگیره.
سه حوزهای که در نظر گرفته شده جنبههای تکنیکی (مثلا محاسبات ریسک)، رهبری و مهارتهای بینافردی و در نهایت استراتژی و کسب و کاره.
جدول زیر خلاصهای از تغییرها رو نشون میده. لطفا توجه داشته باشین که فقط …
دوره آموزشی خیلی ساده و کوتاهی در مورد مفهوم چابکی در پروژه طراحی کردم و رایگان هم هست و اگه علاقهمند باشین همین الان میتونین توش ثبت نام کنین.
این دوره با سیستم خاصی طراحی شده که خیلی کنجکاوم بدونم برای کاربر مفید و جالب هست یا نه. مبنای اصلیش اینه که محتوا به قطعههای خیلی کوچیک خرد بشه و مکانیزمی وجود داشته باشه که کاربر آهسته و پیوسته بره جلو.
دوره بیست درس داره و بعد از اینکه ثبت نام کنین روزی یک درس براتون ایمیل میشه. کل محتوای آموزشی هم تو همون ایمیله. روزی چند دقیقه میتونین صرف خوندن ایمیلها کنین و بعد از سه هفته دوره تموم میشه.
دوره آموزشی خیلی ساده و کوتاهی در مورد مفهوم چابکی در پروژه طراحی کردم و رایگان هم هست و اگه علاقهمند باشین همین الان میتونین توش ثبت نام کنین.
دوره بیست درس داره و بعد از اینکه ثبت نام کنین روزی یک درس براتون ایمیل میشه. کل محتوای آموزشی هم تو همون ایمیله. روزی چند دقیقه میتونین صرف خوندن ایمیلها کنین و بعد از سه هفته دوره تموم میشه.
متاسفانه دوره به خاطر مشکلهای فنی فعلا ارائه نمیشه.
این بحث خیلی تکراریه، ولی متاسفانه چون خیلی زیاد میبینم باز هم میخوام توضیحش بدم: اشتراک مطلب تو لینکدین فقط باید با مفهوم حرفهای باشه.
عکس سگ و گربه فقط زمانی پذیرفتنیه که دامپزشک حیوانات خانگی باشین و شبکهتون هم آدمهای مشابهی باشن. عکس از اماکن دیدنی وقتی پذیرفتنیه که شغلتون توریسم باشه. مطالب سیاسی وقتی پذیرفتنی هستن که سیاستمدار باشین. مطالب مذهبی وقتی پذیرفتنی هستن که «شغلتون» ترویج مذهب باشه (ملا و کشیش و …). پازل وقتی پذیرفتنیه که شغلتون طراحی پازل باشه.
اگه غیر از این رفتار کنین عملا دارین هویت حرفهای خودتون رو تو مهمترین و تاثیرگذارترین شبکه حرفهای جهان زیر سوال میبرین؛ چیزی که به این سادگی درست نمیشه.
اگه مطالب نامربوط تو لینکدین منتشر نمیکنین و از دیدن این نوع مطالب ناراحت میشین، میتونین خیلی راحت مثل من روی آیکن Hide که بالا و سمت چپ مطالب باز میشه کلیک کنین تا بعد از اون دیگه هیچ مطلبی از اون فرد نبینین.
برای هر پروژهای باید گسترهای طراحی کنیم، چه وقتی پروژه کلاسیک پیش بره و چه وقتی که چابک باشه. تو پروژههای کلاسیک معمولا (نه همیشه) کل گستره در ابتدا مشخص میشه، ولی تو پروژههای چابک معمولا گستره به تدریج و بر اساس بازخوردهای قبلی شکل میگیره. ولی به هر حال باید تعیین کنیم چه برای کل مدت پروژه یا برای بازهای در آینده نزدیک قراره چه چیزی تولید کنیم.
حالا اینکه گستره به چه ترتیبی میتونه تعیین بشه خودش بحث خیلی مهمیه. یه موقع شرکتی هستین که پروژهای رو از کارفرمایی گرفتین و یه قراردادی دارین که کلیات گستره توش مشخص شده؛ موضوع صحبتم شما نیستین. این مطلب در مورد زمانیه که:
بر اساس قرارداد قراره به کارفرمای خودتون کمک کنین که در مورد کلیات گستره تصمیم بگیره
خودتون کارفرما هستین و میخواین درباره کلیات گستره تصمیم بگیرین
اصلا بحث کارفرما و پیمانکار به شکل متمایز وجود نداره؛ پروژه داخلیه و خودتون هم نقش کارفرما دارین و هم پیمانکار اصلی.
مشکل
یه مشکل خیلی بزرگ برای اکثر شرکتها وجود داره، اون هم اینه که خیلی سریع یه راه حل در نظر میگیرن و تصمیم میگیرن اجراش کنن. مثلا میخواین سیستم مدیریتی پروژههاتون رو بهبود بدین و سریع میگین که یه PMO راه میندازیم. این روند به چند دلیل مشکل داره:
ممکنه اون محصول بهترین راه برای رسیدن به نتیجه نباشه