我不是主張失敗本身是件好事，失敗一點也不好，不僅賠上金錢、傷了士氣、惹火客戶、破壞聲譽、損及職涯，有時還會釀成悲劇。然而在不確定的環境中，失敗是無可避免的，如果管理得當，也可以是一種助力。
與其忽略失敗，我們可以醞釀「智慧型失敗」（intelligent failure），這是杜克大學（Duke University）西姆．希特金（Sim Sitkin）所創的詞，於1992年發表在《組織行為研究》（Research in Organizational Behavior）上的一篇卓越的文章〈從錯誤中學習：小損失的策略〉。如果你的組織也能運用智慧型失敗的概念，就可以更靈活，更善於承擔風險與學習。
智慧型失敗的原則
顯然不是所有的失敗都有益處，就連有些可帶來學習效果的失敗，我們也應盡量避免。不過，如果你相信在不確定的環境中，難免會遇上失敗，最好能事先規劃、管理失敗，從失敗中學習。以下的幾個原則，可幫你的組織善用從失敗中學到的經驗。
原則1／把假設轉化成知識
當你投入不確定性很高的任務時，最初的假設，幾乎都是錯的。如果你想獲得更好的假設，通常，唯一的方法是去測試，但你必須清楚說明假設以後，才能開始試驗。把假設寫下來，讓你的團隊知道。若是獲得新的資訊，就應修改這些假設。這時可能出現的風險，是只注意到那些證實我們既有想法的資訊，這就是所謂的確認偏誤（confirmation bias）。避免這種偏誤的一個很實際的做法，就是授權團隊成員去找那些證實你行動有誤的資訊。你應該及早找出會推翻你想法的資訊，等到你已大規模投入行動、不願改變心意時，才發現那些資訊，為時已晚。
不記錄假設的組織，通常會碰到兩種問題。第一，假設變成大家認定的事實。會議上，經理人可能猜想某個市場可創造500萬美元的銷售額，結果會議還沒結束，這500萬美元的數字已納入明年的預算中了。猜測往往容易出錯，如果真是錯的，這種妄下定論，會導致各種異常的行為。第二，這樣的組織無法有效學習。他們可能在過程中更正錯誤，邊做邊學，但如果不確實比較結果和預期之間的差異，他們學到的啟示就不夠明確，也無法和其他成員分享，未來的專案無法因此受惠。 清楚說明假設並修改後，應該要規劃實驗來驗證這些假設。
原則2／迅速失敗，不拖泥帶水
迅速果決地確認失敗，有幾個重要的好處。第一，避免把更多資源，投入失敗的提案。第二，從行動到結果的時間愈接近，愈容易確立因果關係。第三，及早排除某項行動計畫，可更快朝著目標邁進。第四，早點失敗可減少專案必須持續進行的壓力，因為你的投資還不大。
確保可以很快就確認失敗的實用做法，是及早測試專案的各項要件。在系統設計方面，「敏捷軟體開發」流程（agile software development）就是這麼做，所以往往比傳統的循序開發流程產生更好的結果。在敏捷的環境中，工程師分段撰寫程式碼，迅速來來回回地和其他程式設計師及使用者分享，然後才繼續開發。
速度也會改變你配置資源的方式。例如，你不會要求在專案存續期間，必須有最高的淨現值（NPV），而是把時間和金錢都切割成較小單位，分段進行財務評估。你也可以投資較靈活的資產和人才，累積足夠的經驗後，再大規模推動計畫。
此外，我們也不該小看迅速失敗對人的效益。如果專案成員覺得，專案失敗之後他們可能要等好幾個月才有其他專案可做，甚至可能丟了工作，這樣的失敗會讓人士氣消沉。但如果很多事情都在進行中，一件事情的失敗之後，他們可以馬上投入另一項專案，結束專案對大家來說就是正面的。
原則3／壓低失敗成本
計畫的設計，應盡量讓失敗的後果不會太嚴重。有時候在大舉投資前，最好先做小規模的測試。日本化妝品公司花王有意跨界生產磁碟片，但顧客會不會買掛著花王品牌的磁碟片，是一大問題。所以他們找了一家製造商，採購符合品質標準的磁碟片，印上花王的商標，賣給顧客，結果反應不錯，於是他們開始推動計畫。萬一當初試賣的結果不好，花王可在不衍生太大的成本下，終止那項計畫。
這種做法可能必須打破根深柢固的習慣。一位曾和我共事的高科技公司創新長表示，他們總是讓技術人員先做技術可行性研究，才決定是否跨入新產品的領域。但那些研究不僅成本昂貴（超過20萬美元），也不太能顯示商業上的可行性。所以，那位創新長開始製作潛在新產品的仿製品，拿給潛在顧客看。有好幾次，他們發現一些非技術性的議題，可能導致顧客不願使用產品，例如，外型、實用性、是否和既有系統相容等。採用這種方法，大幅降低了成本，因為仿製品的成本通常只有約2萬美元。此外，速度上的差異也很大，這種方式只需要幾週的時間，而之前那種技術可行性分析則需要到12個月。（更多智慧型失敗原則，請看本期《哈佛商業評論》）
本文作者莉塔．岡瑟．麥奎斯（Rita Gunther McGrath）為哥倫比亞大學商學院教授，研究多變環境中的策略和創新。本文譯自〈Failing By Design〉HBR, April 2011
