ویرگول
ورودثبت نام
Ali Fazeli
Ali Fazeliمهندس نرم افزار
Ali Fazeli
Ali Fazeli
خواندن ۵ دقیقه·۹ ماه پیش

بازنگری‌های پس از حادثه؛ یافتن تعادل بین سرزنش و عدم مسئولیت

Post Mortem
Post Mortem


در سال‌های اخیر، مفهوم «بازنگری بدون سرزنش (Blameless Post Mortem)» در صنعت نرم‌افزار به یک استاندارد تبدیل شده است. این فلسفه بر این مبنا استوار است که مهندسان بتوانند بدون نگرانی از مجازات، به شرح دقیق دلایل یک خطا یا حادثه بپردازند تا از تکرار آن جلوگیری شود. اما آیا این روش همیشه بهترین راه است؟ بیایید نگاهی عمیق‌تر به مزایا و محدودیت‌های این نگاه بیندازیم.

تاریخچه بازنگری بدون سرزنش

بحث درباره بازنگری‌های بدون سرزنش ابتدا در حوزه‌هایی مانند هوانوردی و مراقبت‌های بهداشتی شکل گرفت. خصوصیات این حوزه‌ها که چنین رویکردی را ضروری کرد شامل موارد زیر است:

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

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

بازنگری بدون سرزنش در صنعت نرم‌افزار

این مدل در صنعت نرم‌افزار با ویژگی‌های متفاوتی اجرا می‌شود که شامل موارد زیر است:

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

مقایسه نرم‌افزار با هوانوردی و بهداشت

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

  • فرصت‌های یادگیری از بین می‌رود زیرا به افراد گفته نمی‌شود دقیقاً چه کسی مسئول بوده و چه رفتاری باید تغییر کند.
  • با بی‌مسئولیتی، کیفیت کار کاهش می‌یابد و به جای بهبود، وضع موجود تثبیت می‌شود.
  • احساس ناعدالتی در افراد و تیم ها که سطح متفاوتی از استاندارد را ارائه می‌کنند بوجود می‌آید.

در مجموع، معمولاً شدت میانگین حوادث نرم‌افزاری آنقدر پایین است که عدم تعیین مسئولیت عواقب منفی بیشتری دارد.

راهکار میانه: بازنگری‌های همراه با مسئولیت

بهترین روش، راه میانه‌ای است که هم یادگیری و هم مسئولیت را با هم داشته باشد. ویژگی‌های این بازنگری‌ها عبارتند از:

یک نفر یا یک تیم "مسئول" است

هر مشکل یا خطا باید به یک فرد یا تیم مشخص نسبت داده شود. این مسئولیت می‌تواند مربوط به:

  • شغل فرد یا تیمی که به درستی وظایفشان را انجام نداده‌اند.
  • نبود وضوح در ساختار تقسیم مسئولیت‌ها و وظایف که باید توسط مدیریت اصلاح شود.

اگر مسئولیت میان چندین واحد تقسیم شود، معنایش این است که مسئولیت مشخصی وجود ندارد و مسئله حل نمی‌شود. حتی در مواردی همچون:

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

مسئولیت‌پذیری عادلانه است

فرهنگ‌های بدون سرزنش اغلب اشتباه برداشت می‌شوند که یعنی هیچ جریمه‌ای وجود ندارد. اما در واقع مسئولیت باید به شکلی منصفانه اعمال شود:

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

ایجاد انگیزه‌های درست

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

«با صداقت و سلامت عمل کن یا عواقبش را بپذیر.»

بنابراین در بازنگری‌ها باید به تیم گفته شود:

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

پایان

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

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

مسئولیتارزیابی عملکردتیم
۱
۰
Ali Fazeli
Ali Fazeli
مهندس نرم افزار
شاید از این پست‌ها خوشتان بیاید