團隊緊密協作

前言：jeff atwood，百度百科以及維基百科上都沒有其簡介，他是stack overflow的創始人之一，我是讀“陸其明”大牛的部落格了解到的，進而就在讀《effective programming：高效能程式員的修煉》一書進一步了解作者深邃的思維，我覺得對我個人而言，我很喜歡翻譯的文筆，更喜歡作者Jeff給我的啟發和感悟，每一節都值得我去深思和學習。

不關怎麼說，那總是人的錯

是啊，不關怎麼說，軟體開發過程中出現的任何問題，都不能怪罪于技術的原因，都是由人造成的。作者提出了一個我喜歡讨論的問題：“你喜歡你的同僚嗎？”

恐怕拘泥于我們中國人的禮節和教育，我們都會義不容辭的回答：“既使我不喜歡某一個同僚，但我不讨厭他（她）”。但是我能感受到，無論是在以前的公司還是目前的公司，我的确不喜歡一些同僚，當然别人可能也不喜歡我。然而我想表達的也是作者的觀點：“為什麼我不去找到我喜歡的人、尊敬的人、挑戰和激勵我的人，一起工作呢？”

上司需以身作則

很多時候，我們都能聽到一個聲音，一個公司的企業文化在于其老闆，一個團隊的執行力在于其組織者。這都是無可厚非的道理，所謂一隻羊帶領着一群狼無法和一隻狼帶領着一群羊進行抗衡也有着内在的道理。團隊能夠得到升華在于要有一個好的上司。

我們很多程式設計人員在面對他行的人時，總會沉默不語，而一旦面對自己的同行時，往往又誇誇其談。今天早上我們幾個同僚還在“秉持”着自己的觀點聊了很久，我發現我不是一個實幹家，因為很多時候也在耍嘴皮子，弄的是假把戲。我們總是在向别人提供建議的時候滔滔不絕，我們似乎也樂于去指導别人去按照自己的意願去做，而自己總是在行動上落空。那麼這樣的我們，又如何能獲得别人的信賴呢？

保持謙虛。在融入一個團隊的時候，如果不謹言慎行，沒有調查出結果之前為了表現自己多麼有經驗，而妄下斷論，最終的結果如果是錯誤的話，那就倒黴了。

提出建設性的批評時要小心。我承認，我在這方面做得不好，我在面對别人的錯誤的時候，總是容易沖動，把自己的意見強加在夥伴身上，當然是由于我和團隊成員相對熟悉了，如果在融入一個團隊時，就要小心了，盡量不要去冒犯他人。

要赢得他人的尊敬，最好是獲得實實在在的成績。我發現這個是真理，我之前總是喜歡把自己喜歡的博文放到我們團隊的群裡面，然而發現别人并沒有很感興趣，我堅持寫部落格，把自己在CSDN上取得的成績在群裡炫耀，别人也不感冒，當看到作者這句話的時候，我能夠釋懷了，隻有等自己做出别人無法取得到并且能夠證明自己的成績後，才能赢得别人的尊敬。

百說不如一幹。OK，這句話就不用再多做解釋了，放之四海而皆準，做一名實幹家永遠是對的。

如果你希望你的團隊能夠成為你想要的狀态，那麼首先就要求自己去做到，自己先遵守規則，如果你的成員做到了，而你并沒有做到，OK，低下你高昂的頭顱，向他學習。如果你想成為一名好的上司，那麼就以身作則，你不能披着“畢外公”的外衣去惡意中傷你所屬的團隊，是吧？！善意的對待别人，别人才有可能對你投桃報李。

程式員和系統管理者的黑夜傳說

目前我們的團隊還小，我個人就同時兼做兩個角色，而在之前的公司，分工很明确，一個項目的SVN管理庫、系統運作的環境等等都會交由固定職能的人員來管理，我作為開發人員，的确在有的時候很讨厭系統管理者，他們要求我按照各種規定來送出SVN，當然這是對的，但是我們當時沒有很好的相處。

結對程式設計和代碼評審

對于這個小節，我有的時候感到無力，因為我們的團隊從來不曾執行過代碼的“結對程式設計”、“代碼評審”。雖然我不認可結對程式設計，因為那太過可怕，小團隊來說簡直就是要了命，因為總共就兩三個人，如果還要交叉工作，那就等到天荒地老吧。但是代碼評審，真的是非常棒的一件事情，然而我們卻從來沒有執行過，我現在都深深感到遺憾，究竟是什麼造成了我們現在這個樣子。

我們團隊的有一些成員，總是抱怨團隊之間缺少“副手”，就是說一旦某人因為一些原因不能正常工作了，其他人對他負責的業務無從下手。我有的時候就是幹着急，我曾經提出的代碼review，從來都得不到實踐。

我很希望我們的團隊成員在完成代碼的開發後，能夠安靜的坐下來進行一次代碼的review，旁觀者去發現講述者所編寫的代碼存在的漏洞、不完美的格式、不夠簡潔的表達方式，還能去了解業務，真是百利而無一害啊，真希望以後我們能夠進行代碼的評審工作。

會議是浪費工作時間的最佳去處

對于會議，我們團隊也有很多弊端，開會之前大家毫無準備、會議主題總是不夠明确、會議内容散漫無記錄、上一個會議的結果從來不落實等等，我不是多麼的憎惡自己的團隊，進而提出各種銳利的批評，而是内心太希望我們的團隊能夠鳳凰涅槃，浴火重生，在未來呈現出新的面貌，為大家的職業生涯帶來價值。

會議絕對不可超過一個小時。雖然我無法斷定這是不是一個真理，但是絕對的值得考慮，畢竟漫長的會議會讓人沉沉欲睡，并且容易忘記。

每個會議都應該有一個清晰的目标。這當然是必須的，如果會議跑題了，那自然也是失敗的。

開會之前做好功課。如果參加一個會議之前，提議者沒有充足的準備那很荒謬，而如果旁聽者也沒有準備，那麼在會上就會不知所雲。

把會議變成可選的。這個是個好想法，如果與會者對目前主題不感興趣，OK，就不要去耗費時間了。

在會議結束的時候概括待辦事項。這很重要，另外我想追加一個就是“在會議開始之前，回顧上一次會議的執行結果”。

處理壞蘋果和壞蘋果是團隊的毒藥

所謂千裡之堤潰于蟻穴，和作者提出的觀點是一緻的。如果壞蘋果不及時處理，我們都知道，好的蘋果也會随之腐爛；而如果壞的蘋果遺留在團隊之中，就會成為團隊的害群之馬。

作者提到鑒定壞蘋果的警報信号：

他們掩飾自己的無知。就如同南郭先生一樣，他們精于藏匿自己的無知，他們會說“我的代碼太複雜了，無法測試”。

他們對于個人隐私過度在意。他們害怕别人檢視自己的代碼，進而不斷回避。

他們在意自己的地盤。他們不允許别人去修改他們的代碼。

他們抱怨團隊做出的決定。總是認為自己的是對的。

他們不會積極參與團隊的行動。他們無故請假，找各種借口不參加群體活動。

OK，這個時候，團隊上司要做的就是把他攆走吧！

“ 毫無疑問，有壞蘋果的團隊表現就會很差 。”

我們都知道木桶效應，木桶所能容納的水量在于最短的擋闆而不是最長的。如果團隊之中有害群之馬，而你無法鑒别出來，OK，那麼你就是那個需要被趕走的人。

關于遠端辦公

在這上面，也許我有很多經驗之談，因為之前在江蘇富士通，由于是做對日外包項目，自然少不了和在日本的人員進行溝通，那麼需要做的無非就是遠端越洋電話和視訊會議。

作者所說的遠端辦公，是建立在有相同程式設計熱情的基礎上，也是我一直想說的“有自我驅動力”，這不僅僅是在遠端協作上，在團隊中，同樣适用。如果團隊成員不是建立在同一願景下，也沒有很強的自我驅動力，團隊往往就會落後于他人。

下面作者提到的幾個觀點，我想我們日常開發也需要類似的做法：

實時交談。如果團隊成員不能在步調上保持一緻的話，那就讓人痛苦了，遠端協作的時候尤其重要，因為兩人身處異地，交流起來就更加容易被時間阻隔，那麼好的及時通信軟體很重要的。

固定的郵件清單。這個同樣适用于我們目前的開發團隊，我們的團隊分兩塊，兩塊的言語和架構不同，大家之間的交流就更少之甚少。雖然我們每個團隊小組都有自己清晰的郵件清單，每天都會要求發送工作日報給彼此，但是我們的執行力還不夠，需要加強。

語音和視訊聊天。OK，講話在一些方面上的确比文字來的直接和痛快。

另外我接下來需要做的流程：

周一的團隊報告：我們上周做了什麼？這周準備做什麼？有什麼阻礙我們前進。這個主題和站立會議差不多，現在說起來都慚愧，說好的站立會議，我們團隊也執行的不夠。

會議紀要：是的，當我們在讨論的時候，必須要把重點内容記錄，所謂好記性不如爛筆頭，就是這樣。