团队之间有协作就避免不了沟通问题，人与人之间的沟通并不能百分百的传达好指令，所以项目上的事情需要经常的沟通。喜欢看综艺节目的人应该经常能看到一些你画我猜的游戏，画的人如果表达的有问题，或者猜的人理解稍微有偏差，结果都会大相径庭。
公司在讲这个问题的时候就做过一个实验，有兴趣的话也可以尝试一下，实验是这样子的：
先由一个人画一个简单的图形，然后拿给另一个人，让他看完之后用几句话进行描述，每句话都是独立的，然后让其他人根据他的描述将图形画出来。以一个等边四边形为例子：描述：1、有四条线2、四条线长短不一（如果描述成两条长两条同样短那可能就很容易了）3、四条线最终连起来了最终的结果是有的人画对了，有的人不知道线是直线，有的人画的乱七八糟的。
这还只是一对一的情况下，如果是跨部门间领导沟通完之后，继续传达给下属，下属又传达给实际负责人，那结果可就更天差地别了。
所以做项目跨部门间，及时并多次的沟通是必须的。
但沟通从来不是一方能决定的，总得有人愿意沟通吧！这时候就是如何去沟通的问题了。
沟通通常都是因为需求问题，首先要认清自己的定位，即现在有个问题需要被解决，而且是你负责的，但解决这个问题的人不一定是你本人，可能是你直接吩咐给其他人去做再由你进行监督知道问题被解决，或者是需要在别人的协助下由你去完成。
这也就意味着你可能需要去麻烦人家，去求人家，从这个角度考虑，那你就应该更多的站在别人的角度去提供尽可能多的信息，来协助他尽快的帮你解决。
以开发工程师和实施/运维工程师为例子：
开发工程师负责技术实现，实施/运维工程师负责到甲方目的地进行项目部署、测试并收集客户意见，于是开发经常会遇到以下几种情况：
实施/运维工程师：为什么我XXX了，却还是不行？开发工程师：这个是需要先XXX，再XXX，然后再XXX，最后XXX才可以的，你前面这些都做了吗？实施/运维工程师：啊！这样子啊！那我试试吧。开发工程师：卒。。。实施/运维工程师：这个功能怎么不行了？昨天还好好的。开发工程师：怎么不行了？日志报错了吗？报什么错？是接口问题还是系统问题？昨天还可以说明系统很稳定，那应该考虑接口问题，接口问题是甲方提供的，那你应该测试一下是不是出问题了，有问题就直接跟甲方沟通，别什么事情都找开发。实施/运维工程师：/害怕。。。实施/运维工程师：甲方说这个地方要加XXX，然后可以XXX，这周能搞定吧！开发工程师：需求确定了吗？有签协议吗？做这个东西需不需要甲方提供接口支持弄清楚了吗？实施/运维工程师：啊这。。。相信我，这个开发工程师算是脾气好的了，可能有的人会认为，这个实施/运维工程师一点都不专业，岗位职责都没弄清楚，的确，小公司就这样。。。
那么如何解决这个问题呢？
前面已经说到，当你去找别人协助的时候，意味着你要麻烦人家求人家，那么你应该更多的站在别人的角度去提供尽可能多的信息，来协助他尽快的帮你解决，此外，你自身的问题也该检点检点。
如图所示，当你提出“为什么我XXX了，却不行？”的时候，原因大概率就是：
解决这几个问题也很简单，不了解那你就去了解，不明白的那你就去问（描述好问题），然后就是办事要有责任心。
实在不行需要麻烦到别人了，那也是要讲究技巧的，你可以这样去提问问题：
为什么我已经做了XXX事情了，却还是出现了XXX问题，按理说先XXX这样，然后再XXX这样就可以XXX的呀。首先“为什么我做了XXX事情”是让别人知道自己具体干了什么，“却还是出现了XXX问题”是让别人知道发生了什么事情，“按理说XXX之后”是让别人知道你是否按照正常的流程去做了，“应该是可以XXX的呀”是让别人确认你是否真的理解业务。
当你按照这样的话术去描述你的问题的时候，别人马上就能定位出你是哪里做错了还是真的有问题了。
搞技术的人大都比较生僻，不喜欢被打扰，所以当你麻烦到开发工程师的时候，尽量一句话表达完所有需求，这样能获得更好的解决问题效果。
亲测有效！
有一次公司外派到贵州跟进一个合作项目，到了那边发现项目部署有问题，但是没人敢在群里向第三方厂商反应，后来才知道原来是他们问题都描述不清楚，也提供不了有效的信息让第三方去定位问题。于是我就让他们把我拉进去，按照大概（可以适当修改）这样的话术在群里发起提问，并提供有效的错误日志以及问题复现后的截图到群里，他们很快就回复了。还主动的要求我提供手机号码，想通过通话联系跟我讲解问题可以尝试如何去解决，最终的确是他们提供的jar包出现问题了，就等他们明天上班处理完重新发jar包给我们进行部署，问题圆满解决！！！还有一个同样需要注意的就是，如果项目有第三方厂商参与，如提供接口，则与甲方对接的人一定要按照系统要求进行测试后才交给开发工程师，一定一定一定。
每个部门都做好自己的事情，才不会给其他部门的人带来麻烦。