«چرا؟» یک زنجیره نیست
از پنج چرا تا نقشه‌ی علت‌ها
دیروز برای ده دقیقه نمی‌شد در سایت آگهی ثبت کرد.
حالا سایت درست شده و سؤال بعدی می‌رسد:
چرا این اتفاق افتاد؟
یک روش مشهور برای دنبال‌کردن این سؤال پنج چرا است؛ روشی که با نظام تولید تویوتا و تاییچی اونو شناخته می‌شود. ایده ساده است: به اولین جواب اکتفا نکن. جواب هر «چرا؟» را موضوع «چرای» بعدی کن.
برای خرابی دیروز شاید چنین زنجیره‌ای بسازیم:
چرا ثبت آگهی از کار افتاد؟
چون دیسک سرور پر شد.چرا دیسک پر شد؟
چون فایل‌های لاگ همه‌ی فضا را گرفتند.چرا لاگ‌ها این‌قدر بزرگ شدند؟
چون چرخش خودکار لاگ خاموش بود.چرا خاموش بود؟
چون در آخرین استقرار تنظیمش از قلم افتاد.چرا از قلم افتاد؟
چون چک‌لیست استقرار چنین موردی ندارد.
پنج چرا. یک زنجیره‌ی تمیز. و در انتها چیزی که می‌شود اسمش را گذاشت «علت ریشه‌ای»:
چک‌لیست ناقص بود.
پس چک‌لیست را اصلاح می‌کنیم و پرونده را می‌بندیم.
اما پیش از بستن پرونده، یک سؤال:
اگر چک‌لیست را اصلاح کنیم، آیا واقعاً فهمیده‌ایم چرا این خرابی اتفاق افتاد؟
پنج چرا چه کار خوبی می‌کند؟
مشکل از خودِ پرسیدن «چرا؟» نیست.
اتفاقاً حرکت مهمی در آن هست: در اولین نشانه متوقف نشو.
اگر فقط بگوییم:
«ثبت آگهی خراب شد چون دیسک پر بود.»
هنوز چیز زیادی یاد نگرفته‌ایم. «دیسک پر بود» بیشتر شرح صحنه‌ی حادثه است تا چیزی که بتوانیم از آن جلوگیری کنیم.
یک «چرا»ی دیگر ما را به لاگ‌ها می‌رساند. یکی دیگر به تنظیم چرخش لاگ. یکی دیگر شاید به فرایند استقرار.
پرسیدن پیاپی «چرا؟» ما را وادار می‌کند از نشانه به سمت سازوکار حرکت کنیم.
عدد پنج هم جادویی نیست. گاهی دو سؤال کافی است و گاهی بعد از هفت سؤال هنوز چیزی نمی‌دانیم.
ارزش روش در «پنج» نیست.
ارزشش در این است که اولین جواب را آخرین جواب نگیریم.
اما همین‌جا یک خطر پنهان است.
هر بار که پرسیدیم «چرا؟»، فقط یک جواب انتخاب کردیم.
اولین شاخه
برگردیم به این سؤال:
چرا دیسک پر شد؟
جواب دادیم:
چون فایل‌های لاگ همه‌ی فضا را گرفتند.
اما این تمام ماجرا نیست.
اگر لاگ‌ها بزرگ شدند، چرا توانستند همه‌ی دیسک را بگیرند؟
شاید:
- چرخش لاگ خاموش بوده؛
- سقفی برای اندازه‌ی لاگ وجود نداشته؛
- دیسک بیش از حد کوچک بوده؛
- یک فایل پشتیبان موقت هم همان شب روی دیسک مانده بوده؛
- سطح لاگ‌گیری اشتباهاً روی حالت بسیار پرجزئیات قرار گرفته بوده.
و سؤال دیگری که زنجیره‌ی اول اصلاً نپرسید:
چرا قبل از پرشدن دیسک هیچ هشداری نیامد؟
یا حتی:
چرا پرشدن یک دیسک توانست ثبت آگهی را کاملاً متوقف کند؟
ناگهان یک خط ساده تبدیل به چند جهت شده است.
در مسئله‌های واقعی، «چرا؟» معمولاً یک زنجیره نمی‌سازد؛ یک درخت می‌سازد.
یک حادثه، چند «چرا» دارد
وقتی چیزی خراب می‌شود، سؤال «چرا؟» خودش مبهم است.
درباره‌ی خرابی ده‌دقیقه‌ای ما دست‌کم چهار سؤال متفاوت می‌شود پرسید:
چرا خرابی به وجود آمد؟
چرا دیسک پر شد؟
این سؤال ما را به لاگ‌ها، تنظیم‌ها، ظرفیت و فرایند استقرار می‌برد.
چرا خرابی به کاربر رسید؟
فرض کنیم دیسک پر شد. چرا نتیجه‌اش این شد که هیچ‌کس نتواند آگهی ثبت کند؟
آیا برنامه می‌توانست بدون نوشتن آن لاگ ادامه دهد؟
آیا داده‌های مهم و لاگ‌ها باید روی یک فضای مشترک می‌بودند؟
آیا می‌شد به‌جای شکست کامل، سرویس به شکل محدودتری ادامه پیدا کند؟
چرا زودتر متوجه نشدیم؟
دیسک معمولاً در یک لحظه از صفر به صد درصد نمی‌رسد.
آیا هشدار ظرفیت داشتیم؟
اگر داشتیم، چرا دیده نشد؟
اگر دیده شد، چرا اقدامی نشد؟
چرا خرابی ده دقیقه طول کشید؟
چرا سیستم خودش بازیابی نشد؟
چرا پیدا کردن مشکل ده دقیقه زمان برد؟
آیا راه بازگشت سریع داشتیم؟
این چهار سؤال به چهار خانواده‌ی متفاوت از راه‌حل‌ها می‌رسند:
جلوگیری — مهار — کشف — بازیابی
ممکن است نتوانیم جلوی همه‌ی خرابی‌ها را بگیریم. اما شاید بتوانیم کاری کنیم که خرابی به کاربر نرسد، یا زود دیده شود، یا به‌جای ده دقیقه در ده ثانیه رفع شود.
این نکته مهم است:
برای بهترکردن یک سیستم، لازم نیست همیشه علت آغاز حادثه را از بین ببریم.
گاهی بهترین تغییر در جایی است که جلوی گسترش حادثه را می‌گیرد.
بعضی علت‌ها با «و» به هم وصل‌اند
درخت علت‌ها فقط فهرستی از جواب‌های ممکن نیست.
گاهی یک اتفاق زمانی رخ می‌دهد که چند شرط هم‌زمان کنار هم قرار بگیرند.
مثلاً شاید برای پرشدن دیسک این سه چیز با هم لازم بوده باشند:
لاگ‌ها سریع رشد کردند
و
چرخش لاگ کار نکرد
و
هیچ هشداری پیش از پرشدن دیسک نیامد.
اگر هر کدام از این سدها وجود داشت، ممکن بود حادثه شکل دیگری پیدا کند.
در مقابل، بعضی علت‌ها راه‌های جایگزین‌اند:
شاید لاگ‌ها دیسک را پر کرده باشند
یا
شاید فایل پشتیبان بزرگی فضای باقی‌مانده را گرفته باشد.
این تفاوت کوچک است، اما طرز فکر ما را عوض می‌کند.
وقتی روی کاغذ درخت می‌کشید، گاهی کنار انشعاب بنویسید:
و؟
یا:
یا؟
آیا یکی از این علت‌ها به‌تنهایی کافی است، یا حادثه فقط از کنار هم قرار گرفتن چند شرط به وجود آمده؟
درخت را از حدس پر نکن
حالا می‌توانیم درخت بزرگی بسازیم:
همان حادثه، این بار به شکل درخت. برگ‌هایی که با «؟» تمام می‌شوند هنوز حدس‌اند.
این از زنجیره بهتر است.
اما هنوز یک مشکل بزرگ دارد.
تقریباً همه‌چیز در آن می‌تواند ساخته‌ی ذهن ما باشد.
هر جواب به «چرا؟» یک ادعاست
فرض کنیم می‌گوییم:
«چرخش لاگ در آخرین استقرار خاموش شد.»
از کجا می‌دانیم؟
شاید فقط چون این توضیح معقول به نظر می‌رسد.
باید بتوانیم سراغ چیزی برویم که این ادعا را امتحان کند:
- تنظیم فعلی سرور چیست؟
- نسخه‌ی قبلی چه بوده؟
- تغییر در کدام commit اتفاق افتاده؟
- زمان تغییر با شروع رشد لاگ‌ها جور درمی‌آید؟
- روی سرور دیگری که همان استقرار را گرفته چه اتفاقی افتاده؟
روی درخت علت‌ها می‌شود کنار هر شاخه یکی از این علامت‌ها را گذاشت:
؟هنوز فرضیه است
✓شواهد با آن سازگارند
×شواهد آن را رد کرده‌اند
مثلاً:
همان شاخه‌ها بعد از سر زدن به شواهد: سه ادعا تأیید شد، یکی رد شد، و یکی هنوز فرضیه است.
این تفاوت میان داستان ساختن و تحقیق کردن است.
«چرا؟» به ما فرضیه می‌دهد.
شواهد تصمیم می‌گیرند با آن فرضیه چه کنیم.
هر حلقه‌ای که به زنجیره‌ی علت اضافه می‌کنیم باید بتواند اشتباه از آب دربیاید.
اگر هیچ مشاهده‌ای نمی‌تواند نظر ما را درباره‌ی یک شاخه عوض کند، آن شاخه هنوز توضیح خوبی نیست.
یک سؤال کوچک بعد از هر «چرا»
پس بعد از هر بار که نوشتیم:
چرا؟
یک سؤال دوم هم اضافه کنیم:
از کجا می‌دانیم؟
مثلاً:
چرا دیسک پر شد؟
چون لاگ‌ها خیلی بزرگ شدند.از کجا می‌دانیم؟
اندازه‌ی فایل‌ها و نمودار مصرف دیسک را دیده‌ایم.
یا:
چرا چرخش لاگ خاموش بود؟
چون در استقرار جدید تنظیمش جا افتاد.از کجا می‌دانیم؟
هنوز نمی‌دانیم. باید تاریخچه‌ی تنظیمات را ببینیم.
همین سؤال دوم جلوی مقدار زیادی از اطمینان کاذب را می‌گیرد.
«خطای انسانی» معمولاً جای خوبی برای توقف نیست
فرض کنیم زنجیره به این‌جا برسد:
چرا تنظیم جا افتاد؟
چون برنامه‌نویس یادش رفت.
می‌شود همین‌جا متوقف شد:
علت ریشه‌ای: خطای انسانی.
اما اگر هدف ما جلوگیری از تکرار حادثه باشد، این جواب معمولاً چیز زیادی در اختیارمان نمی‌گذارد.
آدم‌ها فراموش می‌کنند.
سؤال مفیدتر این است:
چه چیزی باعث شد یک فراموشی ساده بتواند تا محیط واقعی پیش برود؟
مثلاً:
- آیا تنظیم به‌صورت دستی انجام می‌شد؟
- آیا تستی وجود نداشت که نبودنش را بفهمد؟
- آیا مقدار امنی به‌عنوان پیش‌فرض وجود نداشت؟
- آیا بازبینی تغییرات شامل این فایل نمی‌شد؟
- آیا کسی نمی‌توانست بفهمد چرخش لاگ خاموش شده؟
این به معنای بی‌اهمیت بودن اشتباه آدم‌ها نیست.
فقط یعنی اگر تحلیل ما با «فلانی اشتباه کرد» تمام شود، احتمالاً هنوز چیز زیادی درباره‌ی سیستم یاد نگرفته‌ایم.
عمیق‌ترین علت لزوماً بهترین علت برای درست‌کردن نیست
فرض کنیم زنجیره‌ی اول کاملاً درست بوده است:
دیسک پر شد
← لاگ‌ها بزرگ شدند
← چرخش لاگ خاموش بود
← تنظیم جا افتاد
← چک‌لیست ناقص بود.
آیا باید فقط چک‌لیست را اصلاح کنیم؟
نه لزوماً.
چند تغییر مختلف ممکن است مفید باشند:
- مورد تازه‌ای به چک‌لیست اضافه کنیم؛
- روشن‌بودن چرخش لاگ را خودکار آزمایش کنیم؛
- برای مصرف دیسک هشدار بگذاریم؛
- برای لاگ‌ها سقف حجم تعیین کنیم؛
- لاگ و داده‌ی اصلی را از هم جدا کنیم؛
- کاری کنیم که پرشدن فضای لاگ ثبت آگهی را متوقف نکند.
هیچ‌کدام «عمیق‌ترین علت» نیستند.
اما بعضی از آن‌ها ممکن است خانواده‌ی بزرگ‌تری از خرابی‌های آینده را بگیرند.
هشدار ظرفیت فقط جلوی «فراموش‌شدن تنظیم چرخش لاگ» را نمی‌گیرد. اگر هفته‌ی بعد علت پرشدن دیسک چیز دیگری باشد، باز هم می‌تواند کمک کند.
پس به‌جای پرسیدن:
علت ریشه‌ای کدام است؟
گاهی سؤال مفیدتر این است:
کجای این درخت، تغییر کوچکی می‌تواند جلوی بخش بزرگی از خرابی‌های بعدی را بگیرد؟
ریشه شاید استعاره‌ی خوبی نباشد
عبارت «علت ریشه‌ای» تصویری وسوسه‌کننده می‌سازد.
درختی بیمار است. زیر خاک یک ریشه‌ی خراب پیدا می‌کنیم. ریشه را درست می‌کنیم و مشکل تمام می‌شود.
اما بسیاری از خرابی‌های واقعی بیشتر شبیه این‌اند:
چند چیز مستقل کمی بد پیش می‌روند، چند سد محافظتی هم‌زمان کار نمی‌کنند، و ترکیبشان حادثه می‌سازد.
اگر فقط یکی از آن‌ها متفاوت بود شاید حادثه رخ نمی‌داد.
برای همین در مسئله‌های پیچیده، شاید بهتر باشد به‌جای جست‌وجوی وسواس‌گونه‌ی «علت اصلی» دنبال این‌ها باشیم:
- عوامل مؤثر چه بودند؟
- کدام‌ها شواهد دارند؟
- کدام سدها کار نکردند؟
- کجا می‌توانیم مداخله کنیم؟
هدف توضیح کامل جهان نیست.
هدف این است که از حادثه چیزی یاد بگیریم که تصمیم بعدی را بهتر کند.
داستان زیبای یادبود جفرسون
روایت مشهوری در کتاب‌ها و دوره‌های حل مسئله تکرار می‌شود.
می‌گویند سنگ‌های یادبود جفرسون در واشینگتن بیش از حد فرسوده می‌شدند.
چرا؟
چون زیاد شسته می‌شدند.
چرا زیاد شسته می‌شدند؟
به‌خاطر فضولات پرندگان.
چرا پرندگان زیاد بودند؟
برای خوردن عنکبوت‌ها.
چرا عنکبوت زیاد بود؟
برای خوردن پشه‌ریزه‌ها.
چرا پشه‌ریزه‌ها زیاد بودند؟
چون نور یادبود هنگام غروب آن‌ها را جذب می‌کرد.
پس نورها را یک ساعت دیرتر روشن کردند، حشرات کمتر شدند، و مسئله حل شد.
این تقریباً مثال ایدئال «پنج چرا»ست.
حتی کمی بیش از حد ایدئال.
آنچه واقعاً می‌دانیم
در سال ۱۹۹۰ واقعاً آزمایشی روی نورپردازی یادبودهای لینکلن و جفرسون انجام شد.
در بعضی شب‌ها نورهای بیرونی حدود یک ساعت بعد از غروب روشن شدند و در شب‌های دیگر طبق برنامه‌ی معمول روشن ماندند. پژوهشگران تعداد پشه‌ریزه‌هایی را که روی قسمت‌های مشخصی از بنا می‌نشستند شمردند.
در شب‌های با نورِ دیرتر، تعدادشان به‌شدت کمتر بود.
پس دست‌کم یک حلقه از داستان شاهد تجربی خوبی داشت:
زمان روشن‌شدن نور → تعداد پشه‌ریزه‌ها
اما این آزمایش چیزهای دیگری را ثابت نکرد.
ثابت نکرد که نور تنها علت مشکل بنا بوده است.
ثابت نکرد که تمام فرسایش سنگ از همین زنجیره آمده است.
در همان دوره، بررسی‌های بنا عوامل دیگری هم برای فرسایش و خرابی مطرح می‌کردند.
این تفاوت مهم است.
روایت پنج چرا می‌گوید:
«این زنجیره علت مسئله بود.»
آزمایش می‌گوید:
«این حلقه را دست‌کاری کردیم و این پیامد تغییر کرد.»
دومی ادعای کوچک‌تری است.
و دقیقاً به همین دلیل قوی‌تر است.
داستان علت را با علت اشتباه نگیریم
ذهن ما داستان‌های خطی را دوست دارد:
A باعث B شد،
B باعث C شد،
C باعث D شد.
وقتی داستان به پنج جمله‌ی مرتب تبدیل می‌شود، احساس می‌کنیم مسئله را فهمیده‌ایم.
ولی مرتب‌بودن یک توضیح، شاهد درست‌بودنش نیست.
گاهی حتی بعد از یک حادثه، دانستن نتیجه باعث می‌شود گذشته بیش از حد قابل‌پیش‌بینی به نظر برسد:
«واضح است که اگر چرخش لاگ خاموش باشد، دیسک پر می‌شود.»
اما پیش از حادثه آیا واقعاً این خطر واضح بود؟
اگر بود، چرا کسی آن را ندید؟
چه عوامل دیگری لازم بود کنار آن قرار بگیرند؟
یک تحلیل خوب فقط داستانی نمی‌سازد که گذشته را توضیح دهد.
باید چیزی به ما بدهد که پیش از حادثه‌ی بعدی هم قابل استفاده باشد.
یک نسخه‌ی بهتر از پنج چرا
لازم نیست «پنج چرا» را دور بیندازیم.
می‌توانیم آن را کمی عوض کنیم.
۱. رخداد را دقیق بنویس
نه:
«سرور مشکل داشت.»
بلکه:
«از ساعت ۱۴:۰۳ تا ۱۴:۱۳ درخواست ثبت آگهی با خطای نوشتن روی دیسک شکست می‌خورد.»
هرچه رخداد مبهم‌تر باشد، «چرا»های بعدی هم مبهم‌تر می‌شوند.
۲. یک بار بپرس «چرا؟»
اولین توضیح را بنویس.
۳. بپرس «چه جواب دیگری ممکن است؟»
خودتان را مجبور کنید دست‌کم یک شاخه‌ی دیگر ببینید.
لازم نیست آن جواب درست باشد. فعلاً فرضیه است.
۴. چهار جهت را جداگانه نگاه کن
- چرا اتفاق افتاد؟
- چرا اثرش به کاربر رسید؟
- چرا زودتر کشف نشد؟
- چرا زودتر بازیابی نشد؟
ممکن است مهم‌ترین اصلاح در شاخه‌ای باشد که اصلاً علت آغاز حادثه نیست.
۵. کنار هر شاخه بپرس «از کجا می‌دانیم؟»
مشاهده را از حدس جدا کن.
۶. دنبال «ریشه» نگرد؛ دنبال نقطه‌ی مداخله بگرد
از خودت بپرس:
اگر این عامل را تغییر دهیم، چه نوع خرابی‌هایی دیگر سخت‌تر می‌شوند؟
و:
اگر دفعه‌ی بعد علت آغاز حادثه چیز دیگری باشد، این اصلاح هنوز به ما کمک می‌کند؟
کجا متوقف شویم؟
درخت علت‌ها هم می‌تواند بی‌نهایت رشد کند.
چرا تنظیم جا افتاد؟
چون فرایند استقرار دستی بود.
چرا دستی بود؟
چون هنوز خودکارش نکرده‌ایم.
چرا خودکارش نکرده‌ایم؟
چون وقت نداشتیم.
چرا وقت نداشتیم؟
چون…
در جایی دیگر سؤال از مسئله‌ی امروز دور می‌شود.
همان قاعده‌ی برگه‌ی «مسئله‌ی پشت مسئله» این‌جا هم کار می‌کند:
تا جایی ادامه بده که جواب بتواند تصمیم تو را عوض کند.
و یک شرط دیگر هم اضافه کنیم:
تا جایی ادامه بده که برای شاخه‌هایت بتوانی دنبال شاهد بگردی.
«چرا؟» قرار نیست ما را به عمیق‌ترین حقیقت جهان برساند.
قرار است ما را به فهمی برساند که بتوانیم بر اساسش کاری انجام دهیم.
اکنون باید چه چیزی با شما بماند؟
پنج چرا یک عادت خوب به ما یاد می‌دهد:
در اولین توضیح متوقف نشو.
اما اگر هر بار فقط یک جواب انتخاب کنیم، خیلی زود داستانی می‌سازیم که از آنچه واقعاً می‌دانیم تمیزتر است.
پس بعد از هر «چرا؟» دو سؤال دیگر هم اضافه کنید:
چه جواب دیگری ممکن است؟
و:
از کجا می‌دانم؟
آن‌وقت خروجی تحلیل دیگر یک زنجیره‌ی پنج‌خطی نیست.
یک نقشه‌ی کوچک است: چند شاخه، چند فرضیه، چند شاهد، و چند جای ممکن برای مداخله.
تمرین‌ها
تمرین ۱ — زنجیره را خراب کنید
این زنجیره را بخوانید:
جلسه دیر شروع شد.
چون سارا دیر رسید.
چون اتوبوسش دیر آمد.
چون ترافیک زیاد بود.
چون باران می‌بارید.
حالا برای هر مرحله دست‌کم یک شاخه‌ی دیگر پیدا کنید.
مثلاً از همان ابتدا:
آیا جلسه فقط به‌خاطر نبودن سارا نمی‌توانست شروع شود؟
کدام شاخه‌ها درباره‌ی علت تأخیر سارا هستند و کدام درباره‌ی آسیب‌پذیری جلسه در برابر تأخیر یک نفر؟
اگر هدفتان این باشد که جلسه‌های آینده سر وقت شروع شوند، کدام سؤال مهم‌تر است؟
تمرین ۲ — چهار جور «چرا»
فرض کنید پرداخت آنلاین فروشگاه برای بیست دقیقه از کار افتاده است.
چهار ستون بکشید:
| سؤال | فرضیه‌ها |
|---|---|
| چرا خرابی به وجود آمد؟ | |
| چرا به مشتری رسید؟ | |
| چرا زودتر کشف نشد؟ | |
| چرا بیست دقیقه طول کشید؟ |
برای هر ستون دست‌کم دو فرضیه بنویسید.
بعد کنار هر فرضیه بنویسید برای آزمودنش چه داده‌ای لازم دارید.
تمرین ۳ — مشاهده یا داستان؟
این جمله‌ها را بخوانید:
دیسک ۱۰۰٪ پر بوده است.
فایل لاگ ۸۲ گیگابایت حجم داشته است.
برنامه‌نویس هنگام استقرار فراموش کرده چرخش لاگ را فعال کند.
تیم عجله داشته است.
علت اصلی فرهنگ بد استقرار بوده است.
کدام جمله‌ها می‌توانند مستقیماً مشاهده شوند؟
کدام‌ها نیاز به شواهد بیشتری دارند؟
هرچه از «رخداد» دورتر می‌شویم، برای پذیرفتن ادعا چه شاهدی می‌خواهیم؟
تمرین ۴ — حادثه‌ی واقعی خودتان
یک خرابی، اشتباه یا تأخیر واقعی از ماه گذشته انتخاب کنید.
اول آن را با روش معمول پنج چرا به شکل یک زنجیره بنویسید.
بعد:
- در هر مرحله دست‌کم یک شاخه‌ی دوم اضافه کنید.
- مشخص کنید کدام شاخه‌ها با «و» و کدام با «یا» به هم مربوط‌اند.
- کنار هر شاخه بنویسید
؟،✓یا×. - جداگانه بپرسید چرا حادثه رخ داد، چرا اثرش گسترش یافت، چرا دیر کشف شد و چرا دیر رفع شد.
- سه نقطه‌ی مختلف برای مداخله پیدا کنید.
در پایان فقط یک سؤال:
آیا راه‌حلی که بعد از ساختن درخت انتخاب کردید با راه‌حلی که از زنجیره‌ی اول به دست می‌آمد فرق دارد؟
اگر فرق دارد، درخت کار خودش را کرده است.
دفترچه‌ی مسئله
برای این برگه چند خط تازه به دفترچه اضافه کنید:
چه جواب دیگری برای این «چرا؟» ممکن است؟
از کجا می‌دانم این جواب درست است؟
این شاخه با بقیه «و» است یا «یا»؟
چرا خرابی به وجود آمد، چرا گسترش یافت، چرا دیر دیده شد و چرا دیر رفع شد؟
و در پایان:
کجای درخت بهترین جای مداخله است؟
منابع
- Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production.
- Alan J. Card, “The Problem with ‘5 Whys’,” BMJ Quality & Safety, 2017.
- Charles Vincent et al., “Analysis of Clinical Incidents: A Window on the System Not a Search for Root Causes,” Quality & Safety in Health Care, 2004.
- Hartman-Cox Architects, Preservation and Restoration of the Jefferson Memorial, Phase I Report, National Park Service, 1990.
- Steve Twomey, reports on the Lincoln and Jefferson Memorial midge-lighting experiments, The Washington Post, 1990.