在大一點的公司做事，經常聽到大家談論部門牆的問題。作為一名測試人員，更是深有感觸。幾乎方方面面都得去麻煩別人。1 你要去麻煩系統架構師，測試乙個系統的時候，無**能測試，還是介面測試，你得了解整體的架構，這樣才可以從全面的視角去看待這個測試，也有利於提高對系統的認識和學習。那你要虛心想系統架構師學習，少不得「麻煩你下，問乙個問題……」
2 你要去麻煩部件開發人員。針對乙個龐大的系統，涉及部件眾多，即使針對乙個部件，涉及的模組眾多。一旦出現問題，你得依據流程分析在哪塊出了問題，一旦定位出部件或模組問題，免不得要跟部件開發人員或模組開發人員溝通確認，甚至爭論究竟是不是問題。
3 你要去麻煩需求人員。書寫測試用例，理解需求是完成大部分測試用例的基本要求，有一些用例的設計要跟需求人員溝通，甚至兩個人針對客戶的需求文件理解也不一致，免不了溝通確認，爭論不休。
4 你要去協調資源。用例具備，要想測試，沒環境也是白搭，你不得不協調網路資源路由器交換機等，還有伺服器資源，甚至手機等，甚至**的資源，比如什麼室外室內，什麼方位等。
5 你要去資料確認。環境用例ok，你得根據資料去搭建環境，這時候你覺得資料讓你領會了一句古詩「書上的來終覺淺，得知此事要躬行」，驗證後告訴資料這錯那錯的。
上述的種種都會導致協調溝通，協調溝通必然帶來大家的「部門牆」情結。
在實際的工作操作中，我發現要想更好的推動測試工作，做事一定要有霸氣，且不說拿什麼質量重要的理論來壓迫其它部門，只要測試出的問題，要緊盯不放，不怕與其它部門打官司。領導們對缺陷數量妥協，但測試人員不能對缺陷結果妥協，要暴露的問題乙個不放。至於其它部門的搪塞，不理睬，時間緊等適度給予壓力。溝通過程中，首先郵件知會對方，給予其缺陷的證據，而後**溝通，說服他人，若其定位不出問題，在條件允許的情況下，再現問題現場，抓包乃至反編譯其原始碼，指出邏輯錯誤，處理不當。
部門牆說到底是個溝通的問題，作為個人在實際工作中如何更好的開展工作，還是要從溝通上下手。練好自己內功，就是測試出的問題要一定是問題，這就要求測試人員要心細和善於分析，別叫的很響，最終是配置問題，是ip錯誤等問題導致，浪費大家時間和精力，還讓人覺得你能力不濟，工作態度不認真。在確認問題的基礎上，運用大棒加胡蘿蔔溝通策略，拿出螞蝗吸血的執著，也就輕易而據穿越部門牆了。
IT部門如何應對VDI問題
的確，vdi專案可能受到多種因素影響，比如隱性成本 低估需求 嚴苛的使用者，或者使用這種技術從根本上來說就是一種錯誤，但是所有這些原因都可以歸結為兩類 錯誤資訊和效能表現，其所引發的問題能夠在vdi專案完成之前就將其摧毀。錯誤資訊 在部署vdi之前，許多企業甚至不清楚應該採用哪種方式才能夠順利完成這...
IT部門如何績效考核？
it員工的績效如何衡量？怎樣量化，才能實現對讓it部門的績效實時考核？看看包子堂的會員們都有哪些高見。宋褀 對於不直接產生效益的it部，如何為其制定績效考核指標？能否適用一般意義上的績效考核方法？冷懷晶 it雖然不是效益直接產生部門，但卻是公司運作基礎部門，以穩定性和問題處理反應速度為主要考量。宋褀...
IT從業人員如何打破公升值瓶頸
貼這些文章是告誡自己乙個事情，青春無多，社會殘酷，作為it人，真的要為以後早做打算。今天一位同事 已30多了 被老闆叫到他的辦公室去。老總對他說，由於效益不好，公司不再和他續訂到期的合同 我看到他很落寞地離去。他前年才結婚，還供著房子，老婆孩子要養，這一下子就失業了，而且又是快過年的時候 我跑去和他...