در این اپیزود از «کدشناسی»، سراغ یکی از مهمترین و در عین حال نادیده‌گرفته‌شده‌ترین موضوعات در مهندسی نرم‌افزار می‌رویم: اشتباهات.
اما نه صرفاً خودِ اشتباه، بلکه نحوه‌ی برخورد ما با آن. چطور یک خطای فاجعه‌بار می‌تواند به فرصتی برای رشد تیم و ارتقاء پروژه تبدیل شود؟ چرا بعضی شرکت‌ها به‌جای مقصر پیدا کردن، تمرکزشان را روی یاد گرفتن از اشتباهات می‌گذارند؟ و چطور می‌شود از فرهنگی به‌نام «Postmortem» یا همان گزارش پس‌از‌حادثه، در تیم‌های نرم‌افزاری الهام گرفت؟
الهام‌بخش این اپیزود، دوچرخه‌های سفید رنگی هستند که در گوشه‌وکنار شهرهای بزرگ دیده می‌شوند ( Ghost Bikes) نمادهایی از یک اشتباه مرگبار، که حالا به فرصتی برای آگاهی و یادآوری تبدیل شده‌اند.
اگر به دنبال ساختن تیم‌هایی هستید که به‌جای ترس، با شجاعت از اشتباهاتشان یاد می‌گیرند، این اپیزود را از دست ندهید.
منابع این اپیزود :
Black Box Thinking: The Surprising Truth About Success - by Matthew Syed
The Site Reliability Workbook: Practical Ways to Implement SRE - by Niall Richard Murphy (Author), Betsy Beyer (Author), Chris Jones (Author), Jennifer Petoff (Author)
متن اپیزود
تو خیلی از شهرهای دنیا، دوچرخه‌های سفیدرنگ پارک‌شده‌ای تو بخش‌هایی از شهر دیده می‌شن. به این دوچرخه‌ها می‌گن Ghost Bike. این دوچرخه‌ها یادبودی هستن برای افرادی که متأسفانه دقیقاً تو همون منطقه در یک تصادف، جان‌شون رو از دست داده‌اند.
اولین بار، سال ۲۰۰۳، یک هنرمند آمریکایی که شاهد چنین صحنه‌ای بود، دوچرخه فرد آسیب‌دیده رو نماداً رنگ سفید زد و کنار پیاده‌رو همون مکان گذاشت و روی اون یک تابلو نصب کرد و توضیح داد که چه اتفاقی افتاده. این حرکت خیلی زود به یک جنبش جهانی تبدیل شد؛ هم برای یادبود افراد فوت‌شده، و مهم‌تر از اون، برای هشدار به دیگر دوچرخه‌سوارها که این منطقه خطرناکه و عملاً حرکتیه برای جلوگیری از سانحه‌های مشابه.
این روش تو خیلی حوزه‌های مختلف برای پیشگیری از حوادث استفاده می‌شه! مثلاً تو هواپیماها، اگر سانحه‌ای رخ بده، از بلک باکس برای بررسی علت سقوط و آخرین وضعیت استفاده می‌کنن تا بفهمن چه اتفاقی افتاده و چرا.
اما این روزها، با بزرگ‌تر و پیچیده‌تر شدن پروژه‌های نرم‌افزاری، احتمال ایجاد مشکلات و اشتباهات در فرآیند توسعه هم خیلی بیشتر شده. گرچه ابزارهای زیادی برای جلوگیری و گزارش خطا ساخته شدن و به کنترل پروژه‌ها کمک می‌کنن، اما حتی تو بزرگ‌ترین شرکت‌های دنیا، مثل گوگل و فیسبوک، باز مشکلاتی دیدیم که ضررهای زیادی به سرویس‌ها وارد کرد.
البته این فقط مربوط به شرکت‌های بزرگ نیست؛ در خیلی از پروژه‌ها هم شاهد چنین اشتباهاتی هستیم! اما تو مواجهه با این موقعیت‌ها باید چه کرد؟
تو این اپیزود درباره رویکردی به نام Postmortem Culture یا فرهنگ «بعد از حادثه» در پروژه‌های نرم‌افزاری بحث می‌کنم! طبق روال هر اپیزود، چند سؤال رو مطرح می‌کنم و در طول اپیزود درباره‌شون صحبت می‌کنم:
چرا اشتباهات رخ می‌دن؟ و چی باعث می‌شه مشکلات بزرگ‌تر ایجاد بشن؟
چرا افراد در مواجهه با مشکلات و باگ‌ها سعی می‌کنن اشتباهات‌شون رو پنهان کنند؟
رفتار و فرهنگ شرکت‌ها در مواجهه با چنین مشکلاتی چطوری باید باشه؟
و در نهایت، چطور حل این مسئله می‌تونه به رشد و بهتر شدن پروژه یا محصول تبدیل بشه؟
معرفی اپیزود
سلام! من محمدم و این اپیزود هفت از پادکست کُدشناسیه. در هر اپیزود از این پادکست، معمولاً یک چالش، یک موقعیت یا یک جستار فکری از دنیای مهندسی نرم‌افزار مطرح می‌کنم و کمی روش مکث می‌کنیم. موضوع این اپیزود، رویکرد فرهنگ یادگیری از اشتباهات در پروژه‌های نرم‌افزاریه. سعی می‌کنم سؤال‌های مطرح‌شده در بخش اول رو با کمک منابع و تجربه‌های شخصی بررسی کنم و اگر شد، کمی روشون عمیق شیم.
بخش دوم – سرچشمه اشتباهات
اشتباهات و شکست‌ها چیزهایی هستن که تقریباً هر کسی در طول عمرش، در شرایط مختلف شخصی یا حرفه‌ای، بارها تجربه‌شون کرده. این اشتباهات می‌تونن تو سن‌های پایین، مثلاً یه امتحان یا یک بازی، یا موقعیت‌های ساده دیگر اتفاق بیفتن. اما با بالارفتن سن و مسئولیت‌ها، این اشتباهات می‌تونن در جنبه‌های جدی‌تری مثل مصاحبه‌های کاری، انجام تسک‌های پیچیده یا راه‌اندازی یک کسب‌وکار رخ بدن.
اما در برخی موارد، یک اشتباه می‌تونه تبعات خیلی بزرگی داشته باشه! مثلاً از کار افتادن یک سرویس؛ مثل اتفاقی که در سال ۲۰۲۱ برای شرکت متا افتاد: تمام سرویس‌های این شرکت مثل فیسبوک، واتساپ و اینستاگرام تقریباً شش ساعت از کار افتادن و خسارت زیادی به‌شون وارد شد. یا بدتر از اون، در حوزه‌هایی مثل پزشکی یا هواپیمایی، که یک اشتباه می‌تونه متأسفانه منجر به مرگ چند نفر بشه.
پس سؤال اینه: چرا این اشتباهات رخ می‌دن؟
این بحث در خیلی حوزه‌ها صدق می‌کنه، ولی من می‌خوام تخصصی‌تر درباره اشتباهات تو پروژه‌های نرم‌افزاری صحبت کنم. اگر بخوایم چند عامل اصلی به وجود اومدن اشتباهات رو بررسی کنیم، می‌تونیم به موارد زیر اشاره کنیم:
میزان پیچیدگی سیستم یا تغییرات گسترده در کدبیس یا زیرساخت
فشار کاری و عوامل محیطی که افراد رو مجبور می‌کنه در شرایط مختلف تصمیم‌های سریع بگیرن
تعلل در تصمیم‌گیری یا اجرای اقدامات لازم
این‌ها همه می‌تونن نقش مهمی در رخ‌دادن اشتباهات ایفا کنن!
یکی از راهکارهایی که در چند سال گذشته برای کاهش این اشتباهات مؤثر بوده، حذف یا کم‌رنگ کردن فعالیت‌های تکراری و دستی بوده، مثل فرآیندهای دیپلوی، سیستم‌های مانیتورینگ و اسکالیگ خودکار سرورها.
این کمک کرده که در خیلی پروژه‌ها، خطاها کمتری اتفاق بیفته، اما تعداد اشتباهات تأثیرگذار هنوز به صفر نرسیده.
به نظرم لازمه بیشتر درباره ماهیت این خطاها صحبت کنیم، چون عوامل دیگری هم وجود دارن که تأثیر زیادی دارند و الگوهای مشابهی نشان می‌دن!
یکی از مهمترین الگوها اینه که اغلب مشکلات، نتیجه ترکیبی از عوامل هستن که در قالب یک باگ جدید ظاهر می‌شن و در واقع تکرار خطاهای قبلی هستن! در این موارد، باگ‌های قبلی بدون بررسی دقیق و بدون تهیه گزارش مکتوب، فیکس شدن و حالا دوباره ظاهر شدن.
جالبه بدونید این موضوع فقط مربوط به نرم‌افزاره و تو حوزه‌های حساس‌تری مثل پزشکی هم رخ می‌ده!
اما سؤال اینجاست... چرا این اشتباهات و باگ‌ها در گذشته نادیده گرفته شدند و دوباره ظاهر شدن؟ این موضوع رو در بخش بعد بررسی می‌کنیم.
بخش سوم – چرا اشتباهات پنهان می‌شن؟
معمولاً تصمیم‌ها در شرایط خاص گرفته می‌شن و می‌تونن تأثیرهای زیادی روی فرد و محیط بذارن. یکی از این شرایط، موقعیتی هست که افراد احساس می‌کنن یک اشتباه شخصیت یا اعتبارشون رو تهدید می‌کنه.
این احساس ممکنه در بازی‌های ساده یا فضای کار شکل بگیره. طبیعتاً هر چقدر شرایط سخت‌تر باشه، احساس شکست هم بیشتر می‌شه!
در چنین شرایطی، اولین چیزی که افراد معمولاً ناخودآگاه بهش رو میارن اینه که دنبال مقصر بگردن یا خودشون رو از مشکل دور نگه دارن. نتیجه‌اش می‌شه محیط کاری با اعتماد پایین و افزایش پنهان‌کاری اشتباهات.
اما مشکل اصلی اینه که اگر مسئله گزارش نشه، داده‌های مهمی درباره چگونگی ایجاد باگ و تأثیرش روی سیستم از دست می‌ره، و بعید نیست دوباره اتفاق بیفته.
در این شرایط، مهمترین عامل برای کاهش این پنهان‌کاری و تکرار اشتباهات، فضاییه که در اون کار می‌کنیم؛ فرهنگ سازمانی و نگرش افراد نسبت به اشتباهات نقش کلیدی داره.
پس سؤال اینه: شرکت‌ها باید چه رویکردی در این شرایط داشته باشن؟ در بخش بعد به این موضوع می‌پردازیم.
بخش چهارم – فرهنگ Postmortem
اشتباهاتی که توسط اعضای تیم در پروژه نرم‌افزاری انجام می‌شن، مخصوصاً در محیط‌های رقابتی مثل شرکت‌های فناوری، می‌تونن باعث واکنش‌های مختلفی بشن که روی تیم و پروژه اثر می‌ذارن. اینجا، نقش فرهنگ سازمانی و نوع مواجهه با این شرایط حیاتی می‌شه!
یکی از شرکت‌هایی که خیلی روی این موضوع کار کرده گوگله! چند سال پیش اونها شروع کردن به پیاده‌سازی رویکردی به نام Postmortem Culture یا فرهنگ «بعد از حادثه» در سیستم‌ها! این مفهوم قبل از گوگل در زمینه‌هایی مثل هواپیمایی استفاده می‌شد، اما گوگل این رو به عنوان بخشی از فرهنگ سازمانی خودش آورد، با تأکید بر این نکته: بدون سرزنش یا مقصر کردن افراد.
تمام تلاش‌شون این بود که تیم‌ها بتونن بدون قضاوت، تمام اطلاعات مربوط به مشکل رو با یک گزارش کامل منتشر کنند؛ یک داکیومنت شفاف برای همه جزئیات اتفاق. (با تأکید) ترکیز باید روی این باشه که «چه چیزی اشتباه شد؟» نه «چه کسی اشتباه کرد!»
این گزارش باید یک «اونر» داشته باشه — شخص یا تیمی که مسئول پیگیری مورد و تکمیل گزارش هست. بنابراین، تمرکز به جای پنهان‌کاری، به تهیه گزارش دقیق و حل مسئله منتقل می‌شه.
گزارش باید ظرف یک هفته پس از بسته شدن مشکل نوشته بشه تا جزئیات از حافظه خارج نشه؛ و قبل از تکرار، همه از اتفاق مطلع بشن!
اشتراک گزارش‌ها بین تیم‌ها نه تنها دانش‌رسانی می‌کنه، بلکه گوشزد می‌کنه آیا موارد مشابه قبلاً رخ دادن یا نه؟ اگر تکراری باشه، ممکنه مشکل، نتیجه طراحی مشکل‌دار سیستم باشه و نیاز به بازنگری طراحی داریم.
گوگل نمونه‌هایی از این فرم‌ها رو به‌صورت عمومی و بدون اشاره به تیم یا فرد خاص منتشر کرده. مثلاً در دسامبر ۲۰۲۰، وقتی سرویس‌های اصلی گوگل مثل Gmail و YouTube حدود ۴۵ دقیقه از دسترس خارج شدن، نقصی در فرآیند مهاجرت سیستم باعث شد که ظرفیت استوریج سیستم احراز هویت به‌اشتباه کاهش یابه و تقریباً همه درخواست‌های لاگین خطا می‌داد. گزارش کامل این مشکل با تمامی جزئیات و اقدامات اصلاحی منتشر شد.
شرکت‌های مختلف این رویکرد رو دنبال می‌کنن، اما به‌نظر من، گوگل در این حوزه یک‌لِیگ بالا کار می‌کنه! سعی می‌کنم لینک نمونه‌های گزارش‌ها رو براتون در وب‌سایت یا کانال تلگرام قرار بدم تا جزئیات‌شون رو ببینید.
بخش پنجم – چطور این فرهنگ باعث رشد پروژه می‌شه؟
ولی چطور سرمایه‌گذاری در این فرهنگ می‌تونه باعث رشد یا بهتر شدن پروژه یا محصول بشه؟ (مکث کوتاه)
اصلی‌ترین چیز برای من، حس اعتمادیه که در تیم‌ها شکل می‌گیره؛ طوری که اعضا بدون ترس از قضاوت شدن در شرایط بحرانی، همه تمرکزشون رو بذارن برای حل مشکل و سپس اشتراک دانش به‌دست‌اومده برای جلوگیری از تکرار.
این یکی از (با تأکید) مهمترین مواردیه که منجر به بهتر شدن محصول در بلندمدت می‌شه!
باید اینو در نظر داشته باشیم: اگر بدترین اتفاق هم اتفاق بیفته، ولی تبدیل بشه به دانش تیم، خیلی آسیب کمتری به محصول وارد می‌شه تا این‌که چندبار شاهد اتفاق‌های مشابه باشیم.
بخش پایانی – جمع‌بندی
خب، بیایید یک جمع‌بندی داشته باشیم:
این اپیزود با مفهوم دوچرخه‌های سفیدرنگ شروع شد؛ نمادی از یادگیری از حوادث ناگوار. (مکث کوتاه)
بعد، ریشه‌های اشتباهات بررسی شد و پرسیدیم چرا باگ‌ها پنهان می‌شن؟ (مکث کوتاه)
سپس بررسی کردیم چطوری شرکت‌هایی مثل گوگل بدون مقصر کردن افراد، با مشکلات برخورد می‌کنن.
و نهایتاً دیدیم چطور فرهنگ سازمانی و فضای باز در مواجهه با اشتباهات، می‌تونه باعث رشد و پیشرفت یک پروژه بشه.
اگر این اپیزود رو دوست داشتید، لطفاً به اشتراک‌گذاریش کمک کنید؛ و اگر تجربه، نظر یا پیشنهادی دارید خوشحال می‌شم از طریق شبکه‌های اجتماعی یا پادگیرها با من در تماس باشید!