2016年12月17日，又拍云Open Talk有米科技專場在廣州舉辦。此次Open Talk邀請了有米科技（834156.SZ）技術團隊的4位大咖探討技術領導力、大數據和用戶畫像、在線業務擴容的技術選型等話題。

今天小拍給大家整理了有米科技CTO蔡銳濤分享的《技術領導力：提升技術團隊的“有米實踐”》。

蔡銳濤對如何提升技術領導力方面分享了如下經驗：

先來了解一下有米科技吧~

我今天更多的是分享有米科技的技術團隊如何從一個大學生團隊一直做到現在。我分享一些技術領導力經驗，比如我們如何維護工程師的象牙塔，在每一個公司，一個團隊能做深入的技術研究是非常考驗人的一個事情，這也是每個CTO要做的一個事情，既要技術跟業務結合，也不能讓業務去太干擾技術的發展。

有米科技的技術團隊平均年齡在25歲，今天和我一起進行分享的三位同事里面，有兩個畢業還不到三年。有米科技的體系比較完善，現在有120多個工程師，有1945個公司內代碼庫。

最近4年來，技術團隊達成了以下一些成就：

關心核心技術，充分運用云服務

講完背景再講一下技術的領導力在有米是怎么做的。

我覺得作為一個領導來說，應該是帶領，而不只是鞭策。

有米科技打造技術領導的一個核心在于“關注核心技術”。

從有米科技的創業到現在，技術團隊只關注自己的核心技術，大量使用外部資源，能不用自己做的就不用自己做，能用錢解決就用錢解決。

有米科技是國內最早使用云服務的一批公司，這其中也包括了又拍云的云服務。有米科技在2016年已經把所有物理服務器轉為云服務器。

第二點，有米科技非常重視強化工程師個人能力。在我們這邊工作，分工不會做得非常細，運維、DBA、架構師這三個崗位在我們公司里是沒有的。我們一開始創業就立下了一個規矩，不設運維崗位，我們80%時間是開發各種各樣的工具做自動化的管理。

我們可能更傾向于在前端、大前端的技術方面做一個區分，最近在探討的一個話題，就是我們整個客戶端往大客戶端的方向上發展。

第三個，有米科技鼓勵跨領域，比如鼓勵工程師去做一個前端，了解非本崗位以外，特別是上下游技術領域。

提倡技術與業務結合

有米科技非常提倡技術與業務結合，我們正在做，我也不覺得我們現在能達到這樣的目標。

但是要往這個方向走，一個非常重要的就是要重視基礎組件的開發。只要重視基礎組件的開發，上一層做業務的工程師才能專心的做業務，目前，有米科技在公司內有統一的Web框架最佳實踐方案，同類技術方案能夠快速移植（比如廣告系統從國內到海外），此外還有統一的Devops方案。

業務跟技術結合，最重要的一點就是避免KPI導向，有米科技采用 OKRs進行績效評估，OA系統公開各項OKRs。現在是實驗階段，如果有相應的時間可以考慮分享大家，O就是公司、所有人的目標，整個團隊的目標是什么都是公開透明的。

怎么樣把公司的目標轉化為產品、技術的目標，此外還要關注整個技術的目標完成情況，不能為了短期的運維發展不需要的技術……這些是執行過程中需要去平衡的一個問題。

我們堅持每個月做OKRs的梳理，關注結果也關注過程，執行OKRs需要不斷去調整，這也是我們其中的一個心得。

重視分享和寫作

“分享是最好的學習”，我們公司內一直在強調這個事情，每一次去做分享，受益的不是下面這幫聽眾，受益的是上面的分享者；因為準備PPT要收集很多資料，這是一個轉化知識的過程。

我們在公司里面每周都會做一個分享，每周都會特批一到兩個小時的工作時間，由公司的資深工程師帶領進行分享。當然每個小組有各自的模式，有的是指定一個固定主題或者技術領域。分享這個事情我們已經堅持了三年，一直沒有中斷過，覆蓋了前端、移動廣告網絡后端技術、SRE、程序化交易技術、安卓客戶端技術、iOS客戶端技術、設計。在很多時候，分享是提升我們整個工程師能力的一個過程。

寫作是最好的思考。大家可以看一下，我們有92個空間，運行了6年，有15110篇內容，基本上每天要寫兩篇。假設你是一個應屆生，從熟悉工作流程，到構建一個系統，寫一個符合我們規范的小型項目，怎么上手，這些都基本上形成了標準化流程。

我們非常鼓勵團隊成員多去寫，而不是空口一說。如果你真正的思考寫出來，而且不是記流水賬，能夠讓一個從來沒有接觸過技術的人都能看得懂，這才是真的吃透了技術。

有米科技文檔里涵蓋范圍：

• 技術最佳實踐

• 每周分享

• 技術棧/工具鏈、庫的選擇

• 系統設計文檔

• 產品文檔

Q & A

Q1：CTO是一個業務和技術的結合，技術有時候需要跟非技術的同事去溝通，我可能是一個相對傳統的產品經理，但我覺得大數據發展以后每家公司都用得到，我可能想知道一些結果。我在得到這個結果的過程中，怎么跟數據處理、數據挖掘的同事去溝通，會更順暢一點？

蔡：我建議在討論需求或者想法的過程中，應該帶上工程師一起參加討論的過程中，而不是最后給到一個干巴巴的結果。有米科技是做移動營銷的，基本上只要是討論大數據交易或者數據交換，都會拉上團隊的領導一起去聊一下，數據維度夠不夠，跟我們的互補性夠不夠，能不能支持營銷需求。

我不建議一線工程師參加這個過程，讓技術的領導參加這個過程，從產品、商業是怎么樣去考慮這個問題的，只有讓他比較完整地了解整個問題背后產生的原因，他才能更好配合工作。

Q2：正常都是拉上領導去溝通，然后領導去分配、任務，我理解他是怎么樣跟下面負責執行的團隊成員進行溝通，他想是我要一個結果，你怎么老是不給我？

蔡：這個要看團隊的規模，如果你的團隊規模很大，那我很難幫你解決這個問題。這里面存在的問題就是組織架構的問題，而不是一個溝通的問題，比方說組織架構已經很僵化了。組織架構一定是要比較典型、靈活，團隊不要太大了。

Q3：我的問題是剛才技術團隊的實踐和管理方面的。如果是項目多了的話，存在一個橫向的分類：前端、后端、App、大數據平臺，他們之間的共同語言會更多；第二種就是分部門，Java開發部、安卓開發部等，大家沒有歸屬感，項目很難去落地。還有一種方式：每一個項目有一個獨立的團隊，前端的、后端的每一個崗位都配一兩個人，但來了一個新成員就沒有人帶。我不清楚您這方面有沒有實踐的經驗跟大家分享？

蔡：這個問題問得很好。有米科技其實也經歷過這樣的一個階段。

我們會把技術兩個層，一個是針對業務的，一個是針對底層業務的，還有做內部寫作優化的，就是所有項目組都可以共用的底層共有資源。在每一個業務線里有專門的技術團隊，就分成兩層，你可以理解為我們叫技術工程部是服務技術的，業務技術是服務業務的。

這里面當然也會存在你說的這個問題，因為每一個業務團隊有各種各樣的小項目，小項目里面怎么保證這里來了一個新人都沒人帶，有米科技的做法是支持、經驗全部文檔化，就少用語言等非標準化的方式來傳播。

小團隊里還有一個問題，就是說這個人、這個團隊這個項目不行了，要失敗了，那可能待不住了怎么辦？這也是比較棘手的一個問題，無法避免的，除非是讓他自然流失的情況下，如果你覺得這個項目不靠譜，你可以找另外的領導溝通，那個領導要你，你就可以過去了，如果發現說某一個小項目組的成員流動突然間往上漲，那可能就會考慮這個項目組的領導是不是合適了，或者說這個項目組是不是有存在的必要。

在項目管理這一塊，盡可能讓市場經濟用腳投票。所以在新項目一定要有足夠的準備和足夠的自信才能去帶一個項目，而不是隨便想去自己做一個新的項目。這其實是另外一種鞭策，這幾個人跟著你肯定是希望做出一定的成績，而不是就看你人緣好，每天請我吃飯就跟著你干，這樣的項目失敗率就絕對高。脫離了市場，脫離了產品的項目，只是一味的人緣好、跟著干，這是不符合市場規律的。

Q4：你們有沒有用到微服務？

蔡：有。有米科技內部主張不要過分強調太多的新興技術的東西，我們整個策略還是取它這里面某一項技術好的一塊。在技術上，有米科技是相對比較保守的。