date: 2017-11-6 17:55:56
title: 「進化: 從孤膽極客到高效團隊」讀書筆記

圖靈社區: http://www.ituring.com.cn/book/1759
百度腦圖: http://naotu.baidu.com/file/8ec171f03701ba263958f6255021138c?token=856a40b1d8a70f98

三大基石(核心原則): 謙虛(Humility) 尊重(Respect) 信任(Trust)
早失敗, 快失敗, 常失敗

天才程序員神話

天才神話:

• 關注你能控制的一個變數: 你自己
• 缺乏安全感(隱藏代碼)
• 天才神話 -> 名人效應: 人有一種本能, 發現領導者和楷模, 將他們偶像化, 然后試圖模仿他們

事實:

• 如果總是獨自工作, 失敗的風險就會增加, 你也會錯失成長的機會
• 「巴士因子(bus factor)」: 項目中多少人被巴士撞死會導致項目完全無法進行下去
• 除了巴士因子, 還需要關注項目的整體進度
• 程序員在使用小型的反饋循環時工作效果最好
• 獨自工作一定比多人合作更具有風險
• 不發表則消亡

團隊為王:

• 軟件開發是一項團隊活動
• 不要低估社交游戲的力量 -> 即使項目結束, 人際關系依然存在
• 快速失敗和迭代: 失敗是一個選項; 從錯誤中學習的關鍵是將失敗記錄在案
• HRT -> 減輕痛苦, 而非傷害 -> heart, not hurt -> 你 團隊 合作者 組織 用戶
• 放下自我: 不夠謙虛的人別擺架子; 并不是應該完全任人擺布; 和自信并不矛盾, 追求「集體」自我; 表現得服從有很多好處 vs 我要按自己的方法做
• 批評與自我批評: 建設性批評是基于尊重的; 不僅需要對自己的技術持謙虛態度, 還要相信提出批評的人是真心為你和項目好; 你的自尊不應該和你寫的代碼有任何聯系, 你和你的產品不是一回事; 討論僅限于代碼本身, 不涉及任何人的價值或編程技術
• 留出學習時間: 跨出舒適區, 接受未知的挑戰
• 學會忍耐: 結對編程
• 接受改變: 越愿意接受改變, 就越能引起改變 vs 越是脆弱的人, 越表現得堅強; 有時最好的做法就是直接承認, 我不知道; 隊友是合作者而非競爭者(vs 政客)

完備的事后分析報告(事故報告):

• 概述
• 時間線: 問題的發現/調查/解決
• 事件發生的主要原因
• 影響和損失估計
• 立即解決問題的一系列措施
• 預防事件發生的一系列措施
• 吸取的經驗教訓

團隊文化

文化:

• 維護團隊文化: 團隊領導者 vs 團隊每個成員
• 團隊契合度面試
• 讓團隊擁有卓越的工程師
• 基于共識的團隊
• 接受批評需要一定程度的自信
• 一切為了產品: 你的產品最終與人溝通, 而不僅僅與機器溝通

方法:

• 人少時使用同步溝通(郵件), 人多時使用異步溝通(郵件, bug追蹤, 文檔注釋)
• 最重要的是, 要保存所有的信息都存在項目文檔中, 大家都可以訪問
• 任務說明書: 簡明定義工作方向, 限定產品范圍
• 高效會議: 任何需要深入討論的事情都應該在會后進行, 只要求相關人員出席; 有人來負責主持會議, 保持會議簡短
• 面對面溝通(分布式團隊): 不要低估信息量; 重要性
• 設計文檔
• 郵件列表: 約定郵件談論規則, 保持文明, 防止「聒噪」的少數人「擾亂秩序」
• 在線聊天: 群聊與一對一即時消息
• bug追蹤系統
• 工程中的溝通: 代碼注釋應該關注代碼如此實現的理由, 而不是代碼的功能; 強調一致性; 不要署名; 每次提交必有審閱; 測試與發布流程

主持會議的五條簡單準則:

• 只邀請必需人員參加
• 草擬議程并在會議開始前盡早發出
• 完成會議目標即可散會
• 保持會議按議程進行
• 盡量將會議安排在中斷點附近(午餐/下班時間)

群龍不可無首

經理 -> 領導者
經理: 「有人向他匯報工作」, 而不是「必須發號施令」
唯一需要擔心的是, 所有事
服務型領導

反模式:

• 雇傭軟弱者: 你應該努力雇傭比自己聰明, 可以替代自己的人
• 忽視表現不佳者
• 忽視人際問題
• 與所有人為友
• 放寬招聘標準
• 把團隊當孩子管: 要讓團隊指導你不信任他們, 最好辦法就是像對待孩子一樣對待他們

領導模式:

• 放下自尊: 應該努力培養強大的團隊集體自尊和認同感; 信任團隊; 需要對自己的角色有基本的安全感, not all things; 犯錯時道歉
• 禪意大師: 作為工程師, 你可能慣于持懷疑態度, 還有些憤世嫉俗, 但是這種心態不適合領導團隊; 你可以把公司架構看做一組齒輪; 領導者總是身在舞臺之上; 提出問題
• 成為催化劑: 加速化學反應但是不損耗自身; 很多時候認識正確的人比知道正確的答案更有用; 失敗是一個選項, 在風險上 個人 vs 公司
• 成為老師和導師: 熟悉團隊流程和系統; 能夠向別人清楚解釋事情; 能夠判斷新人需要多少幫助
• 設定清晰目標
• 以誠相待: 我不會對你說假話, 但如果事情不能透露, 或者我也不知情, 我會如實地告訴你; 如果希望對方能聽取批評, 善意和同情是關鍵; 每次做出一個決定, 就像一列火車穿過城鎮
• 關注幸福度: 一對一對話結束時「你需要什么」; 關注團隊在辦公室以外的幸福度也很有用; 關注職業發展
• 放權, 但是也要做具體工作; 尋找接替自己的人; 知道何時出手; 給團隊一方凈土; 保護團隊; 肯定團隊的成就; 同意嘗試容易恢復的事情

the lead:

• 不想擔任管理者, 但不知怎的就擔任了領導者的角色 -- 管理炎
• 冒充者現象: 裝著裝著就成真了
• 無聊到興奮 -> 需要激勵; 散漫到自主 -> 需要指引
• 內在激勵: 自主性 卓越性(提供學習新技能/提高已有技能的機會) 目標

應對有害之人

「如何從有害之人手中拯救項目」
「驅除惡人」的經營同盟會 -> 創造一種拒絕容忍特定負面行為的團隊文化
將人視為純善或者純惡是幼稚的行為, 發現和譴責不可容忍的行為則更為有效和實際
團隊文化 -> 自我選擇性

最好的防御手段是制定一組有效的最佳實踐和流程, 鞏固團隊文化:

• 發布任務說明書, 明確目標和非目標
• 為郵件討論建立適當的禮節規范. 保存歸檔, 請新成員閱讀歸檔郵件, 防止少數人干擾討論
• 記錄所有歷史: 代碼 設計決策 重要bug修復 以往錯誤
• 有效合作: 保持代碼少改動, 可審閱, 增大「巴士因子」
• 明確 bug 修復/測試/軟件發布的政策和流程
• 降低新成員的磨合障礙
• 依賴基于共識的決策方法, 但也要制定備用流程

發現威脅:

• 不尊重他人時間
• 自大: 無法接受集體決定, 不能聽取/尊重相左意見, 或不愿做出讓步的人
• 頤指氣使: 整天抱怨不足之處, 又不愿給出任何直接幫助
• 溝通幼稚或混亂
• 疑神疑鬼
• 完美主義: 可能使團隊喪失行動能力

祛除毒素:

• 引導完美主義者的能量
• 對挑釁不予理會通常需要極大的意志力, 堅持住
• 不要過于情緒化: 你的工作是創造偉大的事物
• 在憤怒中尋找事實
• 以德報怨: 有時候表現得格外友善可以把人嚇走
• 適時放手: 知道如何識別敗局
• 放眼未來: 就長遠來說, 你確實相信項目將受益么? 沖突最終會以一種有益的方式解決嗎? 為了短期效益而損害團隊文化是不值得的

組織操控的藝術

大多數人所在的公司都存在各種問題, 需要應用某些操控技能才能有效的完成工作. -> 政治 / 社會工程 / 組織操控
經理為你服務, 還是你為經理服務?
你必須了解的是, 這些規則與計算機系統的規則沒有什么不同. 有些規則可以改變, 其他的規則可以打破. 明白了嗎? 那就來戰吧.

理想情況:

• 兩層: 經理和經理以外的部分
• 完成本職工作后, 尋求更多職責
• 承擔風險而且不懼失敗
• 表現得像成年人一樣: 別人怎么待你, 其實取決于你自己
• 對不確定的東西提出疑問
• 經理不是透視眼: 及時匯報工作進度

通常情況:

• 不稱職經理: 害怕失敗; 缺乏安全感而堅持插手; 知識就是力量而不愿意分享; 藏匿信息
• 辦公室政治家: 整天做出有影響的樣子, 而不是實際產生影響
• 管理不當組織: 工程師是完成商業目標的手段; 指揮和控制結構僵化有如割據; 充滿了極力維護組織層級的人; 缺少一些重要的東西, 比如焦點/愿景/方向

操控組織:

• 了解公司允許什么行為, 相信的自己的直覺固然不錯, 但從你信任的人那里獲得一些意見也非常重要的
• 另辟蹊徑: 在公司內做出改變 -> 讓底層接受; 說客 -> 找幾個支持你的人; 想法 -> 不在意功勞歸誰, 可以流傳很廣; 停止壞習慣 -> 替換為好習慣
• 學會向上管理: 需要確保自己的經歷和團隊外的人不僅知道你在做什么, 而且知道你做的很好; 盡可能少承諾, 多提交; 推出產品放在首位
• 將工作分為「進攻性」和「防御性」: 進攻性 -> 產品改進, 用戶可見; 防御性 -> 產品長期健康; 法律的十分之九是認知(財富); 防御性工作不要超過三分之一/二分之一
• 運氣和人情經濟: 運氣好的人「善于創造和捕捉偶然機會」
• 政治銀行賬戶: 人情經濟
• 晉升到一個安全職位: 能讓你升職的事情 vs 對公司重要的事情
• 尋找有影響力的人: 聯系人 老員工
• 寫信尋求高管幫助: 三個要點和一個行為召喚; 不那么生動, 但是 10s 就可以看完
• 備用計劃 - 撤退: 做正確的事, 等著被炒; 如果的確無能為力, 那就不要耗著, 走為上策

用戶也是人

用戶是軟件成功的命脈, 一份耕耘一分收獲

產品開發成功的要素:

• 一小群聰明富有創造力的人開始
• 注入 HRT 團隊文化
• 以服務的方式領導他們, 幫助他們打成合作, 作出明智的決策
• 內在激勵
• 保護他們免受負面影響
• 循環: 用戶使用 -> 反饋 -> 改進

用戶參與:

• 注意到產品: 存在 使用前看法
• 用戶體驗:是否達到預期 可用度 是否幫助了用戶
• 與忠實用戶高效互動

積極和用戶合作:

• 市場營銷: 不能忽視; 積極合作是可能的; 程序員總是邏輯感過強, 但大多數人的行為決策收到邏輯和情感的雙重影響, 必須考慮用戶對產品的感性認知
• 注意第一印象, 產品的最初一分鐘的體驗
• 少許諾多提交
• 與工業分析師謙恭合作: 用非暴力不合作的態度對抗一個系統, 絕對沒必要
• 可用性: 關注用戶, 其他都將水到渠成; 選擇聽眾; 考慮進入壁壘; 衡量使用量, 而非用戶數
• 設計很重要: 用戶為先, 不可「產品懶惰」(office的全工具條); 速度不容忽視, 延遲也是「進入壁壘」, 響應快速會對用戶產生很深的潛意識影響; 速度是一個功能; 切勿求全, 少即是多; 隱藏復雜性, 但封閉產品來束縛用戶不可取, 是因為愿意, 而不是無法離開
• 管理與用戶的關系: 客戶服務, 用戶希望建立聯系, 有人傾聽; 時間推移, 用戶增多, 平均技術水平降低, 而軟件復雜度上升; 尊重用戶智商; 保持耐心, 最關鍵的傾聽技巧在于學會理解人們想要說的是什么, 而不一定要試圖解釋他們實際說的是什么; 創造信任和愉快, 不存在所謂的暫時失去誠信, 信任是最寶貴的資源, 必須從別對自己太嚴肅開始

記住用戶:

• 市場營銷
• 產品設計
• 客戶服務

附錄

工程易做, 人際關系難處.
眾人的審視使缺陷無所遁形 -> 眾人的審視使項目保持相關性, 并按計劃進行
取得原諒比獲取許可更容易
發現一萬種走不通的路, 并不意味著我失敗了. 我不會氣餒, 因為每次失敗的嘗試都是前進的一步. -- 愛迪生
他常常游走在天才和瘋子的邊界上. 問題是, 如今天才是件商品, 舉止怪異已經行不通了. -- Greg Hudson
不要講愚蠢歸為惡意 -- Robert J. Hanlon
TED: 內向者的力量
如果討論不在郵件項目組中進行, 那就真的沒有發生過 -- subversion 項目組
愿望不是策略 -- Google 服務運維團隊
不要喂食能量生物 -- Usenet
任何層級組織中, 每個人都將晉升到他不能勝任的階層 -- 彼得原理

創客 maker
人件 peopleware
maker's schedule, manager's schedule
科學管理 scientific management
泰勒主義 Taylorism
技術主管 tech lead, TL
技術主管經理 tech lead manager, TLM