۰
هنوز چیزی ذخیره نشده است.
در یکی از انبارهای آمازون، انگشت شست یک اپراتور آسیب دید. ماجرا در نگاه اول ساده بود: بی‌احتیاطی. گزارش نوشته می‌شود، توصیه‌ای درباره‌ی «رعایت نکات ایمنی» اضافه می‌شود، پرونده بسته می‌شود. در بیشتر شرکت‌ها همین‌جا تمام است.
آمازون اما ابزاری دارد به نام Correction of Errors؛ و قلبِ آن، پنج بار پرسیدنِ «چرا» است.
- چرا انگشتش آسیب دید؟ چون دستش لای تسمه‌نقاله گیر کرد.
- چرا دستش رفت سمت تسمه؟ چون داشت کیفش را که روی نقاله افتاده بود برمی‌داشت.
- چرا کیفش روی نقاله بود؟ چون آن را همان‌جا گذاشته بود.
- چرا آن را همان‌جا گذاشته بود؟ چون جای دیگری برای گذاشتن وسایل شخصی نداشت.
- چرا جای دیگری نبود؟ چون در طراحی آن ایستگاه کاری، هیچ میز یا قفسه‌ای برای وسایل شخصی پیش‌بینی نشده بود.
راه‌حل، بخشنامه‌ی ایمنی نبود. یک میز بود.
نکته‌ی نویسندگان کتاب Working Backwards همین‌جاست: تا وقتی شرطِ زیرینی که مسئله را ساخته تغییر نکند، مسئله برمی‌گردد. آموزش دادن به آدم‌ها برای زندگی کردن با یک سیستمِ بد، راه‌حل نیست؛ تعویقِ گران‌قیمت است.
من این را در مقیاس کوچک‌ترِ کار خودم زیاد دیده‌ام. سالی که پشتیبانی محصول شلوغ می‌شد، جواب اولم همیشه «سریع‌تر جواب بدهیم» بود. اما تیکت‌ها کم نمی‌شد. مسئله سرعتِ پاسخ نبود؛ مسئله یک مرحله‌ی گیج‌کننده در فرآیند نصب بود که هر روز چند نفر را به بن‌بست می‌رساند. تا آن مرحله عوض نشد، هیچ‌مقدار تلاشِ انسانی جای طراحیِ درست را نگرفت.
و بخش دوم ماجرا: آمازون فهمید حتی وقتی ریشه را پیدا می‌کنی، اگر حل کردنش را به‌عنوان کارِ اضافه‌ی کسی روی میزش بگذاری، هیچ‌وقت حل نمی‌شود. از همین‌جا مفهوم Single-Threaded Leader زاده شد: یک نفر، با یک مسئولیت، بدون وابستگی‌های فلج‌کننده. کسی که صبح که بیدار می‌شود فقط به یک چیز فکر می‌کند.
خلاصه‌ی امروزِ من از این فصل: ریشه را پیدا کن، شرط را عوض کن، و آدمِ تمام‌وقت برایش بگذار.
ترجمه‌ی نقل‌قول‌ها
«آمازون خیلی زود دریافت که اگر شرطِ بنیادینی که مسئله را ایجاد کرده تغییر نکند، باید انتظار داشته باشی همان مسئله دوباره تکرار شود.»
«بهترین راه برای شکست خوردن در ساختن یک نوآوری، این است که آن را به کارِ نیمه‌وقتِ کسی تبدیل کنی.»