有時好象IT分裂成了兩個敵對的陣營。一邊是致力于穩定性的基礎架構工程師，他們要保護自己的環境。另一邊是開發者，他們經常努力去發現獨特的、更棒的方法來達到他們的目標。這兩個陣營之間的斗爭是如此的激烈，以至于連最忙碌的經理都開始注意到這點。
　　一個失敗的項目

　　我參加的第一個大項目是幫助一個學校把一個基本財務信息系統從一個平臺移到另一個平臺上。我作為基礎架構小組的解決問題專家以及配置專家。這個應用很陳舊，開發團隊還面臨著升級它，以符合該學校目前以及將來的需求的挑戰。

　　事情的開始很正常。我們架起了自己的服務器，配置路由器，并在搭建IP子網絡中找到了樂趣。當基礎架構團隊忙于進行穩定性測試的時候，開發者們卻退到他們滿是灰塵的房間和黑暗的角落里去。他們在深夜工作。

　　該項目進行了一個月以后，這兩個團隊除了在我們每周的例會之外，就已經不說話了。進行了兩個月的時候，這些周例會也開始變味了。基礎架構團隊進行最后的配置并完成了基本的穩定性測試。開發團隊每周到我們這來，帶來新的變化，補丁和他們想放在服務器上的程序。

　　雙方的脾氣都開始爆發。從我們的角度看，我們不理解為什么開發者們不能接受我們為他們測試的，所有的偉大的事情。對于他們來說，這些開發者不能理解我們為什么如此頑固。他們只是想要幫助客戶。

　　一天下午，事情發展到了頂端。一個開發者走進測試實驗室，在桌上放了一個軟件，并宣布要我們在當天安裝并測試這個軟件。我告訴他我們要在別的時間來進行這件事--也許是下個月的某個時候，我有我的方法。他很不高興。事情從那個時候開始就有些失去控制了。我們面對面地站著，向對方大聲嚷嚷。

　　我們的客戶協調人剛巧在我們兩個扭打在一起的時候走進這個房間。他關上門出去了。兩個小時以后，那個開發者和我都被踢出了那個項目。但是，在我們走了以后，那個項目里的兩個團隊之間的情況沒有任何改善。事實上，情況越來越糟，最后導致了整個項目的失敗。

　　發生了什么？

　　除了我自己的不夠職業的行為，這個項目還受到一個根本問題的困擾。基礎架構和開發者這兩個團隊之間的關系制造了大量的緊張氣氛。我的大聲嚷嚷和那個開發者的失態只是表象，而不是問題的實質。辨認出并理解這個問題成了我在等待下一個新項目的時候關注的焦點。

　　在回顧了我們從事的工作類型之后，我認識到基礎架構和開發對于世界持有相矛盾的看法。這種矛盾不可避免地導致了兩個團隊之間的戰爭。

　　基礎架構團隊關注的是能力和風險管理。他們的目標通常包括諸如“快速配置”，“沒有麻煩的安裝”以及“快速的問題解決方案”等內容。經理們通過檢查當機時間和問題解決方法來衡量基礎架構。為了達到這些目標，有天賦的基礎架構人員努力創造穩定，低風險，高可管理性的環境。當變化讓他們難以達到目標的時候，他們就會有些抗拒風險。

　　程序員們則有著完全不同的文化。他們的目標包括解決商業問題，改造現有的程序來解決新的問題，并思考新技術的可行性。衡量他們的標準是他們能夠成功承擔風險的能力和愿望。風險越大，他們能解決的問題越大，他們就越有成績。

　　這種討厭風險/喜歡風險的不同態度解釋了我每天從基礎架構和開發團隊那里聽到的評論。基礎架構團隊通常把程序員們看成是肆意妄為的牛仔。程序員把基礎架構團隊當作是庸俗古板的人，并抱怨說他們總是整天憂心忡忡。這兩者之間的矛盾是顯而易見的，所以這個問題就不是我們怎樣才能阻止這兩者間的戰爭，而是我們如何才能利用它，并從中獲得最大的收益。

　　利用緊張

　　從實踐的角度，我們不能夠改變這兩個團隊之間的緊張氣氛。冒險者和反對風險的人總是會起沖突。但是還是有可能利用這些不同的觀點并讓他們能夠在理智的環境中一起工作。

　　最簡單的辦法是指定兩個團隊中最外向，喜好交際的人作為同另一個團隊的“聯絡者”。聯絡者參加對方團隊的會議，學習去了解對方想要什么以及對方如何處理問題。這在兩個團隊之間創建了一點相互的理解。同時保證了他們之間非正式的溝通。

　　一個更復雜的方法是建立基本變化管理。建立起一套可以接受的方法和時間讓兩個團隊坐在一起討論變化。在這個會議之外，建立一些非正式的頭腦風暴會議來讓兩邊關鍵的人表達自己的意見。在正式會議沉悶的氣氛之外，非正式的交流使兩個團隊能夠建立共同的目標。

　　快速前進

　　幾年以后，我發現自己再次參加了一個項目，該項目中也包含了大型的開發同基礎架構團隊。當敵對的陣營開始形成的時候，我利用自己作為高級基礎架構管理人員的身份，建立了一個變化管理流程。在第一次會議上，開發者們對基礎架構人員進行了嘲笑和抨擊。會議結束后，我同軟件團隊和我身份相似的一個人進行了一個走廊會晤。我們同意作為另一個團隊的聯系人。雖然這樣做花費了我不少時間，我從參加開發會議獲得的預先警告和信息讓變化管理流程順暢進行。這個系統也幫助開發者們認識到并不是所有的基礎架構團隊的成員都僅僅是想妨礙他們的工作。那個扮演聯系人角色的開發人員也告訴他們的人基礎架構團隊所需要處理的風險，以及為什么我們那么反感突然的變化。

　　在我們的會議中，我們建立了一個變化方法（變化的數量，變化的范圍以及變化持續的時間），它能夠幫助我們清楚地交流對于環境必要的改變。隨著時間的推移，我們建立起了一套通用的語言，并對彼此最終能夠幫助客戶節省時間和金錢的方法表示感激。在第一個項目中，我們沒有能夠理解這兩個團隊之間根本的不同。而在第二個項目中，我們使用了正式和非正式的方法來利用這種不同，以產生更具創新、更有效的解決方案。