مقابله با 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)

سخنرانی من در PMI BeLux Day 2014

امسال هم مثل سال گذشته برای سخنرانی تو کنفرانس PMI بلژیک انتخاب شدم. عنوان موضوع امسال من اینه: Project managers are biased too.

PMI BeLux Day 2014

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

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

 

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

 

  بازی A بازی B
اگه شیر بیاد: ۱۰۰ هزار تومن جایزه ۳۰۰ هزار تومن جایزه
اگه خط بیاد: هیچی ۱۰۰ هزار تومن جریمه

 

خوب، جوابتون A بود یا B؟

اگه جوابتون A باشه، مثل اکثر افراد، دچار یکی از همون مشکلایی تصمیم‌گیری هستین. امید ریاضی برد تو بازی اول ۵۰ هزار تومنه، در حالی که تو بازی دوم ۱۰۰ هزار تومنه؛ یعنی تو بازی دوم انگار دو برابر پول گیرمون میاد. با این حال چون ریسک پول از دست دادن داره،‌ اکثر افراد بازی اول رو انتخاب می‌کنن.

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

البته یه استثنا هم وجود داره: اگه مبلغ باخت گزینه دوم کل دارایی آدم باشه، طوری که در صورت باخت مجبور بشه کل دار و ندارش رو بده بره و بعد هم گوشه خیابون بخوابه، اونوقت قطعا بازی اول بهتره.

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

انسان بدوی

دلیل وجود داشتن این bias هم مثل همه اون‌های دیگه اینه که برای بقای انسان بدوی که تو محیط‌های خیلی خطرناک زندگی می‌کرده لازم بودن. «به دست آوردن» برای اون آدم‌ها یه مقدار غذای بیشتر بوده، در حالی که «از دست دادن»ها معمولا به قیمت جونشون تموم می‌شده. به همین خاطر این bias بر اساس انتخاب طبیعی در اون‌ها درونی شده.

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

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

پروژه‌های نمونه برای پراجکت

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

چون خیلی‌ها به دنبال پروژه‌های نمونه بودن، به این نتیجه رسیدم که بهتره فعلا دو پیوست انتهایی کتاب پراجکت ۲۰۱۰ که پروژه‌های نمونه‌ش بود رو در اختیار خواننده‌ها بذارم تا زمانی که کتاب اصلی رو بتونم تهیه کنم.

پروژه‌های نمونه برای پراجکت

اگه علاقه‌مند باشین می‌تونین کتاب رو به رایگان از صفحه پروژه‌های نمونه برای Microsoft Project 2010 دانلود کنین.

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

چطوری می‌شه درس آموخته‌های پروژه رو مدیریت کرد؟

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

ولی واقعا چطوری باید این کار رو کرد؟

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

برای این‌که بتونیم این کار رو بکنیم شرایطی وجود داره:

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

 

حالا چطوری؟

راه حلی که من همیشه پیشنهاد می‌کنم استفاده از ویکی (wiki) یا انجمنه (forum). اولی برای تیم‌هایی که مهارت‌های کامپیوتری بالاتری دارن مناسبه (مثلا اعضای تیم پروژه‌های نرم‌افزاری) و دومی برای بقیه تیم‌ها.

wiki

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

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

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

 

این سیستم عملا دو کار رو همزمان انجام می‌ده:

  • ثبت درس آموخته‌های پروژه
  • همفکری با همکاران، تقویت ارتباط‌های پروژه، افزایش شفافیت و …

 

که هردوشون خیلی مفیدن.

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

چطوری با جنبه‌های فنی پروژه‌هامون آشنا بشم؟

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

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

متاسفانه خیلی‌ها فکر می‌کنن این کار بده و باعث می‌شه فکر کنین کار بلد نیستین. ولی این اصولی‌ترین و حرفه‌ای‌ترین شکل برخورد با کاره، چون:

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

 

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

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

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

از حرف تا عمل

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

مسئله

ماجرا اینه که:

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

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

 

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

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

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