我當初是怎麼管理技術團隊的

此文爲早期文檔

建立於2015/6/28

關鍵詞：管理技術人才、管理技術團隊、技術傳承、對題集/錯題集、研發哲學

本文檔適用人員：研發幹部

閱讀大約須要二十分鐘。

0x00，背景知識

窩窩技術團隊大約兩三百人左右，主要是五大塊：研發、數據、無線、質量、運維。

2012年年初，一個大項目結束後，我召開了飛行研討會，通過此次深入反思，造成了幾個影響深遠的管理觀點：

1. 管理者要向下提供工具，以造成幹部的簡單、易記憶、易執行的工做套路。

2. 幹部要直面白刃戰，必須隨時能深刻到業務細節。

3. 培訓直到最基層，有案例點評，結合正反實例反覆講，有機會就講，有機會就補充，有機會就強調，不斷檢查，不斷重複。業務精英都是從五湖四海聚集而來，工做習慣、方式、話術、意識不盡相同，因此須要經過重複重複再重複、CheckCheck再Check，不只僅要矯正錯誤行爲，更重要的是指明什麼是正確的行爲。

隨後的數年歲月裏，首先咱們在實踐中造成了本身的研發哲學：

1. Don't make me think：凡是被不少人不斷重複的好習慣，要將其自動化，綁定到工具之中，以"Don't make me think"的方式來推廣最佳實踐（best practice）。

2. If it hurts, do it more and often：若是一件事作起來很煩，那就把它拆成不少塊兒，天天作一點，每次作一點。

3. 這個世界歷來沒有什麼救世主：歷來就沒有什麼救世主，要創造人類的幸福全靠咱們本身，不要期望有什麼人能救咱們，只能絞盡腦汁闖陣。

4. 沒有苦勞，只有功勞：沒有結果就沒有意義。不要指望公司由於你和小夥伴們有苦勞而寬容大家沒有產出，這是一個商業公司。

其次，通過長期的磨合，咱們認同以下理論：

企業的研發管理應該注重創建一個良性的循環：

1. 研發能力的提高，有助於促進研發效率的改善；

2. 研發效率的提高，使得研發人員能夠有更多的空餘時間，進而激發更多的研發活力；

3. 研發活力的提高，研發人員積極交流與分享，有助於提高研發人員的整體能力。

過去的軟件開發方法論，每每只是注重了研發管理中的一兩個方面，缺少總體視角，經常指望以一套方法論包打天下。事實上，真實狀況下的研發管理，須要至少三套方法論：

1. 提高研發能力，主要依靠經驗積累，創建企業內部的知識庫與傳承體系（促進交流與協做，藉助研發活力促進研發能力提高，也很重要）；

2. 提高研發效率，主要依靠科學的數據分析，創建或引進一系列的研發工具，創建合理的流程與制度（經過提高研發人員能力，激發他們不斷改進效率，也很重要）；

3. 提高研發活力，主要靠多種社會化的溝通機制，促進分享與交流（給研發人員鬆綁，讓他們有足夠的空餘時間，也很重要）。

咱們從2012年開始推行的不少策略制度都暗合以上理論，下面展開講一講。

0x01，管控基本思路

=2012年=

1.1.RCA制度

話說2011年下半年，多個技術團隊融合，又處於「飛行過程當中換髮動機」的重構期間，陸續出現了項目一再 delay、Bug 數遲遲不能收斂、類似問題在不一樣團隊反覆發生、剛修復的 Bug 又復現等現象，團隊之間也互相抱怨。爲了遏制這種勢頭，我組織了一些項目管理者和你們分享他們以前的成功經驗，看看能不能從中找到解決之道。

2011年9月的一次分享會上，鮑嘉寶分享了他在上一家公司作飛信項目時下降 Bug 率的幾個措施：

方案一：逐步落實質量保障措施

1. 增長 RCA（Root Cause Analysis，根本緣由分析）制度，對 Bug 的成因進行分析和標註，定時彙總並通告，讓開發人員集體增加問題解決經驗，減小同類問題屢次出現的機率；

2. 開展協議與接口規範講解，下降使用方由於理解誤差或者使用隨意形成問題的機率；

3. 強制推行編碼規範，下降代碼隨意形成問題的機率；

4. 規範化技術方案實施與評審機制，下降邏輯層面與架構層面形成問題的機率；

方案二：Bug 評審會

1. 按期或不按期開展 Bug 評審會，清理庫存 Bug，或者針對難以解決的 Bug 協商處理方案；

2. 評審會上對「解決 Bug」和「作新需求」的優先級進行明確安排；

3. Bug 評審會還具有其餘職責，包括迴歸測試出現問題的解決方案討論，上線前遺留 Bug 的處理措施的肯定等。

最終，從2012年9月開始，研發體系正式推廣 RCA 制度，雙週一次 RCA 總結會，發送質量保障週報，公佈每一個開發任務的有效軟件 Bug 數和千行代碼缺陷率等指標。

當時的具體作法以下所示：

1）雙週一次RCA總結會

主持人：質量控制負責人

形式：會議

面向對象：研發全體+質量控制全體

時間：每雙週五下午14點～16點

開始執行時間：2012 年 9 月 28 日

規則：

1. 點評案例提早準備好，要點名；

2. 重點針對漏測 Bug ；

2.1. 兼顧有典型意義的 Bug；

3. 回顧每個 RCA 案例時，作到：

3.1. 形成的後果或影響，

3.2. BUG的緣由(必定要問清楚，說得太含糊可起不到警示做用)，

3.3. 漏測的緣由，

3.4. 獲得的教訓，

3.5. 過後補救措施或改進方案。

2）每週質量保障報告

報告人：質量控制負責人

形式：郵件

發送範圍：質量控制部全體，研發部全體，產品經理全體，SA 全體

第一份報告：漏測BUG簡報

字段：

項目名稱 上線時間 BUG描述 嚴重程度 發現人 線上處理辦法 責任人 缺陷類型

第二份報告：項目質量簡報

字段：

項目名稱 提測時間 測試用例數 (預計)上線時間 有效Bug數 嚴重Bug數 嚴重缺陷率 平均Bug解決時長 千行代碼缺陷率

在以後的幾年裏，咱們在技術團隊內部貫徹了 RCA 處理流程：

• 收集足夠多證據

• 從新描述問題

• 現象沒有描述清楚以前，切勿下結論

• 構建證據鏈

• 給出結論

• 線下重現

• 確認影響範圍

• 糾正線上數據

• 制定防範措施

• 撰寫 RCA 報告

• 公開通報（包括同步給其餘業務部門）

• 歸入 RCA 案例庫

時至今日，RCA 已彙總了七季，RCA 報告數百個，成爲了研發體系的寶貴財富。

RCA報告的標準格式爲：

1. 背景知識（Optional）

2. 問題現象

3. 影響範圍

4. 問題緣由

5. 問題分析過程（Optional）

6. 解決辦法

7. 後續處理措施：如線上髒數據如何修復，如對用戶形成的影響如何彌補等（Optional）

8. 經驗教訓

9. RCA類型：如代碼問題、實施問題、配置問題、設計問題、測試問題

=2013年 - 2014年=

在設定2013年工做計劃時，我明確須要解決以下三個問題：

1. 對產品的質量及細節（如穩定性、速度、體驗等）的把控不足，

2. 團隊的開發效率不夠理想（如產品的迭代速度慢），

3. 技術團隊對於行業關鍵技術的掌握能力偏弱。

我認識到，必須預留足夠多的研發資源，優先解決技術團隊平常開發和維護過程當中遇到的痛苦。

那時候咱們有哪些痛苦？

1. 開發聯調環境、測試環境搭建和部署麻煩，動輒服務中斷、接口，開發者爲此勞心勞力。

2. 系統之間的數據同步，通常經過接口同步調用達成，不夠可靠，不能保證最終數據一致性，遺漏後難以排查。

3. 層出不窮的定時任務難以管理，日誌難以查看，經常是用戶投訴了，咱們才發現定時任務沒有執行或者執行失敗了。

4. 不能保證平滑上線，經常通宵上線。

……

因而，2013年集中解決製造工具、持續集成和過程透明化數據化這三件事。

1.2.製造工具

製造（或發現）什麼樣的工具 ？答案是：

1. 提升開發效率的 ，

2. 提升系統可伸縮和可靠性的，

3. 不一樣業務線可複用的。

方法是：

• 找到技術團隊的痛點；

• 找到技術團隊的生產效率低的緣由；

• 抽象業務場景；

• 有針對性地深刻了解其餘公司如何解決的，梳理各類方案，向功課好的學生學習；

• 發現現有開源工具，或組織人員開發工具，制定和驗證高可用方案 。

實例：

• 自動化測試

• 早期的自動化測試都是基於 QTP 的，比較古老。2013年開始，質量控制部一支人馬開始基於 Robot Framework（Python）作，另外一支人馬則基於 Lazyman（Ruby）展開作。

• 持續集成

• 2012年你們想作持續集成，以後你們各自發展，一，主站所有切換到 gitlab 管理代碼，二，由 hudson 或 jenkins 驅動構建，三，使用統一的 maven 庫，四，去除那些影響構建和部署的配置項，五，運維部開發自動化上線的管理平臺。

• 定時任務調度和管理 JobCenter

• 最開始是由於多個定時任務停了或每天報錯，但無人知曉，直到用戶投訴。

• 因此痛下決心整頓。開發中間件 JobCenter 花了三個月，推廣又花了三個月。

• 異步推送 NotifyServer

• CMS 與商品中心之間的消息推送屢屢失敗，引起各類問題和投訴，排查費時費力。

• 最終決定自行研發一個健壯的中間件 PushServer。

時至今日（注：指2015年），積累的通用技術工具備：

1. 前期基於StatsD+Graphite，後期基於OpenTSDB的智能監控解決方案-天機

2. 定時任務調度與管理系統-JobCenter

3. 內部統一認證系統-IdCenter

4. 異步消息可靠推送-NotifyServer

5. 分佈式跟蹤系統-鷹眼

6. 分佈式緩存管理平臺-Discache

7. 基於ELK的異常日誌分析方案

8. 基於Diamond的持久化配置中心和業務降級方案

9. 基於ElasticSearch的搜索篩選排序解決方案

10. 基於FastDFS的文件上傳和分佈式文件存儲系統

11. 數據庫自動化運維平臺

12. 基於Apriori算法的Nginx+Lua+ELK異常流量攔截方案

13. 基於TCPCopy的仿真壓測方案

1.3.持續集成

 我在《窩窩研發過去幾年作對了哪些事》一文中講過：

每逢業務大躍進，就會欠下一屁股技術債。

是債就要還。

酷殼陳浩說過，技術債是不能欠的，要殘酷無情地還債。不少事情，一開始不會有，那麼就永遠不會有。一旦一個事情爛了，後面只能跟着一塊兒爛，爛得越多，就越沒有人敢去還債。

首當其衝的就是線下環境和線上環境的維護和發佈，大把大把的時間浪費在這上面，一代又一代的工程師在離職時表達了憤懣情緒。

因而，從2012年6月開始到2013年10月底，窩窩研發體系開始了持續集成第一季整改，萬事開頭難，這一干就是一年多。

所謂的第二季 CI，截止到2014年6月，至此，團購業務線基本作到了線下自動化編譯、部署、測試（日檢），線上自動化上線和回退。

第三季 CI 主要是讓 PHP 工程（CMS和SWP）和前端（CSS/JS/Images）也接入自動化上線體系，截止到2014年10月底，基本完成。

目前，基於 Docker 的私有云深入地影響着持續集成的方方面面，全部的環節都被改變了。

1.4.過程透明化數據化

2013年我在內部作職場培訓時，以《職場（潛）規則：心法和技法》爲題講過：

十三）解釋成本很高
彪悍的人生也必須解釋。
前面說過，多數人都不太清楚其餘板塊和部門在作什麼，是怎麼運轉的，管理方式是什麼，人都投在哪兒了，爲何作這件事爲何不作那件事，那個外部投訴是怎麼解決的，爲何一個我認爲簡單的問題大家卻遲遲未解決。
若是咱們沒有作到冰箱陳列式的項目管理方式，若是沒有養成信息第一時間同步、通報的習慣，咱們就可能被迫過後解釋。
當你須要解釋的時候，其實已經有點兒晚了。
別人心中可能已經造成了觀點，可能還傳播出去了，你又保證不了你的解釋能讓該聽到的人都聽到，聽到也不見得再幫你傳播。

還會耗費你我大量時間解釋，與其如此，不如提早主動通報、制定流程和信息同步。

因此咱們應該有意識地遵循以下模式：

模式75 冰箱門

——團隊成員按期地把各自的工做成果展示給團隊全部的人。

項目產物的公開展現反映出團隊成員之間的信任，它傳達了一種信號——沒有什麼會僅僅由於主觀緣由而隱藏起來。沒有人會由於讓其餘人看到了未完成的事務或進度延遲而擔憂。冰箱門型項目上的團隊成員基本上不會去「偏袒」或者粉飾本身的進度報告。

 

因此，從2013年3月開始，咱們試圖一步步作到過程數據化 ，而後作到過程透明化：

• 按項目：

• 收集項目實施中的各類數據

• 資源投入、佔用和釋放

• 工時

• 加班工時

• 代碼統計信息

• 測試用例數

• BUG數/嚴重BUG率/缺陷類型/解決時長

• 線上漏測數

• 千行代碼缺陷率

• 按部門

• 細分到日的人員工做飽和度

• 技術分享和培訓的類型和工時

• 過程透明化

• 每個流轉環節都向外部干係人通告，過程透明，數據可檢索

• 提早發出延期預警通告

• 提早發出風險警示

1.5.預研藥不能停

工程師文化中有一條：願意投資比較長期的項目。是的，若是一個技術團隊總被」緊急且重要「和」緊急且不重要「的事情牽着鼻子走，沒有餘力去作」重要但不緊急「的事情，最後必定是被動挨打，積勞成疾，最後病入膏肓。

我在《窩窩研發過去幾年作對了哪些事》一文中講過：

職場潛規則裏我講過，必定要低頭拉車擡頭看路。

最開始咱們怎麼擡頭看路呢，那就是看淘寶這麼多年都怎麼過來的，他們在不一樣階段都在解決什麼問題。

馮侖說過，咱們要把別人的歷史看成本身的將來，這樣，才能知道過去人家在作什麼，咱們如今應該怎麼作。

因而，從2013年開始，咱們抽調寶貴的研發人力，花費三四個月去作 JobCenter、NotifyServer、鷹眼、數據倉庫，花費大量精力去測試 Dubbo、Cobar，作完這些還須要見縫插針地分批分期內部推廣。

但這些提早量都是值得作的，不然咱們極可能作着作着就「死作作死」了。

 

因此，藥不能停，技術領袖須要眼光放長遠，技術積累和傳承不可能一蹴而就，中間的坑一個也少不了，不趟怎麼知道有多少雷，曾鳴的話怎麼說的：

什麼叫戰略？

——作對了必定會有好結果。

什麼叫執行？

——中間的苦，一步也少不了。

時至今日（注：指2015年），咱們提早預研了這些解決方案：

1. 基於mesos+marathon+consul+registrator+haproxy+docker的容器虛擬化方案

2. 基於Shib+Presto的大數據即席查詢方案

3. 基於HUE+Oozie的Hadoop集羣調度與管理

4. 基於Piwik+Flume+Kafka+Storm的推薦評測系統

5. 基於Cobar的水平分庫方案

6. Disruptor在訂單交易中的應用方案

7. 基於Ionic+Cordova+Saas+Bower+Angularjs+CoffeeScript+Gulp的HTML5移動開發方案

8. 基於ArtTemplate+FrozenUI+Backbone+Zepto的H5輕應用方案

9. 灰度發佈平臺

10. 運維自動化平臺

11. 自助式報表解決方案

1.6.分享與學習的氛圍

 工程師文化中還有兩條：分享與學習的氛圍強，讓工程師有必定的冗餘時間自我學習新知識。這也暗合最前面我提到的研發能力、研發效率和研發活力三者之間的循環促進關係。

爲了激發研發活力，須要多管齊下，從2012年開始咱們有意識去作：

• 按期舉辦技術分享講座，當研發人員足夠多，方向足夠廣時，Topic 仍是有不少的；

• 爲了開講座，須要給主講人預留出必定的學習和準備時間；

• 爲了讓你們有研究有思考有實踐，不能把人全陷在具體業務邏輯開發上，不要過度追求低費率和性價比，明明10我的的活兒非讓5我的幹，最後項目也屢屢延期，一年到頭技術團隊也沒進步。

其次，研發工程師要可以清晰表達。別人聽不懂，多半是由於你講不清楚，你講不清楚，每每是由於你原本就沒想明白沒聽懂，天然也就沒邏輯。

因此，咱們重新員工入職以後就有意識要求他們，在試用期內，新人必須作一次技術分享和一次技術評審，面對各方的 challenge，逼着你們學會公開陳述和清晰表達。

之後，我打算實行講師制度，效仿微博的新兵訓練營，申請預算，爲訓練營講師的課件製做和授課支付費用。

1.7.組織架構隨需調整

當組織結構影響效率時，就要動動組織結構了 ，幹部都得擡擡屁股動動窩了。

首要目的是要避免以部門爲溝壑。何謂溝壑？阻礙了問題排查或解決，阻礙了技術方案的推行，某類型工程師過少造成管理死角或不利於技術進步，這都叫溝壑。

有時也可能爲新業務線提供骨幹和人員。這都須要調整部門結構。

以上這七點就是窩窩技術團隊在20十二、201三、2014這三年間所作出的管控策略。咱們認爲管理技術人才是一門學問，第一，外行不可能領導內行，第二，靠挖人，靠獵頭，一朝一夕之間不可能組建一支能打硬仗的技術團隊，那隻能攢出烏合之衆。

-第一節完-

頭圖圖片來源於必應搜索

歡迎訂閱個人微信訂閱號『老兵筆記』