第1章引言—繫統化（軟件）創新1
1.1軟件創新簡史5
1.2軟件工程—問題是什麼10
1.3七根完美的支柱16
1.4本章小結23

第2章七根完美的支柱之一—完美25
2.1收益、有形和“足夠好”26
2.2定義“完美”，發現矛盾34
2.3為什麼我們要獲得完美40
2.4完美和“從哪入手”的策略42
2.5自我45
2.6我該怎麼做46

第3章七根完美的支柱之二—擺脫48
3.1大腦不是為創新而設計的49
3.2三種不同種類的心理慣性53
3.3打破思維定式62
3.4擺脫思維定式的工具68
3.5我該怎麼做79

第4章七根完美的支柱之三—資源81
4.1發現未利用的資源83
4.2變廢為寶88
4.3杠杆91
4.4趨勢跳躍98
4.5某人在某處已經解決了你的問題108
4.6我該怎麼做115

第5章七根完美的支柱之四—功能117
5.1為什麼朝著現在的方向前進118
5.2功能和屬性分析125
5.3技術替代—專利規避設計134
5.4我該怎麼做135

第6章七根完美的支柱之五—湧現137
6.1流：從哪裡創新141
6.2修復：認知映射147
6.3修正：錯誤分析152
6.4進化：緊急矛盾166
6.5我該怎麼做170

第7章七根完美的支柱之六—矛盾173
7.1解決矛盾很簡單179
7.2解決矛盾並不簡單183
7.3工具187
7.4效率策略202
7.5我該怎麼做209

第8章七根完美的支柱之七—烏龜211
8.1通用S形曲線213
8.2復雜性先增長後衰減218
8.3結果遷移222
8.4裁剪226
8.5我該怎麼做228

第9章非連續的繫統化流程230
9.1當我們解決創新問題時會發生什麼231
9.2連續的“繫統化創新流程”236
9.3自校正240
9.4我該怎麼做244

第10章案例和場景246
10.1案例研究1：語音識別249
10.2案例研究2：Design4Wow網站256
10.3場景介紹264
10.4測試264
10.5再一次強調需求多樣性法則270
10.6度量272
10.7我該怎麼做277

第11章總括278
11.1現在要做什麼279
11.2將這種方法傳授給他人285
11.3常見問題292
11.4我該怎麼做294

第12章預測未來296
12.1真實世界—萬物理論301
12.2繫統完整性法則304
12.3繫統軟件創新策略315
12.4軟件創新工具和過程320
12.5我該怎麼做322
附錄1問題定義模板325
附錄2資源清單333
附錄3不間斷的軟件進化趨勢343
附錄4軟件矛盾矩陣372
附錄540個發明（軟件）原理與實例398

“人有時會被真理絆倒，但大部分人爬起來就趕快走開了，對絆倒他的真理視而不見，就好像什麼都沒發生過。”
—溫斯頓·丘吉爾
我寫下了第100段Fortran代碼。這段代碼屬於一個軟件，該軟件用於給工程師提供一個設計工具，讓他們能設計出模擬噴氣式發動機並使其“飛翔”。當我次完成這個軟件時，總代碼不到500 KB。2001年，我們簽訂了一份對該軟件進行升級的合同，主要是添加一個友好的用戶界面以及一兩個新功能。從理論上講，這個工作應該8周完成。個項目組（具有數十年軟件編程經驗的傑出團隊）決定在原來的Fortran核心代碼上建立圖形界面。20周過去了，項目組反饋說這種策略並不奏效，說需要重寫全部的Fortran代碼。隨後第二個項目組加入，又一個20周過去了，他們完成了優雅的35 MB的VB代碼。雖然這份代碼很優雅，卻仍不奏效。當我們考慮是否就此終止這個項目時，項目組又請求延長幾個月。4個月以後，我們依然一無所獲。隨即第三個項目組加入，這個項目組較之前兩個項目組甚至擁有更多的經驗，這些軟件高手說他們將在8周內完成這個項目。然而直到2004年年末，該項目依舊沒有完成。在2005年年中的時候，後一個項目組宣布失敗。到現在為止，我們依舊沒有一個可運行的更新版。
這究竟是怎麼回事？在1985年那個計算機不發達的年代，我究竟寫了什麼東西，以致三個不同項目組都無法復制？要知道這三個項目組都是由極其聰明的成員組成的，並且每個成員使用的工具都很復雜，問題究竟出在哪裡？我倒希望是因為我是個天纔。然而事實並非如此。簡單的事實是我和這三個項目組之間有兩個明顯的不同：，在我所處的編碼年代所有軟件資源都短缺，我不得不對算法進行巧妙構思和優化；第二，我對噴氣式發動機的知識稍有了解—這也是出問題的更重要的原因。本書主要是關於這兩個問題的：巧妙的構思和領域知識。
1985年我的個Fortran版本是在打孔帶上完成的。本書的大部分讀者恐怕從來沒聽說過打孔帶吧？個版本中的每一行Fortran代碼都用一張打孔帶表示。看到地上堆著2000張那樣的打孔帶，頓時就會有種崩潰的感覺。在那種條件下，能夠有效緩解這種狀況的，就是結束一天的工作後打掃地板的人，他會將地板上堆積的打孔帶清理干淨。因此，在忍受著制作和處理那些打孔帶帶來的痛苦時，我產生了一種強烈的需求，那就是盡可能使用較少的數字，而且我需要非常清楚每張打孔帶是如何和其他打孔帶相關聯的。人們常說需求是創新之母。不幸的是，這並不完全正確，但和早期的軟件設計思想息息相關。在成堆的打孔帶帶來的痛苦和苦惱的驅使下，我產生了強烈的需求，即用巧妙的構思來解決問題。沒有人希望再次使用打孔帶，人們的所有痛苦都隨著可用的內存空間以及處理器速度的快速增長煙消雲散了。因此，巧妙的構思對於我們來說也不那麼重要了。不必擔心代碼運行過慢，因為在3個月內就會有新一代芯片問世。科技的進步固然重要，但本書討論的個主題是，科技從來不是，也不會成為軟件工程的終極目標。我依然認為，在某些方面，巧妙的構思仍占有一席之地。
過度依賴工具是一個巨大的陷阱，但還不是的陷阱。根據近幾年我與許多世界的軟件從業者共同工作所積累的大量經驗來看，的陷阱是習慣於將軟件行業看作一個封閉的領域。封閉的領域意味著可以獨立工作並且與現實世界分離。毫無疑問，這是那個噴氣式發動機項目失敗的主要原因。建立一個虛擬的噴氣式發動機模型很簡單，但是建立一個與現實世界的物理現實相結合的虛擬噴氣式發動機就有點復雜了。現實世界充滿了很多難解之謎，像物理和化學、機械壓力和材料溫度限制，以及可操作性、可靠性、魯棒性。如果一名軟件工程師認為他不需要知道這些，必將會導致的結果，那就是帶來麻煩。
以噴氣式發動機建模來舉例可能有點，但它卻代表了所有軟件項目的全部相關特征。確切地說，某些情況下軟件工程是需要與外部領域交互的，無論這個外部領域是基於硬件定義的，還是由用戶定義的，或是由另一個軟件定義的，在某個地方都會需要一個接口，而這個接口恰好就是軟件初存在的主要原因。而且，在我與軟件工程師一起解決大量問題時，工程師們經常抱怨我們想出來的解決方案不屬於軟件範疇，從而終止與我們合作。可是如果這樣的問題不能算作軟件範疇的問題，它又能算是什麼問題呢？
本書完全是關於軟件問題的。決定一種情境是否屬於軟件領域的步就是了解這種情境。因此本書的大部分內容是幫助讀者去了解情境。一旦構建了某種可以通過軟件進行改變的情境，本書的其餘部分便會專注於幫助大家找出好的可行方案。這裡的“好”指的是巧妙而可行。
歡迎來到另外一個世界。