通過幾個情景描述，來聊一聊技術人溝通中的幾個常見問題。
一、情景一
在你設計的一個技術方案中，領導不同意其中的一些設計，覺得設計很繁瑣，實現起來不容易，耗費時間。你不同意領導的這些說法，雖然設計很繁瑣，但是考慮的一些問題很全，所以設計會有一點繁瑣。 這時候你該怎麼辦？
這裡表現出了一個技術人對技術設計追求完美的一個體現。這種追求當然是值得提倡的。
但有時候往往受制於一些現實因素-時間，業務發展，資源等，這些都是領導需要考慮的，領導不僅要考慮技術方面，還要考慮其他因素。所以設計的時候，要適度設計，不要過度，畢竟要考慮成本和時間。
技術人往往注重技術方面的思考，而忽略了其他因素的限制。領導考慮事情的因素往往比技術人要多，他要確保專案順利完成，他是對整個專案進度負責。
二、情景二
領導給你佈置了一項任務，評估時間大概需要2個星期來完成。你領了任務後，就急急忙忙的去做了，中間就像“消失”了一樣，沒有任何任務進度的訊息。領導不知道你做的怎麼樣了，做到了哪裡？還剩多少沒做？
- 在接到任務時，要用自己的話給領導複述一遍任務內容，確保自己真正理解了佈置任務的內容。最好把任務內容用筆記本記下來，重點部分標記下。好記性不如亂筆頭嘛。
- 現在雖然有好多週報彙報形式，甚至日報形式，這種過於形式化了。所以在做任務過程中，除了日常形式彙報，最好也能有其他形式積極彙報工作情況，特別是重點任務情況，讓領導掌握任務的進度，不要讓領導感覺對任務進度失去控制。
三、情景三
還是領導給你佈置了一項任務，不過是比較重要的任務，你也和領導確認了任務內容。然後你就下去做了，也積極的彙報工作情況。那還有什麼情況需要注意的呢？
按照上面情景二來做的話，大部分溝通還是很正確的。要說還缺什麼？那就是領導對這個任務的期待。他對這個任務的看法、要求，以及希望做成一個什麼樣子。即是你對領導的期待要有所瞭解，這個也要好好溝通。雖然做事情根本上來說是為了公司，但是領導決定了你的很多事情，比如晉升、加薪、kpi等。
還有預估工作量，如果需要人手，一定提前和領導溝通。
四、情景四
自己做某一個任務，遇到了技術難點，研究了很長時間（比如4個小時），還是沒有眉目，自己還打算明天繼續研究看看。這種情況該怎麼辦？
如果這個任務不是很急，時間也充裕，那麼你可以自己繼續研究。 如果任務比較急，那麼這時就不要自己一個人去研究，2個小時左右解決不了的問題，就要把問題彙報給領導或者同事，把你研究的情況說明清楚，然後請求領導協助解決。一是讓其他同事或者領導瞭解你的進度和困難，二是請求他們幫助你解決問題。不要有其他顧慮，我們最終目的是解決問題，讓任務順利向前推進。
五、情景五
做了一個框架，想向其他兄弟部門推廣，讓他們使用，怎麼溝通？怎麼做呢？
- 技術宣講：先在自己組內進行試講預熱，然後到公司裡對該框架技術進行宣講，讓他們瞭解特性功能，順便“安利”他們使用。最好能在公司多宣講幾次，增加框架在他們面前出現的頻率。
- 拉著其他部門、組領導吃飯，然後宣傳推廣；聊天的時候時不時推廣下。這時候臉皮要厚，不要怕被拒絕，拒絕了隔一段時間再給他說說。總之，臉皮不要太薄。不過，這也是程式設計師通病，拉不下面子，臉皮太薄。我們目的是推廣框架使用，其他都是次要的，不要太在意。
六、情景六
產品和技術的溝通問題，有時候溝通大家不在一個頻道上
這是不同工種交流普遍存在的問題，因為不同工種所使用的語言和語境都不相同，他們都有自己的專業語言。
比如：it技術就有各種程式語言，不同語言又有不同的特性，還有高併發，高可用等各種術語，你要用這種專業語言跟外行人溝通，人家肯定一臉懵逼的看著你。
同理，與產品溝通時，要用雙方都能明白的語系進行溝通。
還有就是同理心，站在對方角度考慮問題。
最後瞭解對方的領域知識，擴大自己的知識範圍，然後就可以用對方領域的知識交流溝通了。
[完]