沒人想交付延遲的、超過預算的軟件，我從沒見過一個軟件開發者會大早上起床后心里想著“我就想把工作干得很差勁，我怎能讓老板花更多錢呢？”但是，有太多的軟件項目進行得都并不順利。而且對于每一個新項目來說，似乎在加快軟件開發速度方面的壓力變得越來越大。所以，如果我們正在從事軟件開發的工作，那么我們應該怎么做呢？我們應該如何在不降低軟件質量的前提下加快開發速度呢？

雖然歷經 50 多年的歷史，已推出無數方法、建議和書籍，但是 IT 項目仍總是經歷失敗。——Susan Moore [1]

現在，我不是以某種專家的身份在這兒寫東西。我從沒運營過自己的軟件公司，也沒傳播從豐富的學術研究或對照實驗中提煉而出的理念，我寫這篇文章是為了組織我自己的想法，因為我想要設法了解我所看到的周遭所發生的一切。

為了正確地看待此事，我們首先需要搞清楚為什么要開發軟件？所有軟件生產的意義是什么？我們為什么最開始要做的就是開發軟件？咱們暫且把開源當做房間里的大象擱置一邊，先來探討一下商業軟件。咱們先從生意說起。

生意就是指減少客戶的痛苦

按照我的理解，為了達成一筆成功的交易，我們首先應該找到使人們痛苦的東西（找痛點），可能是一種隱喻形式的或字面形式的痛苦（但通常是隱喻形式的），然后我們以錢作為交換，為他們提供減少痛苦的方法。例如，人們發現編程很難（很痛苦），所以開辟了編程書和編程課的市場；有些人不喜歡他們自己的外表，所以帶動了健身、化妝品、美容等等整套完善產業的發展。生意從某種程度上給客戶傳達的觀念是它們可以減少客戶的痛苦（或對痛苦的感知），而且如果人們相信我們可以減少他們的痛苦，那么他們就會很樂于給我們付錢。

在軟件產品業務中，軟件就是我們用來減少客戶痛苦的東西。對于這種類型的業務，軟件開發就是提供價值的關鍵環節�？蛻糍I（或訂購）一件產品，那么軟件開發這一環節負責把它開發出來。當然，這只適用于產品業務。如果我們把咨詢服務或IT作為一種支撐功能進行售賣，那么情況就會有所不同�？墒堑�凡主要核心業務是軟件產品的，那么完成該業務的手段就是軟件開發。

這不是說軟件開發就是增加價值的唯一方式。例如，要是沒人知道我們的產品存在，那么還不如說它真的不存在呢，所以產品的營銷和推廣活動也是至關重要的。我們也需要確保我們的產品實實在在解決了客戶的真正痛點，否則，我們就是在浪費時間，所以市場調查（無論是正式的還是自組織的）同樣是非常重要的。產品中的摩擦是我們解決客戶問題時的攔路虎，我們也需要用戶體驗（UX）和圖形設計活動來減少摩擦，所有的這些活動（營銷、銷售、市場調研、UX、設計）都很重要，而且如果你略微瞄一下，它們看上去都挺相似。它們就好比同一個核心活動的不同方面，這個核心活動就是理解他人。但是歸根結底，所有的這些活動只為客戶價值提供計劃和承諾，而將所有的計劃和承諾轉化為實際的產品的則為軟件開發。[2]

當你接受了其實“產品”、“設計”和“工程”僅僅是同一件事的不同方面這種觀點時，事情便都會進展得更好。——Greg Veen

將開發時間對業務的影響最小化

如果我們能夠很好地做到“理解他人”，那么軟件開發這項活動就能穩步推進。在軟件開發過程中，我們會更加了解那些我們致力于解決的問題，所以我們可以開始設計更優的解決方案，因而我們創造的軟件產品也需要有所改進。為了實現此目標，我們需要一支敏銳的開發團隊、一支可以快速傳播價值并且迅速應對變化的團隊，這是軟件開發實踐中的核心目標。正如 Dan North 指出：

“軟件開發的目標是持續盡力降低軟件開發時間對于業務的影響。”——Dan North[4]

所以，擁有一支敏銳的開發團隊至關重要。但是如何能夠擁有一支敏銳的開發團隊呢？你會：

• 將開發者像王一樣供奉？
• 給他們買超快的、昂貴的計算機？
• 把他們送到任意他們想要參加的瘋狂科技研討會？

我們有很充分的理由做任何這種事：如果你想要維系你那支敏銳的開發團隊，那么就要對團隊中的每個人都認真上心。運行快的計算機和優良的科技研討會使開發者表現得更好，這種對開發者的投資總有一天會得到回報。但是這種投資對留住優秀的開發者更有用，而我們想要組建的是一支敏銳的開發團隊。

所以如果不給開發者提供他們所想要的，那么我們該做什么呢？簡單的答案是，去問開發者。但是，請在合適的時間，用合適的方式問他們。我們需要理解的一點是，開發者往往是天生的問題解決者。優秀的開發者熱愛他們的工作，熱愛的原因是他們整天能解決有趣的、復雜的難題，并且能夠因此而掙錢。優秀的開發者陶醉于迎接復雜的挑戰并且找到簡約漂亮的解決方法。所以他們應該能想出精彩的點子以變得更加敏銳。但是許多組織鼓勵開發者專注于錯誤的問題，這種鼓勵可能既不是深思熟慮的也不是有意而為之，但是卻時常發生。

專注于錯誤的問題

這是怎么發生的？我們怎么可能甚至不知道自己在做錯事，以至于最后讓開發者專注于錯誤的問題呢？因為我們將開發者從消費者身邊拉開。一個項目一有任何合理的規模，我們就會找來項目經理和業務分析師。[5] 我們拉來這些人是出于一個非常好的理由——開發者無法完成所有的事。軟件項目是復雜的，代碼已經夠復雜了，但是另外更重要的是，還有各種工作諸如決定構建的內容、規劃開發的階段、制定推廣部署的計劃、聯絡客戶……不一而足。代碼已經夠讓開發者操心了，所以我們需要這些額外人員來幫忙。

但是，這樣做使得這些額外人員成為了開發者面向世界的接口。與外部持股者進行協調溝通的是項目經理和業務分析師，尤其是項目經理非常在意項目的交付。項目經理向管理部門匯報情況，管理部門關心的是：

• 項目需要耗費多少資金？
• 項目需要進行多長時間？
• 為什么項目需花費這么多資金？
• 為什么項目拖延到這么晚？
• 為什么項目還沒有完成？
• 我的天哪，這個項目拖到這么晚每天需要燒我們多少錢？

于是我們可以理解為什么之后項目經理開始變得專注于預測項目了。他們想要計劃、結構、評估，他們想要知道什么時候在發生什么事。當他們向管理部門匯報的時候，所做的預測和估量會讓他們顯得更稱職，所以他們才會向開發者探討預估、報告和截止日期。所以之后，開發者開始專注于預估、報告和截止日期，他們將精力集中在這些預估和預測性上來讓取悅項目經理。

但是這樣做有一點不如人意的是，預估和預測性都是不可能解決的問題。每次一個開發者開始著手一個新任務時，他們就面臨一個不安的事實：任何一個給定的任務背后都可能有一個潛在復雜性的大坑，也可能沒有。我們都希望任務是簡單的，但是它有可能并不簡單，你永遠都不會知道。這時霍夫史達特定律就起作用了：

霍夫史達特定律：事情總是要比你預期的花費更長的時間，甚至當你把本定律考慮在內時也一樣。——Douglas Hofstadter[6]

考慮這種情況：

一個項目經理向一個沒經驗的開發者問項目的估算，這個沒經驗的開發者告訴了一個他們認為合理的估算，然后項目經理回去根據估算情況得出截止日期和相應的計劃。優秀的項目經理為穩妥起見，甚而會在此基礎上加上一點“富余”。但是之后不可避免的事情發生了——項目落后了。所以開發人員開始為趕在截止日期到來之前完成任務，開始加班加點地工作。但是長時間的工作使得開發人員疲憊不堪，他們便開始犯更多的錯誤。而且不僅如此，項目仍然在落后。項目經理需要知道到底是什么耗費了這么長時間，所以苦惱的開發者圖省事，開始投機取巧偷工減料，這一過程中，程序漏洞源源不斷地出現，所以此時產品不僅延遲了，而且漏洞頻出。

這種情況傳達了一種消極的客戶價值。當然這種延遲的、漏洞頻出的產品可能仍然能夠解決某種程度的客戶痛苦，但是這些漏洞帶來了新的痛苦，這又需要耗費時間來進行修復，這樣客戶就會對我們可以幫助他們的能力喪失信心，這使得他們更不想為我們付錢，到頭來無人從中獲益。

經驗豐富的開發者知道這種估算是不公平的，所以他們盡其所能不蹚這灘渾水。

想象一下，

一個項目經理來找有經驗的開發人員問預算，開發人員便會回復他一個大到離譜的數據，但同時又小到使這個項目還不能立馬被取消。接下來，項目經理（銷售人員）回頭開始質疑這個荒謬的數據：“那個預算看上去比我們希望的多一點，我們有沒有可能縮減一下，讓預算少點？”這時，有經驗的開發者便會問：“我們著手需要的預算是多少？”銷售人員回復他一個數，然后有經驗的開發者揉揉她的下巴說：“預算有點緊，但是我們會盡量做。這樣的話我們難以滿足所有要求，只能提供最基本的性能。”然后她會在自己看上去不會不稱職的前提下，預估他們可以承諾交付的是多么有限，并且這是她可以承諾的所有。這樣的話，如果她最后交付的比自己先前承諾的更多，那么每個人都很開心。但是甚至在這個情況下，霍夫史達特定律還是會出現，過不了多久，我們就會像從前一樣，在趕最后期限、交付低質量代碼的泥潭中苦苦掙扎。

預算是軟件開發過程中一項必不可少卻令人生厭的東西。不幸的是，人們往往以為編軟件就像建房子或修車一樣，承包商或參與的機修工在客戶審批工作前，應該能很好地對要完成的工作提供一個可靠的預算。[……]然而對于定制軟件，很多系統都是從零開始搭建，而且通常組裝、最終運行、應實現的功能、完成的時間等等都在隨時發生變動，因此在工作之初，你要選的方法和最終達成的效果都是不確定的，所以很難知道到底什么時候可以完成。——Steve Smith[7]

我這兒的觀點不是說要抱怨軟件預算，大家都知道它雖然令人生厭但又十分必要，就怪這種軟件預算會陷入一種惡性循環。為了趕截止日期，我們投機取巧偷工減料，交付低劣的代碼，還一直互相保證我們過后終將回頭將代碼進行完善，但是“過后”再也不回來。如果我們回頭修復那些漏洞的話，我們就已經在下一個階段中又落后了。所以我們構建的一切都建立在脆弱的、雜亂一氣的代碼上，這些代碼難以應對快速的變化。而且一旦困在這個循環中，那么開發者的注意力將難以繼續集中在解決客能戶痛苦上，相反，他們將會專注于諸如以下的問題上：

• 有什么可能的方式能使我們最快地將任務標為“已做”并且讓項目經理不要再煩我？
• 我怎樣才能盡可能少接觸脆弱的代碼呢？因為這些代碼我接觸得越多，它們崩潰的可能性越大。
• 我怎樣才能在這筆巨大而過火的技術債務中，竭力維持讓我引以為豪的那一小塊代碼呢？
• 我怎樣才能向那些不知道我在干什么，或者不知道問題的復雜性的人們證明我的決定是對的呢？
• 當客戶開始抱怨那些我沒有時間修復的軟件漏洞時，我怎樣才能將責任推到其他人身上呢？
• 我怎樣才能在我的簡歷中加入一些流行語，幫我另找一份不這樣混亂不堪的工作？

我沒見過有開發者想要交付一份延遲的、滿是漏洞的軟件，但是我們因為想要他們速度放快，所以給開發者不斷施壓。他們為了取悅我們也答應照辦，但是由于預估往往是錯誤的，所以導致他們深陷泥潭，在重壓之下交付軟件。他們為了取悅我們，加班加點工作，但又在軟件開發中偷工減料。因為大家一直在催問他們“完成了嗎？”使得他們在軟件質量上做出妥協。最終沒有人開心，軟件仍然拖延，仍然滿是漏洞。

所以我知道的大多數開發者都在工作中盡其所能，但卻深陷困境。他們為了趕進度忙得焦頭爛額，甚至連怎么變得“更快”都顧不上想。因此他們把精力集中在了錯誤的問題上，他們重點關注的是如何讓自己活下來。好比當你餓得快要死了的時候，你很難再去關注為退休攢錢的事兒了。也好比當你因為一個延遲的項目一周連續工作七天后，你很難再去計劃怎樣才能做得更巧。所以第一步應該承認，想要項目做得更快就需要投資，而且如果事情進展不順，那么也同時需要時間/財政投資和情感投資兩項。

打破這種惡性循環

之前，我建議去問問開發者怎樣才能減少軟件開發時間對業務的影響，但是當開發者處于“趕進度”模式時，我們不可能得到從他們那兒得到很好的回復。當我們進入這種環境問道：“我們怎樣才能開發得更快？”可能會得到兩種回復中的一種：

1. 用火燒了它。

“我們需要出走兩年，然后重頭再來。”這種情況通常在開發者已經被技術債務徹底壓垮時發生。技術債務太繁重了，所以他們感覺唯一的出路就是宣告破產。他們這樣做可能也有一定的道理，但與此同時，我們可能并沒有相應的預算作為支撐，而且當我們過后重建的時候市場必然不會一成不變。

2. 憤慨。

“我們已經開發地更快了，我不敢相信你竟然覺得你只用半個小時的頭腦風暴就能修復這個復雜的問題！你怎么敢？！”這種情況通常在開發者覺得自己被迫發行低質量代碼時發生。他們感覺當客戶抱怨漏洞時，自己受到了客戶的譴責。而且他們的憤慨很可能是有一定理由的。開發者懷著這種心態是不會幫我們的，除非我們可以向他們表達我們聽到了他們的心聲。他們需要知道我們理解他們的顧慮，我們同樣也需要表明我們正在嚴肅地考慮做一些改變。

在以上兩種情況中，開發者的顧慮是正當的，但他們只關注了自己。我們希望創造一種每個人都為將軟件開發時間對業務的影響降到最低而努力的環境。如果開發者不能擺脫這種心態的話將難以達成以上愿景。一切策略開始的前提是，向他們表明我們正在嚴肅地考慮做一些改變，這通常包括尋找減壓的方式，即使那只是暫時的。

但是即使這樣，開發者仍然只會關注自己，除非再做一些改變。他們關于如何提升自己的工作成效會有大量的主意，其中一些想法可能很不錯，但是有風險。我們需要讓開發者轉移對自身壓力的關注，而將注意力集中在將軟件開發時間對業務的影響降到最低上。我們需要讓他們直面客戶痛苦。

使開發者直面客戶痛苦

我們接下來該如何使開發者直面客戶痛苦呢？不計其數的人已經對此寫過詳盡的文章，所以這里我只是輕描淡寫一下。這兒按照從最低效到最高效的順序有三條觀點：

1.讓開發者將使用自己制造的產品作為他們日常工作的一部分。

這在業界被稱為喝自己的香檳，或吃自己的狗糧。這樣做的好處是使開發者變成了產品的用戶，所以任何明顯的錯誤或問題也會令開發者自己感到煩惱。這種方法存在一個問題，那就是開發者并不是典型的用戶（大多數時候）。開發者使用軟件的方式通常有別于大多數的客戶，所以盡管這樣可以幫開發者修復主要的漏洞，但是可能無法為典型的使用案例提供很好的見解，而且這也并非一直具有實踐性。比如說，假想我們正在為牙科保健員生產一個SaaS產品，這時開發者可能很難將這SaaS產品融入他們的工作流。

2. 讓開發者在支持團隊中輪班工作。

一個更佳的方式是鼓勵開發者參與到一些產品的支持團隊中去。（他們可能需要極強的鼓勵。）這張方式可以讓開發者親自體驗客戶痛苦。所以，他們接電話或收郵件（或推特，或其他種種）時，客戶告訴他們問題所在。開發者做這件事長達一定時間后，他們也將會開始發現常見問題的規律，他們會注意到一次次涌現的問題。無需重復聽那些相同的牢騷會成為修復軟件可用性問題的一大動力。不幸的是，人們幾乎不會聯系支持部門告訴他們產品運行得多么棒，所以得到的反饋是有點偏見的。

3. 定期讓開發者坐在用戶身邊，看他們是如何使用軟件的。

這種方法是最不方便的，因為它需要最多的組織進行協調，但這也可能收獲最好的結果。利用這種方法，開發者可以得知正常人是如何在現實生活中使用軟件去做實在的事的。他們能看得到好的、壞的和丑的。

長期持續這樣做是一件辛苦的事，需要耗費精力，需要進行組織,而且大多數開發者會對此有一種本能的抵觸。我寫這個感覺有點笨拙，因為雖然我理應做這件事，但我并沒有經常這樣做，但我相信值得付出努力做這件事。

使開發者直面客戶痛苦是一種用悉心努力克服認知偏見的訓練過程。這是一條“讓人學會謙卑”的漫漫長途。我們開發者往往認為我們要更聰明，而且許多開發者還要更加聰明，但是我們并不是無所不知。也許我終于搞清楚了一元綁定運算和操作組合的關系，這很好，但是這并不意味著我知道了我們客戶每天使用我們的軟件時會遇到什么。使開發者直面客戶痛苦提醒我們自己我們所真正了解的東西是多么有限。

在我的經歷中，開發者越孤立于周遭，生產的最終產品越差。大多數團隊層次中，有一層為業務分析師，他們認為讓開發者免于接觸用戶是他們的工作，反之亦然，其實這樣做是沒有用的。若創造了一個開發者對于用戶一無所知的環境，那么這種狀況是非常危險的。——Jeff Atwood [9]

現在，所有這種面向客戶的溫情舉措非常模糊，都存在一個明顯的問題。簡單來說，這并沒有讓開發者的開發速度更快。事實上，這奪走了本應該用來編程的時間，所以可以認為這反倒使得開發速度變得更慢。所以我為什么認為以上說法對呢？簡單來說就是如果你工作奮進的方向是錯誤的，那么開發速度的提升沒有絲毫意義。使開發者直面客戶痛苦重要的是方向而非速度。

咨詢開發者

我們想要可持續性地將軟件開發時間對業務的影響降到最低，我的假設是如果你為開發者指引了正確的方向，那么你可以在此基礎上咨詢他們接下來該如何做的意見。如果我們讓他們落實他們的意見，那么我們便應該能看到結果。

理想地來說，這是一個持續推進的過程。我們問開發者他們是否有任何能夠加快軟件開發速度的方法，然后我們對提供的方法進行試驗，幾周之后再回來，打聽進展狀況，繼而再去問開發者加速的方法。就這樣一直問他們，直到你每次你連問都不用問就可以直接進入他們的工作區域。他們于是開始這樣說：“我們所做的路由引擎的重構真的成果不錯。但是我覺得如果我們把那種邏輯的一部分移出來，放入微服務層，那么我們就可以更快地進行縫補和撕毀。”你可能并不知道那意味著什么，但是如果我們看到漏洞減少、客戶更加滿意，那么大家就都成為了贏家。

具體到你自己的團隊，用什么樣的方式詢問他們取決于你自己。有些人喜歡頭腦風暴研討會，另一些人更傾向于調研或一對一專訪。每種方法都有其不同的優缺點，但是無論你選擇哪種方法，請確保弄清了限制。如果你僅有一筆很小的預算，要明說。如果沒有靈活延長任何截止期限的余度，請告訴開發者。假設你擁有聰明的、能干的開發者，他們能夠把以上這些都考慮在內。而且如果他們沒搞明白，甚至在你多次解釋說明后仍不明白，那么你也從中學到了點東西……

務必在探討限制時小心謹慎。如果你告訴開發者沒有預算、截止期限是定死的、沒有一丁點回旋的余地……那么他們無疑將回復你他們無力幫助，這種情況下你應該格外小心。高質量軟件若想要提高生產速度，就需要花費金錢。開發者需要知道我們愿意為他們和他們的工具投資。如果沒有預算、沒有延長截止期限的余地、沒有情況好轉的跡象……那么聰明的開發者就會去考察其他方面，這種做法讓我喝彩。這是一種沒有勝方的局面，這種局面會吸引情感投資。向開發者展示我們在乎、并且愿意向他們和他們的未來投資,向他們解釋我們目前正處于資源嚴重受限的困境，這樣他們便可能會愿意想一些創造性的解決方案幫我們掙脫當前困境。

假設

我在這兒要做一個較大的假設，我假設當你向你的開發者解釋限制時，他們都很聰明，完全能夠理解。最大最顯而易見的限制就是我們并沒有無窮無盡的金錢去揮霍。開發軟件很費錢，遠比大多數人預期的或意識到的要多得多。好的軟件開發者得花不少錢去請。我在這兒的假設是有至少有一個或兩個聰明的開發者可以能夠理解以上情況。

可悲的是一些開發者就是不理解，那么你該怎么做呢？答案并不簡單，但是我推測開發者不理解的原因是他們從來都沒有機會以更大的眼光去看待問題。他們只被要求做去做不現實的預算和加快開發速度，并沒有從客戶或那些付他們薪水的人的角度去考慮問題。唯一使他們開始理解的方式就是有人展示給他們看。

我要做的另一個大假設當我們把開發者帶到委托人員面前時，我們相信他們不會讓公司難堪。當然了，也有很多次我和委托人開會時，開發者說了蠢話或宣泄不滿的情況，畢竟并不是每個人都做好了站在幻燈片前展示推銷游說本領的準備。但是如果我們相信一個開發者能夠僅禮貌地握握手打招呼，那么他們當然至少也能做到坐在一角，靜靜地看人們使用軟件？[10]也許他們需要有人首先能帶帶他們。但是如果從來沒被給過機會，一個人還能以什么方式去學做一個組織優秀的大使呢？

但是我離題了，咱們回到提升軟件開發速度上。

安全帶和引擎升級

咱么假設你的團隊里全是聰明的開發者。當你讓他們出主意時，他們可能首先想出許多聽上去是反直覺的東西，比如像：

• 測試驅動開發（TDD）
• 持續集成
• 結對編程或mob編程
• 代碼審查

所有的這些技術都會降低開發速度……TDD很像是完成同樣的結果卻用了兩倍的代碼量，而結對編程就像利用了兩個高產的開發者卻將結果削減了一半。我能理解一些質疑，但這不只是時髦的流行語（大多數的這些技術已應用了幾十年之久），它們自然有存在的充分理由。

讓我試著用類比解釋一下：當你開車時，你要系安全帶。近些天我們希望車能自帶安全氣囊和防撞緩沖區，但是當你想開得真的很快時，你要戴賽車安全帶、頭盔和防火服，我們還會將翻滾護架、氣流偏導器和粘型輪胎加到車上。這個類比不完美，但是希望你能明白我想表達什么。首先，一些諸如TDD和代碼檢查的方式會使你開發速度變慢，他們會變得笨拙，不易習慣。但正是這些保障團隊更加安全地加速進展。

我們非常確信當維護費用——許多時間和金錢考慮在內時，TDD節省了時間和金錢。——Eric Elliott[11]

像TDD和持續集成這樣的技術是關于提升軟件質量的，這意味著生產中會產生更少的漏洞。在漏洞流出前將其捕獲意味著會減少重做的次數、減少尷尬、更愉悅客戶。問題通常會被更快（耗資更少）得被修復。隨著時間流逝，不耗費在修復漏洞上的時間增加。另外，這些技術支撐下寫出的代碼往往更為靈活，更易改變或再用。這意味著我們可以花費更少的時間去對抗脆弱的代碼庫，能花費更多的時間去添加新的特征或修改功能。最終結果是軟件更好，開發速度更快。

加緊反饋環

這樣的要點是減少從寫代碼到交付客戶所經歷的時間。這樣的話，開發者可以觀測到新的代碼是如何減少客戶痛苦的。掌握了客戶反饋，那么他們可以進一步提升代碼等等，這樣我們就創造了一個良性循環。

我們的轉變就是從真實用戶那兒獲得反饋的時間大大減少。——Phil Wills[12]

如果你在過去幾年一直在追隨IT發展趨勢，那么對良性循環一定很熟悉。良性循環聽上去很像持續交付，但是這種流行語并不是重點。持續交付只是一套實踐的標簽而已。而且，這些實踐能夠提供緊湊的反饋環，反饋環能夠使得我們在提升速度的同時減少風險。

這樣做有一個很好的理由。我們所建立軟件的環境不僅麻煩而且復雜，一個麻煩的系統有許多部分，實則讓一個專家都要好好理解這么多的部分是如何結合在一起的。但是一個復雜的系統不僅僅有許多部分，而且所有的部分都彼此連接，相互作用。所以，當你改變了一小部分后，那么整個系統可能都會因而發生變化。一個經典的案例就是眼鏡蛇效應：

英國政府對德里的有毒眼鏡蛇數量非常擔憂，因此每捕殺一條眼鏡蛇，政府就會發放一筆賞金。起初這是一個非常成功的策略，因為很多人為了賞金開始大量捕殺眼鏡蛇。然而最終，激進大膽的人為了收益反而開始專門飼養眼鏡蛇。當政府意識到這種情況后，這一獎勵計劃便被取消了，眼鏡蛇再無價值，于是導致飼養眼鏡蛇的人只好將其放生，所以野生眼鏡蛇的數量進一步增多。[13]

在復雜的系統中，很難預測一次給定改變所可能產生的影響，這是因為做兩次相同的改變可能產生截然不同的結果，第一次改變能引起一定的系統反應，在下一次中會完全不同。這樣會導致非本意的結果，使計劃和預估出現問題。

理解復雜性的方式是，在空間中的動作會導致空間發生變化，而且原因和結果只有在回顧時才能被理解。——Liz Keogh[14]

那么我們在一個復雜的環境中如何設法去完成每件事？專家建議“探索、感知并且回應。”換句話說，創造緊湊的反饋環去評估哪些事能成或不能成。然后我們盡快重復此動作，保持小變化、短周期。因此，與失敗關聯的風險也控制到很小，恢復的成本也更低。我們要做很多小實驗，保留工作正常的，恢復工作失敗的。