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