گوریل در پروژه

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

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

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

 

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

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

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

گوریل پروژه

امروز داشتم کتابی در مورد «توجه» و «درک» می‌خوندم که توش به این اشاره کرد و نویسنده گفت که خودش اون زمان دانشجو بوده و یکی از کسایی بوده که تو این آزمایش شرکت کرده بوده. نویسنده کتاب از معدود کسایی بوده که گوریل رو دیده! دلیلش چی بوده؟ دلیلش این بوده که اصلا نخواسته بوده تعداد پاس‌ها رو بشمره و فقط داشته نگاه می‌کرده.

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

 

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

نوشته نادر خرمی راد (Nader Khorrami Rad)
بخش: آموزشی
مطالب مرتبط:

چطوری می‌شه یه PMO طراحی و مستقر کرد؟

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

 

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

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

 

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

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

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

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

 

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

 

تمام چیزهایی که گفتم در مورد یه «طرح» بود برای بهبود سیستم‌های مدیریتی مرتبط با پروژه تو یه شرکت. تو جنبه عملیاتی ماجرا نیاز به یه سیستم برای پشتیبانی و مربی‌گری دایمی هم داریم که می‌تونیم اسمش رو بذاریم PMO.

 

خلاصه این‌که:

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

 

و چند مطلب حاشیه‌ای:

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

شروع به کار ویکی تخصصی مدیریت پروژه

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

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

 

زیرساخت این همکاری الان آماده‌س و می‌تونیم کار رو شروع کنیم. این زیرساخت شامل دو قسمت می‌شه:

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

 

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

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

 

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

آخرین نکته اینه که اولین دوره تولید محتوا رو آهسته‌تر از اون چیزی که تو چهارچوب توضیح داده شده شروع می‌کنیم که مطمئن بشیم همه آماده‌ایم. هرچی باشه الان باید مدت زمانی رو هم صرف یادگیری شیوه کار با ویکی کنیم (که البته سخت هم نیست، ولی تا حدی متفاوته).

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

دعوت به یه کار گروهی

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

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

اگه به این کار علاقه دارین به من یه ایمیل بدین تا گروه رو شکل بدیم و کار رو شروع کنیم. لطفا تو موضوع ایمیلتون هم چیزی شبیه «ویکیپدیا» بنویسین که سریع بتونم پیداشون کنم. به این مطلب جدید سایت مراجعه کنین تا با شیوه شروع کار آشنا بشین (نیازی به ارسال ایمیل نیست).

 

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

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

 

سوال احتمالی بعدی اینه که آیا من قراره مدیر یا سرپرست این گروه باشم یا نه. جواب من منفیه. به نظر من بهتره که گروه خودسازمان‌یافته (self-organized) باشه و با تشخیص جمعی جلو بره. همه، از جمله من، سعی خواهیم کرد که گروه موفقی رو شکل بدیم؛ حالا هرکس تو جنبه‌ای که بهتر و موفق‌تره.

 

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

 

منتظر ایمیل‌هاتون هستم. لطفا برای اعلام آمادگی به توضیح‌های این مطلب مراجعه کنین؛ نیازی به ارسال ایمیل نیست.

 

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

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

 

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

 

پی‌نوشت سوم: اصلاح‌هایی که به رنگ سبز داخل متن اصلی انجام شده!

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

از بازی تا کار

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

وقتی آدم تو کار موفقه که ازش لذت ببره. به این فکر کنین که صبح‌ها که از خواب بلند می‌شین (خصوصا شنبه‌ها) با خودتون دارین فکر می‌کنین که «وای، بازم باید برم سر کار»، یا برعکس، یه حسی درونتون هست که می‌خواین هرچه سریع‌تر برین سراغ کار؟ معمولا آدم‌های موفق از گروه دوم هستن. این هم چیزی نیست که با تغییر رویکرد آدم به کار شکل بگیره، معمولا باید نوع کار رو طوری عوض کرد که خود به خود چنین حسی به وجود بیاد.

 

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

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

 

این‌ها نکته‌های کلیدی‌ای بود که به نظرم می‌رسید و خواستم با شماها هم در میون بذارم. این باورهای من هستن که فکر می‌کنم درستن و به شما هم پیشنهاد می‌کنم در نظر داشته باشینشون:

  • فقط وقتی می‌تونین تو کار موفق باشین و پیشرفت کنین که از کارتون لذت ببرین
  • فقط وقتی تو زندگی خوشبخت خواهید بود که از کارتون لذت ببرین
نوشته نادر خرمی راد (Nader Khorrami Rad)

مقابله با biasهای فکر

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

برای این‌که جلوی مشکلات ناشی از biasهای فکر رو بگیریم سه روش و سه مرحله وجود داره:

مرحله اول: درک و پذیرش

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

همین که آدم این کار رو بکنه خودش نوعی ایمنی ایجاد می‌کنه و تصمیم‌گیری‌ها بهتر می‌شن.

برای یادگیری می‌تونین از ویکیپدیا شروع کنین:

علاوه بر اون مطالعه این کتاب‌ها رو هم پیشنهاد می‌کنم:

  • Thinking, Fast and Slow، از Daniel Kahneman – این کتاب خیلی خوبیه و گذشته از این‌که اطلاعاتش خیلی به بهبود تصمیم‌گیری‌ها کمک می‌کنه، درک خیلی خوبی هم از مبنای وجود و مکانیزم عملکرد biasها می‌ده.
  • The Art of Thinking Clearly، از Rolf Dobelli – این کتاب مجموعه‌ای از مهم‌ترین biasها رو با مثال‌های خیلی خوب توضیح می‌ده.

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

مرحله ۲: استفاده از تکنیک‌ها

تکنیک‌های خیلی زیادی وجود داره که کمک می‌کنه جلوی یک یا چنتا bias رو بگیریم. مثلا تکنیک دلفی که احتمالا تو سوال‌های آزمون PMP دیده باشین به همین خاطره؛ همینطور استفاده از Planning Poker که تو پروژه‌های چابک رایج هست.

یه مثال دیگه می‌تونه برای جلوگیری از biasهای مالکیت باشه. ماجرای این‌ها اینه که آدم وقتی صاحب چیزیه، ارزش اون رو بالاتر می‌دونه. مثال بامزه‌ای که تو کتاب The Art of Thinking Clearly هست اینه که نویسنده یه بار می‌خواسته یه ماشین بخره. فروشنده ۵۰ هزار دلار قیمت گذشته بوده و نویسنده نمی‌خواسته انقدر پول بده. می‌گه که من حداکثر ۴۰ هزارتا حاضرم براش پول بدم. فروشنده هم قبول نمی‌کنه و از هم جدا می‌شن. بعد از یه هفته فروشنده تماس می‌گیره و می‌گه که حاضره اون رو ۴۰ هزار دلار بفروشه و معامله انجام می‌شه. بعد از یه مدتی نویسنده کتاب تو پمپ بنزین بوده که یه نفر ماشینش رو می‌بینه، خوشش میاد و پیشنهاد می‌ده که اون رو ۵۳ هزار دلار بفروشه. نویسنده قبول نمی‌کنه!

این حرکت خیلی غیر منطقیه، چون وقتی صاحب این ماشین نبود ارزشش رو ۴۰ هزار دلار می‌دونست و واقعا دلش نمی‌خواست بیشتر پول بده، در حالی که الان که صاحبشه فکر می‌کنه حتی ۵۳ هزار دلار هم براش کمه. مشابه این ماجرا در مورد Sunk Cost Effect (هزینه صرف شده) وجود داره.

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

مرحله ۳: استفاده از روش‌ها و چهارچوب‌های تصمیم‌گیری

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

  • Thinking on Purpose - For Project Managers: Oursmarting Evolution، از Bill Richardson
  • Project Decisions: The Art and Science، از Lev Virine و Michael Trumper
نوشته نادر خرمی راد (Nader Khorrami Rad)
بخش: آموزشی

شیوه اختصاصی‌سازی استاندارد

این ماجرا که اختصاصی‌سازی (tailoring) برای اکثر استانداردها، از جمله PMBOK و PRINCE2، الزامیه، باعث می‌شه که اهمیت زیادی پیدا کنه، در حالی که شیوه انجام این کار برای خیلی‌ها مبهمه. تو این مطلب می‌خوام یه مقدار اختصاصی‌سازی رو توضیح بدم.

 

اولین نکته اینه که برای استفاده از استاندارد تو پروژه‌ها دو مرحله کار لازمه:

  1. انطباق استاندارد با سازمان، که اصطلاحا بهش می‌گن embedding
  2. انطابق نسخه اختصاصی‌سازی شده سازمان با پروژه‌ای که قراره شروع بشه، که بهش می‌گن tailoring

البته این رو باید بدونین که خیلی جاها به هردوی این‌ها tailoring می‌گن.

tailoring

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

مرحله ۱: embed کردن استاندارد در سازمان

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

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

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

مرحله ۲: tailor کردن استاندارد برای پروژه

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

معمولا انتظار داریم که این کار همراه با بقیه برنامه‌ریزی‌ها تو کمتر از ۱۰ درصد زمان پروژه انجام بشه. زمان شروعش هم قاعدتا اول پروژه‌س و جزئی از برنامه‌ریزی به حساب میاد. البته قاعدتا از اولین اقدامات برنامه‌ریزیه، چون شیوه برنامه‌ریزی رو تحت تاثیر قرار می‌ده. نتایج این کار تو PMBOK جزئی از برنامه مدیریت پروژه می‌شه و تو PRINCE2 جزئی از سند آغازش پروژه (PID). مسئولیت اصلیش هم مثل اکثر برنامه‌ریزی‌های دیگه به عهده مدیر پروژه‌س.

چطوری می‌شه استاندارد رو اختصاصی‌سازی کرد؟

تو ترکیب embed کردن و tailor کردن اتفاق‌های زیادی می‌افته، از جمله:

  • تعیین نام‌ها! بله، خیلی وقت‌ها باید اسم عناصری که تو استاندارد هست رو عوض کرد تا برای مخاطب مفهوم‌تر باشه یا جلوی بعضی سوتفاهم‌ها رو بگیره. مثلا نقشی به اسم executive تو پرینس۲ وجود داره که اسمش معمولا ابهام ایجاد می‌کنه، چون تو هر شرکت عده‌ای مدیر ارشد وجود داره که بهشون می‌گن executive. اگه چنین مشکلی باشه، برای اینکه سوتفاهم ایجاد نشه می‌تونیم اسمش رو عوض کنیم و مثلا بذاریم sponsor (مشابه اون چیزی که تو پم‌باک وجود داره).
  • تعیین محصول‌های مدیریتی. خوب، برای مدیریت هر پروژه باید تعدادی محصول مدیریتی تولید کرد که معمولا بهشون می‌گن سند، ولی ترجیح می‌دیم بهشون بگیم محصول مدیریتی، چون ممکنه به شکل سند نباشن. این‌که چه سندهایی قراره تولید بشه و تو هرکدوم چه محتوایی وجود داشته باشه یکی از مهم‌ترین جنبه‌های اختصاصی‌سازیه. مثلا اگه موضوع اختصاصی‌سازی پم‌باکه، آیا لازمه ۱۳ سند مختلف برای ۱۳ نوع برنامه مدیریتیش داشته باشیم؟ اگه پروژه‌های سازمان خیلی پیچیده نباشن معمولا یه سند نسبتا ساده برای این کار کفایت می‌کنه، که البته محتواش تمام ۱۳ موضوع رو دربرمی‌گیره.
  • تعیین فرآیندها و فعالیت‌ها و اقدام‌ها: تو هر استاندارد تعدادی فرآیند، فعالیت و اقدام داره که همه این‌ها باید اختصاصی‌سازی بشن، یعنی مشخص بشه که به چه ترتیبی می‌خوایم اجراشون کنیم و جنبه‌های عملیشون چیه.
  • تعیین نقش‌ها و مسئولیت‌ها: اگه استانداردی که داره اختصاصی‌سازی می‌شه از نوع متودولوژی باشه و نقش و مسئولیت داشته باشه، باید اون‌ها رو هم اختصاصی‌سازی کنیم.

هرکدوم از این‌ها رو به شکل‌های مختلفی می‌شه اختصاصی‌سازی کرد:

  • حذف و اضافه: بعضی وقت‌ها می‌شه عناصری رو حذف و اضافه کرد. البته باید خیلی مراقب بود، چون موارد خیلی کمی رو می‌شه حذف کرد و مطمئن بود که به استاندارد صدمه نمی‌زنه. تحلیل کمی ریسک مثال خیلی خوبی از فرآیندهای پم‌باکه که اگه تناسبی با پروژه نداشته باشه می‌شه حذفش کرد. با این حال مثلا اگه فرآیند برنامه‌ریزی واکنش به ریسک رو حذف کنیم عملا سیستم رو ناقص کردیم. گاهی هم لازمه چیزهایی رو اضافه کنیم. مثلا اگه داریم پرینس۲ رو اختصاصی‌سازی می‌کنیم، استراتژی‌های مدیریتی پیش‌فرضش تمام جنبه‌های پروژه رو پوشش نمی‌ده و می‌تونیم از پم‌باک کمک بگیریم و استراتژی‌های باقیمونده رو بهش اضافه کنیم.
  • بزرگ و کوچیک کردن: حالا هر عنصر رو تا چه حد قراره تفصیلی کنیم؟ مثلا اگه صحبت از بودجه‌بندی پروژه‌س، تا چه حد قراره وارد جزئیات بشیم؟ یه مشکل خیلی رایج اینه که وقتی سعی می‌کنن استانداردی رو به کار بگیرن تو همه چیز زیاد از حد وارد جزئیات می‌شن و انقدر زحمت خودشون رو زیاد می‌کنن که عملا نمی‌تونن به نتیجه برسن. تو خیلی از موارد لازمه که ابعاد یه عنصر ساده‌تر و کوچیک‌تر از اون چیزی بشه که تو استاندارد توضیح داده شده و گاهی هم لازمه که اون رو خیلی بزرگ‌تر و کامل‌تر کنیم که با پروژه تناسب داشته باشه.
  • رسمی و غیررسمی کردن: قرار نیست همه چیز تو پروژه رسمی باشه. مثلا منشور پروژه پم‌باک یا حکم پروژه پرینس۲ لازم نیست حتما یه سند رسمی باشه؛ می‌تونیم یه جلسه نیم روزه بذاریم که همه افراد کلیدی توش باشن، درباره تمام جنبه‌هایی که لازمه صحبت کنیم و نتایج رو هم صورت جلسه کنیم. این صورت جلسه می‌شه خلاصه‌ای از محتوایی غیررسمی که کار منشور پروژه یا حکم پروژه رو می‌کنه. نمونه دیگه گزارش‌های پروژه‌س. مثلا اگه حساسیت زیاد نباشه می‌شه تعیین کرد که checkpoint reportها (گزارش‌های مدیران تیم‌ها به مدیر پروژه) صرفا یه تماس تلفنی باشه که هر هفته دو شنبه‌ها، حدود ساعت ۱۰ صبح انجام می‌شه و تو این مکالمه درباره فلان مسایل صحبت می‌کنن. این می‌شه اختصاصی‌سازی: دلیلی نداره همه چیز رسمی باشه.
  • ترکیب و تجزیه کردن: گاهی لازمه چند عنصر رو با هم ترکیب کنیم یا یه عنصر رو تجزیه کنیم به چنتا. مثلا ممکنه پروژه ساده باشه و بخواین مدیر ارشد و کاربر ارشد رو با هم ترکیب کنین؛ اگه شرایط خاصی رو رعایت کرده باشین هیچ اشکالی نداره. از طرف دیگه ممکنه شرایط ایجاب کنه که نقش هیات پروژه رو مثلا به دو سطح تجزیه کنین و یه سطح جدید به تصمیم‌گیری‌های پروژه اضافه کنین.
  • جانشین کردن: گاهی، تو شرایط خاص، ممکنه بعضی عناصر استاندارد رو با عناصر دیگه‌ای جانشین کنیم. مثلا ممکنه استانداردی که ۶ فرآیند داره رو اختصاصی کنیم و به جای اون ۶ فرآیند، ۴ فرآیند مخصوص خودمون رو بذاریم که هیچ ارتباط مستقیمی با فرآیندهای اصلی ندارن، ولی وقتی اون‌ها رو چک می‌کنیم ببینیم که تمام عملکردهای فرآیندهای پیش‌فرض توشون وجود داره. این کار رو البته باید با احتیاط انجام داد.

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

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

نوشته نادر خرمی راد (Nader Khorrami Rad)
بخش: آموزشی
مطالب مرتبط:

تفاوت enterprise و organization در PMBOK

بعضی‌ها تو تشخیص تفاوت بین enterprise environmental factors و organizational process assets تو PMBOK مشکل دارن که بخشی از این مشکل برمی‌گرده به درک تفاوت واژه‌های enterprise و organization. از طرف دیگه بعضی‌ها هم احتمالا کنجکاوین که به شکل کلی تفاوت این دو رو بدونین.

سازمان

organization

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

کلمه organization تو پم‌باک معمولا به معنی شرکت یا موسسه‌های مشابه اون به کار می‌ره و تو عبارت organizational environmental factor صرفا به معنی سازمانیه که داره پروژه رو اجرا می‌کنه (مثلا پیمانکار).

enteprise

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

معنی دوم enterprise مجموعه کار یا پروژه‌ایه که بزرگ و پیچیده باشه.

کلمه enterprise تو پم‌باک به هر دو معنی به کار رفته. تو اکثر جاها به معنی اوله، ولی تو عبارت enterprise environmental factors عمدتا به معنی دوم به کار رفته، یعنی عملا بهتره به جای «عوامل محیطی سازمان» به «عوامل محیطی پروژه» ترجمه بشه، هرچند که خود من تو کتاب‌هام اون رو اینطوری ترجمه نکردم، چون نگران بودم ابهام‌های دیگه‌ای به وجود بیاد.

تفاوت سرمایه‌های فرآیندی سازمان و عوامل محیطی پروژه

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

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

  1. برنامه‌های پروژه‌های قبلی
  2. مجموعه‌ای از قواعد که قراره برای تدوین هر نوع ساختار شکست کار استفاده بشه و از طرف PMO ارائه می‌شه
  3. ساختار سازمانی شرکت
  4. سیاست‌های شرکت
  5. فرهنگ شرکت و اخلاق کسایی که توش کار می‌کنن
  6. پراجکت سرور (با این فرض که وجود داره و استفاده می‌شه)
  7. سیستم اتوماسیون اداری
  8. سیستم مدیریت فرآیند
  9. شرح وظایف و مسئولیت‌های پست‌های سازمانی شرکت
  10. اخلاق و فرهنگ نیروهای مشاور پروژه
  11. اخلاق و فرهنگ مردمی که تو محدوده پروژه زندگی می‌کنن
  12. قیمت ارز
  13. قوانین و آیین‌نامه‌های صنفی و حکومتی
  14. وضعیت تحریم‌ها علیه ایران
  15. استانداردهای مرتبط
  16. نمونه قراردادهای موجود تو شرکت
  17. شرایط بازار
  18. یه ویکی که برای ثبت درس آموخته‌ها استفاده می‌شه
  19. رئیس جمهور وقت تو کشور!
  20. محل جغرافیایی شرکت
  21. محل جغرافیایی پروژه
  22. آب و هوای محل پروژه
  23. سرور اکسچنج که برای مدیریت ایمیل‌ها استفاده می‌شه
  24. گزارش‌هایی که تو پروژه‌های قبلی تهیه شده
  25. لیست ریسک‌هایی که تو پروژه‌های قبل شناسایی شده
  26. کتابخونه شرکت

خوب، این‌ها از سرمایه‌های فرآیندی سازمان هستن: ۱، ۲، ۴، ۶، ۷، ۸، ۱۶، ۱۸، ۲۳، ۲۴، ۲۵، ۲۶

و این‌ها از عوامل محیطی پروژه که ممکنه بهشون عوامل محیطی سازمان هم بگیم: ۳، ۵، ۹، ۱۰، ۱۱، ۱۲، ۱۳، ۱۴، ۱۵، ۱۷، ۱۹، ۲۰، ۲۱، ۲۲

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

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