文章非常好，我認為我們必須實施這一思想。
原文：翻譯：
正文：概要：無論何時當發現問題時，應連續追問五個為什麼尋找到問題的根源。然後在分析的各個層面進行修正。發現問題時應用五個為什麼，你將（1）發現技術問題下的人員問題，（2）為你的創業公司建立一套免疫系統。
大野耐一是豐田生產方式的發明人之一。他的書《豐田生產方式》是乙份很吸引人的讀物，雖然它並不實用。讀完這本書，你甚至可能都沒法意識到豐田是做汽車業務的。但是我清楚地從這本書學習到了乙個十分具體的方法：問五個為什麼。我認為這是乙個關鍵的精益創業方法。
當問題出現時，我們傾向於將其視作危機並追究責任。更好的辦法是將其視作一次學習的機會。但並不是泛義的整體自我提公升。而是通過五個為什麼尋找到問題的根源然後進行修正。
發現問題時追問五個為什麼。 具體是這樣進行的。比如，你發現你的**崩潰了。顯然，你第一反應是恢復它。但是危機一旦過去，應開展事後調查找問為什麼：
為什麼**崩潰了？因為所有前端伺服器上的 cpu 使用率都達到了 100%。
為什麼 cpu 使用率達到 100%？因為一段新**包含乙個無限迴圈。
為什麼會出現這樣的**？因為某員工出錯了。
為什麼他會出現這樣的錯誤？因為他沒有為這個功能寫單位測試**。
為什麼他沒有寫單位測試**？因為他是一名新員工，且沒有在測試驅動開發方面接受正確培訓。
在這五個地方進行修正。
目前為止，這與主管運營團隊面對**崩潰會作的分析相差不大。接下來：你要承諾按一定比例投資用於對分析的各個層面進行修正。因此，在上面的例子中，我們需要作五處的修正：
恢復**。
移除錯誤**。
幫助出錯的某員工了解為什麼他的**沒有起到預期作用。
培訓該員工學習測試驅動開發相關知識。
將測試驅動開發納入新工程師入門指導內容。
進行修正可建立創業公司免疫系統。
我開始相信應該採用這種方法應對所有問題，而不僅是**崩潰。每次，我們將出現的問題當作尋找系統缺陷的機會，進而小幅地調整改善。
創業公司
在上例中，一開始的技術問題實際上變成了人員和流程的問題。這十分典型。我們工程師有只關注產品部分問題的傾向，而五個為什麼則常會避免這種傾向。
這也是在我以前的工作中可以使新工程師入職第一天就十分高產的原因。我們有一套極佳的入職過程，包括導師制及需要注意的重要事項清單。大多數工程師在入職第一天就將**用於開發了。
根據錯誤成本大小進行修正
我們一開始沒有這樣的好計畫，也沒有馬上將所有時間用在這上面。相反，五個為什麼一直揭示出由於新員工培訓不正確而引起的問題，為此我們進行了小幅調整。所以在我們意識到之前，就已經完全不存在這類問題了。
因此，記住上述規則中的按比例進行投資十分重要。也很容易知道：出現問題時需要徹底的重寫。我們較傾向於關注技術方面的問題且容易反應過度。
如果問題嚴重，比如**崩潰，要耗費大量資金或需要大量人力時間進行除錯，那麼同時應該配備同樣多的人力時間或資金尋找解決方案。
修正預算總額應與引起五個為什麼的錯誤成本成正比。因此，如果**崩潰了，它是五名員工花了一整天時間建成的，那麼也許花五個人工日用於修復才是合理的。但如果這個錯誤花費了三名客戶每人 25 美分，那麼也許修復它只應用幾個小時。
但總有最大限量，也有最小限量。對於所有小問題，只需要向前改進一點。不需要過度投資。如果這個問題再次出現，五個為什麼會給你小額預算讓你再向前改進一點。你可沉著應對，因為只要問題再出現就可採用五個為什麼解決。
總結：採用五個為什麼可以首先將其應用於乙個具體團隊的乙個具體問題。選擇乙個負責人與問題相關人員一起進行事後調查。然後將分析結果通過郵件發給公司所有成員。將五個為什麼反覆應用於 imvu 為公司建立了一套免疫系統，使我們的開發者出錯減少速度更快。
在第一部分，我講述了如何採用五個為什麼找到問題的根源，進行修正，並為你的創業公司建立一套免疫系統。所以…
你是如何開始五個為什麼的？
我建議你從乙個具體團隊和乙個具體類別的問題開始。我第一次選擇了擴充套件性問題及運營團隊。但你可以從任何地方開始—我曾在很多不同的團隊用過。
剛開始採用五個為什麼只需要乙個負責人。一旦團隊裡有人發現乙個問題，他將進行事後調查。
但不要讓負責人獨自一人完成；將問題相關人員（包括診斷或除錯的人）聚集在一起十分重要。讓負責人主導討論，並賦予他或她權力給每個人分配解決方案中各自承擔的任務。
將五個為什麼調查結果傳送給公司每個人
一旦任務分配完畢，讓出錯的新員工將分析結果郵件傳送給公司所有人。最後一步十分困難，但我認為十分有用。五個為什麼應該讀起來簡明易懂。如果不是，那麼你就有可能搞錯了真正的問題。
將結果資訊廣泛共享的優點在於它可以讓每個人都認識到團隊所面對的問題，同時也了解到這些問題是如何解決的。如果分析無懈可擊，每個人就很容易理解團隊為什麼要花時間用於問題預防而不是用於開發新功能。
另外，如果這樣導致了公司大風暴—也是一件好事。現在你知道存在問題：要麼是分析不合理，需要重做，要麼就是公司不理解你所做事情的重要性。明確是哪一種情況，然後解決問題。
長期採用五個為什麼會遇到什麼？
以下是我的經驗。
人們習慣了五個為什麼的步驟，增加投入變得十分正常。大多數時候，你投入的都是需要大量會議才能決定的事情。
你將看到公司裡的人為幫助你把工作做得更好都向你提出有趣的建議。現在，所有人都一起學習—了解你的產品、程式及團隊。每封五個為什麼郵件都是乙份教學檔案。
採用五個為什麼幾年後 imvu 的免疫系統。
讓我向你展示 imvu 的運營團隊和工程團隊在實施五個為什麼幾年後的樣子。我們為部署對工具和程式作了很多改進，現在**出現崩潰機率很小。我們有五層堅固的防禦。
每位工程師都有他/她自己的沙盒用以盡可能地模仿應用程式（一旦出現錯誤，我們其後不可避免地會在五個為什麼中發現）。
我們整個團隊有一套全面的單位測試、驗收測試、功能測試、效能測試及可行的測試驅動開發。工程師設立了一系列的測試標籤，所以你可以在你的沙盒裡進行一系列你認為與現在專案或功能相關的測試。
通過持續的整合聚集，檢入後 100% 的測試可執行。如測試失敗，它將阻止修正版被使用。
如某人想要進行部署，我們有一套稱為集群免疫系統的完全自動化系統。這將採用漸進的改變方式，一次一台機器。這個系統還將持續監控這些機器的執行狀況以及整個集群，以判斷這些改變是否帶來問題。如果正在發生的不受認可，它將拒絕改變快速恢復原狀並鎖定部署，直到有人調查出了什麼差錯。
我們有一整套的監控警報系統，一旦出現問題，正在執行的頁面排程程式將被觸發。由於五個為什麼不斷發現一些很難設定靜態閾值的關鍵指標，我們甚至有乙個動態**演算法。如果指標超出正常值，基於過去的資料及火災警報，就可利用這個演算法作出相應**。（你可以閱讀我們一位工程師的一篇關於這個方法的文章。）
堅固的免疫系統減少出錯加快速度
所以如果你能夠潛到我們任何一位工程師的桌上，登入他們的機器，在某高流量頁面錄入乙個無限迴圈**，那麼大概 10 到 20 分鐘後，他們會收到一封電子郵件，內容大概是這樣：
好吧，並不是完全一樣。但是大意如此。
擁有這樣一系列的防禦對實施五個為什麼有益。如果應用程式遇到錯誤的改動，我們就將有一套內建式的問題：為什麼自動測試沒有發現它？為什麼集群免疫系統沒有拒絕它？為什麼操作沒有上網頁？如此等等。
我們每次都對各層防禦進行細微的改善。最後，它將使我們每天可以完成許多次的部署，而且無顯著停機或故障回歸。
總結：任何時候開始採用五個為什麼都不晚，即使你被不計其數的遺留**困擾。一旦發現問題就開始問為什麼—你自然而然就會開始解決那造成你 80% 問題的 20% 的潛在問題。最初是豐田公司發現五個為什麼—如果它適用於汽車行業，它也適用於你。
在第一部分，我講述了如何採用五個為什麼找到問題的根源，進行修正，並為你的創業公司建立一套免疫系統。第二部分，我解釋了如何開始五個為什麼以及 imvu 怎樣經過經年累月的應用五個為什麼而建立了一套創業公司免疫系統。在最後一部分，我將介紹如何將五個為什麼應用於傳統創業公司。
開始問為什麼永遠都不晚。
當我向創業家和大公司解釋五個為什麼時，我有時得到這樣的回應：「好吧，當然，如果你擁有很好的工具、程式及測試驅動開發，這樣開始當然很容易！但是我的團隊被不計其數的遺留**困擾著，而且…」
所以我鄭重宣告：imvu 是在不擁有這其中任何一項的情況下開始五個為什麼的。我們甚至沒有在全團隊實施測試驅動開發。我們從未聽說過五個為什麼，團隊裡還有無數個「敏捷懷疑論者」。我們開始持續整合時，還有成千上萬行**不在測試範圍之內。
而五個為什麼的優點在於它本身包含帕累託原理。因為最常見的問題始終重複出現，你的防禦自然而然地集中在最需要幫助的那 20% 的產品上。而也正是這 20% 的產品花費你最多時間。所以五個為什麼的償還速度十分快，且它能立即使狀況明顯好轉。你只需要開始。
如果它適用於汽車行業，那它也適用於任何地方。
因此，謝謝您，大野耐一。我想你會喜歡看到：在你開始豐田之旅時尚不存在的行業裡，我們能夠從系統與程式中消除所有不必要的浪費。
你還等什麼？
來自為知筆記(wiz)
五個為什麼
2008年1月10日的凌晨3點30分，一陣急促的嘟嘟聲驚醒了我們的系統管理員michael gorsuch，當時他正在位於布魯克林的家中睡覺。那是一條網路管理員nagios發來的短訊息，報告系統不正常。michael gorsuch從床上爬起來，不小心踩到了正在床邊酣睡的他的狗，把狗也弄醒了。那條狗...
十萬個為什麼
目錄 import sys import some module noqa答案 將 noqa新增到一行表示linter 乙個自動檢查 質量的程式 不應該檢查此行.可能生成的任何警告都將被忽略。那條線可能有一些 看起來很糟糕 的東西,但開發商理解並打算出於某種原因它在那裡 有關更多資訊,請參閱flak...
為什麼為什麼為什麼為什麼為什麼你要做一名程式設計師？
from 本文是從 why why why why why are you a developer?這篇文章翻譯而來。做乙個程式設計師很忙，你需要去寫 去建立meme，去進行測試，以及隨時關注最新最熱的gem 開源軟體技術。最近，我一直在想讓自己的節奏慢下來，去做一些心裡一直想做但沒有去做的事，去思...