在一個專案中管理好基礎架構和開發團隊 （轉）
有時好象IT分裂成了兩個敵對的陣營。一邊是致力於穩定性的基礎架構工程師，他們要保護自己的環境。另一邊是開發者，他們經常努力去發現獨特的、更棒的方法來達到他們的目標。這兩個陣營之間的鬥爭是如此的激烈，以至於連最忙碌的經理都開始注意到這點。
一個失敗的專案
我參加的第一個大專案是幫助一個學校把一個基本財務資訊系統從一個平臺移到另一個平臺上。我作為基礎架構小組的解決問題專家以及配置專家。這個應用很陳舊，開發團隊還面臨著升級它，以符合該學校目前以及將來的需求的挑戰。
事情的開始很正常。我們架起了自己的伺服器，配置路由器，並在搭建IP子網路中找到了樂趣。當基礎架構團隊忙於進行穩定性測試的時候，開發者們卻退到他們滿是灰塵的房間和黑暗的角落裡去。他們在深夜工作。
該專案進行了一個月以後，這兩個團隊除了在我們每週的例會之外，就已經不說話了。進行了兩個月的時候，這些周例會也開始變味了。基礎架構團隊進行最後的配置並完成了基本的穩定性測試。開發團隊每週到我們這來，帶來新的變化，補丁和他們想放在伺服器上的程式。
雙方的脾氣都開始爆發。從我們的角度看，我們不理解為什麼開發者們不能接受我們為他們測試的，所有的偉大的事情。對於他們來說，這些開發者不能理解我們為什麼如此頑固。他們只是想要幫助客戶。
一天下午，事情發展到了頂端。一個開發者走進測試實驗室，在桌上放了一個軟體，並宣佈要我們在當天安裝並測試這個軟體。我告訴他我們要在別的時間來進行這件事--也許是下個月的某個時候，我有我的方法。他很不高興。事情從那個時候開始就有些失去控制了。我們面對面地站著，向對方大聲嚷嚷。
我們的客戶協調人剛巧在我們兩個扭打在一起的時候走進這個房間。他關上門出去了。兩個小時以後，那個開發者和我都被踢出了那個專案。但是，在我們走了以後，那個專案裡的兩個團隊之間的情況沒有任何改善。事實上，情況越來越糟，最後導致了整個專案的失敗。
發生了什麼？
除了我自己的不夠職業的行為，這個專案還受到一個根本問題的困擾。基礎架構和開發者這兩個團隊之間的關係製造了大量的緊張氣氛。我的大聲嚷嚷和那個開發者的失態只是表象，而不是問題的實質。辨認出並理解這個問題成了我在等待下一個新專案的時候關注的焦點。
在回顧了我們從事的工作型別之後，我認識到基礎架構和開發對於世界持有相矛盾的看法。這種矛盾不可避免地導致了兩個團隊之間的戰爭。
基礎架構團隊關注的是能力和風險管理。他們的目標通常包括諸如“快速配置”，“沒有麻煩的安裝”以及“快速的問題解決方案”等內容。經理們透過檢查當機時間和問題解決方法來衡量基礎架構。為了達到這些目標，有天賦的基礎架構人員努力創造穩定，低風險，高可管理性的環境。當變化讓他們難以達到目標的時候，他們就會有些抗拒風險。
程式設計師們則有著完全不同的文化。他們的目標包括解決商業問題，改造現有的程式來解決新的問題，並思考新技術的可行性。衡量他們的標準是他們能夠成功承擔風險的能力和願望。風險越大，他們能解決的問題越大，他們就越有成績。
這種討厭風險/喜歡風險的不同態度解釋了我每天從基礎架構和開發團隊那裡聽到的評論。基礎架構團隊通常把程式設計師們看成是肆意妄為的牛仔。程式設計師把基礎架構團隊當作是庸俗古板的人，並抱怨說他們總是整天憂心忡忡。這兩者之間的矛盾是顯而易見的，所以這個問題就不是我們怎樣才能阻止這兩者間的戰爭，而是我們如何才能利用它，並從中獲得最大的收益。
利用緊張
從實踐的角度，我們不能夠改變這兩個團隊之間的緊張氣氛。冒險者和反對風險的人總是會起衝突。但是還是有可能利用這些不同的觀點並讓他們能夠在理智的環境中一起工作。
最簡單的辦法是指定兩個團隊中最外向，喜好交際的人作為同另一個團隊的“聯絡者”。聯絡者參加對方團隊的會議，學習去了解對方想要什麼以及對方如何處理問題。這在兩個團隊之間建立了一點相互的理解。同時保證了他們之間非正式的溝通。
一個更復雜的方法是建立基本變化管理。建立起一套可以接受的方法和時間讓兩個團隊坐在一起討論變化。在這個會議之外，建立一些非正式的頭腦風暴會議來讓兩邊關鍵的人表達自己的意見。在正式會議沉悶的氣氛之外，非正式的交流使兩個團隊能夠建立共同的目標。
快速前進
幾年以後，我發現自己再次參加了一個專案，該專案中也包含了大型的開發同基礎架構團隊。當敵對的陣營開始形成的時候，我利用自己作為高階基礎架構管理人員的身份，建立了一個變化管理流程。在第一次會議上，開發者們對基礎架構人員進行了嘲笑和抨擊。會議結束後，我同軟體團隊和我身份相似的一個人進行了一個走廊會晤。我們同意作為另一個團隊的聯絡人。雖然這樣做花費了我不少時間，我從參加開發會議獲得的預先警告和資訊讓變化管理流程順暢進行。這個系統也幫助開發者們認識到並不是所有的基礎架構團隊的成員都僅僅是想妨礙他們的工作。那個扮演聯絡人角色的開發人員也告訴他們的人基礎架構團隊所需要處理的風險，以及為什麼我們那麼反感突然的變化。
在我們的會議中，我們建立了一個變化方法（變化的數量，變化的範圍以及變化持續的時間），它能夠幫助我們清楚地交流對於環境必要的改變。隨著時間的推移，我們建立起了一套通用的語言，並對彼此最終能夠幫助客戶節省時間和金錢的方法表示感激。在第一個專案中，我們沒有能夠理解這兩個團隊之間根本的不同。而在第二個專案中，我們使用了正式和非正式的方法來利用這種不同，以產生更具創新、更有效的解決方案。[@more@]
一個失敗的專案
我參加的第一個大專案是幫助一個學校把一個基本財務資訊系統從一個平臺移到另一個平臺上。我作為基礎架構小組的解決問題專家以及配置專家。這個應用很陳舊，開發團隊還面臨著升級它，以符合該學校目前以及將來的需求的挑戰。
事情的開始很正常。我們架起了自己的伺服器，配置路由器，並在搭建IP子網路中找到了樂趣。當基礎架構團隊忙於進行穩定性測試的時候，開發者們卻退到他們滿是灰塵的房間和黑暗的角落裡去。他們在深夜工作。
該專案進行了一個月以後，這兩個團隊除了在我們每週的例會之外，就已經不說話了。進行了兩個月的時候，這些周例會也開始變味了。基礎架構團隊進行最後的配置並完成了基本的穩定性測試。開發團隊每週到我們這來，帶來新的變化，補丁和他們想放在伺服器上的程式。
雙方的脾氣都開始爆發。從我們的角度看，我們不理解為什麼開發者們不能接受我們為他們測試的，所有的偉大的事情。對於他們來說，這些開發者不能理解我們為什麼如此頑固。他們只是想要幫助客戶。
一天下午，事情發展到了頂端。一個開發者走進測試實驗室，在桌上放了一個軟體，並宣佈要我們在當天安裝並測試這個軟體。我告訴他我們要在別的時間來進行這件事--也許是下個月的某個時候，我有我的方法。他很不高興。事情從那個時候開始就有些失去控制了。我們面對面地站著，向對方大聲嚷嚷。
我們的客戶協調人剛巧在我們兩個扭打在一起的時候走進這個房間。他關上門出去了。兩個小時以後，那個開發者和我都被踢出了那個專案。但是，在我們走了以後，那個專案裡的兩個團隊之間的情況沒有任何改善。事實上，情況越來越糟，最後導致了整個專案的失敗。
發生了什麼？
除了我自己的不夠職業的行為，這個專案還受到一個根本問題的困擾。基礎架構和開發者這兩個團隊之間的關係製造了大量的緊張氣氛。我的大聲嚷嚷和那個開發者的失態只是表象，而不是問題的實質。辨認出並理解這個問題成了我在等待下一個新專案的時候關注的焦點。
在回顧了我們從事的工作型別之後，我認識到基礎架構和開發對於世界持有相矛盾的看法。這種矛盾不可避免地導致了兩個團隊之間的戰爭。
基礎架構團隊關注的是能力和風險管理。他們的目標通常包括諸如“快速配置”，“沒有麻煩的安裝”以及“快速的問題解決方案”等內容。經理們透過檢查當機時間和問題解決方法來衡量基礎架構。為了達到這些目標，有天賦的基礎架構人員努力創造穩定，低風險，高可管理性的環境。當變化讓他們難以達到目標的時候，他們就會有些抗拒風險。
程式設計師們則有著完全不同的文化。他們的目標包括解決商業問題，改造現有的程式來解決新的問題，並思考新技術的可行性。衡量他們的標準是他們能夠成功承擔風險的能力和願望。風險越大，他們能解決的問題越大，他們就越有成績。
這種討厭風險/喜歡風險的不同態度解釋了我每天從基礎架構和開發團隊那裡聽到的評論。基礎架構團隊通常把程式設計師們看成是肆意妄為的牛仔。程式設計師把基礎架構團隊當作是庸俗古板的人，並抱怨說他們總是整天憂心忡忡。這兩者之間的矛盾是顯而易見的，所以這個問題就不是我們怎樣才能阻止這兩者間的戰爭，而是我們如何才能利用它，並從中獲得最大的收益。
利用緊張
從實踐的角度，我們不能夠改變這兩個團隊之間的緊張氣氛。冒險者和反對風險的人總是會起衝突。但是還是有可能利用這些不同的觀點並讓他們能夠在理智的環境中一起工作。
最簡單的辦法是指定兩個團隊中最外向，喜好交際的人作為同另一個團隊的“聯絡者”。聯絡者參加對方團隊的會議，學習去了解對方想要什麼以及對方如何處理問題。這在兩個團隊之間建立了一點相互的理解。同時保證了他們之間非正式的溝通。
一個更復雜的方法是建立基本變化管理。建立起一套可以接受的方法和時間讓兩個團隊坐在一起討論變化。在這個會議之外，建立一些非正式的頭腦風暴會議來讓兩邊關鍵的人表達自己的意見。在正式會議沉悶的氣氛之外，非正式的交流使兩個團隊能夠建立共同的目標。
快速前進
幾年以後，我發現自己再次參加了一個專案，該專案中也包含了大型的開發同基礎架構團隊。當敵對的陣營開始形成的時候，我利用自己作為高階基礎架構管理人員的身份，建立了一個變化管理流程。在第一次會議上，開發者們對基礎架構人員進行了嘲笑和抨擊。會議結束後，我同軟體團隊和我身份相似的一個人進行了一個走廊會晤。我們同意作為另一個團隊的聯絡人。雖然這樣做花費了我不少時間，我從參加開發會議獲得的預先警告和資訊讓變化管理流程順暢進行。這個系統也幫助開發者們認識到並不是所有的基礎架構團隊的成員都僅僅是想妨礙他們的工作。那個扮演聯絡人角色的開發人員也告訴他們的人基礎架構團隊所需要處理的風險，以及為什麼我們那麼反感突然的變化。
在我們的會議中，我們建立了一個變化方法（變化的數量，變化的範圍以及變化持續的時間），它能夠幫助我們清楚地交流對於環境必要的改變。隨著時間的推移，我們建立起了一套通用的語言，並對彼此最終能夠幫助客戶節省時間和金錢的方法表示感激。在第一個專案中，我們沒有能夠理解這兩個團隊之間根本的不同。而在第二個專案中，我們使用了正式和非正式的方法來利用這種不同，以產生更具創新、更有效的解決方案。[@more@]
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7839396/viewspace-937743/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 我在谷歌管理一個開發團隊谷歌
- 構建有效的專案團隊（轉）
- J2EE專案中開發團隊的組建（轉）
- Medium開發團隊談架構設計架構
- 團隊專案一
- JavaSE基礎專案：改進版開發團隊人員排程軟體Java
- IT專案團隊管理 （轉）
- 團隊專案：二次開發
- IT專案開發團隊建設與管理總結（轉）
- 為你的專案團隊舉辦一個Party（轉）
- 專案團隊的發展階段（轉）
- 專案團隊的“薪平企和”（轉）
- 集團資訊基礎架構架構
- 如何組織一個高效的開發團隊(轉)
- 多團隊敏捷開發的組織架構和協作模式敏捷架構模式
- 軟體專案中的人員管理和團隊建設 (轉)
- 團隊開發_軟體專案風險管理
- 專案管理過程之專案團隊（轉）專案管理
- 專案管理過程之專案團隊 （轉）專案管理
- 專案管理中需要處理好的四個問題(轉)專案管理
- 專案管理從改變團隊開始 （轉）專案管理
- 成功專案團隊角色模型——Belbin團隊角色模型（轉）模型
- 專案團隊建設有“四戒”(一)（轉）
- 管理好時間就是管理好專案 (轉)
- Zoopkeeper基礎（一）：架構和元件OOP架構元件
- 怎樣組建一個TPM專案團隊？
- 如何管理好團隊，團隊需要同心圓建設
- 團隊專案
- 專案管理 : 軟體專案團隊建設的“三個中心” （轉）專案管理
- 淺談團隊管理在IT專案實施中的作用
- 【Java】基礎_14_開發團隊排程系統Java
- 軟體專案團隊建設的“三個中心”(轉)
- 建立高效的專案團隊(轉載)
- 專案團隊的凝聚力(轉)
- 專案團隊建設“四戒”（轉）
- 專案團隊建設中的經驗總結（轉）
- 敏捷開發案例:用白板解決專案管理和團隊溝通敏捷專案管理
- 在開發專案中進行有效的專案管理（轉）專案管理