از اختلال کوچک تا شکست بزرگ

ما دوست داریم برای هر شکست بزرگ، یک علت بزرگ پیدا کنیم.

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

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

شکست چگونه رشد می‌کند؟

یک الگوی رایج چنین است:

1. یک فرض کوچک غلط از آب درمی‌آید.
2. نخستین نشانه دیده می‌شود، اما جدی گرفته نمی‌شود.
3. فردی امیدوار است مشکل را بدون اطلاع دیگران حل کند.
4. برنامه‌های وابسته بر اساس اطلاعات قدیمی ادامه پیدا می‌کنند.
5. حاشیهٔ زمانی و گزینه‌های جایگزین کم می‌شوند.
6. مسئله در لحظه‌ای آشکار می‌شود که دیگر اصلاح کم‌هزینه ممکن نیست.

در پایان، شکست ناگهانی به نظر می‌رسد؛ اما مسیر آن مدت‌ها در حال ساخته‌شدن بوده است.

مثال یک پروژهٔ معمولی

قرار است نسخهٔ جدید یک محصول دوشنبه منتشر شود.

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

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

شنبه، تیم می‌فهمد حل مشکل به تغییر بخشی از معماری نیاز دارد. فروش پیش‌فروش را آغاز کرده، پشتیبانی پیام مشتریان را آماده کرده و تیم بازاریابی کمپین را زمان‌بندی کرده است.

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

سیستم فقط مجموعهٔ آدم‌ها نیست

یک تیم می‌تواند از افراد توانمند و خیرخواه ساخته شده باشد و همچنان خروجی غیرقابل اتکا تولید کند.

عملکرد کل فقط جمع کیفیت افراد نیست. رابطهٔ میان آن‌ها نیز مهم است:

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

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

درس سازمان‌های پرریسک

در محیط‌هایی مانند هوانوردی، شبکهٔ برق و مراقبت ویژه، حذف کامل خطا ممکن نیست و هزینهٔ نادیده‌گرفتن نشانه‌ها بسیار بالاست. سازمان‌هایی که قابلیت اطمینان بالاتری دارند، معمولاً با یک ویژگی شناخته می‌شوند: به نشانه‌های ضعیف و وضعیت‌های غیرمنتظره زودتر توجه می‌کنند.

آن‌ها فرض نمی‌کنند چون دیروز حادثه‌ای رخ نداده، امروز نیز سیستم سالم است. نبود حادثه را نتیجهٔ توجه، بررسی و تنظیم مداوم می‌دانند.

این به معنای کپی‌کردن رویه‌های سنگین یک نیروگاه در هر تیم کوچک نیست. اصل قابل انتقال این است:

اختلال کوچک زمانی کم‌هزینه می‌ماند که سیستم بتواند آن را زود ببیند، بدون ترس بیان کند و به اقدام متصل سازد.

به‌جای مقصر، مسیر شکست را پیدا کنید

پس از یک شکست، پرسش «چه کسی اشتباه کرد؟» ممکن است لازم باشد، اما کافی نیست. پرسش‌های دقیق‌تر عبارت‌اند از:

• نخستین نشانهٔ قابل مشاهده چه بود؟
• چه کسی آن را دید؟
• چه چیزی مانع انتقال یا جدی‌گرفتن آن شد؟
• کدام تصمیم‌ها همچنان بر فرض قدیمی بنا شدند؟
• چه کنترل یا بازخوردی وجود نداشت؟
• کجا امکان محدودکردن اثر وجود داشت؟

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

تمرین: خط زمانی یک شکست

یک تأخیر یا شکست واقعی را انتخاب کنید و پنج نقطه را روی خط زمان بنویسید:

1. تعهد یا انتظار اولیه
2. نخستین نشانهٔ اختلال
3. نخستین زمانی که نشانه می‌توانست اعلام شود
4. زمانی که دیگران واقعاً باخبر شدند
5. اثری که تا آن زمان گسترش پیدا کرده بود

بعد بپرسید: اگر در نقطهٔ سوم اطلاعات منتقل می‌شد، کدام گزینه‌ها هنوز باز بودند؟

جمع‌بندی

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

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

منابع

• Columbia Accident Investigation Board Report, Volume I، هیئت بررسی حادثهٔ کلمبیا، ۲۰۰۳.
• Weick, K. E., Sutcliffe, K. M., & Obstfeld, D. (1999). Organizing for High Reliability: Processes of Collective Mindfulness.