FPs

《極客與團隊》讀書筆記

team_geek_cover

《极客与团队》這本書是在看《技术管理猪鸡-1 开篇》注意到的:

Google 的芝加哥 office 有两个技术领导:Brian Fitzpatrick 和 Ben Collins-Sussman。他们合写了一本书,叫做 Team Geek。

這本書的副標題是“软件工程师的团队生存秘笈”,畢業一年認識到和同事合作、如何更高效的推進工作也十分重要,正如作者在書一開始提到了書的宗旨:

本書旨在幫助程序員改進理解他人、與人溝通,以及與人合作的能力,進而使其在編寫軟件的過程中變的更有效率。

這本書的核心是“HRT”,即“謙虛”,“尊重”,“信任”,不算是什麼祕訣,但卻非常難做到,一遍讀,一遍想着工作中的一幕幕,感慨良多,希望能在閱讀完這本書之後,在下一份工作中有更好的表現吧。
把書中的內容要點,以及一些隨想簡單的記錄如下,方便日後查閱。

注重團隊合作和分享

公開透明和信任可以極大的降低成本,以及強化公車因子。

公車因子::一個項目裏,需要有多少個人被公交車撞到才能令其完全癱瘓。

擴大“公車因子”,避免出現領地感。

分享協作,然後有良好的文檔積累,可以讓單個人免於四處救火,想起了《鳳凰項目》裏的超級員工“布伦特”。另外團隊合作帶來的榮譽感和激勵作用也非常大,過去一年的工作所在的團隊並沒有讓我有這種感覺。

三支柱(HRT):謙虛,尊重,信任

謙虛

沒有人是宇宙中心。誰也不是萬能的,誰都會犯錯。你必須不斷地提高自己。

尊重

你必須真心實意地關心同事。他們都是活生生的人,他們的能力和成績都需要得到肯定。

信任

要相信別人的能力和判斷力,在適當的時候懂得放權。

HRT

HRT 實戰

  • 放下自負
  • 學會批評和接受批評
    • “別把你的自尊和你的代碼等同起來”
  • 快速失敗;學習;迭代
    • “失敗是可以接受的”
    • “不要等到完美的時候再出來”
    • “真正的檢討應該包含有關學到了什麼,以及怎麼改正等經驗教訓的詳細註解”,爲了方便以後查看,和總結積累經驗。
  • 爲學習預留時間
  • 學習保持耐心
  • 對影響保持開放的態度
    • “你越是容易受影響,你就越能影響別人;你越是示弱,你就越強壯”
    • “同事是合作者,不是競爭者”

團隊文化

作者在這裏說的文化,其實更像一種團隊氛圍,以及團隊內形成的默契,而不是阿里那種強價值觀的文化。好的文化可以薰陶新人,讓團隊健康的運作,最終的目的都是帶來更高效的產出。

“如果你想要優秀的工程師爲自己的團隊工作,首先的就是僱傭出色的工程師”,優秀的人總是傾向於和優秀的人一起工作,能夠保持更好的節奏,也更好溝通,也常常見到劣幣驅逐良幣的情況。

優秀的人,大多數都很有主見和想法,可以說是比較難“管理”,一群平庸、混日子的人好管理,但是毫無戰鬥力。“基於共識決策的團隊”,是讓團隊成員都有主人翁精神和責任感,這個時候,好的TeamLeader不會擔心自己的地位受到威脅,而應該注重團結,和傾聽意見。

對付害羣之馬

這是第四章的內容,但是作者在團隊文化這章提到了,就給總結到一起了。

要剔走的是行爲本身,而不是人。

害羣之馬:

  • 不尊重別人的時間
  • 自負
  • 過分索求
  • 幼稚或者莫名其妙的偏執妄想
  • 完美主義

一些解決方法:

  • 轉移完美主義者的注意力
  • 別去搭理挑釁的傢伙,無視是最好的辦法
  • 別太感情用事
  • 抓住重點處理問題
  • 對付挑釁要不卑不亢
  • 知道什麼應該放棄
  • 關注長遠

這一部分還是需要看書中的詳細解釋才好回顧,只看這些有些寬泛。

溝通

“溝通的指導原則之一就是在同步溝通的時候(比如開會),人越少越好。而在異步溝通的時候(比如E-mail),涉及的聽衆越多越好。”
更重要的是,你必須確保文檔裏的信息要盡可能地讓所有人都看到。

想起之前一份工作,公司強烈依賴IM 工具,不勝其擾。而且某些領導一點小事就喜歡開個會,“聊一下”,然後一部分人放下手頭工作去了之後,只是站了幾十分鐘,回來還得拿起剛剛放下的事情,非常要命。

高層面同步

制定任務宗旨,準確定義產品的方向和範圍,這樣大家知道努力方向,同時出現分歧的時候,結果能夠更好的達成一致。

開會要有效率,開會的五條小貼士

  • 只邀請一定要參加的人
  • 開會前要決定好議程,而且要事先通知所有人
  • 達成目的後應該提早散會
  • 注意別跑題
  • 鏡像幣會議安排在休息時間前後(比如午飯時間,下班前等)。

遠程團隊要多溝通,同時也要勇於見面

注重文檔的編寫和積累

日常溝通

  • 郵件列表
  • 在線聊天
    • 儘量群聊
    • 聊天記錄可檢索

使用Bug 跟蹤系統

代碼註釋

“註釋應該儘量解釋爲什麼代碼要那麼寫,而不是去解釋代碼做了什麼”,“註釋不應該涉及過多細節”,“過猶不及”。

代碼署名

作者不建議在代碼中進行署名,更好的方式應該是通過版本控制工具,在裏面進行跟蹤,例如git。
之前工作中,需要寫很多監控腳本,爲了以後找到對應的負責人,會在腳本開頭署名,不過如果當初大家通過git 協作的話,就沒這個必要了。

代碼審查

“代碼改動應該儘量短小以保證審查的質量。”

測試和發佈

測試和發佈流程應該儘可能的自動化,測試自動化程度越高,“在修復bug 和添加新特性的時候就越自信”,也容易更早得發現問題。發佈流程越自動,越流暢快速,可以讓產品迭代得越快。

團隊主管

“傳統型經理關心的是怎麼完成任務,而主管只關心完成了什麼任。。。。(並且相信團隊能自己想出解決方法)。”,主管只需要負責設定大方向,這也是“信任”的一種表現。

僕人式領導

“僕人式領導要爲團隊填補前進道路上的裂縫,並在必要的時候給予建議,同時還要勇於沖到第一線。僕人式領導唯一要做的管理工程師就是對團隊的技術和人事健康情況負責。”

反模式

  • 僱傭聽話的人
  • 無視表現不佳的人
  • 無視人際關係
  • 和誰都是朋友
  • 降低招聘標準
  • 把團隊當小孩子

領袖的處事之道

  • 放下自負
    • “如果你能鼓勵這種提問,你才能有更多的機會聽到諫言,這能讓你成爲一個更好的領袖,團隊也會變得更加成功”
  • 做一個禪師
  • 保持淡定和冷靜
  • “工程師來問你建議通常是不是你去解決他的問題,而是要你幫助他解決問題,所以最簡單的方法應該是問問題”,“正確的做法是在HRT 的原則下,幫助他解決分析問題,從而達到讓他自己解決問題的目的”,“這通常能引導工程師得出答案,最重要的是,這是他自己想出來的答案,因爲也就回到了本章開頭所講的主人翁精神和責任感。”
  • 成爲催化劑
  • 引導大家達成共識
  • 給予團隊安全感
  • “在遭受失敗的時候指責個人則不利團隊,而且會從根本上阻礙承擔風險的意願”,“個人的成功可以在衆人面前表彰,但個人的失敗最好還是私下檢討”,“需要公開批評某一個人的情況幾乎是不存在的,絕大多數時候這樣做都是很過分,很殘忍的。團隊裏的其他人肯定早就知道這個人把事情辦砸了,所以完全沒必要重複講。”,應該抓住機會幫助團隊從失敗從成長起來。
  • 當一個導師
  • 三個條件:
    • 熟悉團隊的流程和系統
    • 向他人解釋事物的能力
    • 估計被知道的人到底需要多少幫助的能力
  • 設置明確的目標
  • 坦誠
    • 警惕三明治讚美法,即先讚美,再批評,再讚美。
  • 記錄團隊的快樂程度
    • 建立信任,建議一對一會議結束的時候問“你還有什麼要求嗎”,考慮團隊成員的訴求。
    • “絕對不要以爲人人都是工作狂----對別人在工作上能投入的時間不要有不切實際的期望。否則很容易失去別人對你的尊敬,甚至徹底絕望。”
  • 不必事事躬親,但也不能當甩手掌櫃
  • 尋找接班人
  • 知道什麼時候要做惡人
    • 不符合團隊要求的人,拖的越久,對團隊傷害越大
  • 保護團隊不受混亂干擾
  • 幫團隊遮風擋雨
    • “在條件允許的情況下,應該儘可能的和團隊分享信息,但是也不要把那些不太可能會直接影響到他們的事情告訴他們,這種組織性的混亂只會讓他們分析”
  • 告訴團隊他們乾得很好

激勵

  • 給工程師一個目標;
  • 讓工程師有機會學習新技術和提高技術。

操作組織的藝術

這一章作者列了一些工程師遇到具體問題該如何處理,節選幾句印象深刻的話。

“要儘可能確保你的經理以及團隊之外的人不但知道你在幹嘛,還要知道你乾的很棒”

“在做承諾的時候要謹慎,而幹工作的時候要盡最大努力”

“不管技術債務有多少,團隊也永遠不應該花超過三分之一甚至一半的時間和精力去做防禦性的工作,否則就等於政治自殺”

寫郵件求助要採用“三個論點和一個行動”,絕對不能有其他內容,讓他人能在10秒內讀完。

和用戶的關係

軟件要服務的是用戶,最後一章列了一些例如“要多溝通”,“注意第一印象”,“關注用戶”,雖然都很有道理,比較雜亂,是一些經驗之談,讀完就要用起來非常難。

整本書的內容都是圍繞HRT,不過人和人之間,總是能和HRT 扯上關係。 每章的獨立性其實不是很強,作者在講很多論點的時候,會穿插其他內容。總之,看完也很難記住,只能記住HRT,好好工作,多實踐。

This article is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
If you reprint it, please indicate the source: http://fangpeishi.com/team_geek_notes.html