تعیین گستره و داستان تحول آسانسور
برای هر پروژه‌ای باید گستره‌ای طراحی کنیم، چه وقتی پروژه کلاسیک پیش بره و چه وقتی که چابک باشه. تو پروژه‌های کلاسیک معمولا (نه همیشه) کل گستره در ابتدا مشخص می‌شه، ولی تو پروژه‌های چابک معمولا گستره به تدریج و بر اساس بازخوردهای قبلی شکل می‌گیره. ولی به هر حال باید تعیین کنیم چه برای کل مدت پروژه یا برای بازه‌ای در آینده نزدیک قراره چه چیزی تولید کنیم.
حالا این‌که گستره به چه ترتیبی می‌تونه تعیین بشه خودش بحث خیلی مهمیه. یه موقع شرکتی هستین که پروژه‌ای رو از کارفرمایی گرفتین و یه قراردادی دارین که کلیات گستره توش مشخص شده؛ موضوع صحبتم شما نیستین. این مطلب در مورد زمانیه که:
- بر اساس قرارداد قراره به کارفرمای خودتون کمک کنین که در مورد کلیات گستره تصمیم بگیره
- خودتون کارفرما هستین و می‌خواین درباره کلیات گستره تصمیم بگیرین
- اصلا بحث کارفرما و پیمانکار به شکل متمایز وجود نداره؛ پروژه داخلیه و خودتون هم نقش کارفرما دارین و هم پیمانکار اصلی.
مشکل
یه مشکل خیلی بزرگ برای اکثر شرکت‌ها وجود داره، اون هم اینه که خیلی سریع یه راه حل در نظر می‌گیرن و تصمیم می‌گیرن اجراش کنن. مثلا می‌خواین سیستم مدیریتی پروژه‌هاتون رو بهبود بدین و سریع می‌گین که یه PMO راه می‌ندازیم. این روند به چند دلیل مشکل داره:
- ممکنه اون محصول بهترین راه برای رسیدن به نتیجه نباشه
- اصلا به اندازه کافی به نتیجه‌ای که می‌خواین برسین فکر نکردین و به همین خاطر در آینده هم اون هدف اصلیتون نخواهد بود؛ شاید اصلا کسی یادش نباشه چه نتیجه‌ای می‌خواستین بگیرین. خیلی سریع محصول به هدف نهایی تبدیل می‌شه و به همین خاطر حتی همون محصولی که در نظر گرفتین هم به شکلی تولید نمی‌شه که رسیدنتون رو به نتیجه تسهیل کنه.
راه حل
براتون مثال محبوبم رو می‌گم که معمولا تو کلاس‌ها هم تعریفش می‌کنم. خیلی قدیم بزرگ‌ترین مشکل آسانسورسازها سرعت پایین محصولشون بوده. افزایش سرعتش هم کار ساده‌ای نبوده، چون سیستم‌هایی که بتونن توقف‌های نرم به وجود بیارن به راحتی الان در دسترس نبودن.
یکی از اون شرکت‌ها از یکی از تحلیل‌گرهاش می‌خواد که پروژه‌ای رو شروع کنه برای پیدا کردن راهی برای افزایش سرعت آسانسور. اون تحلیل‌گر به جای این‌که بلافاصله بره دنبال پیدا کردن راه حل، ازشون می‌پرسه «چرا می‌خواست سرعت رو زیاد کنین؟». سوالی که به نظر خیلی بدیهی میومده. بهش می‌گن که خوب این مهم‌ترین کاریه که می‌تونیم بکنیم. تحلیل‌گر سوالش رو تکرار می‌کنه: خوب، برای چی می‌خواین سرعت رو زیاد کنین؟ و بالاخره بهش جواب می‌دن که چون سرعت کمه و مردم توی آسانسور حوصله‌شون سر می‌ره. اون هم می‌گه، پس هدف شما افزایش سرعت آسانسور نیست، هدفتون اینه که یه کاری کنین مردم حوصله‌شون سر نره. حالا بیاین بشینیم فکر کنیم ببینیم برای رسیدن به این هدف چه راه حل‌هایی داریم.
چند وقت بعد با صرف زمان و هزینه خیلی خیلی کم این پروژه تموم می‌شه. محصول چی بوده؟ توی همه آسانسورهاشون آینه نصب می‌کنن، بدون این‌که سرعتش رو تغییر بدن. راه حلی که بعد از اون تو همه آسانسورها استفاده می‌شه.
وقتی تو آسانسور آینه نصب کردن مردمی که توش بودن شروع می‌کنن به ورانداز کردن خودشون؛ اگه تنها باشن مو و لباسشون رو صاف می‌کنن یا ژست می‌گیرن و خودشون رو ستایش یا سرزنش می‌کنن، یا اگه تنها نباشن تصویر خودشون رو با بقیه مقایسه می‌کنن که ببینن بقیه چطوری می‌بیننشون و بدون این‌که بفهمن اون چند ثانیه چطوری گذشته، سفرشون تموم می‌شه.
جالب اینه که وقتی از مردم پرسیدن که به نظرتون سرعت آسانسورهامون بهتر شده یا نه، اکثرا گفتن آره؛ در حالی که سرعت تغییر نکرده بوده.
مکانیزم
هر محصولی که تو پروژه‌ای تولید می‌کنیم رو برای رسیدن به نتیجه‌ای تولید کردیم. وگرنه دلیلی نداره پروژه‌ای انجام بدیم. نتیجه‌ای می‌خوایم، بر اساس محصولی طراحی می‌شه و بر اساس اون محصول کارهایی که باید انجام بشه مشخص می‌شه.
اولین مشکل اینه که اکثر اعضای تیم پروژه حواسشون به کارهاس و حتی به محصول هم توجه نمی‌کنن. به همین خاطره که تو اکثر استانداردها، از جمله پرینس۲، تاکید می‌شه که تمرکز باید روی محصول باشه و نه کار، تا مطمئن باشیم که کارهامون در راستای تولید محصوله. از طرف دیگه:
- اگه پروژه چابک باشه تو شرایطی هستیم که هیچوقت نمی‌تونیم بدونیم چه محصولی ما رو به نتیجه می‌رسونه، به همین خاطره که حتی به تمرکز روی محصول هم اکتفا نمی‌کنیم و تمرکز هر روزه‌مون رو می‌ذاریم روی نتیجه.
- اگه پروژه کلاسیک باشه ارتباط ساده‌ای بین محصول و نتیجه وجود داره، به همین خاطر یک بار در ابتدای پروژه این رابطه رو شکل می‌دیم و بعد از اون تمرکز بر محصول کافی خواهد بود. با این حال باز هم باید برای مسایل حساس و تصمیم‌گیری‌های مهم نتیجه رو در نظر داشته باشیم. این همون جاییه که پرینس۲ و پم‌باک تاکید می‌کنن باید حواسمون به انگیزه تجاری (business case) باشه. انگیزه تجاری سند یا مفهومیه که نتیجه مطلوب و ارتباطش رو با محصول نشون می‌ده.
اگه پروژه کلاسیک باشه معمولا تعریف محصول رو تو لایه مدیریت طرح یا مدیریت پرتفولیو انجام می‌دیم و تو لایه مدیریت پروژه حواسمون عمدتا به محصوله. ولی اگه پروژه چابک باشه ایجاد چنین تفکیکی ممکن نیست.