تغییرهای پم‌باک ۸
نسخه نهایی پم‌باک ۸ چند روز پیش، بعد از ۱۱ ماه که از انتشار پیش‌نویسش می‌گذشت، منتشر شد. به سنت همیشگی تغییرهای این نسخه رو توضیح می‌دم. توضیح‌ها با این فرض هستن که نسخه‌های پیشین استاندارد رو کمابیش می‌شناسین.
بازگشت فرآیندها
فرآیندها، که همیشه محتوای اصلی پم‌باک بودن، تو نسخه ۷ حذف شده بودن. البته بلافاصله نسخه‌ای از فرآیندها تو بستر آنلاینی که برای محتوای تکمیلی در نظر گرفته شده بود قرار گرفت و بعدا در قالب کتابی جداگانه هم منتشر شد، ولی به هر حال جزئی از خود پم‌باک ۷ نبود، که به این معنیه که اهمیتش پایین رفته بود.
دلیل این‌که فرآیندها حذف شده بودن این بود که تاکید بره روی اصول. من البته با حذف فرآیندها موافق نبودم، چون به نظرم باارزش‌ترین بخش پم‌باک بودن. بعد از انتشار پم‌باک هم بازخوردهای زیادی در این مورد اومده بود و PMI به این نتیجه رسید که فرآیندها باید تو نسخه بعد برگردن به پم‌باک.
تغییر برچسب «حوزه دانش»
فرآیندها به دو شکل گروه‌بندی می‌شن، یکی از اون‌ها بر اساس نوع دانشیه که در پس فرآیندها قرار می‌گیره؛ مثلا مدیریت زمان، هزینه، کیفیت و امثال اون. به این گروه‌بندی قدیم حوزه‌های دانش (knowledge areas) گفته میشد و الان اسمش شده حوزه‌های عملکردی (performance domains). حالا من دارم area و domain رو یکجور به فارسی برمی‌گردونم، ولی واژه‌های انگلیسیشون متفاوته و بین این دو واژه انگلیسی، عبارت جدید یه مقدار سرراست‌تره و فکر می‌کنم فهمش رو برای کسایی که تازه‌وارد باشن راحت می‌کنه.
این تغییر در نسخه هفتم ریشه داره. تو اون نسخه مفهوم حوزه‌های عملکردی اضافه شد. البته تو اون نسخه به عنوان مفهومی جدید و متفاوت با حوزه‌های دانش ارائه شده بود. اون هم شاید ایده خیلی خوبی نبود که مفهومی انقدر نزدیک به حوزه‌های دانش و در عین حال متفاوت با اون‌ها وارد بشه. یادمه یه پرسش رایج بعد از انتشار پم‌باک این بود که تفاوت مفهومی این دو چیه.
به هر حال، اون مفهوم نسخه هفتی حوزه عملکردی حذف شده و اسمش برای مفهومی که پیش از نسخه هفتم حوزه‌های دانش نامیده میشد به کار می‌ره.
تغییر برچسب «گروه فرآیندی»
حوزه‌های عملکردی یا حوزه‌های دانش، یک راه برای گروه‌بندی فرآیندهان. راه دیگه چیزیه که اسمش «گروه‌های فرآیندی» (process groups) بود و فرآیندها رو بر اساس ارتباطشون با چرخه حیات پروژه گروه‌بندی می‌کرد؛ چیزهایی مثل آغازش و برنامه‌ریزی و کنترل و پایان. این گروه‌بندی الان اسمش شده حوزه‌های تمرکز (focus areas).
برچسب قدیمی این گروه‌بندی خوب نبود، چون صرفا بهش می‌گفت «گروه فرآیندی»، در حالی که حوزه‌های دانش هم یه جور گروه فرآیندی بودن. بهتر بود که نوع گروه‌بندی تو برچسب بیاد. از این رو تغییر نام فکر خوبی بوده، با این حال نامی که انتخاب شده شاید بهترین نباشه. اگه حوزه‌های تمرکز طوری بودن که یکی بعد از دیگری و بدون همپوشانی میومدن، میشد گفت که در هر زمان روی یکیشون تمرکز می‌کنیم و اونوقت اسم حوزه تمرکز خیلی خوب میشد.
حذف فصل مدل‌ها، متودها و اسناد
تو نسخه ۷ فصلی در مورد مدل‌ها، متودها و اسناد اضافه شده بود که الان حذف شده و من خیلی از این بابت خوشحالم. مشکل اون فصل این بود که همه چیز رو خارج از بسترشون آورده بود و نمی‌تونست ارزشی ایجاد کنه. مثلا اشاره می‌کرد به سندی به اسم project brief، در حالی که اون سند فقط در بستر کاملی که تو پرینس۲ شکل گرفته معنی واقعی داره و خارج از اون تبدیل میشه به توصیفی ناقص که تفاوتش رو با خیلی چیزهای دیگه مشخص نمی‌کنه و هدفش رو هم نمی‌رسونه.
تغییر اصول
اصولی که در نسخه ۷ اومده بودن تبدیل شدن به اصولی کاملا متفاوت. البته میشه ماجرا رو اینطور دید که هر اصل چتریه برای در بر گرفتن چند مفهوم نزدیک به هم و در نسخه جدید از چترهای جدیدی داره استفاده میشه. با این حال، اصول جدید به نظر من امتیاز بزرگی نسبت به اصول قبلی ندارن و چنین تغییر بزرگی رو توجیه نمی‌کنن. این نکته وقتی پررنگ‌تر میشه که روی زیربنایی بودن اصول تاکید می‌کنیم، ولی یه دفعه‌ای می‌بینیم که به این سادگی عوض شدن. عملا باوری که در مخاطب ایجاد میشه اینه که چیزهایی که به عنوان اصول ارائه شدن چندان هم زیربنایی نبودن.
حذف حوزه تدارکات
حوزه تدارکات یکی از حوزه‌هایی بود که از اولین نسخه پم‌باک وجود داشت و به مدیریت قراردادهای پایین‌دست، خریدها و امثال اون‌ها مربوط میشد. یعنی چیزهایی که تو خیلی از پروژه‌ها، مثل پروژه‌های ساختمانی، نقش کلیدی دارن.
پروژه‌های برنامه‌نویسی تدارکات چندانی ندارن و به همین خاطر برای کسایی که تو اون صنعت باشن چنین حوزه‌ای به نظر کم اهمیت میاد. از این رو که پم‌باک به شدت داره گرایش به پروژه‌های نرم‌افزاری پیدا می‌کنه، تو این نسخه حوزه تدارکات رو حذف کرده و فرآیندهای اون رو در حوزه هزینه ادغام کرده.
این ماجرا خیلی مشکل داره، یکی از این جهت که اهمیتی که به تدارکات می‌ده برای پروژه‌های غیرنرم‌افزاری به اندازه کافی نیست. مشکل دوم اینه که تدارکات به گستره، کیفیت، زمان، ریسک و خیلی چیزهای دیگه هم مربوط میشه و نمی‌شه به این راحتی اون رو در حوزه هزینه محدود کرد. اگه واقعا لازم بود حذف بشه و فرآیندهاش به حوزه دیگه‌ای پناهنده بشن، جای درستش حوزه یکپارچگی می‌بود. هرچند که البته اسم و مفهوم حوزه یکپارچگی رو هم عوض کردن که در ادامه بهش می‌رسیم.
حذف حوزه ارتباطات
نسخه‌های اولیه پم‌باک حوزه‌ای برای ارتباطات داشتن و همیشه هم تاکید می‌کردن که ارتباطات یکی از مهم‌ترین چالش‌های مدیریت پروژه‌س. کم کم که این حوزه تو نسخه‌های بعدی قویتر شد، توش جنبه‌های زیادی از مدیریت ذی‌نفعان دیده میشد. در نهایت، تو نسخه ۵، فرآیندهای مدیریت ذی‌نفعان از این حوزه جدا شدن و حوزه خودشون رو پیدا کردن.
تو نسخه ۸، بدون هیچ دلیل خوبی، حوزه ارتباطات حذف شده و فرآیندهاش رفتن تو حوزه عملکرد ذی‌نفعان. مشکل این مسئله رو میشه در ترکیب فرآیندهای این حوزه دید:
* حوزه عملکرد ذی‌نفعان
- حوزه تمرکز آغازش
- شناسایی ذی‌نفعان
- حوزه تمرکز برنامه‌ریزی
- برنامه‌ریزی مشارکت ذی‌نفعان
- برنامه‌ریزی مدیریت ارتباطات
- حوزه تمرکز اجرا
- مدیریت مشارکت ذی‌نفعان
- مدیریت ارتباطات
- حوزه تمرکز نظارت و کنترل
- نظارت بر مشارکت ذی‌نفعان
- نظارت بر ارتباطات
همونطور که می‌بینین، هر حوزه تمرکز تو این حوزه عملکرد دو فرآیند داره، یکی برای ارتباطات و یکی برای ذی‌نفعان. یعنی عملا دو حوزه عملکردی وجود داره، ولی به زور اون‌ها رو تو یکی جا دادن. حتی اگه واقعا قرار بود به دلایلی اینطور باقی بمونه، می‌بایست اسم حوزه به جای «مدیریت ذی‌نفعان»، «مدیریت ارتباطات و ذی‌نفعان» باشه.
حذف حوزه مدیریت کیفیت
حوزه کیفیت در حوزه گستره ادغام شده. شاید تعجب کنین، ولی من مخالفتی زیربنایی با این مسئله ندارم، چون اصولا تفکیک گستره و کیفیت کار ساده‌ای نیست و سال‌های ساله که وانمود می‌کنیم می‌تونیم چنین کاری کنیم، در حالی که در عمل اینطور نیست. در عمل، برنامه‌ریزی، نظارت و کنترل کیفیت و گستره تو اکثر پروژه‌ها با هم انجام میشه و نمی‌شه به راحتی از هم جداشون کرد.
با این حال، یه مشکل وجود داره: با این کار اهمیت کیفیت به عنوان یه حوزه مهم در مدیریت پروژه دست کم گرفته میشه. وقتی گستره و کیفیت رو در هم ادغام کنیم، باید اسم حوزه هم «گستره و کیفیت» باشه یا چیزی که نشون بده محدود به یکی از اون دو نیست.
تغییر نام حوزه یکپارچگی
چیزی که قدیم حوزه دانش مدیریت یکپارچگی (integration management knowledge area) نام داشت، الان شده حوزه عملکردی حاکمیت (governance performance domain). این تغییر نام اصلا درست نبوده، چون فرآیندهای این حوزه ارتباط بسیار محدودی با حاکمیت (روال چند سطحی تصمیم‌گیری) دارن و کاملا درباره یکپارچه کردن بقیه حوزه‌های عملکردی هستن.
این تغییر نام با تغییر ماهیت فرآیندها همراه نبوده؛ یعنی اینطور نبوده که فرآیندها رو طوری تغییر بدن که جنبه حاکمیت تو این حوزه قویتر بشه. عملا فرآیندها همون‌هایی هستن که قبلا بودن و فقط فکر کردن که «حاکمیت» توصیف بهتری براشونه تا «یکپارچگی»، که فکر درستی نبوده.
کلا از این رو که پم‌باک متودولوژی نیست، بحث حاکمیت هیچوقت توش پررنگ نبوده و نمی‌تونه هم باشه. حاکمیت در بستر متودولوژی می‌تونه شکل بگیره و نه راهنما.
اشاعه باورهای نادرست در مورد مدیریت پروژه
عده‌ای هستن که تحت تاثیر پروژه‌های کوچیک نرم‌افزاری که در استارتاپ‌ها انجام میشه، باور دارن که مدیر پروژه باید همه فن حریف باشه و علاوه بر اون چیزی که واقعا مدیریت پروژه‌س، تو حوزه استراتژی، بازاریابی، فروش، تکنولوژی‌های جدید و به طور کلی فنی، طراحی رابط کاربر و خیلی چیزهای دیگه هم وارد باشه و فعالیت کنه.
من سال ۲۰۲۳ مقاله‌ای در این مورد تو سایت انگلیسیم نوشته بودم با عنوان مدیریت پروژه رو ناممکن نکنین و تو کنفرانس‌های زیادی هم ارائه کردمش.
مشکل این باور اینه که چیزهایی رو با هم ترکیب می‌کنه که قابل ترکیب نیستن. مثلا، برای مدیریت مناسب پروژه، باید به کار نزدیک بود. با این حال، برای مدیریت مناسب ارزش، باید از پروژه دور بود و با زاویه دید باز همه چیز رو دید، بدون این‌که جزئیات آدم رو منحرف کنه. ترکیب این دو در یک نفر ممکن نیست. از طرف دیگه، هر کسی که سعی کرده باشه نیروی متخصص استخدام کنه می‌دونه که چقدر پیدا کردن کسی که در یکی از این موارد تخصص داشته باشه سخته، چه برسه به کسی که تو همه این‌ها تخصص داشته باشه. نکته جالبش اینه که کسایی که این ماجرا رو باب کردن خودشون حتی تو یکی از این حوزه‌ها هم دانشی ندارن که به حد متوسط برسه.
اتفاقی که می‌افته اینه که انتظارهای ناممکن از مدیر پروژه‌ها خواهیم داشت و عملا مدیر پروژه‌های خوب هم به نظر ناکارآمد میان و سرخورده می‌شن. خیلیا هم وقتی ببینن اصولا نمی‌تونن اون ایده‌آلی بشن که توصیف شده، کلا دور پیشرفت رو خط می‌کشن و همون چیزی که بودن باقی می‌مونن، در حالی که اگه انتظارهای معقول از آدم‌ها داشته باشیم تشویق می‌شن که پیشرفت کنن.
تو مقاله‌ای که نوشته بودم تکه‌ای از یه مطلب که کسی برای تبلیغ اون ایده مخرب نوشته بود رو آورده و نقد کرده بودم. نکته عجیب اینه که چند سال بعد که پیش‌نویس پم‌باک ۸ اومد، دقیقا همون پاراگرافی که به عنوان سمبل ایده‌های نادرست نقل قول و نقد کرده بودم تو پم‌باک اومده بود! یعنی عملا پم‌باک یا اون پاراگراف رو از مقاله اون فرد کپی کرده، یا هردو از جای دیگه‌ای که اول اون رو نوشته بوده کپی کردن. در هر حال، الان پم‌باک که از نظر خیلیا مهم‌ترین مرجع مدیریت پروژه هست داره یکی از مخرب‌ترین ایده‌هایی که در مورد مدیریت پروژه وجود داره و باعث افت اون میشه رو تبلیغ می‌کنه.
بعد از اعتراض‌های فراوانی که به این مسئله کردم، متن رو تو نسخه نهایی اندکی اصلاح کردن که تعدیل بشه، ولی هنوز هم همون معنای نامناسب اولیه رو داره.
تاکید هرچه بیشتر بر ارزش
روش‌های چابک از آغاز روی «ارزش» تاکید می‌کردن؛ هرچند که هیچوقت هیچکدومشون تعریف کامل و کاربردی‌ای از ارزش ندادن و نگفتن که دقیقا چطوری قراره استفاده بشه. ولی به هر حال، با مد روز شدن چابکی و بالا رفتن تب و تابش در سال‌های گذشته، بحث محور بودن ارزش هم خیلی پررنگ شد. این مفهوم تو نسخه ششم پم‌باک وارد شده بود، در نسخه هفتم زیاد از حد بزرگ شد و در نسخه هشتم حتی از اون هم بزرگ‌تر شد!
توجه به ارزش خیلی مهمه، ولی مشکلی که داره اینه که ارزش رو نمی‌شه در محدوده پروژه مدیریت کرد و باید به طور همه‌جانبه، بر اساس همه پروژه‌ها، محصول‌ها و خدماتی که الان سازمان داره و احتمالا در آینده خواهد داشت مدیریت بشه. به عبارت دیگه، مدیریت ارزش موضوع مدیریت پرتفولیوس و نه مدیریت پروژه. تو مدیریت پروژه فقط کمی محتوا در مورد مدیریت ارزش باید داشته باشیم، تا جایی که برای هماهنگی و همکاری با لایه‌های بالاتر لازمه.
تاکید زیاد از حد بر ارزش به معنی نادیده گرفتن اکثر پروژه‌ها و فقط نگاه کردن به پروژه‌های نرم‌افزاری در سازمان‌های تک محصوله‌س. اگه شما مدیر پروژه Netflix و Spotify و امثال اون باشین می‌تونین به کل چرخه ارزش فکر کنین و درکی از مسایل داشته باشین، هرچند که کیفیت این کار وقتی که مدیر پروژه انجامش بده بحث دیگه‌ایه. با این حال، به پروژه‌ای مثل ساخت یه بیمارستان فکر کنین: یه مدیر پروژه خوب می‌دونه که چطوری کار ساختمانی اون بیمارستان رو مدیریت کنه، ولی آیا از همه جنبه‌های پزشکی خبر داره؟ این‌که اون بیمارستان چقدر در آینده ارزش ایجاد می‌کنه بستگی به این داره که تو دانشکده‌های پزشکی چی می‌گذره، چه بیمارستان‌ها و کلینیک‌های دیگه‌ای در منطقه وجود داره، وضعیت کلی سلامت و تغذیه در اون محدوده چطوریه، آموزش‌های عمومی سلامت تو رسانه‌ها چیه، وضعیت آلودگی هوا که وابسته به صنایعه چطوره، وضعیت حوادث رانندگی که به شبکه راه‌ها و فرهنگ رانندگی مربوط میشه چطوریه و خیلی چیزهای دیگه. اینجاس که میشه دید چطور یه مدیر پروژه یا هر کس دیگه‌ای تو مرزهای پروژه نمی‌تونه ارزش رو مدیریت کنه و نیاز به افراد زیادی داره که در سطح‌های بالاتر و با نگاهی جامع‌تر به ماجرا نگاه کنن.
گذشته از اون مسایل، توصیف‌هایی که در مورد ارزش اضافه شده هم چندان درست نیست. مثلا تو حوزه مالی بحثی وجود داره درباره بیشینه کردن ارزش. ممکنه کسی که با این حوزه آشنا نباشه فکر کنه ارزش و پول یکیه، ولی اینطور نیست. ارزش فقط تو حوزه یکپارچکی می‌تونه طرح بشه. البته بگذریم که اسم حوزه یکپارچگی رو عوض کردن و گذاشتن «حاکمیت»!
جمع‌بندی
متاسفانه پم‌باک داره گرایش بسیار زیادی به پروژه‌های برنامه‌نویسی پیدا می‌کنه و به جای تمرکز بر روش‌های موثر و جا افتاده (best practices) بیشتر توجهش داره می‌ره به سمت کلیشه‌ها و مدهای روز. این مشکلیه که در سه نسخه اخیر وجود داشته و هر نسخه بیشتر از نسخه قبل هم شده. مثلا، تو تیم ۱۲ نفره تالیف نسخه قبل، من تنها کسی بودم که تو پروژه‌های ساختمانی و فرآیندی تجربه داشت! متاسفانه این مشکل محدود به پم‌باک هم نمی‌شه و پرینس۲ هم همینطوره.
تفاوت دیگه اینه که پم‌باک زمانی مجموعه‌ای غیرانتفاعی بود که گروهی از افراد بسیار باتجربه اون رو به طور داوطلبانه مدیریت می‌کردن. الان قدرت اون گروه بسیار کم شده و به جاشون کارمندهای حقوق‌بگیر و مدیر عامل‌ها و امثال اون‌ها قدرت گرفتن. همین تغییر موازنه قدرت هم بوده که باعث شده به PMI به عنوان مجموعه‌ای تجاری نگاه کنن و فعالیت‌ها و منابعش رو با رویکرد تجاری مطابق مد روز پیش ببرن.
با وجود همه این‌ها و با این‌که اعتراض‌های شدیدی به بعضی تغییرهای پم‌باک دارم، تغییرهای خوب هم توش بوده و مجموعا به نظر من نسخه هشتم نه خیلی خوب بوده و نه خیلی بد. برای مقایسه می‌تونم این رو بگم که تغییرهای آخرین نسخه پرینس۲ به شدت بد بوده و به همه کسایی که علاقه‌مند به پرینس۲ هستن اکیدا توصیه می‌کنم که نسخه ۵ رو مطالعه کنن و نه نسخه‌های بعدیش رو.