我以前做什麽都喜歡一個人，靜悄悄地，誰都不鳥。工作了之後更多的是團隊協作，十幾個人的項目組和十來個人的部門都待過，打過交道的人多了之後對人與人之間的合作關系就有了一點點感悟，特此做一下總結。

-----------------------------------------------------------------------------------------------

關於BUG

現代軟件都是多個工(wu)種(zhong)之間互相配合協作開發的，既然哥幾個搭夥兒搞事情，事情搞多了，就難免有搞砸的時候，當事情搞砸出現問題的時候應該如何處理呢。

一般解決問題的兩個步驟：

1. 排查出問題出在哪裏（打開冰箱門）

2. 給出解決方案，執行並觀察結果（把大象塞進去關上冰箱門）

第一步，排查出問題出在哪裏，這一步是容易導致內訌的地方，沒人願意承認自己的東西有問題，但是爭吵是解決不了問題的（武力更不行...）。之前跟測試打交(si)道(bi)的經歷告訴我，靠吼是沒有用的，遇事一定要講道理，只有拿出證據才能讓人信服。

1. 不帶個人感情，有一個現象就是當我們對某個人的某個行為看不順眼的時候，慢慢會演變為對這個人整個人的否定，平時可能還看不出來，當遇到問題的時候就很容易被誤導產生偏激的想法。

2. 屬於自己職責範圍內的事情，當別人提出質疑的時候，應該自己證明自己是沒問題的，而不是讓別人來證明你是有問題的。

3. 如果證明確實是自己的問題，坦然承認並修復它，不許心裏明知道確實是自己錯了還死要面子梗著脖子嘴硬（我也有過信誓旦旦嘴硬的時候被鐵一般的證據啪啪打臉....~~o(>_<)o ~~）。

4. 不管寫的是代碼，還是腳本，關鍵操作什麽的都要多打log，log可以避免很多無意義的爭吵，log讓生活更美好（Axure是產品經理的利器，log是程序員的利器）。

5. 一定要博學，擁有一定的廣度和深度，當你對某個東西不是很熟悉的時候，人家說啥你也很懵逼，就很沒有底氣，所以說人醜就要多讀書是有一定道理的！

第二步，給出解決方案，執行並觀察結果

1. 誰汙染，誰治理。誰搞出來的問題誰負責修復它，一個是這個人比較熟悉，修復起來成本比較低，另一個就是培養責任感，現在很多程序員都缺少責任感。

2. 解決方案要公開，透明，別藏著掖著只說修復啦，到底怎麽修復的啊，拿出來給大家看看科學不，萬一有明顯漏洞也能及早發現避免bug reopen。

關於聯調

1. 自己做的東西，起碼要自測一遍確認沒有明顯問題再交給對方，這是對合作夥伴的基本尊重，不要傳個還有語法錯誤的文件說搞好了。

2. 如果是做前端的，頁面寫完了做點假數據，自己點一點，多用幾個瀏覽器測一測，server url要統一在一個地方配置，不要好幾個地方搞的人家部署的人頭都大了。

3. 如果是寫後端接口的，應該出一份接口文檔，此文檔以實用為主，哪個接口，接受什麽參數，參數數據類型，是否必選，默認值是啥，接口請求的樣例數據，接口響應的返回樣例，返回字段解釋等等。

4. 如果是傳統型軟件，計算任務（日期格式化之類的將原始數據轉為對用戶友好易讀格式的計算任務）放在後端沒問題，可能後端處理確實要方便一些，但如果是高並發型項目，服務器資源很寶貴，應該盡量將計算任務往前移，原因是顯然的。

最後，學好Linux很重要！學好Linux很重要！學好Linux很重要！

道理都懂，還是做不好.........

。

關於團隊成員之間協作的一點感悟