这里着重强调系统owner或者领域owner的沟通事项，一线开发者可适当参考。
正常一线开发需要沟通的事项并不是太多，例如迭代中的需求（预）评审、技术对接、沟通对象也大都限制在产品经理、内外部开发人员、项目经理。除此之外的大部分时间都是在coding当中度过。即使在出现沟通问题，大部分情况都能够内部解决。
但是当你站在更高一层，系统或者领域的时候，你面向的对象则远超出这几个角色，产品总监会找你讨论产品问题、技术总监及CTO可能找你讨论系统架构、运营会和你沟通未来规划、客服会找你咨询用户问题，等等。
所以你的沟通的方式决定了这些角色对你的定位、评价。

先看几个较为常见的沟通bad case

case1：大的工作群里抱怨

小潘负责门店审核相关领域，在下个月的需求规划的群中，产品小胡在提出需要更改当前流程提高效率，当前小潘负责的审核流程刚刚经过一轮改造，正处理新老流程的迁移过程中，被很多问题忙的焦头烂额，气不打一处来，立即在大群里发了顿牢骚，没有给产品任何面子。
结果：领导认为该同学的负面情绪很重，影响团队氛围，产品认为该同学不好合作，以后需求能绕过则绕过。

case2：响应不及时

在故障沟通群里，客服在群里反馈了几例门店操作异常的案例，小胡很紧张，立刻去看监控、查日志排查问题根源，半小时后客服看群里没人回答，为避免问题持续恶化，通过电话告知你的老板，老板气势凶凶的拿你问罪。
结果：客服认为该故障没有人维护，该部门领导负主要责任。用户认为该问题持续存在，继续投诉。

case3：重度关心自身利益，不为大局考虑

大数据开发提出要将某个表的数据重新整理，整理后的数据将更加精确，但是会引发数据的下游使用方小袁负责的系统较大的技术改造，费时费力也没有产出，所以在这个问题上小袁在人力及排期上做文章故意拖延。
结果：两个团队合作越来越紧张，问题讨论经常不以解决问题为目的的沟通转而是如何让对方完事，已方能不做就不做。

如何避免如上问题

换位思考，站在别人的角度上去看待问题，是解决上述所有case的前提；
升层思考，站在领导的角度上去看告诉问题，假设领导会如何处理该问题；
拓展视野，主动了解业务规划及发展方向，系统（技术）规划也要大致符合业务规划，了解整体背景后再做决策