تطبیق (Adapt) و کالبدشکافیِ شکست‌ها

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


اما چگونه می‌توانیم مشکلات را به جای پنهان کردن زیر فرش، از ریشه بخشکانیم؟ پاسخ، در یکی از درخشان‌ترین ابزارهای مدیریتیِ تاریخ نهفته است: تکنیک پنج چرا (The Five Whys).


جادوی «پنج چرا»؛ یادگاری از تویوتا

تکنیک «پنج چرا» توسط تایچی اونو (Taiichi Ohno)، معمارِ سیستم تولید تویوتا، خلق شد. ایده اصلی به طرز فریبنده‌ای ساده است: پشتِ هر مشکلِ ظاهراً «فنی»، یک مشکلِ عمیقِ «انسانی و فرآیندی» پنهان شده است. برای رسیدن به این ریشه، شما نباید به پاسخ اول قانع شوید، بلکه باید پنج بار بپرسید «چرا؟».


«اکثر اشتباهاتی که ما آن‌ها را خطای انسانی، تنبلی یا بی‌دقتی می‌نامیم، در واقع نشانه‌هایی از یک سیستمِ آموزشی یا مدیریتیِ معیوب هستند.»

فرض کنید در یک کمپین مهم، ناگهان سرورِ اصلی سایت از کار می‌افتد. واکنشِ سنتی این است: سرور را ری‌استارت کنید و برنامه‌نویس را توبیخ کنید! اما یک سازمانِ ناب این‌گونه عمل می‌کند:


۱. چرا سرور از کار افتاد؟ (چون یک کدِ جدید و پر از باگ روی سایت آپلود شد.)
۲. چرا کدِ پر از باگ آپلود شد؟ (چون برنامه‌نویس، کد را قبل از آپلود در محیطِ تستی بررسی نکرده بود.)
۳. چرا کد بررسی نشده بود؟ (چون نرم‌افزارِ تستِ ما بسیار پیچیده و زمان‌بر است.)
۴. چرا نرم‌افزار تست پیچیده است؟ (چون هیچ‌کس به برنامه‌نویسِ جدید آموزش نداده که چگونه به راحتی از آن استفاده کند.)
۵. چرا آموزش داده نشده است؟ (چون مدیرِ تیم، زمانِ کافی برای مستندسازی و آموزشِ نیروهای جدید اختصاص نداده و فقط روی سرعتِ تحویل پروژه فشار آورده است!)


شگفت‌انگیز است! ما از یک مشکل فنی (قطعی سرور) به یک مشکل ریشه‌ایِ مدیریتی (فقدان سیستم آموزش و آنبوردینگ) رسیدیم. اگر فقط سرور را تعمیر می‌کردید، این مشکل هفته بعد توسط یک برنامه‌نویس دیگر تکرار می‌شد.


━━━━━━━━━━━━━━━━━━━━━━━━

📌 معماری پایدار: وقتی «چرا»های شما به زیرساخت ختم می‌شود

در دنیای پرشتاب دیجیتال، زمانی که یک اپلیکیشن موبایل زیر بار ترافیکِ کاربران کِرَش (کرش یعنی خطا در اپلیکیشن موبایل) می‌کند، یا سایت شما جایگاه خود را در صفحه اول گوگل از دست می‌دهد، اولین «چرا» همیشه به خطای سرور یا آپدیت الگوریتم ختم می‌شود. اما وقتی تا چرای پنجم پیش بروید، معمولاً به یک حقیقتِ تلخ می‌رسید: عدمِ استفاده از یک تیم فنیِ حرفه‌ای و فقدانِ معماریِ استاندارد. طراحی وب‌سایت‌های مقیاس‌پذیر، توسعه اپلیکیشن‌های نیتیو و قدرتمند، و اجرای استراتژی‌های سئویی که با هر آپدیت گوگل فرو نریزند، نیازمندِ زیرساختی است که از روز اول بر پایه اصول مهندسیِ ناب بنا شده باشد. اگر کسب‌وکار شما دائماً درگیرِ باگ‌های تکراری، افت سئو یا ضعف در شبکه‌های اجتماعی است، تیم مهندسی استینومنت آماده است تا معماری دیجیتال شما را از ریشه بازطراحی کند. برای دریافت مشاوره رایگان در زمینه توسعه پلتفرم‌ها و سئو، می‌توانید همین حالا با بخش پشتیبانی مهندسی ما (به مدیریت حامد اصغری) در ارتباط باشید تا مشکلاتِ فنیِ شما را برای همیشه متوقف کنیم.


━━━━━━━━━━━━━━━━━━━━━━━━

سرمایه‌گذاریِ متناسب (Proportional Investment)

یکی از اصولِ حیاتی در قانون پنج چرا، «سرمایه‌گذاریِ متناسب» است. این یعنی شما باید به اندازه بُزرگیِ مشکل برای حلِ آن زمان و پول صرف کنید. اگر مشکل، یک باگِ ساده است که فقط یک کاربر را تحت تاثیر قرار داده، رفعِ ریشه‌ای آن شاید یک ساعت زمان ببرد. اما اگر مشکل، هک شدنِ دیتابیسِ کل شرکت است، شاید نیاز باشد تمام تیم به مدت یک ماه کارها را متوقف کنند تا زیرساخت‌های امنیتی بازنویسی شوند. پنج چرا، به عنوانِ ترمزِ اتوماتیک عمل می‌کند: مشکلاتِ بزرگتر، ترمزِ محکم‌تری می‌کشند.


تله‌ی مرگبار: تبدیل «پنج چرا» به «پنج مقصر»

بزرگترین خطری که این سیستم را تهدید می‌کند، زمانی است که فرهنگ سازمانیِ شما مبتنی بر ترس باشد. در چنین سازمان‌هایی، وقتی مدیر می‌پرسد «چرا این اتفاق افتاد؟»، تیم به جای ریشه‌یابی، شروع به انگشت‌نما کردنِ یکدیگر می‌کنند. اریک ریس این حالت را «پنج مقصر» (The Five Blames) می‌نامد. برای اجرای موفقِ این تکنیک، مدیریتِ ارشد باید تضمین کند که هدف از این جلسات، پیدا کردنِ نقص در سیستم است، نه اخراج کردنِ افراد.


━━━━━━━━━━━━━━━━━━━━━━━━

💡 یادداشت حامد اصغری (CEO of Stinoment)

به عنوان یک مدیرعامل در عرصه بین‌المللی، بارها شاهدِ جلسات بحرانی (War Rooms) در شرکت‌های مختلف بوده‌ام. زمانی که بحرانی رخ می‌دهد، غریزه اولیه مدیرانِ کلاسیک، پیدا کردنِ یک مقصر برای اعدام در میدان شهر است! آن‌ها تصور می‌کنند با اخراجِ برنامه‌نویس یا مدیر کمپین، مشکل حل شده است. اما در واقع، آن‌ها فقط نشانه بیماری را با مسکن پوشانده‌اند.


در غول‌های تکنولوژی مانند گوگل یا نتفلیکس، مفهومی وجود دارد به نام «کالبدشکافیِ بدون مقصر» (Blameless Post-mortem). در استینومنت نیز ما دقیقاً از همین الگو پیروی می‌کنیم. وقتی یک باگِ جدی در یکی از پلتفرم‌های کلاینت‌هایمان رخ می‌دهد، قانون اول من در جلسه این است: «ما اینجا جمع نشده‌ایم که ببینیم چه کسی اشتباه کرده؛ ما اینجاییم تا بفهمیم سیستمِ ما چگونه به یک انسان اجازه داده تا چنین اشتباهی را مرتکب شود.»


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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *