本文要點
- 在面對不確定性時，說到預測和規劃，軟件行業一直以來的記錄都不太靠譜。
- 阻礙我們學習的偏誤有很多，包括認知偏差和薪酬結構。
- 使用統計協助預測有可能成功，只要我們努力創建基於學習的模型，比如蒙特卡羅模擬。
- 使用作爲敏捷方法本質的迭代學習模型，是處理高度不確定性環境的最佳手段。
- 面對極端不確定、難以找到決定因素的環境，最佳手段是使用假設檢驗（假設驅動開發）這樣的增量式學習方法，並且努力接受不確定性帶來的不適感。
規劃好的最佳方案……
預測很難，尤其是預測未來的時候。
人們常常認爲這句話來自物理學家尼爾斯·玻爾。還有人將其歸到下列名人之一：馬克·吐溫、棒球明星尤吉·貝拉（Yogi Berra）、著名電影製作人薩繆爾·高德溫（Samuel Goldwyn)、政治家卡爾·克里斯丁·思丹克（Karl Kristian Steincke），或者就是那麼一句丹麥老話。這是一句有益的警告：很多時候，事物不是看上去那麼簡單，當我們瞭解不斷深入，它們會變得越來越複雜。如果我們甚至無法判斷是誰提醒我們預測有多難，也許這表示預測本身更讓人撓頭。
軟件行業幾乎完全依賴預測。然而，我們卻沒有多少靠譜的成功。在不同評判標準下[1]，大約 60% 到 70% 的軟件項目交付時預算超標、時間延期、或是直接取消，而且常常是在花費了大量資金之後。
此種情形原因何在？應該怎麼做才能增加預測成功概率？討論它們之前，我們先看看預測軟件開發的原因。
商業需要預算和規劃。資本，作爲商業的血脈，必須理性分配給提供最佳回報的工作。我們需要回答這樣的問題：應該花費多少資金？哪些項目可以批准啓動？我們需要分配多少時間？是下次衝刺迭代的兩週時間，還是下個財年的 12 個月？
傳統而言，要回答資源分配問題，首先需要根據長期項目成本和範圍加以估算，圍繞估算形成時間表和計劃，然後決定哪個計劃值得投入資本。出於多種原因，我們下面會討論一些，一個計劃常常在墨水未乾之前就已經展開了。
有了諸如 Scrum 這樣的敏捷方法，工作規劃週期已經減少到兩週這麼短。既便如此，待辦事項列表中哪些故事值得開發，仍然是個問題。但是，即便縮短髮布週期，仍舊導致至少 60% 的失望率[1]。那麼，到底出了什麼問題？爲什麼我們不能取得進步？爲什麼我們似乎無法學會做得更好？
爲什麼我們沒有吸取教訓
讓我們看看，是什麼機制讓我們繼續採取常常失敗的策略，從而陷於無法學習改進的死循環中。如果我們可以理解自己行爲背後的驅動因素，也許要改變它們就更容易，從而不斷學習。
我們不學習也能拿錢
企業中的常見情況是，工作保障和激勵與下列因素有關：預測準確、制定規劃達成預測、分配稀缺資本、然後按計劃交付。而且，要是能低於預測成本、早於預定日期完成，常常能得到財務激勵。只要金錢激勵與預測和規劃未來相關，預測和規劃就是商業活動的必備行爲，無論是否能產出預期成果。實際上，人們得到複雜的結果，常常是爲了證明它的有效性，而不管這樣的有效性是否合理。
然而，面對失敗的預測，人們的解決方法經常是聽上去誘人而又可行的“我們下次會做的更好”。很容易想到的是：要嘗試多少次才能徹底掌控？到了某個時點，我們應該意識到：這種策略不成功，應該試試其他辦法。之所以不能吸取教訓，是因爲薪酬常常與不理解背後原因相關聯。美國作家 Upton Sinclair抓住了這種想法的精髓，他寫道（性別用詞中立）：
當一個人的工資取決於他不能理解某件事物的時候，那就很難讓他理解該事物。
如果我們希望改善產出，那就需要改變我們的薪酬結構，獎勵我們的學習過程，遠離獎勵我們不去理解事物的薪酬結構。
小故事：有一次，我在向一位公司高管講述非確定性系統中的不確定截止日期是怎麼回事，他看着我，滿臉怒氣，大拇指和食指分開一英寸，然後說：“你說你不知道何時能完成，直到你距離完成這麼近的時候才知道？這是胡說！”這次對話中誰更失望，很難說。是高管嗎？因爲在他眼中，我看上去不能理解最基本的商業理念和活動。是我嗎？因爲高管似乎不能理解他的公司的基本數學邏輯。實際上 ，我們都是對的，至少從我們的出發點看來如此。真正的問題，在於我們的薪酬結構系統，迫使我們有彼此不兼容的想法。
簡單的誘惑力
無論我們如何實踐，軟件工程都是一項複雜的商業行爲。它一直如此。Fred Brooks 多年前就寫過，結論是“沒有銀彈”[2]可以消除軟件開發的內在複雜性和困難。可這麼多年過去了，我們還在這裏，仍然想要找到複雜性的解決方案，能讓它變得更簡單的方案。對於簡單的渴求讓我們制定過於簡化的計劃，其中低估了出現未知因素的可能性，而當它們突然現身，就會讓我們的項目偏離正軌，導致花費大量資金，然後還計劃延期。
說到預測，我們很容易相信：存在某種簡單的、一勞永逸的解決方案，可以滿足所有人的要求，需要做的，就是要嚴格按照它的實踐要點。然而，歷史告訴我們：簡單方案的隊伍來來去去，永無休止，定期出現，此起彼伏。這其中需要理解的是：軟件行業的要求複雜，沒有簡單的“銀彈”方案可以滿足。作家門肯的奇妙智慧給我們這樣的告誡，警告我們簡單的誘惑力：
每一種人類的問題，總有一個衆所周知的解決方法：優雅、可行，而且錯誤。
沉沒成本謬誤
只要我們投入了時間和金錢來建立預測，沉沒成本謬誤就開始擡頭了。沉沒成本謬誤可以歸結爲：已經花出去的錢無法收回來，但我們常常看不到這一點，然後繼續花更多錢，希望能從前面的開銷中獲得一些回報。我們傾向於這麼做，因爲我們的工作保障常常需要我們證明：我們做出了明智的財務決策，可以帶來利潤回報。更糟糕的是，錢花得越多，我們就越覺得有必要證明這些投入的價值，這就讓我們走上越花越多的漩渦之路。所有這樣意味着，我們常常花錢來爲失敗的預測辯護，而此時早已過了放棄的最佳時機，後面的開銷本來可以用在更理性的想法上。
自然界中沒有沉默成本謬誤，可以找到一個有教益的例子。如果某個物種出現問題，如果它無法適應環境，就要承受迅疾、無情的打擊——絕滅，被新的物種快速取代。這個例子值得銘記，特別是下一次我們相信自己的預測可以成功的時候，只要再多投點錢進去。
教條的陷阱
無論是有意還是偶然，任何成功的公司都能找到一系列成功的實踐，讓自己可以開拓市場環境中的某個利基市場。這些實踐就會作爲規範進入一系列規則系統和組織管理層級中，後者想要保持公司的成功，直到永遠。成功時間越長，它的盈利實踐就越容易變成教條。如果這些成功實踐中存在預測，那麼相信預測有效的信念就可能變成教條。
當然，教條的主要問題在於：就其定義而言，教條是無法改變的，從而讓我們在變動的環境中視而不聞，而市場環境不存在無法改變的定義。那麼，當市場環境變化時，教條不改，那就離消亡更近了一步。要想避免，我們就得拒絕制訂教條。
但是在組織中，拒絕教條常常不受歡迎。質疑它的人常被打上“不合羣”的標籤，或被視爲需要“跟上隊伍”。典型反應是讓他們靠邊站，或是除掉這樣的人。畢竟，教條在公司內存在，是因爲它定下的策略曾指向成功，保護這個成功是組織的主要任務。然而，說到預測，理性的方法建議：指導決策過程的應該是深思熟慮，而不是教條。
殘忍的隨機性
預測常常有兩個內在的錯誤信念。第一，未來與過去差不多；第二，所有過去的事件都在期望之中。實際上，當過去的事件發生時，塑造將來的那些常常是不可預期的。預測未來時，我們常常假定不存在未知因素，因此不存在未知的未來事件。其中的認知陷阱是：由於新付出的努力和過去類似，這就讓我們相信，自己已經事先了解了可能出乎意料的事件。問題在於， 每次新付出的努力在顯現時，都是根據自身內在的、而且常常是不爲人知的、一系列獨特因素。
如果我們知道自己不知道什麼，只要增加一個合適的軟性因子，就能對付它，然後繼續前行，同時滿足於自己的規劃可以應對未知。不幸的是，我們常常不知道自己的無知，更不用說如何應對未知了。此外，外界鼓勵我們找到這樣的原因，是它“上次由於 X 因素導致的失敗，但我們這次已經留心了”。雖然我們已經留心了上次預測中的 X 因素，但下一次絕不是 X 因素煩惱我們。將會是 Y 或者 Z，或者其它未知原因。雖然字母表是有限的，我們可以覆蓋所有原因，但在現實世界中，未知因素可沒有上限。
可要是我們運氣好，而且因爲自己的預測取得偶然的成功呢？ 如果無法認識到它的偶然性，那麼我們必將傾向於避免採取新策略，因爲我們自然相信：成功是源於我們的技能，而不是偶然機會。接下來更有可能發生的是：偶然成功將會被擡高到完美執行了策略和計劃的地位，而重複的失敗將被合理化爲策略和計劃執行糟糕。可是，是隨機性讓我們從幸運的預測得到回報，而我們將會更加努力試圖重現這樣的預測。研究顯示：小小的鴿子很快就能識別出模式——用嘴啄槓桿，就能得到食物[3]。如果沒有食物出現，它們很快就會放棄。但要是獎勵是隨機的，如果沒有可以辨識的模式，不知道何時啄槓桿可以得到食物，鴿子很快就會進入迷信的瘋狂狀態，使勁啄槓桿，想要判斷模式。比起我們想要反覆讓自己的預測成真，這樣的行爲似乎並無天壤之別。
魅力型人格
再看看另一個人類偏誤：我們喜歡自信、有魅力的人。自信、果斷的人升職更快，他們會坐到影響整個公司前途的位子上。在那裏，他們安排活動，表明自己可以預測未來，制訂規劃，再按其執行。面對未知因素時，他們手邊總有答案和行動規劃，即便這樣的規劃表明他們的能力和信心並不相符。然後，我們就在他們的領導下安排資源，對他們確信無疑，全速前進。相比而言，有的人沒那麼確信，被問到面對未知因素怎麼辦時，他們會聳聳肩，回答道：“不知道。咱們做個實驗，看看能不能找出辦法。”比起他們，我們更容易轉向有魅力的人，而不是謹慎的人士。
過度自信偏誤就是在這時候生效的。相對同伴而言，魅力型人格和自信的人們更容易認爲，自己擁有超出常人的預測能力。理性來看，瞧瞧 70% 的預測失敗率，我們還是最好躲開他們，因爲我們只有 30% 的成功機率。相反，極其自信的人看法不同，他們無視衆多項目的多年統計數據，堅信自己的努力總能在別人失敗的地方成功。
小故事：多年前，在互聯網第一次泡沫的尾聲，我在一家創業公司擔任軟件開發工作。帶領我們的是一個年輕的、能量滿滿的、充滿魅力的 CEO，他渾身散發着自信和掌控力。當時，我們租的辦公樓已經見證了一家又一家軟件公司租戶的倒下，像多米諾骨牌一般。後來，只剩我們少數幾個人留下了，整棟樓幾乎空無一人，停車場有種詭異的後末世之感。就是在這種情形下，我們的 CEO 召開了全員大會，向焦慮的員工們保證，我們的未來是光明的。我想起他口若懸河，激情四射，充滿整個房間，讓我們相信可以得償所願。
當然，最後我們跟其他無數 dot-com 公司一樣，泡沫破滅，我們關門。實際上，就在 CEO 激昂的演講後不久，我們的結局就降臨了，當時我們無法拿到另一輪融資，從而加入了大樓租客離去的行列。
被魅力型領袖的自信和理念所矇蔽，公司的很多人無法看到顯而易見的事實：如果無法盈利，我們就不能生存。事後看來很清晰，但在當時，相信我們跟其他人不同，相信雖然那麼多人剛剛失敗了但我們終將成功，這好像很合理。這是很有教益的例子，讓我面對魅力型人格的時候心存懷疑。
犯錯，經常性地
“哎，我們將來不會再犯這樣的錯誤了。我們甚至炒了某些人的魷魚，確保它不再出現。”也許如此。我們不會犯同樣的錯誤，因爲下一次我們就有所準備了。問題在於，第一個錯誤出現之前，沒人知道它，同樣的事情還會發生，不過這次是另一些錯誤了。使我們成爲犧牲品的新的錯誤，將會不斷出現，因爲之前沒有人知道它們。第二次世界大戰即將開始之前，丘吉爾在對議會發言時完美描述了此種情形。當時議員們擔心重複一戰的錯誤，希望確保不要再犯。丘吉爾的回答是：
我保證當時的錯誤不會再重複了；我們也許會犯下新的錯誤。
我們常常出錯，而且不知道自己犯錯。出了錯還不知道，感覺上就像自己完全正確[4]。實際上，對錯常常無法區分，直到證明我們錯了。這應該讓人們警覺起來，明白錯誤的不可避免。
在管理層會議和董事會中，常常能聽到這樣的說法：“決不允許失敗。”雖然這麼說常常是爲了讓人們不要敷衍工作，但的確排斥了學習和探索的機會，因爲失敗是學習的必要過程。這句話同時讓人覺得，承認過程意味着承認能力不足，也許會導致失去工作。一旦這樣的思考方式固定下來，再加上財務激勵的鞏固，就會讓人們認爲：失敗，意味着過去一直成功的做法現在臨時面臨某些問題，我們只要付出雙倍努力，它將來就能成功，即便真正的教訓是，我們應該換條路走。在這些情形下，承認錯誤並改變做法，就變得很難了，因爲我們堅持過去的思考方式，不可逆轉。歷史中充滿了這樣的例子，公司失去學習能力，持續投入越來越多寶貴資本到錯誤的策略中，即便這些策略把它們拖下懸崖。停下來反思一下，就能讓我們醒悟，知道我們並非對此種愚蠢免疫。
利用學習的策略
前面列舉的這些原因，說明我們爲什麼無法學習，而且繼續採取讓我們失敗的策略。但要是可以避免這些陷阱呢？是否有策略把學習作爲重點呢？實際上，當然有。
決定性的方法
過去，軟件項目使用瀑布開發模型。先收集需求，再根據需求做估算，再從估算創建時間表。這種方法以決定性的觀點看待軟件項目，認爲只要收集足夠的數據和分析，我們就能準確預測成本和交付日期。這些項目常常在早期就開始出問題了，需求不足和估算不準是主要原因。對於後者，估算常常出錯，是因爲它們不是根據嚴格的統計方法，而是從某些類似於拍腦袋的做法中收集得來。
不過，決定性的觀點也有可能成功，只要使用校準過的統計模型，並且從公司的歷史軟件項目中收集數據。蒙特卡洛分析是常見的統計方法。[5] [6]該方法背後的數學原理非常複雜，不過可簡單概括如下：我們收集一系列歷史數據，其中常常包括諸如工作量和持續時間這樣的參數。然後，我們模擬這個場景幾千次，其中隨機輸入不同參數，以產生概率分佈，表明給定數量的工作可以在給定的時間內完成。比如，我們會得到一個分佈，表明某個定量工作有 25%的機率在一個月內完成，50%機率兩個月內完成，90%的機率在五個月內完成。這裏的重點是：我們使用的歷史數據，是我們這個組織獨有的，用它來校準我們的模型，產生結果機率範圍，而不是單一的值。注意，這種方法是很嚴謹的，而不是像某個人隨口一說：“我一個星期就能做完。”
使用此方法，我們就是在選擇學習。我們隨時間推移收集數據，然後迭代地使用這些數據，並從中瞭解我們組織的能力如何，以及完成工作需要的成本和時間。當然，模型的準確性，與用來校準它的數據相關。模糊的需求說明、糟糕的工作完成記錄，以及其他類似問題會產生讓人失望的結果。
僞決定性方法
上述這樣的完全決定性的方法要想成功，前提條件是所有的需求都能提前說明，而且不會經常變更，不過這樣的項目可不常見。如果我們開發的是更典型的項目，目標不是很明確，需求說明不確定，市場需求也未知，那該怎麼辦？這些條件下，決定性的預測不太可能產生讓人滿意的結果。
這就要說到敏捷方法了。
敏捷方法採取僞決定性的手段來交付軟件。它脫胎於傳統瀑布項目反覆失敗帶來的沮喪之中，放棄採信長期預測和規劃，而是聚焦於短期內交付可以用的軟件，同時適應不斷出現的變化。使用敏捷方法，我們接受這樣的思想：需求無法過於提前確定，但必須隨着時間不斷演化。
Scrum [7] 是常見的敏捷方法。它的兩週衝刺迭代縮短了發佈的時間週期，從而將項目的錯誤和偏移降到最低。我們在每個衝刺前重新設定優先級，這麼做有效地重置了項目的時鐘，讓我們可以靈活適應變化。
我們仍然可以使用蒙特卡洛方法，來預測蘊含需求的故事的大小[9]，但我們放棄了決定主義的一個表現：用長期規劃來決定項目日程。相反，我們用迭代方法發現需要交付的東西，從而再次將重點放在學習上。
但這樣做是不是就解決了預測和規劃的問題？還是隻是將錯誤預測和規劃的影響最小化了？看上去我們還會有同樣的問題，只是規模變小了。
演化式的方法
我們從傳統方法的長髮布週期出發，前進到了敏捷方法的短週期，而且短得多。我們還放棄了長期、固定需求的理念，轉而選擇關注更小的故事。這些改變可以幫我們迭代式地探索需求，得到更好的結果。這就帶來一個明顯的問題：如果一小點探索是好事，那麼更多的探索是不是要好得多？
這就要說到假設檢驗。
假設檢驗（又稱爲假設驅動測試）的靈感，來源於史上最偉大的實驗室：自然演化。自然演化不會假裝自己可以預測未來的樣子。它只是以頻繁實驗來應對變化。產生好結果的實驗，其獎賞是更長的壽命。糟糕的結果很快就會導致屈辱的滅絕。如果我們願意放棄自己的預測式思維，就能從自然演化中學習到很多。
使用假設檢驗，我們就能採用更深思熟慮的做法，而不是單純依賴演化的隨機性。面對未知情況，我們就像科學家一樣：形成某個假設，然後在真實世界中度量、失敗。如果它是可以被證僞的，但還沒有被證僞，至少目前如此，那麼它就有價值。
實施假設檢驗有很多方法[8] [9] [10]，不過這裏有一個簡單的例子。我們形成一個假設，比如“我們相信，客戶在數據門戶上需要方便左撇子可以用的小部件。如果一週內門戶的流量可以增加 5%，我們就認爲這個假設是正確的。”如果假設正確，那麼我們就會在一週內看到至少 5% 的流量增加。如果沒有，我們就錯了，應該拒絕假設，同時有可能移除該功能。然後，我們調整該假設，或是考慮其他假設。討論如何完成假設檢驗已經超出本文範圍，不過文末的資源參考有一些文章鏈接，其中有手把手的例子和最佳實驗。
使用假設檢驗，我們放棄了預測將來的想法，不去想未來如何展開。相反，我們從底層開始，一邊往前走，一邊測試每個小部分，將資本風險降到最低，同時可以儘早減少損失。實際上，我們讓自己在智識上更謙卑，承認自己對未來的瞭解不足。我們可以接受：我們不知道自己不知道的事物，而且不太可能提前知道多少東西。我們只能藉助實驗去探索。
更重要的是，假設檢驗可以儘可能減少前面提到的偏誤，不再讓它們耽誤我們的學習。有了假設檢驗，我們掙的錢就是靠學習得來的，而且可以使用客觀數據來驗證或是證僞我們的想法。我們將沉沒成本降至最低，因此就不太可能抱着錯誤想法不放。我們藉助隨機性輔助學習，而不是欺騙自己尋找並不存在的獎勵。有了客觀數據作爲度量工具，魅力型人格就沒那麼有影響了。最後，大家認可錯誤是一種正常狀態，也是實驗的一部分。實際上，我們使用的是基於證據的決策系統，而不再是依靠全知全能或者迷信。
我們可以進一步讓自己免於偏誤，這需要針對假設可以使用的資本，施加嚴格的、一致的限制，同時要求在短時間週期內驗證它們。否則，我們就又回到了老路上：需要“再多那麼一點點時間”，或是“再多那麼一點點錢”。自然演化不允許這樣的豁免。歸根結底，我們需要判斷：是想自己“正確”，還是要賺錢。有時候，我們想達成前者，而口頭上說是要追求後者。
不可否認，這種方法不會激發能讓鼓舞人的激情演講，比如前文預測式方法的“全速前進”！相比而言，“咱們做個實驗吧”，聽上去不那麼熱血澎湃。但這麼做有可能帶來更多利潤，也許這樣自有其鼓舞作用。
常見的錯誤策略
親愛的勃魯託斯，那錯處並不在我們的命運，
而在我們自己。
莎士比亞《裘力斯·凱撒》，第一幕，第二場（譯註：朱生豪譯本）
也許我們在自己的行業裏選取了有偏差的例子，只聽到噩夢般的預測和規劃，而無視成功案例，從而使我們相信，噩夢場景比比皆是。可是，這麼多年來，有這麼多人講出這麼多故事，看來那是可以代表很多工作環境的。其中含有最差的選擇，幾乎必將帶來失敗的結果。
事情是這樣發生的。我們有一個泛泛的、很是模糊的目標，諸如：“明年網站帶來的收入增長 10%”。抑或是更明確的：“在我們的數據門戶上加入一個左撇子用戶的小部件，因爲客戶會爲之買單。”不管是什麼，它經常沒有明確說明，在前提之下的假設只是假設而已，沒有依據。當然，只要我們開始幹活了，任何隱藏的細節都會跳出來。我們在過去開發過類似功能，但是，關鍵在於，我們過去沒有做過完全類似的事情。但這作爲預測的依據就已經“足夠好”了。然後，我們就有了一個，或者兩個，開發人員做出預測，跟隨意的瞎猜差不多。然後，我們就開工了。在預測性的工作環境中，常常是這樣的：
經理：開發那個小部件需要多久？
程序員：我不知道，大概一個月吧。
經理：什麼？開玩笑！不可能需要那麼久！
程序員：呃，好吧，也許我一週能完成。
經理：這還差不多。我會放到日程表裏。下週做吧。
在敏捷環境中，差不多是這樣的：
經理：那個小部件的故事，你估計要幾個故事點？
程序員：不知道，也許是 13 吧。
經理：什麼？開玩笑！不可能那麼大！
程序員：呃，好吧，也許是 3 點。
經理：這還差不多。我會更新到待辦任務列表裏。下個衝刺迭代做吧。
這跟處於強大壓力下的瞎猜差不多，而且會營造出最糟糕的情況：模糊的需求說明；沒有認真收集的歷史數據，無法勇氣做出用心的統計分析；來自一兩個程序員的武斷猜測，然後將猜測變爲承諾，要根據時間表交付。不但如此，一旦程序員無法交付，經理還有理由去“拿程序員是問”，而程序員沒有意識到自己給出的是一個承諾，而不是猜測，同時，程序員還會擔心受到懲罰，因爲怕自己的猜測變爲承諾後出現錯誤，這種擔心也是可以理解的。那麼，要是失敗不可避免，這還有什麼奇怪的嗎？唯一能夠按時交付的方法，就是砍功能、狂加班、舍質量。然而，吸取的教訓很少是：“這樣幹不行，我們得試試別的辦法。”相反，常常是：“我們得把預測做得更好。”
人們讓我們付錢做什麼，我們就會做什麼。如果要求我們必須用預測制定計劃，那我們就必須投入時間和金錢把它做好。如果我們使用敏捷方法，那麼交付可用的軟件必須優於做出預測。其他做法相當於希望天上掉餡餅。正如熱力學第二定律所明言：“世上沒有免費的午餐。”（譯註：熱力學第二定律是表述熱力學過程的不可逆性——孤立系統自發地朝着熱力學平衡方向──最大熵狀態──演化，也表明第二類永動機永不可能實現。來自維基百科。）
瞭解汝之環境
瞭解自己的業務開展的環境，很有必要。如果我們開發的是合同驅動的大型項目，時間表已經展開，而且需求已經明確定義，那麼定量的預測是生存的必要條件。然而，要是我們身處的環境更常見，需求模糊甚至不存在，市場需求不明確甚至是未知的，時間要求很短而且緊迫，市場份額的競爭很激烈，那麼我們就應該考慮使用假設檢驗方法。
關鍵問題在於，我們常常誤解自己所在環境的底層數學邏輯。我們常常相信，自己處於決定性的世界，付出更多努力就能得到滿意的結果。實際上，我們常常是在非決定性的、高度實驗性的世界中，它的基礎不穩固，會隨時間變化。統計學家稱這樣的問題有“非平穩基數”（non-stationary base），也就是其基本數學邏輯不穩定，而且沒有可以落地假設的基礎。在這些情況下，固定的、決定性的方法無法成功，除非有十足的運氣。由於上面列出的各種偏誤，我們幾乎無法抗拒這樣的想法：我們可以預測並規劃，即便實際上做不到。
然而，如果我們不是處於穩定的情況中，那麼付出更多努力預測，就會讓我們更加相信它的準確性，而不是去改善準確性本身。這樣一來，我們就更仰仗自己的智慧，而不是選擇自己的疑問。我們更傾向於付出更多資本，以此證明我們的正確，而不是小心保護我們的資源，並且只在數據告訴我們方向正確的時候再去運用這些資源。
瞭解我們所處的環境，意味着薪酬激勵要與在這個環境中成功產出結果的工作方法相一致。我們應該因爲學習而受到激勵，無論學習在環境中如何體現。
結語
預測的關鍵困難，在於我們人類不願意接受不確定性。處於不確定狀態中，並由此產生疑問，這讓我們極爲不適。因此，我們更傾向於擁抱那些信心滿滿的人，而不是聳聳肩、更願意做實驗驗證假設的人。
身邊的現實情況是：商業環境常常受制於不確定性、未知的未知因素，還有我們必須依靠最微弱的光芒才能看清方向的黑暗。我們的挑戰在於，接受這個環境令人不安的本質，而不是抱着某些舒適的想法不放，這些想法讓我們更安心，但卻充滿誤導。
通往知識的路是由不確定性鋪成的，必須擁抱它們，才能獲得知識。只要我們可以接受它們的不適，就能打開學習之路。改換一句名言：恆久不適乃學習的代價。（譯註：此處針對的名言爲：
恆久警惕乃自由的代價。Eternal vigilance is the price of liberty. ）
作者介紹：
J. Meadows 是一位技術人士，有數十年軟件開發、管理和數值分析經驗。作者會不時爲 InfoQ 供稿。
參考資料
[1] Standish Group 2015 Chaos Report.
[2] 《沒有銀彈：軟件工程的本質性與附屬性工作》
[3] ‘SUPERSTITION’ IN THE PIGEON", B.F. Skinner, Journal of Experimental Psychology, 38, 168-172.
[4] 《犯錯的價值》by Kathryn Schulz
[5] “A Gentle Introduction to Monte Carlo Simulation for Project Managers” by Kailash Awati.
[6] “Web-Based Monte Carlo Simulation for Agile Estimation” by Thomas Betts
[7] “The Scrum Primer” by Pete Deemer and Gabrielle Benefield.
[8] 《如何實現假設驅動開發》 by Barry O’Reilly
[9] “Why hypothesis-driven development is key to DevOps” by Brent Aaron Reed and Willy-Peter Schaub
[10] “Hypothesis-driven development” by Adrian Cho