معرفی کتاب «رژه‌ی مرگ» به قلم ادوارد یوردون

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

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

ابتدا نیاز است «رژه‌ی مرگ» را از نظر یوردون تعریف کنیم:

«رژه‌ی مرگ، پروژه‌ای است که ارزیابی بی‌طرفانه‌ی ریسک هدف آن بیانگر احتمال شکست معادل ۵۰ درصد (یا بیشتر) است (ریسک در این‌جا شامل ریسک‌های فنی، ریسک‌های پرسنلی، ریسک‌های قانونی، ریسک‌های سیاسی و غیره است)».

به عبارت ساده‌تر: پروژه‌ی رژه‌ی مرگ، پروژه‌ای است که «پارامترهای پروژه» آن حداقل ۵۰ درصد از حد معمول تجاوز کرده باشند. این وضعیت در بیشتر پروژه‌ها بدان معنی است که یکی از محدودیت‌های زیر به پروژه تحمیل شده اند:

- برنامه‌ی زمانی به کمتر از نصف میزان تخمین معقول آن تقلیل داده شده است. مثلاً انتظار می‌رود پروژه‌ای که انجام آن در حالت نرمال، ۱۲ ماه طول می‌کشد را طی ۶ ماه انجام دهیم. با توجه به فشارهای رقابتی بیزینس‌ها در مارکت جهانی امروز، این احتمالاً متداول‌ترین شکل از پروژه‌ی رژه‌ی مرگ باشد.

• کاهش دادن تعداد کارکنان به کمتر از نصف تعداد کارکنانی که معمولاً به پروژه‌ای با این اندازه و وسعت اختصاص داده می‌شود.بنابراین، به جای اینکه یک تیم 10 نفره به مدیر پروژه داده شود، به او گفته شده است که فقط پنج نفر در دسترس هستند. این وضعیت ممکن است در نتیجه این باور ساده لوحانه باشد که یک زبان برنامه نویسی جدید یا محیط توسعه برنامه به طور جادویی بهره وری تیم را دو برابر می کند (علی‌رغم این که تیم هیچ آموزش یا تمرینی با فناوری جدید ندیده است و احتمالاً در وهله اول درباره تصمیم به استفاده از فناوری، حتی با آن‌ها مشورت هم نشده است). متأسفانه، به دلیل ادامه رکود اقتصادی و کاهش بودجه‌های فناوری اطلاعات، این نسخه بسیار بیشتر اتفاق می‌افتد.
• بودجه و منابع مربوطه به نصف کاهش یافته است. باز هم، این وضعیت اغلب نتیجه‌ی کوچک‌سازی و سایر اقدامات کاهش هزینه است، اما همچنین می تواند ناشی از مناقصه رقابتی در یک قرارداد با قیمت ثابت باشد که در آن مدیر پروژه در یک شرکت مشاوره توسط بخش بازاریابی مطلع می شود که "خبر خوب این است که ما برنده قرارداد شدیم. خبر بد این است که باید بودجه‌ی شما را نصف کنیم تا بتوانیم رقبا را شکست دهیم". این نوع محدودیت اغلب تأثیری فوری بر تعداد پرسنلی از تیم پروژه می‌گذارد که می‌توانند استخدام شوند، اما عواقب آن بعضاً کمی ظریف‌تر است. به عنوان مثال، ممکن است به جای استخدام نیروهای حرفه‌ای با هزینه بالاتر، منجر به تصمیمی برای استخدام توسعه‌دهندگان نرم‌افزار جوان نسبتاً ارزان و کم‌تجربه شود. همچنین می‌تواند منجر به فضای فراگیر صدقه‌شماری شود که باعث می‌شود مدیر پروژه نتواند وقتی تیم، تمام آخر هفته را در شرکت اضافه کاری می‌کنند، برایشان پیتزا سفارش دهد.
• فیچرها، فانکشنالیتی‌ها و نیازمندی‌های پرفورمنسی یا سایر جنبه‌های فنی پروژه، دوبرابر آن چیزی هستند که در حالت نرمال باید باشند. بنابراین به تیم گفته می‌شود که باید دوبرابر تعداد فیچرهای درخواستی را در مقدار ثابتی از رم یا فضای دیسکی جای دهند که رقیب آن‌ها دارد. یا به آن‌ها گفته می‌شود که سیستم‌شان باید بتواند دوبرابر تراکنش‌هایی را انجام دهد که هر سیستم مشابه دیگری تا آن زمان توانسته انجام دهد. محدودیت‌های پرفورمنسی ممکن است به پروژه‌ی رژه‌ی مرگ تبدیل شوند یا نشوند. با این حال، همیشه می‌توانیم با بهینه‌تر کردن الگوریتم‌ها و بهبود طراحی سیستم به سخت‌افزار ارزان‌تر و سریع‌تری برسیم. ولی دوبرابر کردن فانکشنالیتی (مثل فیچرهای موجود) معمولاً به معنای دوبرابر کردن میزان کاری است که باید انجام شود که منجر به یک پروژه‌ی رژه‌ی مرگ می‌شود.

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

یوردون در ادامه، پروژه‌های رژه‌ی مرگ را به چهار دسته‌ی کلی تقسیم‌بندی می‌کند: پروژه‌های با مقیاس کوچک (۱ تا ۳ نفر)، پروژه‌های با مقیاس متوسط (۲۰ تا ۳۰ نفر)، پروژه‌های با مقیاس بزرگ (۱۰۰ تا ۳۰۰ نفر) و پروژه‌های گیج‌کننده (ارتشی از ۱۰۰۰ تا ۲۰۰۰ نفر).

در ادامه پروژه‌ی فرستادن انسان به کره‌ی ماه توسط ناسا در سال 1969 را به عنوان یک نمونه‌ی موفقیت‌آمیز از پروژه‌های رژه‌ی مرگ معرفی می‌کند.

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

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

اما سوال این جاست که چرا یک سازمان معقول چنین پروژه‌ای را ایجاد می‌کند؟ چرا یک فرد فنی یا مدیرپروژه‌ی عاقل تن به شرکت در چنین پروژه‌ای می‌دهد؟

• سیاست، سیاست، سیاست. (هرکجا که بیش از سه نفر برای انجام کاری دور هم جمع شوند، اجتناب از سیاست‌بازی اجتناب‌ناپذیر است. مثلاً ممکن است یکی از مدیران برای اجتناب از پاسخ‌گویی و مسئول ماندن ترجیح دهد پروژه ای شکست‌خورده را حواله‌ی مدیر دیگری کند تا اشخاص دیگری به جای او متوجه این خسارت شوند و غیره.)
• وعده‌های ساده‌لوحانه یا اشتباهی که توسط مدیر بازاریابی، مدیر ارشد یا مدیران پروژه کم‌تجربه و دیگران داده می‌شوند.
• خوش‌بینی ساده‌لوحانه‌ی جوانان: "ما می توانیم آن را در آخر هفته انجام دهیم".
• ذهنیت «ارتش تفنگداران دریایی»: "برنامه نویسان واقعی به خواب نیاز ندارند".
• رقابت شدید ناشی از جهانی شدن بازارها
• رقابت شدید ناشی از ظهور فناوری های جدید
• فشار شدید ناشی از مقررات غیرمنتظره دولتی
• بحران‌های غیرمنتظره و/یا برنامه‌ریزی نشده، مثلاً فروشنده‌ی سخت‌افزار/نرم‌افزار شما ورشکست شد، یا سه نفر از بهترین برنامه‌نویسان شما به تازگی بر اثر طاعون جان باختند.

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

فصل سوم کتاب راجع به مذاکرات، استراتژی‌ها و بازی‌های مذاکره و تریدآف‌های قابل قبول است و این که وقتی مذاکرات شکست می‌خورند، چه کنیم.

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

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

فصل ششم راجع به مدل‌های فرآیند نرم‌افزار (Software Process Models) است.

فصل هفتم درباره زمان‌بندی زنجیره‌ی بحران و نظریه‌ی محدودیت‌ها صحبت می‌کند. مسائلی از این قبیل که کدام رفتارهای سازمانی ناکارآمد هستند؟ و چطور می‌توانیم آن‌ها را تغییر دهیم؟

فصل هشتم به مدیریت زمان و فصل نهم کتاب به مدیریت و کنترل پیشرفت اشاره می‌کنند. مفاهیمی مثل بیلد گرفتن روزانه، مدیریت ریسک و غیره.

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

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