作者認為系統思考高於前幾篇所說的四項修煉。少了系統思考，就無法探究各項修煉之間是如何互動。

到底什麼是系統思考? 簡單的說，系統思考是讓我們「看見整體」的一項修練，它是一個架構，一個系統，能讓我們看見相互關聯而非單一的事件，知道事情漸漸變化的因果，看見事情慢慢發生的形態而非瞬間即逝的一幕。

學會系統思考的最大的好處，是我們看事情看得更清楚了。

舉個例子，「大象愈保育，大象就愈被屠殺」這是為什麼? 我們來瞭解分析一下
因為你愈保育大象，市場上的象牙就愈少，象牙價格就會變得非常高，象牙價格最高的時候在黑市一對要12,000美金，但在非洲有許多人家一個月的收入不到6美金。原先他只看到一隻大動物把他家玉米田踩壞，覺得很討厭，可是他現在看到的不是大象，而是一堆黃金。試問是誰讓大象產生致命的吸引力？

像這樣的思考方式，沒有經過長時間的訓練，就不會知道問題的背後，是很多系統關連在一起的，並不是只看到片面所採取的「症狀解」能解決的。

短時間要培養出系統思考的觀念是不容易的。我上週五給我團隊成員一些建議:
①去看大型系統的程式碼
其實本公司的系統並不算大型。在以前不管是C社或H社都看過比這更複雜的系統的程式碼。當然這是要靠點運氣，但事實上這是你的選擇；你選擇到大公司看大型系統，當然小公司也有可能有大型系統；但不管如何，第一份工作很重要，你要從第一份工作學到你未來做系統思考的養分。

你甚至可以試著去改改看大型系統，改個小地方你就會發現牽一髮而動全身，而不得不強迫自己去看整個系統的架構，才有辦法去改。

②去改別人的code，即使是legacy code (或跟別人做side project)
我發現大部分同仁，看到一群雜亂的code，通常會選擇直接砍掉重練，用自己的方式在重新寫一個。但我認為這是在逃避問題，且失去一個關鍵的學習機會；團隊成員會覺得我debug為什麼這麼快，但羅馬不是一天造成的，最主要的原因是因為我看過太多legacy code，做過不少與人協同的side project；不要只看眼前光鮮亮麗的一面，要知道你要練習一件事情，成為該領域的專家，不五年十年的下苦功是不可能的。

(from gary vaynerchuk 中文粉絲頁)

③系統思考很吃經驗，請模仿資深同仁思考方式
再一次強調，一間公司的資深同仁是非常寶貴的，因為經驗這件事情，沒有捷近。如果公司內部有較多的資深同仁，他們有的甚至待過好幾個不同部門，除了技術上的指導外，還能協助到新進同仁，去如何跟其他部門的溝通，加快新進同仁融入整個公司的文化。

因此在新人剛近公司的時候，我就安排了資深人員為該新進人員的導師，並且在座位上做出調整，讓帶新同仁的資深人員能夠及時的與其做pair programming和code review。

對於新人，每天的下午2:00我們會進行pair programming or code review。並且要求他們不要急著先寫code，而是要懂得去例用一些工具做系統分析，比如利用Mind Map or UML，慢慢培養他們系統思考的能力。

這過程要不斷地Reps. 記住，It’s a process.

然後當分析到對需求越來越清晰的時候，就能讓他們自我覺察到關鍵的點，也就是找到槓桿解。

Peter Senge在書中這樣解釋槓桿解，如果一艘大船要緊急向右轉，如果在船頭打舵，會因為高速航行的慣性以及水的阻力、船的重量等問題，難以讓船轉向。最有效的方法，其實是在船尾打小舵，打相反方向，便因為槓桿原理，龐大的船身反而得以轉彎。

另外還有一個「充滿垃圾的教室」的例子。大家國高中時代一定有過，地板上的垃圾不知道是誰一開始在丟的，大家都覺得那不關我的事，於是垃圾越來越多，少數有公德心的同學一開始會去主動打掃，但掃了幾次之後，垃圾反而變多了，最後變成熱心的同學如果不去主動打掃，還會被一些同學指責：「你怎麼不掃認真一點？」

這跟剛剛大象保育是一樣的，不了解系統，不去找根本解，永遠針對症狀去解決，產生再復發再解決的惡性循環迴路(捨本逐末基模)。上述這兩個cases的根本解，其實都在教育本身，但教育可長可久，可能至少五年十年才會發生變化的事情，但這不代表不需要做，今日的問題來自昨日的解，如果當初就先想到奉行根本解，五年後的今天就不會是原本的惡性循環。

在引導團隊成員做系統思考的過程中，除了讓他們自行練習體驗到失敗挫折，別無他法。以下是今日與新進同仁之間的引導case。

「如果在多頁籤的狀況下，切換pagination來置換table的內容，pagination的current page index應該要被重新設定。」

我:「你打算怎麼做?」(探詢)

「我打算在table裡面多增加一個state來紀錄現在是在哪一個頁籤，或者是再增加一個table B來負責另外一個頁籤的顯示。」

我:「你覺得這樣有達到元件共用?」(觀點)

「好像沒有…。」

我:「那要不要試試看從最上層的頁籤傳入props給table，再去把pagination的default index改成first page?」(核對觀點)

「…不太明白。」

我:「沒關係，你試著去思考我剛說的那句話，並朝向元件共用的思考方式進行。」(釐清觀點，重整根本解)

「現階段都在繼續做需求的分析。要使用哪一套library已經有了底。」

我:「很好，Mind Map也做的很完整。預計何時可以決定要使用哪一個library?」(給予系統分析上的鼓勵，push他朝這個方向前進)

「嗯，明天應該可以。」(核對時間)

我:「每個項目的check point時間，你可以用excel或任何甘特圖的工具畫出來。方便你自己做安排。」(給予方向)

我:「把項目列出來並安排好時間的好處，主要是為了讓自己先知道未來兩個月的時間，大概能夠完成哪個項目，如果前面的幾個check point已經miss了的話，就要重新再評估(refinement)之後的任務，是否有些要從這兩個月要做的item中拿掉，或者有哪一些其實並沒有像當初評估的那麼困難，而可以提早完成彌補之前已經miss掉的任務的時間。」(釐清觀點，重整根本解)