這里著重強調(diào)系統(tǒng)owner或者領(lǐng)域owner的溝通事項，一線開發(fā)者可適當參考。
正常一線開發(fā)需要溝通的事項并不是太多，例如迭代中的需求（預(yù)）評審、技術(shù)對接、溝通對象也大都限制在產(chǎn)品經(jīng)理、內(nèi)外部開發(fā)人員、項目經(jīng)理。除此之外的大部分時間都是在coding當中度過。即使在出現(xiàn)溝通問題，大部分情況都能夠內(nèi)部解決。
但是當你站在更高一層，系統(tǒng)或者領(lǐng)域的時候，你面向的對象則遠超出這幾個角色，產(chǎn)品總監(jiān)會找你討論產(chǎn)品問題、技術(shù)總監(jiān)及CTO可能找你討論系統(tǒng)架構(gòu)、運營會和你溝通未來規(guī)劃、客服會找你咨詢用戶問題，等等。
所以你的溝通的方式?jīng)Q定了這些角色對你的定位、評價。

先看幾個較為常見的溝通bad case

case1：大的工作群里抱怨

小潘負責門店審核相關(guān)領(lǐng)域，在下個月的需求規(guī)劃的群中，產(chǎn)品小胡在提出需要更改當前流程提高效率，當前小潘負責的審核流程剛剛經(jīng)過一輪改造，正處理新老流程的遷移過程中，被很多問題忙的焦頭爛額，氣不打一處來，立即在大群里發(fā)了頓牢騷，沒有給產(chǎn)品任何面子。
結(jié)果：領(lǐng)導認為該同學的負面情緒很重，影響團隊氛圍，產(chǎn)品認為該同學不好合作，以后需求能繞過則繞過。

case2：響應(yīng)不及時

在故障溝通群里，客服在群里反饋了幾例門店操作異常的案例，小胡很緊張，立刻去看監(jiān)控、查日志排查問題根源，半小時后客服看群里沒人回答，為避免問題持續(xù)惡化，通過電話告知你的老板，老板氣勢兇兇的拿你問罪。
結(jié)果：客服認為該故障沒有人維護，該部門領(lǐng)導負主要責任。用戶認為該問題持續(xù)存在，繼續(xù)投訴。

case3：重度關(guān)心自身利益，不為大局考慮

大數(shù)據(jù)開發(fā)提出要將某個表的數(shù)據(jù)重新整理，整理后的數(shù)據(jù)將更加精確，但是會引發(fā)數(shù)據(jù)的下游使用方小袁負責的系統(tǒng)較大的技術(shù)改造，費時費力也沒有產(chǎn)出，所以在這個問題上小袁在人力及排期上做文章故意拖延。
結(jié)果：兩個團隊合作越來越緊張，問題討論經(jīng)常不以解決問題為目的的溝通轉(zhuǎn)而是如何讓對方完事，已方能不做就不做。

如何避免如上問題

換位思考，站在別人的角度上去看待問題，是解決上述所有case的前提；
升層思考，站在領(lǐng)導的角度上去看告訴問題，假設(shè)領(lǐng)導會如何處理該問題；
拓展視野，主動了解業(yè)務(wù)規(guī)劃及發(fā)展方向，系統(tǒng)（技術(shù)）規(guī)劃也要大致符合業(yè)務(wù)規(guī)劃，了解整體背景后再做決策