有人說,若是你想掌握好一門技術,那麼最好的方式就是去當老師,去教會別人這門技術。在教別人的過程當中,你必需要去深刻的瞭解這門技術的方方面面,同時還要思考怎麼才能讓別人理解。每個作過的人都知道,這要比本身學習更難。html
之前我帶的團隊中,都會有比較好的技術分享的氛圍,我會逼着每一個人都按期作一些本身熟悉的技術分享,一方面幫助你們共同成長,同時也讓本身有更大的成長。固然我本身也很樂意作這樣的技術分享的事,我一直以爲能幫助別人是一件快樂的事情。前端
技術分享有主要的形式有寫技術文章、作內部技術講座。不管是哪種形式的技術分享,都有一些基本注意事項:node
每一次的技術分享,篇幅有限,時間有限,聽衆的注意力也有限,這就要求咱們必須能突出主題,不能什麼都講,最後什麼都沒印象,而是儘量聚焦於一個點,讓聽衆留下深入印象。事實上,一次技術分享,能讓大部分聽衆在一個知識點上有所理解和掌握,就已經很是成功了。mysql
例如前不久我剛在部門作了一次技術分享,關於一個聊天系統的技術實現,事實上這個系統比較複雜,服務端用到了node、socket、redis、mysql,另外還有一些負載均衡、安全認證等技術,客戶端用了React、Redux、React-Router、Immutable、SASS、Gulp、Babel、ES6等知識點,若是要完整的講一遍,那麼一兩個小時是不可能講的完的,因此最終我選取了你們比較感興趣的熱門前端技術,僅圍繞客戶端React和Redux來說。過後證實效果不錯,在一個小時內基本完成,而且讓不少同事對React和Redux有了初步的瞭解。redis
在肯定主題後,接下來一件很重要的事情就是要了解技術分享的聽衆了,這和作產品須要瞭解你的目標用戶同樣,作技術分享也須要了解你的"用戶"。有幾個點是須要考慮清楚的:sql
例如我作過的技術分享通常有幾類聽衆:編程
這其實本質上也是一種「指望值管理」,只有瞭解好受衆的指望值,才能最後符合指望甚至超出指望。安全
去作技術分享前,若是不是爲了裝逼須要,大部分仍是願意讓本身內容淺顯易懂的,可是真要作起來可不是那麼容易,包括我本身,還有不少須要提升的地方,但這些年也總結了一些經驗。前端框架
類比對於在作新技術的分享的時候尤其重要,每一個人都或多或少已經創建了本身的知識體系,有必定的積累,用聽衆已有的知識去類比,會比較容易理解和接受。好比說要給技術人員介紹React,我會類比模版、數據綁定、函數式編程,但若是是不懂技術的或懂一點技術的例如老闆,我只會解釋說這是一種相似jQuery的前端框架,前期有必定學習成本,對於複雜的應用能夠提升開發效率。負載均衡
一圖勝千言,好的代碼也是如此。寫PPT或者文章的時候,我總須要花不少時間去搜索圖片,而後本身再畫一些簡單的框圖,幫助說明清楚。
不少技術問題,最終是要反映成代碼,尤爲是對於技術人員,你費勁解釋好久的問題,可能幾行代碼就寫清楚了。
不少時候,費勁講半天,聽衆可能還不明白這門技術能作什麼事情和帶來什麼好處,配合一些直觀的演示,可讓聽衆很直觀的瞭解能夠作什麼,有什麼好處。
在一次短則半小時多則一小時的技術講座過程當中,要想讓聽衆一直能集中注意力是很難的,若是隻是照本宣科念PPT,恐怕觀衆很容易以爲無聊。而聽衆互動是一種很是簡單有效的方式來提升分享的效果。
互動的方式有不少,例如向聽衆提問、讓聽衆參與遊戲、回答聽衆疑問。
有一次作項目管理相關的知識分享,我事先設計了一個遊戲,把你們分紅幾個組,而後每一個組在限定的時間內用紙筆設計一個手機,而後再分組上臺講解。遊戲完成後,我再結合項目管理的知識點作一些講解和點評,這樣的形式讓參加的人都印象深入。相似的還有之前參加過鄒老師組織過的一次遊戲「創新的時機 – 黃金點遊戲」,也是讓我印象深入。
除了互動,通常都會有答疑的環節,尤爲是對於現場答疑這種,須要的就是平時的積累和現場的反應了。須要注意的是要理解清楚提的問題是什麼,若是實在是不會的問題,坦然說明不知道也是很正常的事。
一次分享每每時間有限,因此對節奏的把握很重要,事先要有計劃:整體耗時多少,各個階段要耗時多少,留多少時間答疑。在實際的分享過程當中每每會有些意外環節,例如對於某部份內容講的太細,或者前期互動太多,這極可能致使後面時間不夠,因此在整個過程當中,須要有清醒的意識,當某部分過快或過慢的時候要及時調整。若是有必要,也可讓其餘人輔助提醒。
之前有個朋友,去講時間管理,結果原定1個小時的內容,講了快2小時,最後結束的時候,全部的同窗第一時間衝向廁所:)