مدیریت پروژه تایتانیک و مقایسه با پروژههای نرمافزاری
پروژههای معدودی به شهرت و آوازهای که تایتانیک و کشتیهای خواهر المپیک او یعنی المپیک و بریتانیک، که صد و ده سال پیش طراحی آنها آغاز شد، دست یافتهاند. البته، درسهای بسیاری وجود دارد که میتوانیم از سرنوشت کشتیهای المپیک در مورد مدیریت پروژه بیاموزیم و در واقع جنبههای زیادی از مدیریت پروژه ارزش پوشش دارند.
(هنگام اشاره به کشتیها به عنوان یک مجموعه، من به سادگی آنها را المپیکها مینامم زیرا این سه با هم کشتیهای کلاس المپیک خط White Star بودند. شهرت فردی و بعدی تایتانیک در اینجا نامربوط است. همچنین، موضع من این است که اطلاعات عمومی مربوط به کشتیهای المپیک، تاریخچه و سرنوشت آنها برای خوانندگان دانش عمومی است و دوباره پوشش نمیدهم.)
با توجه به تناوبی که مدیریت پروژه المپیکها مورد بحث قرار گرفته است، فکر میکنم عاقلانهتر است که به چند تناظر مدرن نگاه کنیم که بتوانیم مدیریت پروژه فعلی در دنیای امروز را از طریق یک عدسی تاریخی ارزشمند ببینیم. به خوبی صدق میکند که مدیریت پروژه یک رشته است که هزاران سال ادامه داشته و بسیاری از چالشها، مهارتها و تکنیکها چندان تغییر نکردهاند و تلههای گذشته هنوز به خوبی برای ما امروز کاربرد دارند. ضربالمثل قدیمی صدق میکند: اگر از گذشته نیاموزیم، محکوم به تکرار آن هستیم.
پس هدف من در اینجا بررسی تحلیل ریسک، درک و پروفایل پروژه و اعمال آن به مدیریت پروژه مدرن است.
اول، باید ذینفعان پروژه المپیکها را شناسایی کنیم. خود White Star Lines (شرکت حامی و سرمایهگذار اصلی) و مدیر آن جوزف بروس اسمی، Harland-Wolff (کشتیساز تحت قرارداد) با طراحان اصلی الکساندر کارلایل و توماس اندروز، خدمه کشتیها که شامل کاپیتان ادوارد جان اسمیت میشود، دولت بریتانیا چنان که بعداً خواهیم دید و، مهمتر از همه، مسافران.
مانند هر گروهی از ذینفعان، نقشهای متفاوتی ایفا میشود. White Star از یک طرف حامی و سرمایهگذار است و در یک پروژه نرمافزاری مدرن مشابه یک مشتری حامی، مدیر یا بخش است. Harland-Wolff طراحان و سازندگان بودند و از نزدیکترین موارد به «اعضای تیم» مهندسی نرمافزار در یک تیم نرمافزاری مدرن بودند، خود توسعهدهندگان. خدمه کشتیها پس از تکمیل پروژه مسئول عملیات بودند و قابل مقایسه با یک تیم عملیات فناوری اطلاعات هستند که اجرای نرمافزار نهایی را پس از تکمیل به عهده میگیرند. مسافران بسیار شبیه کاربران نهایی امروز بودند که امیدوار بودند از هم محصول مهندسی (کشتی یا نرمافزار) و هم خدمات ساختهشده بر روی آن محصول (سرویس کشتیرانی یا خدمات مدیریتشده فناوری اطلاعات) بهرهمند شوند. («المپیک»)
محور دیگری از تحلیل پروژه، ذینفعان مرغ و خوک است که مرغها سرمایهگذاری کرده و ریسک میبرند در حالی که خوکها کاملاً سرمایهگذاری کرده و ریسک نهایی را میبرند. در نرمافزار معمولی از این تشبیهها برای صحبت از درجات ذینفعان استفاده میکنیم – آنهایی که درگیر هستند در مقابل آنهایی که متعهد هستند، اما در مورد کشتیهای المپیک این اصطلاحات معنای جدید و وحشتناکی پیدا میکنند زیرا خدمه و مسافران به معنای واقعی کلمه زندگی خود را در مرحله عملیاتی کشتیها به خطر انداختند، در حالی که سرمایهگذاران و سازندگان فقط از نظر مالی در معرض خطر بودند. (Schwaber)
دوم، فکر میکنم مفید است که بین پروژههای مختلفی که در زمینه المپیکها وجود داشت تمایز قائل شویم. البته طراحی و ساخت فیزیکی سه کشتی وجود داشت. این یک پروژه واحد است با دو بخش مشخص – یکی طراحی و یکی ساخت. و سه محصول مجزا، یعنی سه کشتی المپیک. در پایان مرحله ساخت، یک نقطه تمایز بسیار واضح وجود دارد که مدیران پروژه و تیمهای درگیر در مونتاژ کشتی کار را متوقف میکردند و خدمهای که کشتی را اداره میکرد مسئولیت را به عهده میگرفت.
در اینجا میتوانیم یک تناظر مهم با دنیای مدرن فناوری ترسیم کنیم که در آن محصولات نرمافزاری توسط مهندسان نرمافزار طراحی و توسعه مییابند و پس از تکمیل، به کارکنان عملیاتی فناوری اطلاعات تحویل داده میشوند که استفاده عملی واقعی از محصول نهایی را به عهده میگیرند. این دو تیم ممکن است داخلی تحت یک چتر سازمانی واحد یا از دو یا چند سازمان کاملاً جداگانه باشند. اما جدایی بین بخشهای مهندسی و عملیاتی در اکثر کسبوکارهای امروز به همان اندازه واضح و مشخص مانده است که برای کشتیسازی و سرویس کشتیرانی بیش از یک قرن پیش بود.
میتوانیم یک گام بیشتر برداریم و سرویس کشتیرانی اقیانوس اطلس White Star را با بسیاری از فروشندگان مدرن نرمافزار به عنوان سرویس مانند Microsoft Office 365، Salesforce یا G Suite مقایسه کنیم. در این موارد شرکت مورد نظر یک تیم مهندسی یا توسعه محصول دارد که محصول اصلی را ایجاد میکند و سپس یک تیم دوم که آن محصول داخلی را به عنوان یک سرویس اداره میکند. این یک مدل کسبوکار روزافزون مهم در فضای توسعه نرمافزار است که همان شرکتی که نرمافزار را ایجاد میکند اپراتور نهایی آن خواهد بود، اما برای مشتریان خارجی. از بسیاری جهات، ارتباط المپیکها با نرمافزار و فناوری اطلاعات مدرن در حال افزایش است نه کاهش.
این یک درک مهم از رابط را مطرح میکند که در المپیکها نادیده گرفته شد و اغلب امروز هم نادیده گرفته میشود: هر طرف از تحویل معتقد بود که طرف دیگر در نهایت مسئول ایمنی است. مهندسان ایمنی طراحی را تبلیغ کردند، اما وقتی تحت فشار قرار گرفتند حاضر به سازش بودند با این فرض که رویههای عملیاتی خطرات را کاهش خواهد داد و تلاشهای خودشان تا حد زیادی مازاد بودند. به همین ترتیب، وقتی تحت فشار قرار گرفتند تا کارها را پیش ببرند و وقت خوبی داشته باشند، تیم عملیات حاضر به سازش در رویهها شد زیرا معتقد بودند تیم مهندسی آنقدر پیش رفته که تلاشهایشان اساساً بیهوده است، کشتی آنقدر ایمن است که اقدامات احتیاطی عملیاتی توجیه ندارند. این سوء تفاهم پروژه را از داشتن دو نوع سیستم ایمنی شدید به اساساً هیچ کاهش داد. اگر هر طرف میفهمید که طرف دیگر چگونه عمل میکرد یا عمل میکند، میتوانستند آن را در نظر بگیرند. در نهایت، هر دو طرف حداقل تا حدی فرض کردند که ایمنی «کار تیم دیگری» است. در حالی که کشتی به شدت بر اساس ایمنی تبلیغ میشد، واقعیت این بود که روند کلی نیم قرن گذشته را ادامه داد که هر سال کشتیها کمتر از سال قبل ایمن ساخته و اداره میشدند. (Brander 1995)
امروز میبینیم که همین مشکل بین فناوری اطلاعات و مهندسی نرمافزار پدیدار میشود – نه لزوماً درباره پایداری (اگرچه آن هم مطمئناً صادق است) بلکه اکنون درباره امنیت که میتوان آن را مشابه ایمنی در زمینه المپیکها دید. امنیت یکی از مهمترین موضوعات دهه گذشته در هر دو طرف حصار فناوری شده است و صنعت با چالشهای ناشی از نیاز هر دو طرف به اجرای کامل روشهای امنیتی روبرو است – هیچ کدام به تنهایی قادر به پیادهسازی واقعی سیستمهای ایمن نیستند. برنامهریزی برای ایمنی یا امنیت به سادگی جایگزین اجرای رویهای آن در طول عملیات نیست.
یک مقایسه عالی امروزی، British Airways است و نحوه برخورد آنها با هر پروازی که بر فراز اقیانوس اطلس انجام میشود. به عنوان حامل اصلی ترافیک هوایی در اقیانوس اطلس شمالی، همان مسیری که المپیکها قرار بود طی کنند، British Airways باید شهرتی برای تعالی در ایمنی حفظ کند. حتی در سال 2017، پرواز بر فراز اقیانوس اطلس شمالی یک سفر دشوار و پیچیده است.
قبل از پرواز هر پرواز British Airways، خلبانان و خدمه باید یک کتابچه راهنمای مأموریت سیصد صفحهای را مرور کنند که همه اطلاعات از جمله جزئیات هواپیما، خدمه، آبوهوا و غیره را به آنها میگوید. این فرآیند آنقدر دقیق است که British Airways حتی از اعتراف به اینکه این یک پرواز است امتناع میکند، بلکه به طور رسمی هر سفر از اقیانوس اطلس را «مأموریت» مینامد؛ به طور خاص برای تأکید بر جدیت و خطر درگیر شدن در چنین پروژهای به همه افراد درگیر. آنها به وضوح اهمیت تغییر نحوه تفکر مردم در مورد چنین سفری را درک میکنند و از آنچه میتواند اتفاق بیفتد آگاه هستند اگر مردم شروع کنند به فرض کردن که دیگران کارشان را خوب انجام دادهاند و آنها میتوانند در کار خودشان کوتاهی کنند. آنها نمیخواهند کسی بیتوجه شود یا احساس کند که پرواز، حتی اگر چند بار در روز انجام شود، هرگز معمولی است. (Winchester)
اگر رویکرد British Airways برای تایتانیک به کار گرفته میشد، بسیار محتمل بود که فاجعه در آن زمان اتفاق نمیافتاد. فقط از جنبه عملیاتی میتوانست از فاجعه جلوگیری شود. به همین ترتیب، اگر مهندسان کشتی با همان استانداردهایی که Boeing یا AirBus امروز دارند مورد توجه قرار میگرفتند، احتمالاً آنقدر آسان تحت فشار مدیریت برای تغییر الزامات ایمنی قرار نمیگرفتند.
آنچه واقعاً المپیکها را به روشهای زیادی تحت تأثیر قرار داد، نوعی گسترش محدوده کنترلنشده بود. پروژه با رویکرد آبشاری سنتی با «طراحی بزرگ از ابتدا» آغاز شد و الزامات اولیه با ایمنی در نقش محوری خوب بودند. اگر الزامات اصلی پروژه و حتی بسیاری از طراحی اصلی استفاده میشد، کشتیها بسیار ایمنتر از آنچه بودند میبودند. اما الزامات جدید برای اتاقهای غذاخوری بزرگتر یا دکوراسیونهای مجللتر اولویت یافتند و محدوده و پارامترهای پروژه برای تطبیق با این تغییرات جدید تغییر کردند. مانند هر پروژهای، هیچ تغییری در خلاء رخ نمیدهد بلکه عواقبی برای عوامل دیگر مانند هزینه، ایمنی یا تاریخ تحویل خواهد داشت. (Sadur)
گسترش محدوده در تایتانیک به طور خاص چشمگیر بود، اما پنهان و لزوماً برای اکثر مردم آشکار نبود. به آسانی میتوان تغییرات کوچکی مانند تغییر اندازه اتاق غذاخوری را نشان داد، اما از اهمیت بسیار بیشتری بود تغییر در بازه زمانی تحویل کشتی. آنچه واقعاً محدوده را تغییر داد این بود که مهلتهای اولیه و پروژهها باید نسبتاً دقیق حفظ میشدند. این موضوع به طور خاص مشکلساز بود زیرا در میانه کار خشکی تایتانیک و بعداً کار لنگرگاه آن، المپیک قدیمیتر برای تعمیرات گسترده چندین بار آورده شد که تأثیر بسیار زیادی بر میزان زمان موجود در برنامه اصلی برای کار خود تایتانیک داشت. این نوع تغییر محدوده بسیار آسان است که نادیده گرفته یا نادیده شود، بهویژه در گذشتهنگری، زیرا محصولات فیزیکی و تاریخهای اصلی به روشی چشمگیر تغییر نکردند. با این حال، برای همه اهداف و اغراض، تایتانیک بسیار سریعتر از آنچه در ابتدا برنامهریزی شده بود از مراحل تولید عبور کرد.
در مهندسی نرمافزار مدرن کاملاً پذیرفته شده است که هیچکس نمیتواند مقدار زمانی را که یک وظیفه طراحی طول میکشد به اندازه مهندس(ان)ی که خودشان این کار را انجام میدهند تخمین بزنند. همچنین به طور کلی پذیرفته شده است که هیچ راهی برای سرعت بخشیدن قابل توجه به تلاشهای مهندسی و طراحی از طریق فشار مدیریتی وجود ندارد. وقتی پروژه با سرعت حداکثری در حال اجرا است، سریعتر نمیشود. تلاش برای سرعت بیشتر اغلب به اشتباهات، غفلتها یا خطاها منجر میشود. میدانیم که این در نرمافزار صادق است و میتوانیم فرض کنیم که برای طراحی کشتی نیز صادق بوده است زیرا اصول یکسان هستند. اگر به تایتانیک زمان مناسبی برای این فرآیند داده میشد، احتمالاً اقدامات ایمنی با دقت بیشتری در نظر گرفته میشدند یا حداقل به درستی به تیم عملیاتی در زمان تحویل منتقل میشدند. تیمهایی که تحت فشار هستند مجبور به سازش میشوند و از آنجا که زمان به عنوان محدودیت قابل تنظیم نیست، باید در جاهای دیگر کوتاهی شود و تقریباً همیشه این از کیفیت و جامعیت میآید. این ممکن است به صورت یک اشتباه ظاهر شود یا شاید به صورت عدم بررسی کامل همه عوامل درگیر هنگام تغییر بخشی از طراحی.
این ما را به تفکر طراحی کلنگر میرساند. در ابتدای پروژه المپیکها با ایمنی در ذهن طراحی شدند: ایمنی که از کارکرد دقیق بسیاری از سیستمهای جداگانهای ناشی میشود که با هم در نظر گرفته شدهاند تا کشتی بسیار قابل اعتمادی بسازند. ما نمیتوانیم به اجزای یک کشتی از این اندازه به صورت جداگانه نگاه کنیم، آنها معنایی ندارند – طراحی بدنه، سبک عرشهها، وزن بار، مواد استفادهشده، سبک تیغهها همه به هم مرتبط هستند و باید با هم کار کنند.
وقتی پروژه به سرعت بیشتر یا تغییر پارامترها فشار آورده شد، این تفکر کلنگر و بازبینی واضح تصمیمات قبلی انجام نشد یا به اندازه کافی انجام نشد. بلکه اجزای فردی بدون توجه به اینکه چگونه این بر نقش آنها بدون کلیت کشتی و تأثیر ناشی از آن بر ایمنی کلی تأثیر میگذارد تغییر کردند. آنچه ممکن بود تغییری جزئی به نظر برسد پیامدهای غیر قابل پیشبینی داشت زیرا مدیریت پروژه کلنگر رها شده بود. (Kozak-Holland)
این تغییر در مهندسی البته در عملیات نیز منعکس شد. هر تغییری مانند عدم استفاده از دوربینهای دوچشمی یا عدم انجام قرائت سطل یخ، به طور فردی تا حدودی جزئی بود، اما در کنار هم به طور باورنکردنی تأثیرگذار بودند. احتمالاً، اما نمیتوانیم مطمئن باشیم، یک سیستم مدیریت پروژه منسجم یا حداقل بهبود فرآیند استفاده نمیشد. چه کسی نظارت میکرد که دوربینهای دوچشمی استفاده شوند، که آزمونهای آب دقیق باشند و غیره؟ هر بررسی ابتدایی آشکار میکرد که ابزارهای مورد نیاز برای آن وظایف اصلاً وجود ندارند. هیچ راهی وجود نداشت که حتی یک آزمایش ساده از رویهها انجام شود، چه رسد به بررسی منظم و بهبود فرآیند. بهبود فرآیند بهویژه با این واقعیت برجسته میشود که کاپیتان اسمیت در RMS Olympic تمرین داشته، در پنجمین سفر آن با برخورد دریایی باعث تصادف شده بود و سپس تقریباً همان اشتباه را با راهاندازی اولیه تایتانیک تکرار کرد. آنچه باید یک درس مهم برای همه کاپیتانها و خلبانان کشتیهای المپیک آموخته میشد به جای آن نادیده گرفته شد و تقریباً فوراً تکرار شد. («المپیک»)
البته کشتیسازی و نرمافزار چیزهای بسیار متفاوتی هستند، اما درسهای بسیاری میتوان به اشتراک گذاشت. یکی از مهمترین درسها این است که محدودیتهای کشتیسازی را ببینیم و تشخیص دهیم که چه زمانی مجبور نیستیم این محدودیتهای یکسان را هنگام کار با نرمافزار حفظ کنیم. المپیک و تایتانیک تقریباً در یک زمان ساخته شدند بدون هیچ زمانی برای دانش مهندسی به دست آمده از ساخت المپیک، چه رسد به عملیات آن، که بر ساخت تایتانیک اعمال شود. در نرمافزار مدرن هرگز چنین محدودیتی انتظار نداریم و میتوانیم نرمافزار را حداقل تا حدی آزمایش کنیم قبل از ادامه به نرمافزار اضافی که بر آن استوار است، چه در کد واقعی یا حتی مفهومی. مدیریت پروژه امروز باید از تفاوتهایی که هم در زمانهای مدرنتر و هم در صنعت متفاوت ما وجود دارد به بهترین شکل بهره ببرد. برخی پروژههای نرمافزاری هنوز به فرآیندهایی شبیه به این نیاز دارند اما اینها در طول زمان بیشتر و بیشتر نادر شدهاند و امروز به طور چشمگیری کمتر از تنها بیست سال پیش رایج هستند.
ارزیابی کاری که Harland-Wolff با المپیکها انجام داد کاملاً ارزش دارد زیرا آنها تلاش کردند حلقههای بازخورد ممکن در اختیارشان را در آن زمان به کار ببرند. آنها نه تنها تلاش کردند از ساخت کشتیهای قبلی برای یادگیری بیشتر برای کشتیهای بعدی استفاده کنند، اگرچه این بسیار محدود بود زیرا کشتیها عمدتاً به طور همزمان در حال ساخت بودند و اکثر درسها زمانی برای اعمال شدن نمیداشتند، بلکه از اهمیت بسیار بیشتری گام فوقالعادهای برداشتند که یک «گروه تضمین» با کشتیها سفر کند. این گروه تضمین شامل انواع شاگردان و استادکاران کشتیساز از انواع حرف حمایتی بود. («گروه تضمین»)
استفاده از گروه تضمین برای بازخورد مستقیم، در آن زمان و واقعاً هنوز هم، بیسابقه بود و یک سرمایهگذاری عظیم در هزینه واقعی و زمان برای کشتیسازان بود که آنقدر کارگران ارزشمند را برای سفر به تجمل در اقیانوس اطلس فداکاری کنند. گروه توانست کار خود را مستقیماً بازرسی کند، آن را در عمل ببیند، درک از استفاده آن در زمینه کشتی در حال کار کسب کند، در ساخت تیم، انتقال دانش و موارد دیگر با هم همکاری کند. این بسیار ارزشمندتر از بازخورد از تأسیسات کشتیسازی که کشتیها در ساخت همزمان بودند، این یک سرمایهگذاری قوی در آینده سازمان کشتیسازی آنها بود: یک تعهد به آموزش صنعتی که احتمالاً برای دههها به آنها سود میرساند.
سبکهای مدرن استقرار، ابزارها و آموزش از عمده نرمافزاری که تحت روششناسی آبشاری ایجاد میشد که از کشتیسازی ابتدای [قرن گذشته] تفاوت زیادی نداشت، به اکثریت که از درجهای از روششناسیهای Agile بهره میبرند و اجازه آزمایش سریع، ارزیابی، تغییرات و استقرار میدهند منتقل شده است. گسترش محدوده از چیزی که باید کاهش یا به شدت مدیریت میشد به چیزی تبدیل شده که میتوان آن را به عنوان مورد انتظار و فرضشده در فرآیند توسعه تلقی کرد حتی تا نقطهای که تقریباً مورد بهرهبرداری قرار گیرد. یکی از مشکلات اساسی طراحی بزرگ از ابتدا این است که همیشه نیاز دارد مشتری یا ذینفع به نقش مشتری «تصمیمات بزرگ از ابتدا» بگیرد که اغلب برای آنها بسیار سختتر از طراحی برای مهندسان است. این تصمیمات اولیه اغلب یکی از عوامل اصلی گسترش محدوده یا درخواستهای تغییر بعدی هستند و اغلب میتوانند با فرآیندهای چابک که تغییر مستمر در الزامات را انتظار دارند و آن را در فرآیند میسازند کاهش یا اجتناب شوند.
کشتیسازان، Harlan و Wolff، یک مدل پانزده فوتی از المپیک برای آزمایش ساختند که تا حدودی مفید است، اما البته نتوانست عمل هیدرولوژیک که کشتی تمام اندازه بعداً تولید میکرد را تقلید کند و برخی از عوارض جانبی خطرناکتر اندازه کشتی جدید را هنگام نزدیکی به کشتیهای دیگر که به اولین تصادف گروه منجر شد و به آنچه نزدیک بود دومین تصادف باشد، پیشبینی نکرد. سازندگان به نظر میرسد هر تلاشی برای آزمایش و یادگیری در هر مرحله موجود در طول فرآیند طراحی و ساخت کردهاند. (Kozak-Holland)
در مقایسه با مدیریت پروژه مدرن این قابل مقایسه با تولید یک نمونه اولیه سریع یا وایرفریم برای توسعهدهندگان یا حتی مشتریان برای تجربه عملی قبل از سرمایهگذاری بیشتر در آنچه ممکن است یک مسیر بنبست برای دلایل پیشبینینشده باشد. این بهویژه در طراحی رابط کاربری مهم است که اغلب توانایی کمی برای پیشبینی صحیح استفادهپذیری یا رتبهبندی رضایت بدون دادن فرصت به کاربران واقعی برای دستکاری فیزیکی سیستم و قضاوت درباره اینکه آیا تجربهای که دنبالش هستند را فراهم میکند یا نه وجود دارد. (Esposito)
البته باید ریسکی را که المپیکها در زمینه تضاد تاریخی آنها در مورد روندها و نیروهای مالی به عهده گرفتند در نظر بگیریم. در آن زمان، از اواسط قرن قبلی، تفکر مالی غالب این بود که بهتر است به سمت ریسکپذیری تمایل داشت تا به سمت ایمنی – از نظر از دست دادن جان، بار یا کشتیها؛ و تفاوت را از طریق وسایل بیمه جبران کرد. از نظر مالی سادهتر بود که کشتیها به روش پرریسک عمل کنند تا اینکه نسبت به جان انسانها بیش از حد احتیاط کنند. این روند، تا زمان المپیکها، تقریباً شصت سال ادامه داشت و تا زمانی که اثرات تبلیغاتی گسترده غرق شدن تایتانیک تغییر شروع نکند، تغییر نخواهد کرد. تأثیر بازار بر عموم مردم تا زمانی که کشتی «غرقناپذیر» با آن همه سرنشین، به روشی چشمگیر گم نشد وجود نداشت.
این رویکرد به ریسک و معاملات مالی آن چیزی است که مدیران پروژه باید امروز همانند بیش از صد سال پیش درک کنند. آسان است که باور کنیم ریسک آنقدر مهم است که ارزش هر هزینهای برای از بین بردن آن را دارد، اما پروژهها نمیتوانند اینطور فکر کنند. میتوان منابع نامحدودی در جستجوی کاهش ریسک صرف کرد. در دنیای واقعی لازم است که ریسکها را با هزینه کاهش ریسک متعادل کنیم. یک مثال عالی از این موضوع در زمانهای مدرن، اما خارج از توسعه نرمافزار به طور خاص، نحوه مدیریت تقلب کارت اعتباری در ایالات متحده است. تا همین چند سال پیش، عموماً این نظر صنعت کارت اعتباری ایالات متحده بود که هزینه اقدامات امنیتی بیشتر بر روی کارتهای اعتباری برای جلوگیری از سرقت در مقایسه با ریسکهای نداشتن آنها زیاد بود؛ اساساً مقرونبهصرفهتر بود که پول صرف بازپرداخت تراکنشهای جعلی شود تا اینکه از آن تراکنشهای جعلی جلوگیری شود. این نسبت هزینه به ریسک گاهی میتواند غیرشهودی و حتی ناامیدکننده باشد، اما چیزی است که باید تصمیمات پروژه را به شیوهای منطقی و محاسبهشده هدایت کند.
در همین راستا، در فناوری اطلاعات رایج است که سیستمها را طراحی کنیم با این باور که خرابی هزینه اساساً نامحدودی دارد و بسیار بیشتر از آنچه هزینه رویداد خرابی واقعی اگر رخ دهد احتمالاً خواهد بود صرف کاهش ریسک خرابی کنیم. این آشکارا احمقانه است، اما آنقدر به ندرت تحلیل هزینه از این نوع انجام میشود یا درست انجام میشود که بسیار آسان است که قربانی این ذهنیت شوند. در پروژههای مهندسی نرمافزار باید با شیوه مشابهی به ریسکها نزدیک شویم. پذیرفتن اینکه ریسکی از هر نوعی وجود دارد و تعیین ریسک واقعی، اندازه تأثیر آن ریسک و مقایسه آن با هزینه استراتژیهای کاهش ریسک برای گرفتن تصمیم مناسب مدیریت پروژه در مورد ریسک بسیار حیاتی است. (Brander 1995)
همچنین برای پروژههای بسیار بزرگ که المپیکها قطعاً واجد شرایط آن بودند، مفهوم اضافی «بزرگتر از آن که شکست بخورد» وجود دارد. البته این یک عبارت مدرن است که در بحران مالی دهه گذشته به وجود آمد، اما این مفهوم و واقعیت آن بسیار قدیمیتر است و یک ملاحظه ارزشمند برای هر پروژهای است که در مقیاسی قرار میگیرد که در صورت شکست کامل پروژه «فاجعه مالی ملی» ثبت میکند. در مورد المپیکها، دولت بریتانیا در نهایت سرمایهگذاران را از فاجعه کامل بیمه کرد زیرا فروپاشی یکی از بزرگترین خطوط مسافری در آن زمان برای کشور ویرانگر میبود.
White Star Lines ساده «خیلی بزرگ بود که شکست بخورد» و توسط دولت قبل از ادغام اجباری در Cunard چند سال بعد سرپا نگه داشته شد. این مفهوم، با دانستن اینکه دولت نمیخواهد ریسکهای شکست شرکت را بپذیرد، ممکن است در آن زمان محاسبه یا در نظر گرفته شده باشد، نمیدانیم. اما میدانیم که این موضوع امروز با پروژههای بسیار بزرگ در نظر گرفته میشود. مثالی از این اتفاق در حال حاضر، F-35 Lockheed Martin است که به طور چشمگیری از بودجه فراتر رفته، از تاریخ تحویل گذشته و دیگر حتی محتمل نیست که مفید باشد اما سالها توسط حامیان دولتی مختلف حمایت شده که پروژه را برای اقتصاد ملی خیلی مهم میبینند، حتی در حالت شکست در تحویل، تا اجازه دهند پروژه به طور کامل سقوط کند. با بهتر و بهتر شناخته شدن این پدیده، احتمالاً میبینیم که پروژههای بیشتری این موضوع را در مراحل تحلیل ریسک خود در نظر میگیرند. (Ellis)
به سمت جنبه عملیاتی معادله برویم، میتوانیم هر تعداد از جنبههایی را که منجر به غرق شدن تایتانیک شد بررسی کنیم، اما در هسته آن فکر میکنم آنچه بیشتر از همه آشکار بود فقدان رویههای عملیاتی استاندارد در طول فرآیند بود. این تا حدودی قابل درک است زیرا کشتی در سفر افتتاحی خود بود و زمان کمی برای مستندسازی و بهبود فرآیند وجود داشت. با این حال این کشتی پرچم یک خط کشتیرانی با سابقه طولانی بود که شهرتی برای حفظ داشت و تجربه زیادی در این زمینه داشت. همچنین نادیده میگیرد که تا زمانی که تایتانیک سعی میکرد اولین سفر خود را انجام دهد، المپیک آنقدر در سرویس بود که به اندازه کافی مجموعه رضایتبخشی از رویههای عملیاتی استاندارد را ایجاد کرده باشد.
مستندسازی پایه حتی در سفر افتتاحی انتظار میرفت، انتظار غیرمعقولی است که کشتی در این مقیاس اصلاً بتواند کار کند مگر اینکه هماهنگی و ارتباط میان خدمه وجود داشته باشد. سالها وجود داشت، در واقع سالها، برای رویههای عملیاتی پایه خدمه ایجاد و آماده شود قبل از اینکه اولین کشتی حرکت کند و البته این باید برای همه کشتیهای از این نوع انجام میشد، اما آشکار بود که چنین رویههای عملیاتی در مورد تایتانیک ناقص، ناموجود و آزمایشنشده بودند.
طرف مسئول رویههای عملیاتی احتمالاً از طرف عملیاتی معادله پروژه شناسایی میشود، اما نیاز به درجاتی از چنین مستنداتی بود که توسط یا هماهنگشده با تیمهای مهندسی و ساخت ارائه شود. بسیاری از رویههایی که در تایتانیک شکست خورد شامل شکست زنجیره فرماندهی تحت فشار با کارگردان شرکت که به سکوی فرماندهی آمد و کاپیتان که اجازه داد، اپراتورهای بیسیم که دستور داشتند پیامهای مسافران را به عنوان اولویت بر هشدارهای کوه یخ منتقل کنند، اجازه دادن به اپراتورهای بیسیم که به کشتیهای دیگری که سعی میکردند هشدار دهند بگویند از پخش آنها جلوگیری کنند، پیامهای حیاتی که به سکوی فرماندهی نرسید، ابزارهای مورد نیاز برای وظایف حیاتی که تأمین نشد و غیره بود. (Kuntz)
درست مانند آنچه برای مهندسی و طراحی کشتیها نیاز بود، عملیات کشتیها نیازمند راهنمایی قوی و کلنگر بود که اطمینان حاصل کند که کشتی و خدمهاش به عنوان یک کل کار میکنند نه اینکه به بخشهایی مانند اپراتورهای بیسیم مارکنی به عنوان یک واحد فردی نگاه کنند. در آن مثال، آنها رسماً خدمه کشتی نبودند بلکه کارمندان مارکنی بودند که برای مدیریت ارتباطات پولی مسافران و فقط در صورت در دسترس بودن وقت، ترافیک اضطراری کشتی را مدیریت کنند. اگر به عنوان بخشی از یک سیستم مدیریت عملیاتی کلنگر، حتی به عنوان پیمانکاران خارجی، نظارت میشدند، احتمالاً رویههای آنها بسیار بیشتر ایمنیمحور میبودند یا، حداقل، توافقنامههای سطح خدمات برای رساندن پیامها به سکوی فرماندهی به جای اینکه موقتی و اختیاری باشند به وضوح تعریف میشدند.
در هر پروژه و مؤلفه پروژه، مستندسازی خوب چه از اهداف پروژه، محصولات قابل تحویل، رویهها و غیره حیاتی است و مدیریت پروژه امیدی به موفقیت ندارد اگر ارتباطات و مستندسازی خوب در قلب همه کارهایی که انجام میدهیم، هم در داخل پروژه و هم در خارج با ذینفعان، نباشد.
آنچه امروز میبینیم این است که درسهای مدیریت پروژه المپیک، تایتانیک و بریتانیک همچنان برای ما ارزشمند هستند و زمینه عصر چه در فشار برای طراحی پروژه تکراری در صورت امکان، سرمایهگذاری در دانش قبیلهای، محاسبه ریسک، درک نقشهای مهندسی سیستم و عملیات سیستم یا تعاملات نیروهای خارجی محافظ بر هزینههای محصول هنوز مرتبط هستند. عواملی که بر پروژهها تأثیر میگذارند در چرخههایی میآیند و میروند، امروز میبینیم که روندها به سمت مدلهایی بیشتر شبیه المپیکها تمایل دارند تا برخلاف آنها. در آینده، احتمالاً، آونگ دوباره برخواهد گشت. درسهای اساسی بسیار مرتبط هستند و همچنان خواهند بود. ما میتوانیم هم با ارزیابی اینکه پروژههای خود چقدر به پروژههای White Star شباهت دارند و هم چقدر با آنها متفاوت هستند درسهای زیادی بیاموزیم.
منابع و مآخذ:
Miller, Scott Alan. Project Management of the RMS Titanic and the Olympic Ships, 2008.
Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.
Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.
Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.
Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry, February 2007.
Esposito, Dino. “Cutting Edge – Don't Gamble with UX—Use Wireframes.” MSDN Magazine, January 2016.
Sadur, James E. Home page. “Jim's Titanic Website: Titanic History Timeline.” (2005): 13 February 2017.
Winchester, Simon. “Atlantic.” Harper Perennial, 2011.
Titanic-Titanic. “Olympic.” (Date Unknown): 15 February 2017.
Titanic-Titanic. “Guarantee Group.” (Date Unknown): 15 February 2017.
Brander, Roy. P. Eng. “The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture”. (1998): 16 February 2017.
Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 16 February 2017.
Ellis, Sam. “This jet fighter is a disaster, but Congress keeps buying it.”. Vox, 30 January 2017.
یادداشتهای اضافی:
Mark Kozak-Holland ابتدا کتاب خود را در سال 2003 به صورت مجموعهای از مقالات Gantthead درباره تایتانیک منتشر کرد:
Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers and later ProjectManagement.com (2003): 8 February 2017.
بیشتر بخوانید:
Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.
Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.
US Senate and British Official Hearing and Inquiry Transcripts from 1912 at the Titanic Inquiry Project.
آگهی
