وقتی حجم و فوریت کارها بالا میره باید چیکار کرد؟ شاید اکثر آدم‌ها به زبون نیارن، ولی کاری که عملا می‌کنن اینه که سعی می‌کنن سریع‌تر و بیشتر کار کنن. این یه اشتباه مطلقه!
روبرویی با بحران
وقتی تو چنین وضعیتی قرار می‌گیرین به جای این‌که بلافاصله سرعت یا مقدار کارتون رو اضافه کنین، بشینین و خیلی سر فرصت به این فکر کنین که چطوری باید عمل کنین. آیا می‌شه روش کار رو عوض کرد تا بشه اون رو به موقع تموم کرد؟ آیا می‌شه بعضی کارها رو فعلا معلق کرد و روی کارهای ضروری تمرکز کرد تا به موقع تموم بشن؟ اصلا اگه به موقع تموم نشه چه اتفاقی می‌افته؟
باید تمام راه‌حل‌ها رو سنجید و اونی که به نظر بهتر از همه میاد رو انتخاب کرد. افزایش سرعت و مقدار کار (مثلا تعداد ساعتی که تو روز کار می‌کنیم) معمولا از بهترین انتخاب‌ها نیست. یکی از مشکلاتش هم اینه که کیفیت رو می‌بره پایین و این معمولا به ضررمون تموم می‌شه.
مشکل بزرگ‌تر برای کسایی که هروقت فشار کارشون بالا میره بدون این‌که به راه‌حل‌ها فکر کنن صرفا بیشتر به خودشون فشار میارن اینه که عملا تو همین وضعیت باقی می‌مونن و هر از چندی با همین موقعیت برخورد می‌کنن و دوباره فقط به خودشون بیشتر فشار میارن؛ یه جورایی درجا می‌زنن. اگه به جای اون روی راه‌حل‌ها فکر کنین و پیاده‌سازی‌شون کنین، هر بار یه مرحله پیشرفت می‌کنین؛ پیشرفتی که برای کسایی که تو حوزه‌های …
احتمالا می‌دونین که برای PRINCE2 دو سطح آزمون هست، Foundation که اول برگزار می‌شه و عمدتا متمرکزه روی دونستن مفاهیم کلی و اصطلاحات، و بعد سطح Practitioner که پیشرفته‌س و همه چیز رو در بر می‌گیره.
هیچکدوم از این دو سطح الان پیش‌نیاز دوره ندارن؛ هر کسی می‌تونه خودش مطالعه کنه و آزمون بده. تنها پیش‌نیاز این بود که قبل از گواهی Practitioner باید گواهی Foundation رو گرفته باشین. از ابتدای ماه آینده میلادی تبصره‌ای برای این پیش‌نیاز در نظر گرفته می‌شه: کسایی که گواهی PMP یا یکی از گواهی‌های IPMA رو داشته باشن می‌تونن بدون داشتن گواهی PRINCE2 Foundation تو آزمون PRINCE2 Practitioner شرکت کنن.
پ.ن. اگه یادتون باشه قبلا اعلام کرده بودم که دیگه می‌تونیم آزمون‌های پرینس۲ رو تو ایران برگزار کنیم و البته از روی احتیاط گفته بودم که «فعلا». خوب، متاسفانه ماجراهای سیاسی بین انگلستان و ایران چندان هم خوب پیش نرفته و بعد از این نمی‌تونیم آزمون‌ها رو آنلاین برگزار کنیم. تنها حالت ممکن اینه که آزمون رو کاغذی و با حضور من (ناظر رسمی) بگیریم، که اون هم به خاطر شرایط من خیلی محدود می‌شه و از طرف دیگه تضمینی هم وجود نداره که همینش هم تا کی برقرار باشه.
یکی از خواننده‌ها از من در مورد منابع مفید برای بهبود مدیریت اسناد پروژه‌ها پرسیده بود، و این البته اولین باری نیست که چنین سوالی از من پرسیده می‌شه.
جواب من معمولا اینه که نمی‌تونین تو منابع معتبر دنبال چیزهایی باشین که تو خیلی از پروژه‌های ایرانی استفاده می‌شه و انتظار دارن. مثلا حتی عبارت DCC (مخفف document control center یا یه چیزی شبیه اون) که تو خیلی از پروژه‌های ایرانی به عنوان یه عبارت استاندارد استفاده می‌شه هم به هیچ وجه رایج نیست و تو متون به چشم نمی‌خوره. تو چنین فضاهایی، مسئله اصلی یه دانش جامع و عمیق نیست؛ بخش عمده‌ایش در مورد عرف کاریه و بخش دیگه‌ایش در مورد فرآیندهایی که مثلا تو بخش مهندسی وجود داره. بهترین منبع برای یادگیری همه این‌ها هم خود محیطیه که توش کار می‌کنین. یعنی از یه طرف باید با مدیران واحدهای مهندسی صحبت کنین و با فرآیند کارشون آشنا بشین و از طرف دیگه با کسایی که تو بخش مدیریت اسناد کار می‌کنن صحبت کنین و عرف‌هاشون رو بشناسین.
سیستم‌های رایجی که برای مدیریت اسناد تو شرکت‌های ایرانی استفاده می‌شه به اندازه کافی موثر نیست. برای آزمایش می‌تونین چک کنین که سیستمتون می‌تونه خیلی سریع جواب چنین سوال‌هایی رو بهتون بده یا نه:
کدوم اسناد تا الان تکمیل شدن، ولی هنوز تایید نشدن؟
جواب کدوم نامه‌ها رو باید حداکثر تا پایان امروز بدیم؟ جواب کدوم نامه‌ها به تاخیر …
واقعیت اینه که اکثر آدما زیاد از حد از نمودارهای دایره‌ای استفاده می‌کنن، اون هم در حالی که این نمودارها مجموعا زیاد قوی نیستن. تو این مطلب می‌خوام در مورد شیوه درست استفاده از نمودارهای دایره‌ای توضیح بدم.
هروقت می‌خوایم نمودار بکشیم باید به این فکر کنیم که هدفمون چیه و دقیقا چه چیزی رو می‌خوایم منتقل کنیم. مثلا اگه می‌خوایم تغییر یه مقدار پیوسته رو نشون بدیم (مثلا پیشرفت‌های تجمعی)، قاعدتا بهتره از نمودارهای خطی استفاده کنیم، چون پیوستگی رو خوب به تصویر می‌کشن. اگه پیوستگی نداشته باشن (مثلا مقدارهای دوره‌ای به جای مقدارهای تجمعی)، بهتره از نمودار خطی استفاده نکنیم، چون اشتباها پیوستگی رو به ذهن القا می‌کنن.
خوب، حالا چه موقع باید از نمودارهای دایره‌ای استفاده کنیم؟
ببینین نظرتون در مورد نمودار پایین چیه:
این نتیجه یه مطالعه جالبه از Standish Group، که نشون می‌ده چقدر قابلیت‌های اضافه تو نرم‌افزارها داریم. این برای کسایی که تو پروژه‌های نرم‌افزاری کار می‌کنن خیلی مهمه، چون نشون می‌ده که به اندازه کافی روی ارزش تجاری گستره پروژه‌مون تمرکز نداریم. مثلا اون ۴۵ درصد قابلیت‌هایی که تقریبا هیچوقت استفاده نمی‌شن رو می‌تونیم تولید نکنیم و در عوض هزینه و زمان پروژه رو نصف کنیم. مدیریت این ماجرا تو پروژه‌هایی که چابک اجرا می‌شن خیلی راحت‌تره.
این سوال خیلی رایجه… آیا یه مدیر پروژه باید جنبه‌های فنی پروژه رو بشناسه؟ آیا باید یه متخصص باشه؟
قدیم جواب قطعا مثبت بود. اصولا هم کسی مدیر پروژه می‌شد که متخصص خیلی باتجربه‌ای تو جنبه‌های فنی اون پروژه بود. ولی الان اوضاع فرق کرده. الان اعتقاد داریم چیزی که قبلا وجود داشته مدیریت پروژه حرفه‌ای نبوده و الان انتظار داریم که آدم‌ها واقعا متخصص تو مدیریت پروژه باشن. این امکان هم به نظر وجود داره که جنبه‌های مدیریتی پروژه‌ها رو از اون‌ها انتزاع کنیم و در نتیجه کاری کنیم که برای همه یکسان باشه. به همین خاطره که مثلا PMBOK و PRINCE2 برای هر نوع پروژه‌ای قابل استفاده هستن.
الان بین کسایی که تو این حوزه صاحب نظر هستن دو گرایش وجود داره:
این‌که «لازم» نیست مدیر پروژه جنبه‌های فنی پروژه رو بشناسه، ولی اگه آشنا باشه خیلی هم خوبه.
این‌که «لازم» نیست مدیر پروژه جنبه‌های فنی پروژه رو بشناسه و حتی بهتر هم هست که نشناسه!
شاید گرایش دوم به نظرتون عجیب بیاد. خودتون رو بذارین جای یه کسی که تو مدیریت پروژه وارده و الان مدیر پروژه‌ای شده. حالا اگه یه متخصص تمام عیار تو جنبه‌های فنی پروژه باشین چه اتفاقی می‌افته؟ آیا می‌تونین توش دخالت نکنین؟ یا این‌که دایما می‌خواین کارهای فنی رو چک کنین و هر چیزی که ایده‌آل کار نشده بود رو تذکر بدین که بهتر کنن؟ بقیه رو نمی‌دونم، ولی برای من که سخته!
خیلی‌ها این مشکل رو دارین که لازمه برآوردهایی از کارشناس‌ها دریافت کنین و برآوردها خیلی دست بالا هستن. حالا مسئله اینه که چطوری می‌شه برآوردهای واقع‌بینانه‌تری دریافت کرد.
همیشه باید قبل از انتخاب راه حل، مسئله رو ریشه‌یابی کرد. چرا برآوردها دست بالا هستن؟
دلیلش اینه که می‌رین مثلا از یه طرح می‌پرسین چقدر طول می‌کشه فلان کار رو انجام بدی، اون هم مثلا می‌گه بیست روز، بعد اگه بشه بیست و یه روز و هنوز تموم نکرده باشه می‌رین سرزنشش می‌کنین که چرا عقبی. خوب، اون هم خیال خودش رو راحت می‌کنه و از اول می‌گه سی و پنج روز!
به این می‌گن حاشیه اطمینان موضعی (padding) و خیلی چیز بدیه، چون کنترل شده نیست (هیچوقت همه کارهای پروژه در بدبینانه‌ترین حالت ممکن تموم نمی‌شن).
پرده اول
خوب، حالا چطوری می‌شه این مشکل رو حل کرد؟ قطعا اولین و مهم‌ترین قدم اینه که سرزنش کردن رو از برنامه کاریمون حذف کنیم تا خیال همه راحت باشه و احساس نکنن لازمه که حاشیه اطمینان به برآوردهاشون اضافه کنن. مثلا وسط پروژه می‌تونین یکی از دو قضاوت زیر رو در مورد واحد طراحی سازه داشته باشین:
شما کارتون عقبه و پروژه رو به تاخیر انداختین! چرا؟
الان عملکرد شما مهم‌ترین عاملیه که جلوی بیشتر به تاخیر افتادن پروژه رو می‌گیره. چیکار می‌تونیم بکنیم که کارتون سریع‌تر پیش بره؟
این دوتا عملا یکی هستن، ولی اولی سازنده نیست، فقط سرزنشه و …
ایمیلی داشتم که سوال جالبی پرسیده بود؛ این‌که نویسنده گاهی تو درج مقادیر یا سایر مراحل کار اشتباه می‌کنه و می‌خواست بدونه چطوری می‌تونه اشتباه‌هاش رو به حداقل برسونه.
این سوال واقعا خوبه، چون اکثر آدم‌ها وقتی متوجه می‌شن که گاهی اشتباه می‌کنن، تنها اقدامی که می‌کنن اینه که سعی می‌کنن بیشتر حواسشون رو جمع کنن. ولی این واقعا کافی نیست و دنبال روش بودن واقعا خوبه.
این رو هم باید در نظر داشت که کاری که صد در صد ماشینی انجام نمی‌شه احتمال اشتباه داره و همیشه باید این رو بپذیریم؛ مسئله فقط اینه که مقدار این اشتباه‌ها رو به حدی پذیرفتنی برسونیم. از اون گذشته، هر اشتباه که بکنین احتمالا یه مقدار جایگاهتون تو شرکت افت می‌کنه، هرچند جزئی.
نکته اول
شاید بشه تو روش کارتون تجدید نظر کنین. پتانسیل خطای روش‌های مختلف به یه اندازه نیست. وقتی داریم یه سیستم شکل می‌دیم این از مهم‌ترین چیزایی که در نظر می‌گیریم؛ این‌که روشی که برای کار انتخاب کردیم چقدر احتمال اشتباه داره. مثال: بعضی‌ها کل محاسبات پیشرفت رو تو اکسل انجام می‌دن، که البته من به هزار و یک دلیل باهاش مخالم. ولی از اون که بگذریم می‌شه از جنبه پتانسیل اشتباه هم اون رو بررسی کرد. تو چنین فایلی که مثلا ممکنه ده هزارتا آیتم وجود داشته باشه چندتا فرمول برای خلاصه‌سازی اطلاعات وجود داره؟ منظورم انواع میانگین‌گیری‌های وزنیه. مثلا ممکنه هزارتا …
یه مشکل خیلی رایج وجود داره که فقط هم در مورد پروژه‌ها نیست، در مورد مدیریت عملیات هم وجود داره و حتی تو مدیریت زندگی شخصی: این‌که قبل از فکر کردن به سوال‌هایی از نوع «چرا» به سوال‌هایی از نوع «چگونه» فکر می‌کنیم. مثلا وقتی قراره پروژه‌ای رو انجام بدیم، فقط داریم به این فکر می‌کنیم که چطوری باید انجامش بدیم و برنامه‌های ناقصی می‌ریزیم برای «کار» کردن.
حدس می‌زنین چرا به جای کار نوشتم «کار»؟
کسایی که PRINCE2 خونده باشن می‌دونن که یکی از اصول زیربناییش اینه که باید به جای «کار» روی «محصول» متمرکز بشیم. هدف کار کردن نیست، محصول تولید کردنه. این تمرکز روی کار مشکلای خیلی زیادی به وجود میاره؛ مثلا:
فکر می‌کنیم زیاد کار کردن ارزشه؛ در نتیجه دایما سعی می‌کنیم بیشتر و بیشتر کار کنیم و هرچقدر بیشتر کار کنیم، کیفیت کارمون کمتر می‌شه و ذهنمون بیشتر از محصول فاصله می‌گیره. در نهایت کیفیت محصول هم به تبع کیفیت کار افت می‌کنه.
انقدر برای کار ارزش قایلیم که اون رو به نوعی مقدس می‌دونیم؛ تغییرش نمی‌دیم. در حالی که وقتی تمرکزمون روی محصول باشیم، اون نقطه ثابت به جای کار تبدیل می‌شه به محصول و آماده‌ایم که روش کار کردمون رو هر وقت که لازم بود عوض کنیم، طوری که بهتر به محصول برسیم. نتیجه‌ش می‌تونه کیفیت بالاتر، سرعت بیشتر، هزینه کمتر و به طور کلی منافع بیشتر باشه.
خیلی‌ها در مورد تفاوت اصطلاح‌های plan و schedule از من می‌پرسن و دیگه به نظر میاد به جای ایمیل باید اینجا توضیح داد:
schedule یعنی زمان‌بندی و scheduling یعنی زمان‌بندی کردن… برنامه‌ریزی جنبه زمانی پروژه؛ همون چیزی که در مرکز فعالیت‌های اکثر شماهایی که کارتون اصطلاحا کنترل پروژه‌س قرار می‌گیره. معمولا رایجه که برنامه‌ریزی منابع (به جز برنامه‌ریزی‌های خاص منابع انسانی مثل آموزش) هم جزئی از زمان‌بندی دونسته می‌شه. معمولا هزینه و گستره همراه زمان‌بندی تو یه «مدل» قرار می‌گیرن، ولی مفاهیم مستقلی هستن و وقتی صحبت از زمان‌بندیه معمولا شامل گستره و هزینه نمی‌شه.
plan یعنی برنامه و planning یعنی برنامه‌ریزی. منظور از برنامه معمولا کل برنامه‌ریزی‌هاییه که برای پروژه لازمه، یعنی علاوه بر برنامه‌ریزی زمان، شامل هزینه، گستره، منابع انسانی، تدارکات و همه چیزهای دیگه هم می‌شه.
اصطلاح‌های replan و reschedule هم به معنی هر نوع بازبینی تو برنامه یا زمان‌بندی هست. این بازبینی می‌تونه برای اعمال تغییرات درخواستی کارفرما باشه، می‌تونه به این خاطر باشه که ایده‌های بهتری برای اجرای کار به ذهنمون رسیده، برای جبران عقب افتادگی‌ها و هر چیز دیگه‌ای.
اصلاح دیگه‌ای هم تو این حوزه هست که البته تو همه متون استفاده نمی‌شه، ولی باز هم عمومیت داره: catch-up plan یا catch-up schedule. این می‌شه نوع خاصی از replan …
پیش‌نیاز آزمون سه سال تجربه مرتبط، حدود یک سال تجربه پروژه و ۳۵ ساعت آموزش مرتبطه. هزینه‌ش هم برای اعضای PMI حدود ۴۰۰ دلاره. آزمون ۲۰۰ سوال چهار جوابیه و ۴ ساعت زمان داره. مطابق معمول هم تو مراکز Prometric انجام می‌شه که تو ایران نیست.
به تازگی سومین راهنمای عملی که در مورد استقرار مدیریت پروژه سازمانیه هم منتشر شده.
اولین نکته‌ای که باید بدونیم، معنی مدیریت پروژه سازمانیه که به OPM هم مخفف می‌شه. این OPM همونیه که تو ترکیب OPM3 هم قرار می‌گیره؛ یعنی موضوع مدل بلوغی که تو OPM3 تعریف می‌شه همون چیزیه که بحث این راهنمای عملیه.
طبق تعریف PMI از OPM، این مفهوم چهارچوبیه که تحقق استراتژی‌های سازمان رو از طریق پرتفولیوها، طرح‌ها و پروژه‌ها فراهم می‌کنه. به عبارت دیگه مجموعه پرتفولیوها و طرح‌ها و پروژه‌های سازمان و سیستم‌های مدیریتی اون‌ها رو با استراتژی‌های سازمان هماهنگ می‌کنه و اون‌ها رو واقعا به ابزارهایی برای تحقق این استراتژی‌ها تبدیل می‌کنه.
می‌تونین شرکت‌هایی که توشون کار می‌کنین و احتمالا تو OPM بلوغ ندارن رو تصور کنین. آیا مثلا دقیقا مشخصه که پروژه‌هایی که دارین انجام می‌دین به چه دلیل انجام می‌شن؟ یا صرفا چون می‌تونستین یه پروژه‌ای رو بگیرین و قیمتش هم «به نظر» مناسب میومده اون رو پذیرفتین؟
تو یه شرکت باید به راحتی بتونیم بگیم که چه ماهیت و هویتی داره و می‌خواد چی باشه و به کجا برسه. بعد هم سیستمی داشته …
پروژه و طرح عوامل ایجاد تغییر هستن. هر دو موقت هستن و خروجی منحصر به فرد دارن. حالا فرق این دوتا چیه؟ یه رویکرد نادرست اینه که وقتی عامل تغییر از حدی بزرگ‌تر باشه بهش بگن طرح و وقتی کوچک‌تر باشه بگن پروژه. این رویکرد زیاد درست نیست و تو این مطلب می‌خوام تفاوت‌های اساسی این دوتا رو بگم.
خروجی پروژه یه محصول، نتیجه یا خدماته که به طور کلی بهش می‌گیم محصول یا خروجی. محصول پروژه می‌تونه یه ساختمون باشه، یه نرم‌افزار، یه گزارش و امثال اون‌ها.
محصول یک یا چند پروژه بعد از تکمیل یه پتانسیل تغییر به وجود میارن و وقتی این پتانسیل بالفعل می‌شه، عملا یه «نتیجه» به وجود میاره. مثلا در مورد یه بیمارستان، خود ساختمونی که می‌سازیم می‌شه خروجی یا محصول کارمون. این خروجی پتانسیلی برای کارکرد داره که وقتی در کنار خروجی‌های دیگه‌ای مثل پرسنل بیمارستانی، احیانا سیستم تامین اجتماعی، بازاریابی و امثال اون‌ها قرار می‌گیره، «نتیجه»ای به وجود میاره: امکانات درمانی بیشتر برای مردم یا برای گروهی از مردم.
تفاوت اصلی پروژه و طرح اینه:
پروژه محصول به وجود میاره، طرح نتیجه به وجود میاره
پس مثلا ساخت یه سد بزرگ، با این‌که ممکنه سرمایه‌گذاری بزرگی باشه، پروژه‌س، چون داره یه محصول تولید می‌کنه؛ ولی مثلا فراهم کردن آب آشامیدنی برای یه ده، حتی اگه سرمایه‌گذاریش کمتر از یه سد بزرگ باشه، یه طرحه، چون با نتیجه سر و کار …
بعد از یه فرآیند نسبتا سخت شش ماهه که شامل مصاحبه و ارزیابی عملی می‌شد، بالاخره تونستم مجوز رسمی تدریس و برگزاری آزمون PRINCE2 رو از APMG بگیرم.
برای تدریس PMP نیاز به هیچ مجوزی نیست؛ حتی مدرس لازم نیست که PMP باشه. حتی محتوایی هم که تدریس می‌شه لازم نیست تایید شده باشه؛ هرچند که روندهایی برای دریافت تاییدش وجود داره. با این حال اوضاع برای PRINCE2 متفاوته. مدرس پرینس۲ باید گواهی تدریس داشته باشه. این گواهی به کسایی داده می‌شه که نمره‌های بالایی تو آزمون PRINCE2 Practitioner داشته باشن (نمره قبولی ۵۵ درصده، ولی این افراد باید حداقل ۶۷ درصد گرفته باشن)، تو مصاحبه حضوری با ارزیاب نشون بدن که دانششون از پرینس۲ کامل، یکپارچه و پیوسته‌س و بتونن برای همه موارد مثال‌های عملی بزنن، و در نهایت یه دوره آموزشی رو هم تحت مراقبت ارزیاب‌ها تدریس کنن و سبک تدریسشون از نظر پویایی، تعامل، تاثیرگذاری و کیفیت تایید بشه. البته علاوه بر اون باید یه موسسه آموزشی تایید شده پرینس۲ هم این افراد رو تایید و به APMG معرفی کنه.
این مجوز علاوه بر تدریس PRINCE2 برای برگزاری آزمون هم هست. یعنی این افراد باید تسلط کاملی به روند و قوانین آزمون‌ها داشته باشن و بتونن داوطلب‌ها رو راهنمایی کنن. این افراد مورد اعتماد موسسه هستن و می‌تونن هر جای دنیا آزمون‌های کاغذی پرینس۲ رو برگزار کنن.
بعضی وقت‌ها تو استانداردها و روش‌های مدیریت پروژه به توصیه‌های متناقض بر می‌خوریم. مثلا تو خیلی از چهارچوب‌های چابک با تشویق اعضای تیم پروژه مخالفیم، در حالی که داشتن نظام تشخیص و تشویق تو PMBOK لازمه. خوب، حالا کدوم درست می‌گه؟
یا مثلا داشتن تعریف‌های دقیق و شفاف از نقش‌ها و مسئولیت‌ها تو PRINCE2 واجبه (از اصول زیربناییه)، در حالی که مثلا تو تیم تولید اسکرام تعریف هیچ نقش و سمتی مجاز نیست، همه مثل هم هستن. کدوم درست می‌گه؟
موارد متناقض اینچنینی زیاد می‌بینیم و شاید این سوال براتون پیش بیاد که کدوم درست می‌گه. جواب هم ساده‌س: سوال درست نیست!
بله، چنین سوالی درست نیست. هیچکدوم از اون‌ها درست یا غلط نیستن. ماجرای مهم اینه که سیستمی پیوسته، سازگار و موثر داشته باشیم. پم‌باک طوریه که برای حفظ سازگاری و پیوستگیش نیاز به نظام تشخیص و تشویق داریم و خیلی از چهارچوب‌های چابک طوری هستن که چنین چیزی سازگاریشون رو به هم می‌زنه. موارد دیگه هم همینطور هستن.
حالا دلیل اصلی نوشتن این مطلب این نبود که بگم چنین سوالی درست نیست، دلیل اصلیش این بود که بگم تا چه حد مهمه که نظامی که آدم استفاده می‌کنه التقاطی نباشه. کسایی که مثلا سعی می‌کنن از چهارچوبی مثل اسکرام استفاده کنن، ولی یکی دو قسمت اون رو حذف می‌کنن چون اعتقاد دارن که برای محیطشون مناسب نیست یا کسایی که مثلا سعی می‌کنن از پم‌باک و پرینس۲ …
خیلی از شماها که کارتون برنامه‌ریزی و کنترل پروژه‌س به فکر تاسیس شرکت می‌افتین و بعضی وقت‌ها ایمیل‌هایی برای مشورت در این مورد دریافت می‌کنم. تو این مطلب می‌خوام نظرم رو در این مورد برای همه بگم.
من خودم وقتی ۱۸ سال پیش کارم رو تو این حوزه شروع کردم خیلی زود تصمیم گرفتم که یه روزی شرکت خودم رو راه بندازم. شرکتی تخصصی برای برنامه‌ریزی و کنترل پروژه. این هدف من بود و سال به سال که جلوتر می‌رفتم مصمم‌تر می‌شدم و بیشتر از قبل براش برنامه‌ریزی می‌کردم. با این حال شتاب‌زده عمل نکردم و به تدریج چیزهایی یاد گرفتم که باعث شد بفهمم این انتخاب برای من مناسب نیست؛ برای کسای دیگه‌ایه. با این‌که هیچوقت تو زندگیم کارمند نبودم و نمی‌خواستم هم که باشم، ولی تاسیس شرکت از برنامه کاری من حذف شد. البته الان به نوعی ممکنه صاحب شرکت به حساب بیام، چون در ازای دریافت سهام به مجموعه‌ای پیوستم و کارم رو اونجا متمرکز کردم، ولی این شرایط کاملا متفاوته.
بدونیم داریم چیکار می‌کنیم
اولین نکته اینه که دقیقا بدونیم داریم چیکار می‌کنیم. دیدگاه سنتی اینه که وقتی یه نفر پیشرفت می‌کنه باید از کارشناس تبدیل بشه به مدیر و بعد هم یه شرکت برای خودش راه بندازه. ولی این درست نیست. تبدیل شدن از یه کارشناس به یه مدیر یه تغییر تو حرفه‌س، پیشرفت نیست. تاسیس شرکت هم همینطور.
اگه بزرگ‌ترین علاقه‌مندی حرفه‌ای‌تون کار تخصصی تو حوزه …
یه سوال همیشگی اینه که ترتیب فرآیندهای PMBOK چیه و اگه مثلا بخوایم اجراش کنیم باید چطوری پیش بریم. قبلا تو خیلی از نوشته‌ها مستقیم یا غیر مستقیم درباره‌ش توضیح دادم، ولی الان می‌خوام به طور خاص در مورد این ماجرا صحبت کنم.
فرآیندهای PMBOK ترتیب ندارن!
اولین نکته اینه که باید بدونین فرآیندهای پم‌باک ترتیب ندارن. بله، پم‌باک قصد نداشته براشون ترتیب مشخص کنه.
حالا احتمالا فکر کنین که اگه قراره ترتیب برای فرآیندها ارائه نشده باشه، پس اون همه فلش‌هایی که تو پم‌باک از یه فرآیند به فرآیند دیگه میره چیه. اون روابط تو پم‌باک نشون‌دهنده ترتیب اجرا نیستن، نشون‌دهنده اینن که فرآیندها چطوری با هم یکپارچه می‌شن، که این از مهم‌ترین مفاهیم پم‌باکه.
این یکپارچگی نشون می‌ده که چه نوع وابستگی‌هایی بین فرآیندها هست و اگه بخوایم یه فرآیند خاص رو خوب و کامل و موثر اجرا کنیم، باید از چه چیزهایی تاثیر بگیره و بر چه چیزهایی تاثیر بذاره. اگر تاثیرپذیری کامل نباشه، نتیجه‌ش قابل اطمینان نیست و اگه تاثیرگذاریش کامل نباشه، نتیجه‌ش درست استفاده نشده. تو هر دو حالت دچار مشکل می‌شیم.
چرا فرآیندهای PMBOK ترتیب ندارن؟
حالا چرا فرآیندهای پم‌باک ترتیب ندارن؟
می‌شه مثلا به PRINCE2 نگاه کنین. فعالیت‌های پرینس۲ کمابیش معادل فرآیندهای پم‌باک هستن و بین اون‌ها هم فلش‌هایی وجود داره، روابطی وجود داره. ولی این روابط تو …
