一向認為軟體開發就像是在搭房子或者說是在構建一座巨集偉的大廈，當然這根據工程的大小而定。其實細細想來軟體工程的很多地方都是借助於建築方面的知識，就從「工程」這個詞來說就是從建築學引進的，類似的還有設計模式注：食盡鳥投林，落了片白茫茫大地真乾淨等概念也是**於建築學。如此說來軟體的開發和建造房屋一樣，一般是多人合作完成的。如果您非要自己動手蓋乙個小平房也不是不可以，但請注意那一定是乙個足夠小的小平房。
其實要說起團隊開發讓人最頭疼的不是什麼技術問題，而是隊員之間的合作問題。尤其是遇到矛盾重重的團隊，那專案的進度一拖再拖將是家常便飯。團隊開發絕不是架個
svn拉幾個有水平的程式設計師就可以開始的事情！需要注意很多方面才有可能出色的合作完成一項工程。
l給力的專案經理（專案組長）
首先，專案經理（專案組長）必須全面的了解專案的需求，根據需求和組員們商討出一套合理的解決方案來。在這個過程中遇到不同的解決方案專案經理（專案組長）要敢於拍板，敢於承擔責任。無論選擇的對錯都要比不選擇要強，選擇時畏首畏尾只會令專案延期，而選擇錯誤大不了下次公升級版本。一般說來在能實現功能的前提下，使用者更加關心完成的日期而不是效能。因為每拖一分鐘使用者對軟體能否實現的信心就減小一分。
其次，專案經理（專案組長）要有霸氣。相信每個團隊都可能會遇到不配合的隊員，對於這樣的隊員盡量為他分配一些靈活性小的工作。如果隊員嚴重影響合作那麼就需要專案組長（專案經理）出面了，讓你幹嘛就幹嘛，不要廢話，出了事我擔著！畢竟在乙個專案中專案經理最大，專案如果出了問題客戶或老闆不會去責怪乙個程式設計師，他會直接劈頭蓋臉的罵專案經理（專案組長）。所以在專案中隊員有義務也有責任聽專案經理（專案組長）的安排。這也是為什麼專案經理（專案組長）在招人的時候格外注重隊員的合作能力的原因（是否聽從安排也屬於合作能力的一種），招個不聽話的人是多麼鬱悶的事情。
l敢於否定自己
在專案的設計階段，大家一起商討具體的解決方案。很多時候大家是為了面子而不願意否定自己的解決方案。其實這很容易理解，大家都是從程式設計師走過來的，程式設計師的通病就是常常盲目欣賞自己的**，在軟體設計的時候依舊「本性」難易，對於自己的設計不忍拋棄。一旦別人說自己的設計的有問題，恨不得馬上和其大吵三百回合。爭論，對於軟體的設計絕對是好事，越爭論對軟體的需求、設計越清晰，「辯則明」就是這個道理。但是必要的時候（大多數人不肯定自己的時候）就應該好好的想一想：爭論是因為面子還是因為自己的想法真的是完美的、無懈可擊的？難道別人的想法真的是不可就要的、爛到不行的？如果是前者，無論你是誰（普通組員也好專案組長也罷）為了整個專案、為了團隊，請放下自己的面子，否定自己！！！
l不要正面否定他人的意見
無論什麼時候都不要正面否定組員的意見，就算你是專案組長（或者專案經理）也不行！
在專案設計階段，當組員為系統提出其他的見解的時候，如果你覺得合理那自不必說表示贊同即可。如果覺得不合理，你要做的僅僅是把你的觀點擺出來和他的觀點對比，讓團隊所有人進行討論、選擇，到底哪個更有利於軟體的實現。
一旦專案設計完成，無論組員有任何好的方案都不應該採用！！！這時候要做的只是記下來為以後公升級系統做準備，這也是為什麼大公司的軟體（例如
windows
系統）往往在上乙個版本還未發行的時候下乙個版本就已經開始準備了。很多時候開發人員就是在開發的過程中產生了更好的解決方案。好的解決方案——記錄下來下次系統公升級就從些方面做起。
為什麼設計完成後不能「完善」？
如果在專案設計完成後再去修改設計，那麼很有可能對專案其他部分造成影響。整個系統經過了長時間的設計可以說很少再有前後矛盾的地方。如果突然改變某一方面的設計，很大機率會造成牽一髮而動全身的結果，甚至因為沿著這一處小小的改動走下去而使得整個軟體前後矛盾，最終導致推倒從頭再來的惡果。（還有什麼比重頭再來更糟糕？！！）
l善於利用第三人避免「踢皮球」
不得不說的是任何詳細設計文件，任何
uml圖都不會把系統的各個細節照顧到。畢竟文件以及
uml僅僅是建模，乙個大概的樣子而已。這樣一來難免會有細節部分沒有涉及到如果非常不幸，這些細節恰恰是在兩個開發者任務之間那就麻煩了。相互推諉責任，相互「踢皮球」是不可避免的，類似下面的話就會變成團隊的主要語言。 a
：「你的方法中怎麼沒有……的資料處理啊，這樣傳給我的我還得再處理！」 b
：「處理這個資料不應該是你做的麼？」 a
：……
可能無論誰處理一下這個資料僅僅需要
1個小時，但是爭論到底是誰的責任卻會花費數小時，這也是導致團隊開發進度緩慢的原因之一。但是如果有另乙個人在場（要是專案經理最佳），無論第三人到底向著誰，這場「戰爭」雙方人員比例肯定是
2:1。這樣一來對於整個專案來說會大大縮短不必要的爭論時間。
整個預期對話如下： a
：「你的
***方法是不是沒有處理……資料呀？」 b
：「這個資料處理應該在你哪吧，
c你說對麼？」 c
：「按道理來說，這應該是
b的責任，你看啊我是這麼認為的……」 a
：「我也是這麼認為的，還有就是……，
b你說呢？」 b
：「好吧，我這就去加」（雖有一千個不願意，雖有一萬個罵娘，但是……你懂得！）
l溝通的方式無比重要：
change your words,change your world
（點我呀）
要注意自己的說話方式，同樣的意思不同的表達，效果不同。不用或少用第二人稱，要多用「我們」、
「咱們」、「您」或者直接用暱稱（*哥、
*姐等等）之類的代詞開頭。試比較下面的句子
方式一：「你為什麼不這麼寫這個方法？」
方式二：「咱們為什麼不這麼寫這個方法？」
毫無疑問第一句帶有責怪的語氣，儘管你說的時候可能沒有這個意思，但是聽者會很容易這麼認為。如果再加上任務繁重、心情煩躁，那麼這勢必會造成團隊內部的不和諧。
無論自己的心情是多麼的不好，請使用禮貌用語！試比較如下不同的對話。
對話一：
a:「你的那個方法寫完了沒有啊，快一點啊！哥等著測試呢！」 b
：「哦」（
***跟誰充哥呢，慌你妹，趕死啊！就不給你寫！）
對話二： a
：「*哥（*
姐）咱們的那個
**方法實現了沒有呀，拜託稍微快一點啊，你那一搞定我這就基本可以完工了，完事兒咱一起去喝茶啊。」 b
：「好的呀，馬上啊~~」
一樣的意思兩種不同的表達方式，感受就截然不同。第一種很難讓人接受，正常的人聽了多少會不好受，雖然括號裡面的話並沒有說出口，但是那已經影響到了團隊內部的和諧氛圍。要盡量多用第二種那沁人心脾的話語才能使團隊更有戰鬥力！
其實關於禮貌用語方面中國人普遍做的不好，很多人認為大家都是自己人，那樣說話未免太虛假，恰恰相反正因為是自己人所以才更加需要尊重彼此！從接觸的外國資訊（例如外文、美劇）來看，在國外無論是不認識的人之間，還是親的不能再親的親人之間都是非常尊敬對方的。雖說中國是什麼「禮儀之邦」但是國內外對中國人禮貌方面評價普遍不高。我想這也可能是為什麼中國造不出大型軟體（作業系統、資料庫等等）的原因之一吧。缺乏友好的溝通，組員之間彼此不服氣、整個團隊矛盾重重、相互使絆，那這個團隊還合作個磷啊！！！
以上幾方面是自己在合作時候的感受，希望可以幫助您的團隊更好的合作，請牢記：沒有凝聚力的團隊最終的結果必是「
食盡鳥投林，落
了片白茫茫大地真乾淨
！」
——（《紅樓夢》
第五回）
拿什麼拯救你，我的團隊
一向認為軟體開發就像是在搭房子或者說是在構建一座巨集偉的大廈，當然這根據工程的大小而定。其實細細想來軟體工程的很多地方都是借助於建築方面的知識，就從 工程 這個詞來說就是從建築學引進的，類似的還有 等概念也是 於建築學。如此說來軟體的開發和建造房屋一樣，一般是多人合作完成的。如果您非要自己動手蓋乙個...
拿什麼拯救你，我的團隊
一向認為軟體開發就像是在搭房子或者說是在構建一座巨集偉的大廈，當然這根據工程的大小而定。其實細細想來軟體工程的很多地方都是借助於建築方面的知識，就從 工程 這個詞來說就是從建築學引進的，類似的還有設計模式 等概念也是 於建築學。如此說來軟體的開發和建造房屋一樣，一般是多人合作完成的。如果您非要自己動...
拿什麼拯救你，我的團隊
一向認為軟體開發就像是在搭房子或者說是在構建一座巨集偉的大廈，當然這根據工程的大小而定。其實細細想來軟體工程的很多地方都是借助於建築方面的知識，就從 工程 這個詞來說就是從建築學引進的，類似的還有設計模式 等概念也是 於建築學。如此說來軟體的開發和建造房屋一樣，一般是多人合作完成的。如果您非要自己動...