做項目開發需要極具技術性的思維過程，但你會發現工作不僅僅只有編程，和其他同事合作才是你工作的重要組成部分。雖然其他開發者能理解你的技術工作流程，但非技術同事不會。擺脫編程的心態和這些不懂編程的人溝通至關重要。

試想一下這個場景：

產品對兩名開發提出了修復bug的需求。第一位非常詳細地描述了可能包含錯誤的代碼部分以及修復它的各種方法，列出了其中的復雜性。第二位給出了更直接的響應 - 說明問題是什么，并粗略估計修復它的時間。

發現區別了嗎？

在與非技術同事交流時，請務必記得在必要時脫掉你開發者的“帽子”，更好地與他們接觸。下面，是避免尷尬對話的七個策略。

1.認識到你和他們之間的真正障礙

開發寫代碼，設計做布局，經理帶團隊。但這些崗位之間的差異不會自動在這些角色之間創建通信障礙。相反，溝通障礙是由個人獨特的觀點造成的。

觀點的形成受許多因素影響。自身環境、個人喜好和崗位只是其中的一部分。每種因素都會影響他們獨特的工作偏好。而不同的性格，往往也會決定傾向扮演的具體角色。

了解這些不同的觀點是打破溝通障礙的關鍵。 作為開發，你需要跨過代碼庫，接觸和學習其他同事的想法。

2.真正了解需求

了解非技術同事觀點的最佳方式是拋出問題，從他們的角度了解他們特別重視的。

也許上面的產品需要的只是一個高級更新，他可能更專注于實現一個功能，而不是技術細節?；蛘咭苍S和你合作的是一個技術好的產品經理，他可能會更欣賞你編碼的細節。

通過隨時提問來了解同事的需求，將能夠了解如何與他們進行最佳的溝通。比如，你可以向項目業務分析師詢問他們如何定義接受標準?；蛘呖梢詥栐O計師，他們喜歡如何迭代設計。

3.交流而不是交談

當與非技術同行合作時，與他們交流，而不是與他們交談。 這里有一個微妙的區別。 前者對他們的觀點有著重要的意義。

要做到這一點，你必須先了解你交流的目的。是討論新功能？考慮架構決策？還是 Scrum 更新？專注于交流的真正目的，盡量不要跑偏了。

例如，傳統的 Scrum 會議會涉及到已經完成的工作、正在進行的工作和更新遇到的問題。嘗試解決問題并不在其目的范圍之內。通過記住真正目的，從共同點進行交流。

4.合適選擇措辭

開發技術迭代很快，來自全世界的新知識在不斷涌現。對于開發者來說，跟上自己的專長就已經是頗具挑戰的事了。保證整個軟件開發團隊與所需的知識保持同步是非常困難的。更別說是和非技術同事同步這些知識了。

所以，擁有共通的詞匯是從共同點進行溝通的關鍵。除非你的利益相關者想知道你正在使用的 MongoDB 實現的細節，否則最好不要去談起它。當然，有些時候你需要以某種方式在團隊間傳達技術細節。

當討論技術時，請記住，聽眾可能不了解這個特定領域的知識。在談話中注意聽眾的反應，并確保你們都有相互理解。保持你的溝通簡短和有效。

此外，可視化不管是在編程中，還是會議中都很重要。

5.練習講述你的故事

理解聽眾是有效溝通的一半，理解并正確表達自己的想法是另一半。這需要足夠的自我知識和實踐共享，能有效地擴展你的影響力。

第一步是知道你的觀點是什么。要形成作為軟件開發人員的偏好和意見，需要有足夠的技術知識。努力成為你的領域的專家，學習新技術和語言，閱讀博客，并觀察與其相關的開源項目。

除了這些硬技能，了解軟件開發如何與諸如商業、營銷、運營等其他相結合。開發過程因組織而異，了解所在的企業是如何利用軟件開發來做業務的，并得出你自己的結論。

當對自己的觀點有強烈的感覺時，會使你更容易表達自己。

6.當覺得有必要爭取時拿出勇氣去爭

有時，團隊在構建某些功能時可能會發生沖突。如果項目落后于計劃，開發可能爭取的是質量代碼，而產品可能更多的是想臨時解決方法，設計師可能爭取的是用戶體驗，而管理層擔心的是沒有資源繼續維持。

當有沖突時，當你不同意別人的意見時，學會以你作為一名開發者的視角說話。盡可能尋找共同點，并從相互理解的立場進行辯論。如果你能在上面的例子中說清楚保持高質量代碼能帶來的長期好處，可能別人會做出妥協。

記住在正確的場合用正確的方式分享你的意見。記住，你的語氣也同樣重要。

7.眼光盡量放長遠

在團隊中，為了一起共事，妥協很可能會出現在每個業務功能環節上，但最終目標應該始終是相同的 - 構建適合其用戶的軟件。這最終能使企業能夠通過增加收入和/或降低費用來發展壯大。

保持長遠的眼光能使你優先考慮團隊的最終目標，并更容易理解和妥協其他功能。它將時刻提醒你什么時候適合去爭論一些東西，什么時候可以放緩某種功能的開發節奏等等。[文章轉載自 開源中國社區//www.oschina.net]

更多行業資訊，更新鮮的技術動態，盡在。