如何做一個有品質的技術分享
https://coolshell.cn/articles/21589.html
背景
分享資訊并不難，大多數人都能做到，就算是不善言談性格内向的技術人員，通過部落格或社交媒體，或是不正式的交流，他們都能或多或少的做到。
但是如果你想要做一個有品質有高度的分享，這個就難了，所謂的有品質和有高度，我心裡面的定義有兩點：
1）分享内容的保鮮期是很長的，
2）會被大範圍的傳遞。
我們團隊内每周都在做技術分享，雖然分享的主題都很有價值，但是分享的品質參差不齊，是以，想寫下這篇文章 。供大家參考。
定義
首先，我們先扪心自問一下，我們自己覺得讀到的好的技術文章是什麼？我不知道大家的是什麼，我個人認為的好的文章是下面這樣的：
- 把複雜的問題講解的很簡單也很清楚。比如我高中時期讀到這本1978年出版的《從一到無窮大》，用各種簡單通俗通懂的話把各種複雜的科學知識講的清清楚楚。還有看過的幾本很好的書，有一本是《Windows程式設計》，從一個hello world的程式開始一步一步教你Windows下的原生态程式設計。
- 有各種各樣的推導和方案的比較，讓你知其然知其是以然。有了不同方案的比較，才可能讓人有全面的認識。這個方面的經典作著是《Effective C++》。
- 原理、為什麼、思路、方法論會讓人一通百通。這裡面最經典的恐怕就是《十萬個為什麼》了，在計算機方面也有幾本經典書，有《Unix程式設計藝術》、《設計模式》、《深入了解計算機系統》等書，以及《The C10K Problem》等很多技術論文。
其實，從教科書，到專業書，再到論文，都有上面這些不錯的特質。
方法
是以，如果你想做一個好的技術分享的話，下面是我總結出來的方法，供你參考。
1、先描述好一個問題。這樣能夠聽衆帶入進來，如果這個問題是他們感同身受的，那是最好了。千萬不要一上來就說What，或是直接沖進答案裡。這樣的分享是在灌輸和填鴨。把Why說清楚。沒有Why，直接談What的技術分享，通常來說價值不大。
2、How比What重要，在講How的時候，也就是如何解這個問題。
- 先要把問題模型說清楚，有了問題模型這個框框後，方案才有意義。
- 然後要有不同技術的比較。有了比較後，聽衆才會更相信你。
- 直接上What的技術細節，其實沒有太大意義。
3、一定要有Best Practice或方法論總結，否則上不了檔次的。也就是分享中大家可以得到的重要收獲。
其實，這個模型就是：問題 –> 方案 –> 總結。這其中是有一定的心理學模型的，具體表現如下：
- 用問題來吸引閱聽人，帶着閱聽人來一起思考
- 用問題模型來框住閱聽人的思考範圍，讓閱聽人聚焦
- 給出幾種不同的解決方案，比較他們的優缺點，讓閱聽人有一種解決問題的參與感。
- 最後，給出最佳實踐，方法論或套路，因為有了前三步的鋪墊，閱聽人欣然接受。
- 整個過程會讓閱聽人有強烈的成長感和收獲感。
下面是我寫在我們公司内的Knowledge Sharing中的Best Practice，供參考
附錄：Sharing Guideline
Please follow the following sharing protocols
Understand Sharing
Sharing is the hard way to learn knowledge. The presenter gains the biggest advantages. not audience. 分享是學習知識的最難的方式。分享者獲得的好處最最多的，而不是觀衆。
Sharing can open the knowledge door for the audience, but you have to walk to knowledge by yourself. 分享可以為聽衆打開知識的大門，但你能不能獲得知識還要靠你自己。
Best Practices
To perform a great sharing, please follow the below practices.
- Do not share a big topic, a small topic is better. A big topic could make the audience lose focus. Remember, Less is More!
- Sharing time less than 60 mins is the best.
- English language for slides is preferred.
- While prepare the sharing contents, it’s better to discuss with the senior people to help you to see the whole picture, understand the good side and bad side, know what you don’t know … etc.
- Strong Recommend Materials Outlines
- What’s the Problem?
- How to Solve the Problem?
- The Best Solution or Practice.
- The Mechanism, Key Techniques, and Source Code
- Pros/Cons
- References (Further reading)
For example, if you want to sharing a topic about Docker. the following outlines would be good one:
- What’s the major problems need to solve. (Provision, Environment, Isolation etc.)
- The Alternative solutions. (Puppet/Chef/Ansible, VM, LXC etc.)
- The Best Solution – Docker. Why?
- Docker’s key techniques – image, cgroup, union fs, namespace…
- Docker’s Pros/Cons
- Further reading list.
" Knowledge increases by sharing but not by saving.
-- Kamari aka Lyrikal"
如果說我的文章對你有用，隻不過是我站在巨人的肩膀上再繼續努力罷了。
若在頁首無特别聲明，本篇文章由 Schips 經過整理後釋出。
部落格位址：https://www.cnblogs.com/schips/