速成的片段知識的三大危害

連本文同在內，網路上太多可獲取知識，這些知識有時候很片面，零碎而且片段。它在很多時候可以快速解決問題，有時候快速幫助你的生活(例如要找附近餐廳)。但是對於想要獲得完整的知識與歷練，片段的知識有很多危害。特別是快速地用google搜尋某個東西。

相關的研究早在2011年就有了->參考這裡

(1) 喪失組織能力

某些剛畢業的學生(特別是近五六年)明顯地不太能計畫以及組織事務。年輕的人一定有很多創意，但是創意要能夠實踐才有意義。組織事務，計畫事情的發展，了解問題的本質，這些都是優秀人才的必要價值。有了這些價值，才更能在創意上發揮。

當僅僅使用search engine來獲得快速解答的時候，常會喪失推理性，因果關係，組織事情等等必要推演狀態的能力。

因為，現在search engine解答方式是：

1. 有問題 -
2. 搜尋關鍵字
3. 點選前幾個結果看看

由於現在search engine的能力，讓前幾個結果能有"看似滿意的解答"的機率實在太高。

然而，以前在沒有search engine時的問題的解答方式是：

1. 有問題
2. 想一下什麼方案最有可能找到答案(問誰？，看什麼書？，自己嘗試什麼事情)
3. 選擇並執行方案

由於個人判斷力都有限，所以執行方案常有很大的機會找不到結果，然後就會再重新嘗試。這些失敗的過程並不單純浪費時間，每次的經驗會讓知識在腦中"內化"。這是search engine無法幫助的地方。

(2) 喪失記憶力

單純依賴google來獲得任何些許記憶的情況越來越嚴重，可想而知過於依賴會產生副作用。很多文章都已經闡明了這點->參考這裏

在這裡強調一下，並不是反對search engine，它的確是幫助人們進化的好工具，但是人們要能夠駕馭工具，而非被工具綑綁。

(3) 減低創意的靈光一閃

在腦袋裡要有靈光一閃，並不是這麼簡單，通常表示腦中有足夠的經驗，記憶，感受，知識，而在某種情況下匯流。換言之，如果完全依賴外部記憶體(google)，單靠到處搜尋是絕對很難獲取創意的靈感。更有甚者，即便偶有靈感，也會缺乏實踐的能力。

---

沈思

(a) 至少請先看這本書 Technopoly: The Surrender of Culture to Technology by Neil Postman 
Link: http://amzn.com/0679745408

他的立論完整，說明清楚，絕對不是片面知識:)

(b) 但是搜尋引擎(search engine, google)還是有很多好處，思考一下怎麼樣利用才是正確。

(c) 參考研究

如何做一個技術領導 精要版(整合三要素：事實/行動/領導力)

作為一個技術領導者(tech-lead)，要能夠透過技術能力以及領導能力，帶領一個1-7人小組完成任務。在企業趨於扁平化的時候，技術領導越顯重要。(或者稱之為小組長，team leader...等等)

技術領導者雖然不是這個小組的直屬長官，但原則上要帶領小組，突破困難完成任務。無論

處於何種階段，也無論團隊成員是怎麼組成。技術領導者首重需要了解以及考慮事實，接下來透過本身的技術能力以及領導能力，帶領團隊行動。

此模式，在觀念上簡單，只要有意識的朝正確的方向前進，一定能在有限時間裡達到成效。

FLA: Fact <--> Leadership <--> Action

參見下圖

(1) 技術能力以及領導能力

此為驅動FLA模型的最大變數，換言之，超強的技術知識以及有效累積的領導力，能夠驅使這個模型，但是儘只有微弱而不自知的技術能力，以及不太有效的領導力的技術領導，就只能靠運氣。

所以作為小組長/技術領導，第一件事情，應該是先評斷自己的能力。

技術能力評斷：最快速評斷自己的技術能力的方式是和小組內成員比較，如果可以確定小組內成員裡無論哪個人的工作，自己都能完全做到，在效率上一樣或者更好，則大致上沒有技

術能力問題。

然而，如果有少數人的工作自己無法完全做到，最好在最短的時間學習缺乏的知識技術。如果有多數人的工作，身為一個技術領導者無能力執行，最好考慮在能力提升之前不要做技術領導。

接下來是評斷團隊整體的現在能力，重視的是團隊一段時間真實的產出，換言之，考慮的是綜合起來的事實。

例如：一個五人團隊，在台灣2015年1月1日至 6月30日，實際最大可能的工作人月並非5x6=30人月，而是5x5.5 = 27.5人月(扣掉國定假期)，然而實際在考慮過去這五人平均請假天數，實際時間應該更少。另一個例子：這個專案決定以java開發，但五人之中有兩人有java開發經驗，另外三人則無。因此團隊能力第一個月的人力應該只有2個人月，第二個之後才可能會有2個人月以上的產出。

領導能力評斷：評斷自己得領導能力的最簡要方式是：回憶並列出過去不透過職位僅透過影響力主動帶領同仁完成過哪些自己認為重要的技術方面的任務。領導力的評斷帶有點想象力，但是自我評估仍然是實際經驗為依據：也就是技術領導者根據自己過去的記錄，列出有幾次帶領團隊解決困難的經驗；有幾次帶領並提升團隊能力的經驗；有幾次扭轉錯誤的經驗。根據這些來自我評估。

(2)事實：

特定的環境條件特定的時間點，事實就是鐵錚錚的事實。技術領導者要做的是了解現在的事實。

不過要了解完整，不缺細節的事實，在複雜的專案裡十分困難，有時候根本不可能。退而求其次只能了解重要的部份事實。

有限時間要透過自身的智慧和能力了解足夠事實即可。軟體專案最難面對的事實，不過就是無法面對在成本範圍品質這三面向，最多只能控制兩個面向，一定會犧牲一到兩個面相。

(3) 行動：

當大致了解事實，就要採取行動。首先”不行動”也是行動選項。只要確定”不行動”是經過妥善思考的最佳選項。

除此之外，技術領導者的行動一般來說決大部分是要解決問題：無論是事先預防還是事後解決，但是更重要的是增加團隊的未來價值。

行動需要有創意跟實質性，行對需要考慮妥善計劃以及適應性，這些都是為了避免錯誤，產生創新(避免馬斯洛 鐵錘效應：如果你有鐵錘，看到什麼東西都會像釘子: 馬斯洛1966)

---