交流是貫穿整個項目之中的，項目收尾階段，組外之間的交流尤爲突出，交流不好，極容易出現問題，作爲組長剛開始處理時覺得與組外人員交流很麻煩，因爲大家的利益經常是對立，很容易把關係弄僵，但是後來細心觀察、思考、實踐後，發現一些小技巧，可以巧妙地解決很多問題，又何必大家爭得臉紅耳赤呢，現在回想起來還是別有一番樂趣的。
交流的前提：調節好自己的情緒
項目中間出了問題，換成誰都得惱火，特別是出現一些比較低級的錯誤，造成了不必要的損失，這時候你怎麼辦，馬上跑過去，找到當事人，劈頭就罵，假如你是別人上級，估計問題不大（其實也有很大問題呀，被罵人很有可能口服心不服）。假如別人跟你是平級或組外人員，再加上責任劃分不是很明確，別人本來還有點愧疚感，被你這一罵，逆反的心理起了作用，就跟你吵起來了，大家吵得臉紅耳赤，不可開交；等大夥把你們倆拉開的時候，你會發現：好像問題還沒解決呀？
出了問題，應該以解決問題爲主要目的。情緒一來，火氣一大，罵得別人狗血淋頭，反過來是你，你受得了嗎？在進行交流之前，一定要適當地調節好自己的情緒；是調節情緒再進行交流，而不是心平氣和地去和別人交流，因爲脾氣不是一天兩天養成的，一下子達到這境界有可能嗎？
說真的，我脾氣也不小，特別是剛畢業那一會，幾乎是有點屬於眼睛容不下沙子，容不了別人犯錯。在跟別人吵得臉紅耳赤後的兩三天，你再回過頭看到引發爭吵的問題，你會發現那個問題其實也沒嚴重，稍微處理一下就可以解決的事，犯得上吵架嗎？（不知道大家有這樣的感覺嗎？），情緒關鍵在於調節，以下是我的小方法：
（1）先歇而後行；遇了比較惱火的問題，覺得情緒上不是很好，不要馬上去處理，先歇息一下，讓其有一小段時間的間隔，比如上午出了點問題，下午再去交流處理，中午就是個間隔；這樣做看似是誤了些時間，實際則不然；估計你馬上過去處理，怒氣衝衝了，一般也辦不好事情。
（2） 預演罵人；即然有了時間間隔，再加上現在火在心頭，可以先預演一下罵人先了，找個沒人的地方，陽臺，走廊；把你想罵人的話罵出來，想怎麼罵就怎麼罵，當然最好是在心裏或者低聲，不要影響到別人。
經過了以上的調節之後，再去跟當事人進行交流，假如這時候還想罵人，那就罵他，經過了調節情緒還是要罵，可見這事比較重要，活該捱罵。不過就我自身，經過了（1）（2）之後，我覺得也沒那麼嚴重吧，該怎麼處理就怎麼處理得了，犯得上罵人吵架嗎？就算有責怪也不會是那種罵得狗血淋頭的。
關於情緒的小心得：
情緒對工作很重要，情緒好則工作效率高，情緒差則反之；在工作裏遇到有些人情緒控制的能力很差，動不動就發火、罵人；這不僅僅是個人的問題，極容易形成怒火傳遞，例如：上級領導把小組的組長罵了，組長則罵組員，組員只好把怒火發泄在工作上，工作做不好上級領導又火（是不是成了一個循環了？），整個公司充滿了火藥味，大家一肚子怨氣，這又何必呢？做爲小組的組長要勇於承擔一定的責任，讓怒火在組長這一級別止步是很有必要的。
與測試小組的交流
測試小組拿到開發打包的程序，按照設計，需求說明及使用說明書對程序進行相關的測試，測出來的BUG分爲如下幾個級別（因公司而異）：
1、設計中存在功能但產品中沒有
2、極其嚴重的錯誤導致無法工作
3、一個主要的錯誤但還可以工作
4、一個普通的錯誤但還可以工作
5、一個小問題
6、最好能加上的功能
這個BUG級別對開發人員來說比較重要
1、修復錯誤的時候儘量先修復級別高的。特別是時間緊的時候。還有很多時候都不是把整個程序開發完了再交給測試人員進行測試的，這時候測試人員把BUG表送過來了，但你手上又有任務，這時候只要先把3以上的錯誤修復即可，即保證了測試能夠繼續下去，又不會誤自己的開發任務。
2、BUG級別是考覈開發、測試人員績效的重要依據，也是之間矛盾產生的根源。測試人員希望找出越多的高級別的錯誤，這正好表明了程序開發的質量不高，而在程序員這邊素有把程序看做自己的孩子這一說法，再加上同一個錯誤劃分級別主觀因素比較重，測試人員與開發人員常爲了BUG的級別發生爭吵（在有些很嚴格的公司，一定數量某級別的BUG整個軟件不能發版，聽我一個同學說過，在他公司發生過一個開發人員在拿到BUG表後，直接把測試人員叫出來“單挑”），像這些情況主要是缺少有效的交流造成的，以下是我的做法：
（1）BUG表應先交給開發組組長，組長先過目
一來發現BUG級別劃分不當，可與測試組的組長交流，平衡雙方的利益，兩個同一級別的人討論下面組員的事，利益衝突不是很大，容易平衡，
二來防止兩組組員之間鬧矛盾，同一張BUG表由組長交給下面組員，與測試人員直接交給相應的開發人員，效果是完全不同的，前者組員一般是無條件接受，後面則不然。
三來防止兩組組員之間作弊，有時兩個人員私交太好，會做些小動作，影響組長對組員能力的判斷，
四來有利於組長對組員工作的監督，你不知道他的程序出了多少問題，你又怎麼知道他修復BUG時在忙些什麼呢？
（2）平時多注意融洽感情，不要一見面交流都是工作上的事。像融洽小組內部關係一樣，利用空餘時間兩組可以一起出去活動活動，再則可以在適當的時候請測試小組的人員吃吃便飯，中國俗語：吃了別人的嘴軟，拿了別人的手短；這樣的話在工作中測試人員說話就客氣多了，萬事好商量，當然這只爲了搞好關係，更有利於開展工作，私下裏搞太多小動作也是沒必要的，務實才是根本。
與銷售人員的交流
假如開發的是產品，在與銷售人員的交流主要是對銷售人員的培訓（這部分的工作可以由開發人員去做，也可以交給測試人員，因公司而異），出現的問題主要有：銷售人員在培訓時不認真，培訓時都說懂了，等去給客戶做演示時出了問題就推託是軟件的問題，以此推卸責任，到時丟單的責任就說不清了，在培訓時，我的做法是：
（1）培訓之後一定要進行考覈，不及格者有相應處理措施。沒有考覈就沒有壓力，沒考覈，銷售人員在下面聽課是漫不經心，搞小動作，發短信，玩手機遊戲； 一問有問題沒，懂了沒？個個都說懂，到了客戶那就出問題；在培訓之前先聲明要考覈，考覈不通過有相應處理措施，這招一出下面的人不但聽得認真，問題也多，這才能真正起到培訓的作用。
（2）要求銷售給客戶演示的流程一定要按照之前的規範走，甚至連錄入的數據都要求一樣。這是確保銷售人員在給客戶演示時不會出現錯誤的，特別是程序開發時拖了時間，測試不夠深入，這時候連錄入的數據都要求與之前練習的一樣，因爲這時候你不知道程序大概還有多少錯誤，什麼時候會出錯，但你只要知道這樣操作一定不會出錯就夠了。
還有個人認爲開發人員程序應多與銷售人員聊聊天，在閒聊時不僅可以獲取到客戶的很多想法，還可以從中提高與人交流的技巧，要知道銷售人員的主要工作就是與人交流呀！
與客戶之間的交流
客戶用程序的時候出了問題，當然很着急，人之常情嘛；問題轉到開發，去幫客戶解決問題，要儘量耐心點並表示一定的歉意，在具體的交流時針對問題有兩種大的處理方法。
（1）坦然承認是我方失誤，換取客戶的理解和信任。
（2）反扯是客戶方問題，倒打一耙。
“客戶是上帝”，只要說客戶用的軟件出了問題就應該是我方的失誤，採用第一種方法進行處理，其好處也不用我多說了，書上及各種相關的小故事都有很詳細的說明；例如：有客戶自己電腦中了毒，軟件用不了，像這種情況，我們一般也二話不說幫他清毒並弄好防毒的措施。
但客戶是上帝，也不能太過份，特別是有些客戶是那種得理不饒人，吃硬不吃軟的，你跟他說是你的問題，他可就威風了，以此來爲難你，讓你難堪；遇到這種情況，一律採用方法（2）進行回擊，其實軟件出了問題，很大部分是客戶對軟件操作不當，或者環境出了問題，這本來就是有點扯皮的。
在實際操作中我基本上都是使用方法（1）（佔99%）,畢竟大部分客戶都是比較好說話的，相互理解的，再有你責怪我、罵我，有個度我也就接受了。但林子大了，什麼樣的鳥都有呀，遇到特殊的，方法（2）特殊對待。
