چند سالیه که مفهومی به نام enshitification برای روشن‌سازی روند «به گند کشیده شدن» خدمات بسترهایی مثل فیس‌بوک، گوگل و آمازون به وجود اومده. عبارت انگلیسیش ترکیبی نو و نامعموله که بر پایه واژه shit به وجود اومده و اگه بخوایم براش برابر فارسی بسازیم می‌تونه چیزی شبیه «گندینندگی» باشه.

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

سه مرحله برای گندینندگی تعریف شده:

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

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

• کاربر معمولی کسیه که از راهنماها/منوآل‌ها/متودهاشون بهره می‌بره و
• کاربر تجاری داوطلب و مدرسیه که ازشون آزمون و خدمات مشابه می‌خره.

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

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

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

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

به‌روزرسانی ۱۱ دی ۱۴۰۴: نشست زنده بعدی که برای ۱۴ دی برنامه‌ریزی شده بود به خاطر تجمع‌های اعتراضی‌ای که در جریانه لغو شد. پس از اون هم تا اطلاع بعدی نشست زنده‌ای نخواهیم داشت.

اگه بخوایم با برنامه همیشگیمون پیش بریم، نشست بعدیمون همزمان با جشن شب چله می‌شه. پس این بار به جای یکشنبه شب، شنبه شب دور هم خواهیم بود: شنبه، ۲۹ آذر ۱۴۰۴، ساعت ۸ شب به وقت تهران.

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

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

https://meet.google.com/vcj-wgwv-wuh

برنامه سر وقت شروع می‌شه و مدتش یک ساعته.

شرح موضوع

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

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

پیشنهاد برای آمادگی

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

نشست زنده بعدی، یکشنبه، ۱۶ آذر ۱۴۰۴، ساعت ۸ شب به وقت تهران،‌ با موضوع «درون‌گرایی در مدیریت پروژه» برگزار می‌شه. برای شرکت در نشست نیازی به ثبت نام نیست و کافیه که در تاریخ و ساعت گفته شده به آدرس زیر مراجعه کنین:

https://meet.google.com/vcj-wgwv-wuh

برنامه سر وقت شروع می‌شه و مدتش یک ساعته.

شرح موضوع

بعضیا درون‌گرا و بعضیا برون‌گرا هستن. بعضی حرفه‌ها هم برای یکی از این دو گروه مناسب‌تر از گروه دیگه‌س.

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

تو بیست دقیقه تا نیم ساعت اول برنامه مفهوم درست و علمی درون‌گرایی و برون‌گرایی رو توضیح می‌دم و بعد کمی درباره تناسبش با حرفه‌های اکوسیستم پروژه توضیح می‌دم و بعدش می‌ریم سراغ نظرها و پرسش‌های شرکت‌کننده‌ها.

پیشنهاد برای آمادگی

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

نسخه نهایی پم‌باک ۸ چند روز پیش، بعد از ۱۱ ماه که از انتشار پیش‌نویسش می‌گذشت، منتشر شد. به سنت همیشگی تغییرهای این نسخه رو توضیح می‌دم. توضیح‌ها با این فرض هستن که نسخه‌های پیشین استاندارد رو کمابیش می‌شناسین.

بازگشت فرآیندها

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

دلیل این‌که فرآیندها حذف شده بودن این بود که تاکید بره روی اصول. من البته با حذف فرآیندها موافق نبودم، چون به نظرم باارزش‌ترین بخش پم‌باک بودن. بعد از انتشار پم‌باک هم بازخوردهای زیادی در این مورد اومده بود و 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 به عنوان مجموعه‌ای تجاری نگاه کنن و فعالیت‌ها و منابعش رو با رویکرد تجاری مطابق مد روز پیش ببرن.

با وجود همه این‌ها و با این‌که اعتراض‌های شدیدی به بعضی تغییرهای پم‌باک دارم، تغییرهای خوب هم توش بوده و مجموعا به نظر من نسخه هشتم نه خیلی خوب بوده و نه خیلی بد. برای مقایسه می‌تونم این رو بگم که تغییرهای آخرین نسخه پرینس۲ به شدت بد بوده و به همه کسایی که علاقه‌مند به پرینس۲ هستن اکیدا توصیه می‌کنم که نسخه ۵ رو مطالعه کنن و نه نسخه‌های بعدیش رو.

نشست زنده بعدی، یکشنبه، ۲ آذر ۱۴۰۴، ساعت ۸ شب به وقت تهران،‌ با موضوع «پیدایش و تحول PMBOK» برگزار می‌شه. برای شرکت در نشست نیازی به ثبت نام نیست و کافیه که در تاریخ و ساعت گفته شده به آدرس زیر مراجعه کنین:

https://meet.google.com/vcj-wgwv-wuh

برنامه سر وقت شروع می‌شه و مدتش یک ساعته.

شرح موضوع

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

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

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

پیشنهاد برای آمادگی

به نظرتون اعتباری که پم‌باک داره ناشی از چیه و چطور می‌شه اون رو حفظ کرد؟

بیل دانکن (Bill Duncan)، نویسنده اولین نسخه پم‌باک، درگذشت.

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

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

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

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

یادش گرامی.