Crew Resource Management: درس‌هایی که دولوپرها می‌توانند از خلبان‌ها بگیرند!

در دههٔ ۱۹۷۰، سازمان فضایی ناسا تحقیقی انجام داد که در نهایت منجر به کاهش چشمگیر سقوط هواپیما‌های مسافربری شد! نتایج آن تحقیق حاکی از آنند که درصد قابل‌توجهی از دلایل سقوط هواپیماها مرتبط با اطمینان خداگونهٔ خلبان‌ها بوده است به طوری که در آن‌ دهه‌ها، خلبان‌ها آن‌قدر به خود اعتماد داشتند که وقتی تصمیمی -ولو اشتباه- می‌گرفتند، هرگز به توصیهٔ دیگر اعضای کابین توجهی نمی‌کردند! به عبارت دیگر، اگر خلبان‌ با دیگر خدمهٔ پرواز مشورت می‌کرد یا اگر خلبان احتمالات دیگر را در نظر می‌گرفت، امکان داشت تا از اتخاذ برخی تصمیمات بد و اشتباه جلوگیری به عمل آید؛ در واقع، هدف CRM (مخفف واژگان Crew Resource Management به معنی مدیریت منابع خدمهٔ پرواز) خلق فضایی بود که در آن دیدگاه‌های گوناگون آزادانه مطرح شده و مورد مشورت قرار گیرند.

یک مثال واقعی از غرور یک خلبان
در سال ۱۹۷۸، خلبان پرواز شمارهٔ ۱۷۳ شرکت هواپیمایی یونایتد منجر به کشته شدن ۱۰ نفر و زخمی شدن ۲۴ نفر از ۱۸۹ مسافر هواپیمای DC-8 شد! به طوری که یکی از بارزسان تحقیق‌کننده دربارهٔ این حادثه، خلبان مذکور را فردی مغرور توصیف کرد.

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

بعضی وقت‌ها خلبان ارشد آن‌قدرها هم که ما فکر می‌کنیم زرنگ و باهوش نیست!

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

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

چگونه می‌توانیم ایدهٔ CRM را در تیم‌های نرم‌افزاری پیاده کنیم؟
آنچه در مورد خلبان‌ها در دههٔ ۷۰ میلادی صدق می‌کرد، امروزه کمابیش در مورد دولوپرهای ارشد، مدیران پروژه و به طور کلی کسانی که وظیفهٔ رهبری کردن تیم‌های نرم‌افزاری را دارند دیده می‌شود. به عبارت دیگر، اگر تجربهٔ کار در چنین تیم‌هایی را داشته باشید، دیده‌اید معمولاً یک نفر که سابقهٔ بیشتری از سایرین دارد تصمیم‌گیرنده بوده و دیگر دولوپرها نقش Yes Man (بله قربان‌ گو) را بازی می‌کنند!

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

به عبارت دیگر، کسانی که مدیر یک شرکت هستند و یا مدیریت یک پروژه را برعهده دارند، باید فضایی ایجاد کنند تا Hierarchy (سلسله مراتب) تا حد ممکن به حداقل برسد تا یکه‌تازی دولوپر ارشد یک تیم -که ممکن است گاهی‌اوقات هاله‌ای از نور دور خود ببیند- به حداقل برسد و دولوپرهای تازه‌کار و کم‌تجربه‌تر نیز بتوانند عرض اندام کنند.

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

کلام آخر
گرچه تأثیر پیاده‌سازی ایدهٔ سی‌آرام در فرایند توسعهٔ نرم‌افزار به حساسیت آن در صنایع هواپیمایی و پزشکی نیست، اما مسلماً وقتی چنین طرحی توانسته جان هزاران نفر را از دههٔ ۱۹۷۰ تاکنون در سراسر دنیا نجات دهد، مسلماً الهام گرفتن از آن در فرایند توسعهٔ نرم‌افزار و رهبری دولوپرها نیز بی‌تأثیر نخواهد بود و حداقل منجر به ایجاد فضای رشدی برای تمامی اعضای تیم می‌شود.

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