个人如何打破部门墙_做事要有霸气

在大一点的公司做事，经常听到大家谈论部门墙的问题。作为一名测试人员，更是深有感触。几乎方方面面都得去麻烦别人。
1 你要去麻烦系统架构师，测试一个系统的时候，无论功能测试，还是接口测试，你得了解整体的架构，这样才可以从全面的视角去看待这个测试，也有利于提高对系统的认识和学习。那你要虚心想系统架构师学习，少不得“麻烦你下，问一个问题……”
2 你要去麻烦部件开发人员。针对一个庞大的系统，涉及部件众多，即使针对一个部件，涉及的模块众多。一旦出现问题，你得依据流程分析在哪块出了问题，一旦定位出部件或模块问题，免不得要跟部件开发人员或模块开发人员沟通确认，甚至争论究竟是不是问题。
3 你要去麻烦需求人员。书写测试用例，理解需求是完成大部分测试用例的基本要求，有一些用例的设计要跟需求人员沟通，甚至两个人针对客户的需求文档理解也不一致，免不了沟通确认，争论不休。
4 你要去协调资源。用例具备，要想测试，没环境也是白搭，你不得不协调网络资源路由器交换机等，还有服务器资源，甚至手机等，甚至变态的资源，比如什么室外室内，什么方位等。
5 你要去资料确认。环境用例OK，你得根据资料去搭建环境，这时候你觉得资料让你领会了一句古诗“书上的来终觉浅，得知此事要躬行”，验证后告诉资料这错那错的。
上述的种种都会导致协调沟通，协调沟通必然带来大家的“部门墙”情结。
在实际的工作操作中，我发现要想更好的推动测试工作，做事一定要有霸气，且不说拿什么质量重要的理论来压迫其它部门，只要测试出的问题，要紧盯不放，不怕与其它部门打官司。领导们对缺陷数量妥协，但测试人员不能对缺陷结果妥协，要暴露的问题一个不放。至于其它部门的搪塞，不理睬，时间紧等适度给予压力。沟通过程中，首先邮件知会对方，给予其缺陷的证据，而后电话沟通，说服他人，若其定位不出问题，在条件允许的情况下，再现问题现场，抓包乃至反编译其源码，指出逻辑错误，处理不当。
部门墙说到底是个沟通的问题，作为个人在实际工作中如何更好的开展工作，还是要从沟通上下手。练好自己内功，就是测试出的问题要一定是问题，这就要求测试人员要心细和善于分析，别叫的很响，最终是配置问题，是IP错误等问题导致，浪费大家时间和精力，还让人觉得你能力不济，工作态度不认真。在确认问题的基础上，运用大棒加胡萝卜沟通策略，拿出蚂蝗吸血的执着，也就轻易而据穿越部门墙了。