پروفایل مدیریت پروژه مهدی بیات ورکشی

این وبلاگ حاصل دانش و تجربیات مهدی بیات ورکشی در رابطه با مدیریت پروژه است.

پروفایل مدیریت پروژه مهدی بیات ورکشی

این وبلاگ حاصل دانش و تجربیات مهدی بیات ورکشی در رابطه با مدیریت پروژه است.

مهدی بیات ورکشی
مدرس، محقق و مترجم مدیریت پروژه

دارای گواهی نامه های :
(PMP (Project Management Professional
PRINCE2 Practitioner

یکی از تکنیک هایی که تو استاندارده PMBOK5 تو فرایندهای مختلف توصیه شده که از اون استفاده بشه تکنیکیه به نام طوفان ذهنی، یا همون ‘Brain Storming’  . این تکنیک تو فرایندهای زیر می تونه استفاده شه:

  • تهیه منشور پروژه
  • تهیه برنامه مدیریت پروژه
  • گردآوری الزامات
  • شناسایی ریسک ها

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

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

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

گردانندگان جلسه ی تسهیل گر و ی منشیه تسهیل گره که بهش کمک می کنه.

حالا مراحل کار چیه؟ مراحلی که من عنوان می کنم صرفا ی روشه و کسایی دیگه ممکنه طور دیگه ای عمل کنن. روش من اینه:

قدم 1: لیست مدعوین و حضار جلسه رو تهیه کنید. در تهیه لیست حضار موارد بالا رو در نظر داشته باشین.

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

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

قدم 4: تسهیل گر و منشیش رو تعیین کنید. تسهیل گر می تونه خود مدیر پروژه باشه و منشی کارشناس برنامه ریزی و کنترل پروژه.

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

قدم 6 : قوانین جلسه رو برای حضار تشریح کنین. برای مثال:

  • همه ایده ها با ارزشن
  • تا حد ممکن ایده ها باید به صورت کامل شرح داده بشن
  • هر ایده روی یک برگه کاغذ ایندکس که در اختیار حضار قرار میگیره ثبت میشه
  • کیفیت ایده ها مطرح نیست و کمیت اونها بیشتر مد نظره

قدم 7: بعد از این که قوانین جلسه رو شرح دادین به هر نفر تعدادی مشخص ( مثلا 5 کاغذ ایندکس برای هر نفر) و ازشون بخاین هر نفر حداقل سعی کنه 5 الزامی که محصول می تونه داشته باشه رو شرح بده. حداقل 15دقیقه به حضار زمان بدین تو این مرحله. سعی کنید تو این 15 دقیقه اتاق جلسه کاملا ساکت و آرامش بخش باشه. ی پذیرایی مختصری داشته باشین و اگه کسی سوالی داشت با حداقل مزاحمت برای دیگرون به سوالش جواب بدین.

قدم 8: در انتهای این 15 دقیقه از حاضرین بخاین کاغذهای ایندکسی که از ایده هاشون پر شدن رو روی میز مقابلشون مثلا تو سمت راست و اگه کاغذی خالی مونده( نفر ایده ای نداشته) رو سمت چپ قرار بدین.

قدم 9: کاغذهای ایندکس پر شده رو جمع آوری کنین، ترتیب اونها رو بهم بریزین به طوری که معلوم نشه کدوم ایده برای چه کسی و از منشی بخاین اونا رو توطرف سمت چپ وایت برد اتاق جلسه بچسبونه

قدم 10: تو این مرحله از حضار بخاین تو اطراف وایت برد جمع بشن و شروع کنن به خوندن ایده های ثبت شده. احتمالا تعدادی از ایده ها باعث خنده حضار میشه که البته اگه تسهیل گر خوب بتونه مدیریت کنه اتفاقا خیلی هم مفید و جلسه رو از خشکی در میاره. مثلا ی ایده این می تونه باشه که " گوش کوب برقی باید قابلیت این داشته باشه که بشه که مثل ساعت زنگ دار وقتی توی ساعتی تنظیم میشه شروع به کار کنه تا آدم با سروصداش بیدار شه "

قدم 11: شروع کنین به دسته بندی ایدها، حذف ایده های تکراری، ترکیب ایده ها، وقتی افراد با ایده های مختلف دیگران روبرو می شن ممکنه ایده های جدیدی به ذهنشون برسه . تو این مرحله کاغذ های ایندکسی که خالی مونده بود رو بخاین افراد تکمیل کنن و به وایت برد بچسبونن.

قدم 12: بعد از اینکه ایده ها رو ترکیب، دسته بندی و تکمیل کردین از حضار بخاین که هر کدوم از اونها بر روی 15 کارت ایندکس امتیاز بده. این تعداد به خاطره اینه که هر فرد احتمالا امتیازات اول رو به ایده هایی که خودش داشته می ده و امتیازای دیگه رو به ایده هایی که از نظرش جالبن می ده. این امتیاز دهی می تونه با رسم یه خط کوچیک رو کاغذهای ایندکس باشه.

قدم 13: تو قدم آخر بر اساس مجموع امتیاز ثبت شده بر روی هر کاغذ ایندکس، ایده ها رو اولویت بندی کنین و 20 درصد از ایده های بالاترین اولویت رو به عنوان خروجی مشترک نظرات حضار در صورت جلسه ثبت کنین.

محسنات طوفان ذهنی:

  1. روشی ساده و قابل درکه برای بیشتره افراد
  2. کمک می کنه ایده های زیادی خوب یه موضوع تو مدت زمان کوتاهی جمع شه
  3. به افراد کمک می کنه به طور ناشناس خنده دار ترین ایده ها رو به زبون بیارن که گاهی همین نظرات خنده دار باعث میشه ایده های نابی شکل بگیرن
  4. حاصل تفکر گروهی و نه فردی
  5. هرایده و نظر به دنبالش ایده و نظره دیگه ای رو بدنبال داره

معایب طوفان ذهنی:

  1. همه افراد تو جلسه شرکت نمی کنن
  2. بره بعضی از افراد ممکنه کسالت آور باشه
  3. همه به ی اندازه تو این جلسه مشارکت نمی کنن
  4. این روش به نظراتی که بعد از اتمام جلسه ممکنه افراد تو ذهنشون بیاد توجهی نمی کنه

  • ۲۸ شهریور ۹۴ ، ۱۲:۵۷
  • مهدی بیات ورکشی

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

  • ۲۱ شهریور ۹۴ ، ۲۳:۲۴
  • مهدی بیات ورکشی

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

  • ۱۷ شهریور ۹۴ ، ۱۰:۳۳
  • مهدی بیات ورکشی

 

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

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

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

تو استاندارد PRINCE2 دلایل پروژه رو همراه با ی سری اطلاعات دیگه تو سندی به نام  Business Case (مورد کسب و کار، توجیح کسب و کار) ثبت می کنن و به تایید هیئت پروژه میرسونن و تو پایان هر مرحله مدیریتی مجددا ارزیابیش می کنن که مطمئن شن پروژه هنوز توجیح پذیره و یا دلایل توجیح پذیریش تغییر نکرده.

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

3)تعریف دقیق نقش ها و مسئولیت ها: در هر پروژه ای که شروع می شه باید نقش ها کاملا مشخص شده باشه و مسئولیت های هر نقش تعیین شده باشه. نکته ای که باید توجه بشه این لازم نیست که حتما کسایی که این نقش ها رو تو پروژه بازی می کنند همشون تو ایتدای پروژه تعیین شده باشه. به طور مثال نقش کارشناس برنامه ریزی و کنترل پروژه که استاندارد تقریبا به این نقش میگه پشتیبان پروژه (Project Support)  باید دقیقا مشخص شده باشه چه کارهایی رو باید در راستای موفقیت پروژه انجام بده و اینکه دیگران چه انتظاراتی رو ازش دارن. 

4)مدیریت مبتنی بر مراحل: استاندارد PRINCE2 معتقده که از اونجایی که پروژه تو بستر محیط یک موجود پویاست که پیوسته می تونه در حال تغییر باشه لازمه که به طور منطقی به تعدادی مراحل غیر همپوشان تفکیک بشه ، تو انتهای هر مرحله تحویل شدنی های تولید شده در طول مرحله رو به هیئت پروژه ارائه بدیم و تاییدشون رو بگیریم، تو انتهای هر مرحله صرفا برای مرحله بعد برنامه ریزی کنیم نه بیشتر، بازه پایان هر مرحله و شروع مرحله بعد رو فرصتی قرار بدیم که مجددا از یه دیدگاه کلان به پروژه نگاه کنیم تا متوجه بشیم هنوز پروژه برامون ارزشمنده، اطلاعاتمون رو درباره پروژه و محیطش بروز کنیم، درس هایی که تو مراحل قبل رو یاد گرفتیم ثبت کنیم و ازشون تو مراحل بعدی استفاده کنیم. اندیشمندی میگه برنامه ریزی یعنی اینکه به من بگید امروز باید چه کاری باید انجام بدم و نه بیشتر. 

5)مدیریت مبتنی بر سطوح:  استاندارد PRINCE2 اعتقاد داره که سطوح مدیریتی یک پروژه تو چهار سطح زیر خلاصه میشن:

  • سطح سازمان یا طرح: که مدیران ارشد سازمان یا مدیران طرح  قرار دارن.
  • سطح هدایت: که هیئت پروژه درونش قرار داره که شامل مدیر اجرائی، کاربر ارشد و تامین کننده ارشد میشن.
  • سطح مدیریت: که مدیر پروژه و پشتیبان پروژه درونش قرار دارن
  • سطح تحویل: که سرپرستان تیم های اجرائی درونش قرار دارن.

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

6)تمرکزبر محصول پروژه: دستندرکاران پروژه باید همیشه این موضوع رو به یاد داشته باشن که هدف تحقق محصوله نه انجام کارهای مورد نیاز برای تحقق محصول. برای این منظور باید تا حد امکان محصولاتمون رو بشناسیم و ویژکی هاشون رو ثبت کنیم و تغییراتشون رو مدیریت کنیم تا در نهایت محصول مورد انتظاره مشتری رو بهش تحویل بدیم. این موضوع به ظاهر کاملا مشخص و مبرهنه ولی واقعا در بسیاری از مواقع مورد غفلت واقع میشه و پروژه رو به بیراهه می کشونه. احتمالا پروژه هایی رو دیدید که هیچ کس دوست نداره تموم شه و معمولا هم به این راحتیا تموم نمیشه.به چه دلیل!!!!!!!!

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


  • ۱۵ شهریور ۹۴ ، ۱۰:۵۶
  • مهدی بیات ورکشی
استاندارد PRINCE2 از 4 عنصر تشکیل میشه که عبارتند از:
  • اصول
  • مضامین
  • فرایندها
  • محیط 
اصول در واقع ستون های استاندارد رو تشکیل میدن که اگه از یکیشون تو پروژه غفلت شه دیگه نمیشه گفت پروژه مطابق ارزشهایی که استاندارد به اون ها معتقده پیش رفته. این اصول هفت گانه عبارته از:
  1. توجه همیشگی به توجیه پذیری پروژه
  2. تمرکز بر محصولات پروژه
  3. مدیریت مبتنی بر مراحل
  4. مدیریت مبتنی بر سطوح
  5. یادگیری از تجربیات گذسته
  6. تعریف دقیق نقش ها و مسئولیت ها
  7. سفارشی سازی استاندارد با شرایط پروژه
بره این که بتونیم پروژمون رو بر پایه این ستونها بنا کنیم باید جنبه هایی رو تو پروژه بدقت مورد توجه قرار بدیم و تحت کنترل و پایش قرار بدیم. این جنبه ها که تو استاندارد بهش میگن مضامین 7 مورد زیر اند:
  1. کیفیت
  2. برنامه 
  3. تغییرات
  4. ریسک
  5. پیشرفت
  6. سازمان
  7. مورد کسب و کار
تو استاندارد PRINCE2 بره اینکه بتونیم پروژمون بر پایه 7 ستون بنا کنیم و 7 جنبه حیاتی پروژه رو تحت کنترل داشته باشیم هفت فرایند معرفی میشه و ارتباطات اونها تحت ی روش شناسی مشخص تعیین میشه. این فرایندها عبارته از:
  1. راه اندازی پروژه
  2. آغازش پروژه
  3. مدیریت شرایط حدی مرحله
  4. هدایت پروژه
  5. کنترل مرحله
  6. مدیریت تحویل محصول
  7. خاتمه پروژه
استاندارد معتقده که تو هر پروژه ای بره اینکه ما اصول روبنا کنیم و مضامین رو تحت مدیریت دربیاریم و فرایندها رو استقرار بدیم لازمه که به شرایط پروژه توجه کنیم و سعی کنیم از طریق درک درست از محیط استاندارد رو به نحوی تطبیق بدیم که بیشترین اثربخشی رو برامون داشته باشه.
  • ۰۵ شهریور ۹۴ ، ۰۰:۳۷
  • مهدی بیات ورکشی

تو استاندارد PMBOK تاکید شده که ما بره اینکه بتونیم کنترل بیشتری بر روی ابعاد مختلف (حوزه های دانشی) پروژه داشته باشیم باید اون رو به اجزا کوچک تر که قابلیت مدیریت بیشتری داره تفکیک کنیم که مبتنی بر تحویل شدنی های پروژه باشه که استاندارد اسمش میزاره WBS(work breakdown structure).

تو استاندارد PRINCE2  به جای WBS از مفهومی به نام PBS(product breakdown structure) نام برده شده. به این ترتیب که ما می بایست محصولات پروژه رو به اجزاء کوچکتر تجزیه کنیم و ویژگی های اجزا رو به دقت تعیین کنیم و در نهایت پروژه رو برای ایجاد محصولاتی که ویژگی هاشون به دقت تعیین شده اجرا کنیم و همیشه خاطرمون باشه که هدف نهایی محصول پروژست نه کارهایی که برای ایجاد محصول پروژه قراره انجام بشه.

حالا سوال اینجاست که فرق بین WBS و PBS چیه؟

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

  • سند تهیه شده توسط پیمانکار
  • سند تایید شده توسط مشاور
  • سند تصویب شده توسط کارفرما

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

  • ۰۵ شهریور ۹۴ ، ۰۰:۰۴
  • مهدی بیات ورکشی

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

  1.  جمع آوری الزامات
  2. شناسایی ریسک ها
  3. اجرای تحلیل کمی ریسک

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

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

  1. جلسات حضوری
  2. ویدئو کنفرانس
  3. تماس تلفنی
  4. نامه الکترونیک
  5. نامه نگاری معمول

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

به طور کلی می تونیم مراحل یه مصاحبه اثربخش رو تو گام های زیر خلاصه کنیم:

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

2) تعیین هدف از انجام مصاحبه و تهیه سوالات مربوطه. اول بهتره که هدف از مصاحبه رو تعیین کنید که واقعا دنبال چه چیزی هستین . بعد از اون بهتره سوالات را با دقت و حوصله تهیه کنید.(مسلما باید این کارها رو کاغذ بیارین)

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

4) معرفی افراد حاضر در جلسه مصاحبه به شخص مصاحبه شونده. بهتره خودتون و کسایی که همراتون هستن رو به مصاحبه شونده معرفی کنید که مصاحبه شونده بدونه به چه کسایی داره اطلاعات میده و از این جهت آسوده خاطر باشه.

5) شرح چرایی نیاز به مصاحبه برای شخص مصاحبه شونده. در ابتدای جلسه مصاحبه بهتره که خیلی کوتاه هدفتون رو از مصاحبه شرح بدید و صادقانه به شخص مصاحبه شونده بگید چرا فکر می کردید که ایشان مناسب هدف شما از مصاحبه هستن.

6) شروع پرسش سوالات با سولاتی که پاسخ های باز دارند. قبل از اینکه سوالات تخصصی تر که از پیش آماده کردید رو بپرسید بهتره با ی سری سوالات کلی مصاحبه رو شروع کنین. نظیر:

  • در پروژه های گذشته با چه مشکلاتی مواجه بوده اید؟
  • در این پروژه بیشتر شما نگران چه چیزی هستید؟
  • چه چیزی در این پروژه ممکن است با مشکل مواجه شود؟
  • چه فرصت هایی با انجام این پروژه به دست خواهیم آورد؟

7) برای واضح تر شدن پاسخ های مصاحبه شونده سوالاتی رو در ارتباط با  با پاسخ ها طرح کنید.

8) سوالات از قبل طراحی شده را بپرسید. مسلما این سوالات از سوالات قبلی خاص ترن و شما سعیتون این خواهد بود که در مورد یه موضوع کاملا خاص نظر مصاحبه شونده رو استخراج کنید. نظیره:

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

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

10) به سایر ایده هایی که طی مصاحبه مطرح می شن توجه کنید. ممکنه ایده هایی در طول مذاکره مطرح بشن که قبلا دربارشون فکر نشده باشن. خودتون رو آماده کنید که این ایده ها رو در مسیر مصاحبه هدایت کنید و اجازه ندید موضوع بحث منحرف بشه.

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

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

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

14) از مصاحبه شونده به خاطر وقتی که در اختیار شما قرار داده  تشکر کنید.

در انتها برای موفقیت بیشتر مصاحبه موارد زیر رو مد نظر قرار بدید:

  • سعی کنید جزئیات بیشتری رو به مصاحبه شونده بدید و بره این منظور از عکس ها و  نقشه ها کمک بگیرید.
  • بهتره که بیش از یک نفر مصاحبه کننده تو جلسه مصاحبه حاضر باشن. مثلا ممکنه یه نفر سوالات رو بپرسه یه نفر پاسخ ها رو ثبت کنه نفر دیگه به دقت زبان بدن و ارتباطات غیر کلامی رو زیر نظر بگیره. البته می تونید از ضبط صدا یا تهیه فیلم هم بره این منظور کمک بگیرید.
  • بعد از این که سوالی رو مطرح کردید و پاسخی رو گرفتید چند لحظه مکث کنید تا دو طرف زمان این رو پیدا کنن ذهن خودشون رو بازسازی و آماده کنن.
  • به ارتباطات غیر کلامی اهمیت بیشتری بدین و مطمئن باشین اطلاعات زیادی رو از این نوع ارتباط کسب می کنین. (همانطور که میدونین ثابت شده 55 درصد ارتباطات به صورت غیر کلامی صورت می گیره)
  • در نهایت در ارتباط با اطلاعاتی که در نتیجه مصاحبه استخراج می کنیم باید حساس باشیم تا اطلاعات غیر واقعی رو ثبت نکنیم، جزئیات رو از قلم نندازیم، دچار سوء تعبیر نشیم و خودمون در مقام قضاوت نشینیم.
  • ۰۳ شهریور ۹۴ ، ۲۳:۵۱
  • مهدی بیات ورکشی

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

  1. واحد طرح و برنامه
  2. واحد تضمین کیفیت
  3. واحد سیستم ها و روش ها
  4. واحد تحقیق و توسعه
  5. دفتر مدیریت پروژه ها
  6. و موارد دیگه

نکته مشترکی که بین وظایف محوله  هر کدوم از این واحدها وجود داره اینه که می تونیم وظایفشون رو به سه دسته تقسیم بندی کنیم:

  1. وظایف تکراری و روتین. مثلا در دوره های تکراری روزانه، هفتگی یا ماهیانه گزارشاتی تهیه می کنن، تو جلسات شرکت می کنن، اطلاعاتی جمع آوری می کنن و یا کاری دیگه از این قسم رو انجام میدن.
  2. وظایف موردی و خاص. به طور مثال برحسب دستورمدیران رده بالاتر گزارش خاص غیر روتینی آماده می کنن ، برای بازدید کارفرما یا ارگان ها و سازمان های دیگه پرزنتی آماده می کنن. یا اطلاعاتی رو بر حسب مورد و نیاز سطوح بالاتر تهیه می کنن و در اختیارشون قرار میدن.
  3. وظایف بهبود و توسعه ای. که غالبا رسالت اصلی این قسم واحد ها در سازمان هم این دسته از وظایفه که گاها با افتادن تو دام وظایف قبلی کارکنان این واحدها فراموشش می کنن.به طور مثال ارزیابی رضایت سنجی ذینفعان سازمان، استقرار سیستم های مدیریتی و کیفی نظیر IMS ، استقرار سیستم های مدیریت پروژه نظیر PMBOK ، استقرار سیستم های نرم افزاری نظیر CRM و PMIS، و کارهای دیگه از این قسم انجام میدن که البته فرقی که این دسته وظایف با دسته قبلی داره اینه که ماهیتا این امور در تعریف پروژه ها قرار می گیرن هرچند شاید خیلی از مواقع کارکنان از این موضوع غافلند.

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

به نظرمی رسه راهکاری که می تونه  راهگشا باشه استفاده از مفاهیمی که تو مدیریت پروژه های نرم افزاری پیش از این استفاده می شده باشه که همون "مدیریت پروژه  چابکه".

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

  • تصویر درستی از محصولی که می تونه نتایج مورد نظر ما رو به همراه داشته باشه نداریم.
  • پروژه تکرار پذیری کمی داره یا اصلا تکرار پذیر نیست.
  • نرخ تغییرات در محصول و محیط پروژه بسیار بالاست.
  • بر پایه خلاقیت و تعاملات و توانمندی های انسان ها استواره.

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

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

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

تو پست های بعدی سعی می کنم درباره اینکه چطور سفارشی سازی اسکرام رو برای به کار بستن تو پروژه های واحد طرح و برنامه انجام بدیم توضیح میدم.

  • ۰۳ شهریور ۹۴ ، ۲۳:۵۰
  • مهدی بیات ورکشی

سلام

من مهدی بیات ورکشی هستم. امروز در تاریخ 94/05/27 برای به اشتراک گذاشتن دانسته ها و آموخته های خودم  این وبلاگ رو ایجاد کردم. آرزو و هدف نهایی من اینه که این وبلاگ مرجعی برای علاقه مندان و دانشجویان و شاغلان حوزه مورد علاقم باشه. پس به امید اون روز

  • مهدی بیات ورکشی