通過幾個情景描述，來聊一聊技術人溝通中的幾個常見問題。
在你設計的乙個技術方案中，領導不同意其中的一些設計，覺得設計很繁瑣，實現起來不容易，耗費時間。你不同意領導的這些說法，雖然設計很繁瑣，但是考慮的一些問題很全，所以設計會有一點繁瑣。 這時候你該怎麼辦？
這裡表現出了乙個技術人對技術設計追求完美的乙個體現。這種追求當然是值得提倡的。領導給你布置了一項任務，評估時間大概需要2個星期來完成。你領了任務後，就急急忙忙的去做了，中間就像「消失」了一樣，沒有反饋任何任務進度的訊息。領導不知道你做的怎麼樣了，做到了**？還剩多少沒做？但有時候往往受制於一些現實因素-時間，業務發展，資源等，這些都是領導需要考慮的，領導不僅要考慮技術方面，還要考慮其他因素。所以設計的時候，要適度設計，不要過度，畢竟要考慮成本和時間。取捨要平衡。架構也是平衡的藝術。
技術人往往注重技術方面的思考，而忽略了其他因素的限制。領導考慮事情的因素往往比技術人要多，他要確保專案順利完成，他是對整個專案進度負責。
在接到任務時，要用自己的話給領導複述一遍任務內容，確保自己真正理解了布置任務的內容。最好把任務內容用筆記本記下來，重點部分標記下。好記性不如亂筆頭嘛。還是領導給你布置了一項任務，不過是比較重要的任務，你也和領導確認了任務內容。然後你就下去做了，也積極的匯報工作情況。那還有什麼情況需要注意的呢？現在雖然有好多週報匯報形式，甚至**形式，這種過於形式化了。所以在做任務過程中，除了日常形式匯報，最好也能有其他形式積極匯報工作情況，特別是重點任務情況，讓領導掌握任務的進度，不要讓領導感覺對任務進度失去控制。
按照上面情景二來做的話，大部分溝通還是很正確的。要說還缺什麼？那就是領導對這個任務的期待。他對這個任務的看法、要求，以及希望做成乙個什麼樣子。即是你對領導的期待要有所了解，這個也要好好溝通。雖然做事情根本上來說是為了公司，但是領導決定了你的很多事情，比如晉公升、加薪、kpi等。自己做某乙個任務，遇到了技術難點，研究了很長時間（比如4個小時），還是沒有眉目，自己還打算明天繼續研究看看。這種情況該怎麼辦？還有預估工作量，如果需要人手，一定提前和領導溝通。
如果這個任務不是很急，時間也充裕，那麼你可以自己繼續研究。 如果任務比較急，那麼這時就不要自己乙個人去研究，2個小時左右解決不了的問題，就要把問題匯報給領導或者同事，把你研究的情況說明清楚，然後請求領導協助解決。一是讓其他同事或者領導了解你的進度和困難，二是請求他們幫助你解決問題。不要有其他顧慮，我們最終目的是解決問題，讓任務順利向前推進。做了乙個框架，想向其他兄弟部門推廣，讓他們使用，怎麼溝通？怎麼做呢？
技術宣講：先在自己組內進行試講預熱，然後到公司裡對該框架技術進行宣講，讓他們了解特性功能，順便「安利」他們使用。最好能在公司多宣講幾次，增加框架在他們面前出現的頻率。產品和技術的溝通問題，有時候溝通大家不在乙個頻道上拉著其他部門、組領導吃飯，然後宣傳推廣；聊天的時候時不時推廣下。這時候臉皮要厚，不要怕被拒絕，拒絕了隔一段時間再給他說說。總之，臉皮不要太薄。不過，這也是程式設計師通病，拉不下面子，臉皮太薄。我們目的是推廣框架使用，其他都是次要的，不要太在意。
這是不同工種交流普遍存在的問題，因為不同工種所使用的語言和語境都不相同，他們都有自己的專業語言。上面技術人在職場中遇見的幾種情景，總結一下就是做事的方法和思維模式：比如：it技術就有各種程式語言，不同語言又有不同的特性，還有高併發，高可用等各種術語，你要用這種專業語言跟外行人溝通，人家肯定一臉懵逼的看著你。
同理，與產品溝通時，要用雙方都能明白的語系進行溝通。
還有就是同理心，站在對方角度考慮問題。
最後了解對方的領域知識，擴大自己的知識範圍，然後就可以用對方領域的知識交流溝通了。
做事的方法：
站在更高一層看事情思維模式：凡事有交代，件件有著落，事事有回音
及時反饋
以終為始
閉環思維換位思考
[完]
技術人溝通中的幾個誤區
溝通這個話題很大，所以今天的闡述的內容只針對80 以上的技術領域從業者會面對的場景。即便只是講技術團隊中的溝通，也足夠講幾天的課程了。所以，我選擇了 溝通誤區 這個話題作為切入點，通過一些具體事例來談談技術人溝通中的問題，來看看如何將溝通做到更好。誤區1 加強溝通就是多和人說話 這一點最大的問題，就...
網球線的幾個常見問題
關於網球線的幾個常見問題 哪一種穿線磅數能帶更強的力量 如果給一支球拍穿線時穿的是他要求的最低磅數，那麼同樣的擊球力量，球會飛的更遠。因為較低的穿線磅數在擊球時的彈性會更大，因此球會飛的更遠。經過usar的研究發現，低磅數的球拍能夠使球在球拍上停留的時間更長。哪一種穿磅數能帶來更好的控球效果 在同樣...
軟體測試中遇到的常見問題及溝通方法
1 這個bug我這邊重現不了 解決辦法 bug應該簡明扼要，重點突出。如果描述存在歧義，一定要總結並盡快改進。有時會遇到概率性的bug，要告訴開發概率是多少，盡可能多的提供重現的條件。在復現問題時，希望能大致判斷幾個問題點，然後和測試人員溝通下，需要如何捕獲資訊，捕獲那類資訊？是不是提供debug版...