有時候正工作呢，突然就會聽到兩個兄弟聲音放大，言辭也開始變的激烈。
這事兒實在太常見，以至於不需要具體案例大多數人就能想象到是怎麼個場景。
現在的關鍵問題是這個時候經理m
應該幹點什麼？
我個人感覺，有兩種極端的處理方法一定不太行。
一是完全置之不理，就是假裝沒看見，你們吵成什麼樣算什麼樣。
一是什麼事都管，一有爭吵就開始調解，消除所有不「和諧」聲音。
前者比較失職，工作中，人員間矛盾大多與工作有關，完全不處理必然影響到工作，所以即使單純從對工作負責的角度看，這也是種失職。
後者會顯的過於婆婆媽媽，大家都是成年人，不是小學生，你什麼事情都管，討人嫌不說，也不利於當事人成長---
有些能力是要在這種環境中才能練出來的。
還有一種搗糨糊的方法也不太行。
搗糨糊是指看看情形不對，開始分別安撫，誰都很對，先不要吵了是正經。
這招兒和山體綠化跟不上，就塗油漆實質上差不多，矛盾還在，只不過找點東西給蓋上了。
個人感覺，做上司的，遇到這種事一定不能退縮，很多上司實際的活本來就做的少，這種事情，你還退縮，那實在說不過去。
首先要傾聽，在雙方沒有徹底情緒化之前，不要介入，可以讓a和b
做略有點激烈的溝通。
一旦判斷雙方已經情緒化了，比如：完全各說各話，比如已經開始罵人並可能造**際上不可修復的傷害了，那就要趕緊站出來終止爭議。
這時候不能不持立場。
在a面前說
b不對，在
b面前說
a不對，就成搬弄是非的小人了，是大忌。
a也對，
b也對，那就是搗糨糊。
上述兩者都是不持立場，是能力不足的表現。
這時候其實是統一團隊認識的好機會，不管面對a還是b
都要明確傳達是非觀點。
這裡隨便舉個常見的例子。
如果說一戰時候，火藥桶是巴爾幹地區，那軟體開發世界裡的第一火藥桶是開發和測試的交界處。
開發和測試很容易互相抱有敵意。
測試人員辛辛苦苦找到了乙個磁碟滿時會出異常的問題，認為問題很嚴重，把它標為critical
。開發人員則認為規格書裡沒寫，也是非常稀有的場景，完全不值得大驚小怪。
這時候開發者表達時可能因為言語輕蔑，並直接流漏出了你啥也不懂的意思，激怒了測試人員，於是開吵。
處理這類事情本身並不複雜，首先要回歸到絕對的理性，回到文件化的東西。
如果測試人員的行為與已定義規則相符，那開發人員的抱怨屬於無理要求。
如果與定義略有不符，那就要看是不是屬於判斷失誤（因為有模糊區域），如果是測試人員判斷失誤，那就確實是測試人員的問題。
接下來也不能漠視表達的問題，不管工作上是非如何，如果確實有人口出惡言，那不管有理沒理，在表達上是這個人不對。
畢竟作為團隊，可以觀點不同，但要互相尊重。
這種火藥桶區域還有很多。
比如技術流派上的選擇（想想語言的爭論吧），**轉移的前後兩個負責人，有關聯兩個模組的負責人，新手和老手，負責需求的和負責開發的，review
的和被review
的，做具體工作的和做
ppqa
的等等。
形象來講可以叫有人的地方就有江湖，有江湖的地方就有爭吵。
從基本原則來看，首先要「立法」，盡量要有大家事先形成共識，並約定遵守的東西。
其次就只能靠經理m
的判斷，所以做
m可以不是很專家，但你的視角要有高度，要有自己的「道」，並且不能畏懼處理人際關係的問題，否則還是不要幹這活比較好。
至於經理m
可以有什麼樣的「道」就微妙了，暫不解釋，不是賣關子，是太費勁，但「道」的前提倒是好說，它應該是不矛盾並具有一致性的。
你的團隊裡沒有DevOps文化
球很多的系統負責人和程式開發者都在撰寫 聚會 和 討論關於devops的事 如何能更加有效的協作 讓我們更快的創造商業價值。devops的目標是摒棄傳統的深根於開發和實施過程中那種單打獨鬥的思考方式。那麼，你如何能辨別你的團隊是否已具有devops文化了呢？下面的內容將會給你一些線索。心理上的dev...
如何和開發吵架
有一次，產品發布了乙個新的版本。老闆發現有個莫名的commit，後來查清楚是乙個開發同事發現是他自己發行的版本裡寫錯了乙個判斷條件，導致產品在公升級過程 現異常，他偷摸兒的修改 後，偷摸兒的提交到已經發布了的版本的branch上。對於完全不知情的其他人，我只是其中乙個。現如今我們老闆決定打乙個hot...
團隊軟體工程怎樣順利進行，避免吵架
1.使用妥善定義的流程，流程中的每一步都是可以重複 可以衡量結果的。2.團隊的各個成員對團隊的目標，角色，產品都有統一的理解。3.盡量使用成熟的技術和做法。4.盡量多的收集資料 也包括對團隊不利的資料 並用來幫助團隊做出理性的決定。5.制定切合實際的計畫和承諾，團隊計畫要由負責具體執行的角色來制定 ...