عنوان
تمامیت!
جلسهٔ صفر: وقتی نمیشود روی چیزی حساب کرد
آغاز
ساعت ۹:۳۰ صبحِ اول اوت ۲۰۱۲، بازار سهام نیویورک باز شد.
در همان دقایق اول، اتفاق عجیبی افتاد. یک شرکت معاملهگری به نام Knight Capital شروع کرد به فرستادن سیلی از سفارشها به بازار؛ سفارشهایی که منطق روشنی نداشتند. سیستم بعضی سهمها را میخرید و تقریباً بلافاصله میفروخت. دوباره میخرید. دوباره میفروخت. انگار ماشینی بهسرعت کار میکرد، اما دیگر نمیدانست برای چه کاری ساخته شده است.
ماجرا فقط چهلوپنج دقیقه طول کشید.
در این چهلوپنج دقیقه، سامانهٔ شرکت برای اجرای فقط ۲۱۲ سفارش مشتری، بیش از چهار میلیون سفارش وارد بازار کرد، بیش از ۳۹۷ میلیون سهم معامله کرد و موقعیتهای ناخواستهای به ارزش چند میلیارد دلار ساخت. زیان نهایی شرکت بیش از ۴۶۰ میلیون دلار بود.
چیزی نزدیک به ده میلیون دلار در هر دقیقه.
ممکن است اولین واکنش ما این باشد: «حتماً یک برنامهنویس ضعیف کد بدی نوشته بود.»
اما گزارش رسمی کمیسیون بورس و اوراق بهادار آمریکا تصویر ناراحتکنندهتری نشان میدهد.
برای راهاندازی قابلیت جدید، نرمافزار باید روی هشت سرور مستقر میشد. یکی از تکنسینها کد جدید را فقط روی هفت سرور کپی کرد. سرور هشتم، کد قدیمیای را نگه داشت که نباید فعال میشد. هیچ نفر دومی مستقلاً استقرار را کنترل نکرد. هیچ رویهٔ رسمیای برای بازبینی وجود نداشت. شرکت بعد از استقرار، سامانه را طوری آزمایش نکرد که نشان دهد کد روی هر هشت سرور درست نصب شده است.
حتی پیش از بازشدن بازار، یک سیستم داخلی ۹۷ ایمیل خودکار تولید کرد که از وقوع خطا خبر میداد. اما این پیامها بهعنوان هشدار عملیاتی طراحی نشده بودند و کسی بر مبنای آنها مداخله نکرد.
در ظاهر، فقط یک خطا رخ داده بود: یک سرور بهروزرسانی نشده بود.
اما اگر کمی دقیقتر نگاه کنیم، با یک خطا طرف نیستیم. با زنجیرهای از گسستها روبهرو هستیم:
- استقرار نرمافزار به حافظه و دقت یک نفر وابسته بود.
- تکمیل استقرار، معیار قابل مشاهده و تأیید مستقلی نداشت.
- آزمایشی برای تشخیص اختلاف میان هشت سرور وجود نداشت.
- هشدارها تولید میشدند، اما به اقدام متصل نبودند.
- وقتی بازار باز شد، سامانه با سرعتی بسیار بیشتر از توان تشخیص انسان عمل کرد.
تکتک اجزا ظاهراً وجود داشتند: آدم متخصص، کد، سرور، ایمیل، فرایند استقرار و تیم عملیات. بااینحال، کل سیستم کاری را که باید انجام میداد، بهشکلی قابل اتکا انجام نداد.
پروندهٔ Knight Capital را میتوان داستان یک خطای نرمافزاری دانست. میتوان آن را داستان ضعف کنترل داخلی دانست. میتوان دربارهٔ مقررات بازار یا مهندسی انتشار نرمافزار حرف زد. اما برای ما، این پرونده یک پرسش بنیادیتر میسازد:
چه چیزی باعث میشود واقعاً بتوانیم روی یک انسان، یک تیم یا یک سیستم حساب کنیم؟
این دوره از همین پرسش آغاز میشود.
نه از این پرسش که چه کسی آدم خوبی است.
نه از این پرسش که چه کسی نیت پاکی دارد.
و نه حتی از این پرسش که چه کسی باهوشتر یا سختکوشتر است.
پرسش ما این است: چه چیزی امکان اتکا را به وجود میآورد؟
خوببودن، ماهربودن و قابلاتکا بودن یک چیز نیستند
به کسی فکر کنید که دوستش دارید و مطمئنید برای شما بد نمیخواهد؛ اما اگر قرار باشد ساعت چهار صبح شما را به فرودگاه برساند، ترجیح میدهید راه دیگری پیدا کنید.
شاید آدم مهربانی باشد. شاید صادق هم باشد. شاید اگر بیدار شود، واقعاً برای کمک بیاید. اما تجربه به شما میگوید ساعت خوابش قابل پیشبینی نیست، تلفنش گاهی خاموش است و چند بار زمان را اشتباه کرده است.
شما دربارهٔ ارزش انسانی او داوری نکردهاید. دربارهٔ یک وضعیت عملی تصمیم گرفتهاید:
«آیا میتوانم برنامهٔ مهمی را بر این فرض بنا کنم که او در زمان لازم حاضر خواهد بود؟»
این تفاوت، ساده به نظر میرسد؛ اما بخش بزرگی از سردرگمی ما از نادیدهگرفتن همین تفاوت میآید.
ما معمولاً چند چیز را در هم میآمیزیم. از خودمان نمیپرسیم آیا این فرد نیت خوبی دارد، آیا توانایی انجام کار را دارد، و آیا میتوان بر مبنای عملکردش برنامهریزی کرد. این پرسشها را یکی میکنیم و با یک جواب کلی کنار میگذاریم: «آدم قابل اعتمادی است» یا «نیست».
پاسخ این سه پرسش الزاماً یکی نیست.
ممکن است کسی خیرخواه باشد، اما مهارت لازم را نداشته باشد. ممکن است بسیار ماهر باشد، اما اطلاعات حیاتی را دیر منتقل کند. ممکن است صادقانه بگوید «نرسیدم»، اما آنقدر دیر بگوید که دیگر هیچکس نتواند اثر تأخیر را مدیریت کند.
از آن طرف، ممکن است کسی در یک حوزه کاملاً قابل اتکا باشد و در حوزهای دیگر نه. همکاری که در تحلیل داده بسیار دقیق است، شاید در تخمین زمان ضعیف باشد. مدیری که در بحران آرام و قابل اتکاست، ممکن است در پیگیری کارهای روزمره آشفته باشد.
پس «قابلاتکا» یک مُهر کلی روی شخصیت نیست.
قابلیتاتکا همیشه در نسبت با یک کارکرد، یک زمینه، یک افق زمانی و یک سطح ریسک معنا پیدا میکند.
وقتی میگوییم یک ساعت قابل اتکاست، منظورمان این نیست که ساعت «خوب» است. منظورمان این است که در شرایط تعریفشده، زمان را با دقت مورد انتظار نشان میدهد. وقتی میگوییم یک پل قابل اتکاست، دربارهٔ صداقت پل حرف نمیزنیم؛ دربارهٔ توان سیستم برای تحمل بار مورد انتظار، در محدودهٔ طراحی و در طول زمان حرف میزنیم.
دربارهٔ انسانها زبان پیچیدهتر میشود، چون انسان شیء نیست؛ قصد دارد، انتخاب میکند، خسته میشود، میترسد، اطلاعات تازه دریافت میکند و در شبکهای از وابستگیها عمل میکند. اما پرسش عملی همچنان پابرجاست:
اگر کار من به کار تو وابسته باشد، چه چیزی به من اجازه میدهد تصمیمهایم را بر گفته و رفتار تو بنا کنم؟
امکان برنامهریزی در جهانی نامطمئن
یک سوءتفاهم مهم را همینجا کنار بگذاریم: قابلاتکا بودن به معنای هرگز شکستنخوردن نیست.
هیچ انسان، تیم یا سیستم جدیای نمیتواند چنین وعدهای بدهد. هرچه کار پیچیدهتر باشد، عوامل بیرون از کنترل بیشتر میشوند: مشتری نظرش را تغییر میدهد، تأمینکننده تأخیر میکند، بیماری پیش میآید، فرض فنی غلط از آب درمیآید یا شرایط بازار تغییر میکند.
اگر قابلیتاتکا را با بیخطایی یکی بدانیم، دو اتفاق بد میافتد.
اول اینکه افراد برای حفظ تصویر «آدم قابلاعتماد» خطاها و تأخیرها را پنهان میکنند. خبر بد دیرتر میرسد و هزینهٔ اصلاح بیشتر میشود.
دوم اینکه سیستم را طوری طراحی میکنیم که انگار خطا رخ نخواهد داد. در نتیجه، با اولین خطا، کل ساختار غافلگیر میشود.
پژوهش دربارهٔ سازمانهای با قابلیت اطمینان بالا از مشاهدهٔ محیطهایی شکل گرفت که خطا در آنها میتواند فاجعهبار باشد: ناوهای هواپیمابر، کنترل ترافیک هوایی، شبکههای برق و برخی واحدهای مراقبت ویژه. نکتهٔ جالب این نبود که این سازمانها انسانهای بیخطا پیدا کرده بودند. نکته این بود که یاد گرفته بودند خطا، نشانهٔ ضعیف و وضعیت غیرمنتظره را زود ببینند و پیش از تبدیلشدن به فاجعه به آن پاسخ دهند.
در این ادبیات، قابلیتاتکا چیزی شبیه یک «رویداد رخندادهٔ پویا» است: فاجعه رخ نمیدهد، اما این عدم وقوع محصول سکون نیست؛ محصول توجه و تنظیم مداوم است.
این نگاه، تعریف مفیدتری به ما میدهد:
قابلیتاتکا یعنی دیگران بتوانند، با دانستن محدودیتها و با سطح قابل قبولی از ریسک، بر عملکرد یا اطلاعرسانی ما تکیه کنند.
به دو جزء این جمله دقت کنید:
عملکرد و اطلاعرسانی.
اگر خروجی وعدهدادهشده را در زمان و کیفیت توافقشده تحویل دهم، امکان اتکا ایجاد کردهام.
اگر در میانهٔ راه بفهمم تحویل ممکن نیست، اما این واقعیت را زود، روشن و مسئولانه اعلام کنم؛ اثر را توضیح دهم؛ گزینههای جایگزین بسازم؛ و تعهد تازهای بدهم که معتبرتر است، هنوز بخشی از امکان اتکا را حفظ کردهام.
نتیجه همان نتیجهٔ اولیه نیست. شکست واقعاً رخ داده است. هزینه هم ممکن است باقی بماند. اطلاعرسانی جای تحویل را نمیگیرد. اما میان «تعهدی که محقق نشد و به آن رسیدگی شد» و «تعهدی که محقق نشد و دیگران ناگهان با پیامدش روبهرو شدند» تفاوت عملی بزرگی وجود دارد.
قابلاتکا بودن، تضمین کنترل جهان نیست.
قابلاتکا بودن یعنی رابطهٔ ما با واقعیت، تعهد و گسست، برای دیگران قابل فهم و قابل استفاده بماند.
یک قول دقیقاً از چه ساخته میشود؟
فرض کنید مدیر پروژه در جلسه میگوید:
«نسخهٔ جدید را احتمالاً تا چهارشنبه آماده میکنیم.»
مدیر فروش میشنود:
«چهارشنبه میتوانم آن را به مشتری نشان دهم.»
تیم فنی منظورش این است:
«اگر مشکل تازهای پیدا نشود، چهارشنبه نسخهای برای آزمایش داخلی داریم.»
مدیرعامل تصور میکند:
«چهارشنبه محصول آمادهٔ انتشار است.»
همه یک جمله را شنیدهاند، اما چهار واقعیت متفاوت ساختهاند.
چهارشنبه که میرسد، هرکس فکر میکند دیگری خلف وعده کرده است. شاید مشکل اصلی این نباشد که قول شکسته شده؛ شاید اصلاً قول واحدی وجود نداشته است.
برای اینکه یک تعهد بتواند مبنای هماهنگی باشد، باید بشود آن را بدون حدسزدن فهمید. دقیقاً چه خروجی یا اقدامی پذیرفته شده؟ برای چه کسی؟ تا چه زمان یا در چه بازهای؟ از کجا میفهمیم کار واقعاً انجام شده و طرف مقابل آن را میپذیرد؟ و این تعهد به کدام فرضها، آدمها یا شرایط وابسته است؟
این فهرست ممکن است در نگاه اول بوروکراتیک به نظر برسد. اما قرار نیست هر قول روزمره به قرارداد حقوقی تبدیل شود. عمقِ شفافسازی باید با اندازهٔ ریسک متناسب باشد.
برای هماهنگکردن یک تماس دوستانه، شاید «فردا عصر زنگ میزنم» کافی باشد. برای مهاجرت دادههای مالی یک شرکت، چنین جملهای فاجعهآمیز است.
هرچه اثر یک تعهد بر تصمیم دیگران بیشتر باشد، نیاز به وضوح، مشاهدهپذیری و سازوکار رسیدگی بیشتر میشود.
حالا یک لایهٔ دشوارتر:
گاهی ما چیزی را قول مینامیم که در واقع فقط امید است.
میگوییم «انجامش میدهم»، درحالیکه هنوز ظرفیت خود را نسنجیدهایم. وابستگیها را نمیدانیم. اختیار لازم را نداریم. یا بهدلیل ترس از ناامیدکردن طرف مقابل، جرئت نمیکنیم بگوییم «نمیدانم» یا «نه».
لحظهای که میگوییم «بله»، ممکن است از نظر اجتماعی خوشایند باشد؛ اما اگر این بله روی واقعیت عملیاتی بنا نشده باشد، هزینه فقط به آینده منتقل شده است.
یک «نه» روشن در زمان درست، گاهی از یک «بله»ی غیرمعتبر قابل اتکاتر است.
یک «هنوز نمیتوانم متعهد شوم؛ تا ساعت سه بررسی میکنم و پاسخ میدهم» گاهی حرفهایتر از وعدهای است که فقط برای آرامکردن فضا داده میشود.
قابلیتاتکا از لحظهٔ تحویل شروع نمیشود. از کیفیت لحظهای شروع میشود که تعهد را میپذیریم.
چرا آدمهای خوب همیشه قابل اتکا نیستند؟
پاسخ سطحی این است: چون اراده ندارند.
اما واقعیت معمولاً غنیتر است.
ما برای محافظت از رابطه، به رابطه آسیب میزنیم
نمیخواهیم همکار یا مدیرمان را ناامید کنیم، پس زود «بله» میگوییم. بعد، وقتی نشانههای تأخیر ظاهر میشود، خبر بد را عقب میاندازیم؛ چون امیدواریم با کمی فشار بیشتر جبران کنیم. هر ساعت تأخیر در اطلاعرسانی، گزینههای طرف مقابل را کمتر میکند. در نهایت همان رابطهای آسیب میبیند که میخواستیم از آن محافظت کنیم.
تخمین را با تعهد اشتباه میگیریم
ذهن انسان در برنامهریزی اغلب خوشبین است. کاری را بر اساس مسیر بیمانع تخمین میزند، نه بر اساس توزیع واقعی موانع. اما مسئله فقط خطای شناختی نیست؛ ساختار سازمان هم ممکن است تخمین خوشبینانه را پاداش دهد و خبر بد را تنبیه کند.
هویت خود را حفظ میکنیم
برای بسیاری از ما، گفتن «نمیرسم»، «نمیدانم» یا «کمک لازم دارم» فقط گزارش واقعیت نیست؛ تهدیدی علیه تصویر فرد توانمند است. بنابراین با واقعیت مذاکره میکنیم تا لازم نباشد تصویرمان را اصلاح کنیم.
ظرفیت را خصوصی نگه میداریم
دیگران خروجی ما را میبینند، اما بار کاری، محدودیت و وابستگیهایمان را نه. اگر این اطلاعات فقط در ذهن ما بماند، هماهنگی جمعی بر پایهٔ حدس شکل میگیرد.
مسئله را به صفت شخصیت تقلیل میدهیم
وقتی همکاری دیر تحویل میدهد، سریع میگوییم «بیمسئولیت است». این برچسب شاید بخشی از واقعیت را بگیرد، اما مکانیسم را پنهان میکند. آیا تعهد روشن بود؟ آیا او اختیار داشت؟ آیا دو مدیر، دو اولویت متعارض داده بودند؟ آیا اعلام خطر هزینهٔ روانی یا سیاسی داشت؟ آیا این الگو در همهٔ موقعیتها رخ میدهد یا فقط در شرایط خاص؟
نظریهٔ شناختی ـ عاطفی شخصیتِ والتر میشل و یوییچی شودا دقیقاً با این تصور ساده مقابله میکند که رفتار را میتوان مستقیم از یک صفت ثابت پیشبینی کرد. رفتار انسان از تعامل الگوهای نسبتاً پایدار فرد با ویژگیهای موقعیت پدید میآید. این حرف به معنای حذف مسئولیت فرد نیست؛ به معنای دقیقترکردن محل مداخله است.
اگر مسئله فقط «آدم بد» باشد، ابزار ما سرزنش یا جایگزینی فرد است.
اگر مسئله الگویی میان فرد و موقعیت باشد، ابزارهای بیشتری پیدا میکنیم: روشنکردن تعهد، اصلاح بار، آشکارکردن وابستگی، تغییر مشوق، کاهش هزینهٔ خبر بد و ساختن حلقهٔ بازخورد.
دقت علمی، انسان را تبرئه نمیکند. امکان اصلاح را بیشتر میکند.
وقتی مجموعهای از آدمهای توانا، خروجی ناتوان میسازد
یک تیم را تصور کنید که از پنج متخصص عالی تشکیل شده است.
هرکس در کار خودش قوی است. جلسات پر از ایدههای خوباند. هیچکس عمداً به تیم آسیب نمیزند. بااینحال، تحویلها عقب میافتند، دوبارهکاری زیاد است و تصمیمها چند بار باز میشوند.
چطور ممکن است مجموعهای از افراد توانمند، خروجی غیرقابل اتکا بسازد؟
چون عملکرد کل، جمع سادهٔ کیفیت اجزا نیست.
یک ارکستر از بهترین نوازندگان جهان، بدون توافق دربارهٔ قطعه، ضرب، رهبر و لحظهٔ آغاز، موسیقی قابل شنیدنی تولید نمیکند. مسئله ضعف نوازندهها نیست؛ رابطهٔ میان اجزاست.
در تیمها نیز قابلیتاتکا از پیوندها ساخته میشود:
- چه کسی حق تصمیم نهایی دارد؟
- چه اطلاعاتی باید به چه کسی برسد؟
- کدام تحویل، ورودی کار دیگری است؟
- تعارض اولویتها چگونه حل میشود؟
- چه زمانی یک انحراف کوچک باید اعلام شود؟
- آیا خبر بد، اطلاعات ارزشمند تلقی میشود یا بیکفایتی؟
- وقتی شرایط تغییر میکند، چه کسی مجاز است برنامه را اصلاح کند؟
گزارش هیئت بررسی حادثهٔ شاتل کلمبیا به نتیجهای رسید که برای هر سازمان حرفهای تکاندهنده است. برخورد قطعهای فوم به بال، علت فیزیکی حادثه بود؛ اما هیئت بررسی تصریح کرد که رویههای مدیریتی و فرهنگ سازمانیِ حاکم بر برنامهٔ شاتل نیز بهاندازهٔ علت فنی در وقوع حادثه نقش داشتند.
یعنی نمیتوان داستان را در جملهٔ «فوم به بال برخورد کرد» تمام کرد.
اطلاعات وجود داشت. نشانهها وجود داشتند. افراد متخصص وجود داشتند. اما سازمان در نحوهٔ شنیدن، تفسیر و بالا بردن نگرانیها قابل اتکا نبود.
یک سیستم فقط وقتی اطلاعات دارد که بتواند بر مبنای آن عمل کند. دادهای که تولید میشود اما به توجه نمیرسد، نگرانیای که بیان میشود اما قدرت تغییر تصمیم ندارد، و هشداری که به اقدام متصل نیست، از نظر عملی بخشی از هوش سیستم نشده است.
در Knight Capital، ۹۷ پیام وجود داشت؛ اما حلقهٔ پاسخ کامل نبود.
در بسیاری از تیمهای روزمره هم داشبورد، گزارش، جلسه و پیام وجود دارد؛ اما هنوز کسی نمیداند کدام نشانه به چه تصمیمی متصل است.
سیستمهای غیرقابل اتکا همیشه بیاطلاع نیستند. گاهی در اطلاعات غرقاند، اما سازوکاری برای تبدیل علامت به اقدام ندارند.
مسیر کوتاه یک خطای کوچک تا شکستی بزرگ
ما دوست داریم برای هر شکست بزرگ، علت بزرگی پیدا کنیم.
اگر پروژهای یک سال عقب افتاده، انتظار داریم اشتباهی عظیم رخ داده باشد. اگر یک شرکت فروپاشیده، دنبال تصمیمی احمقانه یا مدیری فاسد میگردیم. اگر رابطهای از بین رفته، یک خیانت روشن میخواهیم.
اما سیستمهای پیچیده اغلب اینگونه شکست نمیخورند.
یک ابهام کوچک در مالکیت کار.
یک وابستگی که ثبت نشده.
یک هشدار که چون قبلاً چند بار بیاهمیت بوده، این بار هم نادیده گرفته شده.
یک تأخیر دو روزه که زود اعلام نشده.
یک معیار پذیرش که دو تیم متفاوت فهمیدهاند.
یک استثنای موقت که بیصدا به رویهٔ دائمی تبدیل شده است.
هیچکدام بهتنهایی فاجعه نیست. مسئله این است که این گسستهای کوچک چگونه به هم متصل میشوند، چگونه از دید پنهان میمانند و چگونه فرصت اصلاح بعدی را از بین میبرند.
در سیستمهای قابل اتکا، هدف فقط کاهش احتمال خطا نیست. هدف این است که خطا زود قابل مشاهده شود، دامنهاش محدود بماند و سیستم توان بازیابی داشته باشد.
به همین دلیل، پژوهشگران سازمانهای با قابلیت اطمینان بالا از چند گرایش مهم سخن میگویند:
- حساسیت به نشانههای شکست، حتی وقتی هنوز حادثهای رخ نداده است؛
- مقاومت در برابر توضیحهای بیش از حد ساده؛
- توجه نزدیک به عملیات واقعی، نه فقط گزارشهای رسمی؛
- ساختن توان بازیابی برای رخدادهای پیشبینینشده؛
- سپردن تصمیم در لحظهٔ بحران به کسی که واقعاً تخصص مرتبط دارد، نه صرفاً بالاترین عنوان سازمانی.
اینها نسخهای برای کپیکردن نیستند. ناو هواپیمابر، بیمارستان و استارتاپ یک سیستم نیستند و انتقال مستقیم رویهها میتواند نمایشی و حتی مضر باشد. اما یک اصل مشترک ارزشمند باقی میماند:
قابلیتاتکا یک ویژگی تزئینی نیست که بعد از طراحی سیستم به آن اضافه کنیم؛ محصولِ نحوهٔ دیدن خطا، گردش اطلاعات، توزیع اختیار و بازیابی از گسست است.
اعتماد را نمیشود دستور داد
تصور کنید مدیر جدیدی در نخستین جلسه میگوید:
«باید به هم اعتماد کنیم.»
این جمله شاید نیت خوبی داشته باشد، اما اعتماد با دستور ساخته نمیشود.
در یکی از مدلهای اثرگذار اعتماد سازمانی، راجر مایر، جیمز دیویس و دیوید شورمن اعتماد را آمادگی برای آسیبپذیرشدن در برابر عمل دیگری میدانند؛ آن هم در شرایطی که نمیتوانیم طرف مقابل را کاملاً کنترل کنیم. در این مدل، ارزیابی ما از سه چیز مهم است:
- آیا طرف مقابل توانایی مرتبط دارد؟
- آیا نسبت به ما خیرخواه است یا فقط منافع خودش را میبیند؟
- آیا اصول و رفتار او برای ما پذیرفتنی و نسبتاً منسجم است؟
خودِ فرد اعتمادکننده و میزان ریسک موقعیت هم اهمیت دارد.
این مدل یک هشدار مهم برای دورهٔ ما دارد: اعتماد را نباید به یک علت فروکاست.
ممکن است من شما را انسانی شریف بدانم، اما برای جراحی قلب به شما اعتماد نکنم؛ چون توانایی مرتبط ندارید.
ممکن است توانایی شما را قبول داشته باشم، اما فکر کنم منافع من برایتان اهمیتی ندارد.
ممکن است توانمند و خیرخواه باشید، اما چون چند بار اطلاعات مهم را دیر گفتهاید، نتوانم برنامهام را بر گزارش شما بنا کنم.
پس وقتی میگوییم «اعتماد پیامد است»، منظورمان این نیست که یک رفتار واحد، بهطور مکانیکی اعتماد تولید میکند. منظور این است که نمیتوان اعتماد را مستقیماً مطالبه کرد. میتوان شرایطی ساخت که پذیرش آسیبپذیری برای دیگری عقلانیتر شود.
قابلیتاتکای تجربهشده یکی از این شرایط است.
و نکتهای ظریفتر: حتی اگر امروز رفتار خود را اصلاح کنیم، اعتماد دیگران ممکن است فوراً برنگردد.
ما میتوانیم گسست را همین امروز ببینیم، مسئولیت اثرش را بپذیریم، جبران کنیم و تعهد معتبرتری بسازیم. اما دیگری حق دارد برای تغییر قضاوتش به تجربهٔ تکرارشونده نیاز داشته باشد.
اصلاح رفتار در اختیار ماست؛ زمانبندی اعتماد دیگران نه.
آخرین باری که نتوانستند روی تو حساب کنند
پیش از ادامه، یک موقعیت واقعی را به یاد بیاورید.
نه بزرگترین شکست زندگیتان را. نه موقعیتی که هنوز گفتنش برایتان دردناک است. یک نمونهٔ حرفهای و قابل بررسی انتخاب کنید:
- کاری را دیر تحویل دادید؛
- جلسهای را فراموش کردید؛
- کیفیت خروجی با انتظار طرف مقابل فرق داشت؛
- نشانهٔ مشکل را دیدید، اما دیر گفتید؛
- «بله» گفتید، درحالیکه ظرفیت واقعی نداشتید.
حالا بدون دفاع و بدون سرزنش، ماجرا را از ابتدا مرور کنید.
دقیقاً چه چیزی گفته شده بود؟ نه چیزی که امروز فکر میکنید منظورتان بوده؛ همان چیزی که واقعاً میان شما و طرف مقابل ردوبدل شد. آیا هر دو از «انجامشدن» یک چیز میفهمیدید؟
بعد به نخستین لحظهای برگردید که فهمیدید شاید کار مطابق انتظار پیش نرود. این لحظه معمولاً بسیار زودتر از زمانی است که شکست را اعلام میکنیم. شما چه دیدید؟ چه زمانی آن را گفتید؟ و اگر گفتنش را عقب انداختید، از چه چیزی میترسیدید؟
در پایان، مرز اختیار را روشن کنید. کدام بخش واقعاً در اختیار شما بود و کدام بخش نبود؟ چه تغییری در نحوهٔ توافق، پیگیری یا اطلاعرسانی میتوانست گسست را زودتر آشکار کند یا دستکم اثرش را محدود نگه دارد؟
به زبان پاسخهایتان دقت کنید.
اگر فقط میگویید «من بیمسئولیتم»، هنوز چیزی توضیح ندادهاید.
اگر فقط میگویید «تقصیر شرایط بود»، باز هم چیزی توضیح ندادهاید.
تبیین دقیق باید هم عاملیت شما را ببیند و هم ساختاری را که رفتار در آن رخ داده است.
مسئولیتپذیری با خودسرزنشی فرق دارد.
خودسرزنشی میگوید: «من مشکل هستم.»
فرافکنی میگوید: «من هیچ نقشی نداشتم.»
بررسی مسئولانه میپرسد: «واقعیت چه بود، نقش من چه بود، اثر چه بود و چه چیزی باید تغییر کند؟»
یک تعهد باز را زیر نور بگذار
یکی از تعهدهای باز فعلیتان را انتخاب کنید؛ تعهدی که اگر محقق نشود، تصمیم یا کار فرد دیگری را مختل میکند.
آن را با زبان روشن بازنویسی کنید:
من پذیرفتهام که … را برای … تا … انجام دهم.
این کار زمانی انجامشده محسوب میشود که …
برای انجام آن به … وابستهام و محدودیت واقعی من … است.
اگر … رخ دهد، میفهمم تعهد در خطر است. در آن صورت، تا … موضوع را با … در میان میگذارم و بهجای پنهانکردن مسئله، این گزینهها را روی میز میگذارم: …
حالا یک پرسش نهایی:
اگر طرف مقابل همین پاسخها را ببیند، آیا فهم او از تعهد با فهم شما یکی است؟
اگر پاسخ روشن نیست، هنوز یک مشکل اخلاقی نداریم. یک کار ناتمام در طراحی هماهنگی داریم.
حالا مسئله را میبینیم
هنوز تمامیت را تعریف نکردهایم. این تعمدی است.
فعلاً فقط زمین مسئله را روشن کردهایم.
میدانیم که نیت خوب کافی نیست.
میدانیم که مهارت بالا نیز بهتنهایی کافی نیست.
میدانیم که قابلاتکا بودن به معنای بیخطابودن نیست.
میدانیم که کیفیت پذیرش یک تعهد، بهاندازهٔ لحظهٔ تحویل اهمیت دارد.
میدانیم که اعلام زودهنگام گسست، جای انجام تعهد را نمیگیرد؛ اما میتواند امکان هماهنگی و بازیابی را حفظ کند.
میدانیم که یک تیم میتواند از افراد توانمند ساخته شود و همچنان خروجی غیرقابل اتکا تولید کند، چون قابلیتاتکا در روابط میان اجزا هم ساخته یا شکسته میشود.
و میدانیم که اعتماد فرمانپذیر نیست. دیگران وقتی به ما تکیه میکنند که در گذر زمان، شواهد کافی برای پذیرش این ریسک داشته باشند.
اکنون میتوانیم به پرسشی دقیقتر نزدیک شویم:
چه وضعیت یا کیفیتی باید در یک انسان یا سیستم حفظ شود تا گفته، تعهد، عمل و واقعیت از هم جدا نشوند؟ و اگر جدا شدند، چه چیزی امکان بازگرداندن کارکرد را فراهم میکند؟
نامی که این دوره برای بررسی آن کیفیت انتخاب کرده، «تمامیت» است.
اما پیش از آنکه در جلسهٔ بعد آن را تعریف کنیم، این جمله را با خود نگه دارید:
مسئله این نیست که آیا من در ذهن خودم آدم خوبی هستم. مسئله این است که دیگران، سیستم و آینده چه هزینهای بابت فاصلهٔ میان گفتهٔ من و واقعیت میپردازند.
تمامیت از همین فاصله آغاز میشود.
منابع
-
U.S. Securities and Exchange Commission. (2013). SEC Charges Knight Capital With Violations of Market Access Rule.
منبع اعداد و جزئیات پرونده: بیش از چهار میلیون سفارش، ۳۹۷ میلیون سهم، زیان بیش از ۴۶۰ میلیون دلار، استقرار ناقص روی یکی از هشت سرور و ۹۷ ایمیل خودکار.
-
Columbia Accident Investigation Board. (2003). Columbia Accident Investigation Board Report, Volume I.
منبع تفکیک علت فیزیکی از علل سازمانی و نقش رویههای مدیریتی و فرهنگ برنامهٔ شاتل.
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20030066167.pdf
-
Mayer, R. C., Davis, J. H., & Schoorman, F. D. (1995). An Integrative Model of Organizational Trust. Academy of Management Review, 20(3), 709–734.
-
Mischel, W., & Shoda, Y. (1995). A Cognitive-Affective System Theory of Personality: Reconceptualizing Situations, Dispositions, Dynamics, and Invariance in Personality Structure. Psychological Review, 102(2), 246–268.
-
Weick, K. E., Sutcliffe, K. M., & Obstfeld, D. (1999). Organizing for High Reliability: Processes of Collective Mindfulness. Research in Organizational Behavior, 21, 81–123.
-
Christianson, M. K., Sutcliffe, K. M., Miller, M. A., & Iwashyna, T. J. (2011). Becoming a High Reliability Organization. Critical Care, 15, 314.
بخشهای دوره
بخشی برای این دوره یافت نشد.