技術團隊負責人應該具備怎樣的能力

本文由碼農網 – 馬天宇原創，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

感謝作者馬天宇（@V馬天宇）的投遞

正好寫2015年終總結，其實今年不太想寫的，但是公司層面要求有個人總結要弄，寫了個開始就情不自禁多寫了一些，談談這方面的總結吧。

公司的技術團隊負責人應該具備怎樣的能力？

或者說團隊Leader應該知曉和鍛鍊什麼樣的能力？

大公司、創業公司都經歷過，從Leader或創始人那裡學到了不少東西，自己也會慢慢總結，保持學習的狀態，這裡就發表一下個人想法，也參考了曾看到的優質文章和朋友的看法。

主要從業務、團隊、技術三個層面討論，當然它並不能適用所有公司，也能可引發一些口水，而且我做的是客戶端負責人，所以僅供參考咯。

1. 業務 

為業務負責就是為產品和服務負責，作為技術團隊，總要完成主要任務不是，總要把產品或服務好好的實現不是？

業務要和上級負責人統一認知，和總目標方向去保持一致，才能更好的完成產品和商業的設計與實現，否則力道有了而方向不一致，浪費體力且難以更好的輔助決策。

不同時期Leader也發揮不同的職能，初期側重從技術和專案實踐方面打通設想和打造產品，迭代和試錯，隨著業務發展，能從更合適的技術、構建、架構、業務模型等方面展開專項的工作。

目前能回顧考慮到的，關於做產品（服務），關於做事情，有這麼幾點要說：

有一個核心：設計之始或明確任務前，想好並確定一個核心或者中心目標，嚴格圍繞目標轉，最益先做！它並不能促進完成核心目標，是最好的砍掉理由，真沒有那麼多資源可以用！

功能與業務：我要求團隊個人應該對業務負責，而不是功能或程式碼。如果說功能是基石，而業務才是“生命”啊！功能與體驗等“有機”組成為業務。

要理解業務：整個團隊得深刻理解業務，尤其Leader更要首當其衝，仔細評估產品原型、互動設計，我們是關鍵人物先過初稿確定技術、運營可行避免浪費集體的時間，然後所有相關人一起過。

保持節奏感：目前採用專案拆分為周目標為核心措施。個別事情以天計，少數事情比如修緊急bug以小時甚至更小單位計。

服務可用性：我們是通過預發、灰度測試、可回滾等措施來控制釋出質量，保持較高的可用性。

忠實使用者群：集部分優質使用者入群，保持溝通，挺重要的，微信群雖然是當為首選但是群功能有點弱，我的開源專案主要用QQ群，也比較坑哈哈。

反饋與資料：反饋和資料都是驗證結果的最好的參考之一，追尋反饋背後的動機很重要，研究使用者路徑、功能使用等資料輔助確定下階段任務。

低成本試錯：儘量以最低的成本來試錯，避免大量浪費資源，不要過早優化和擴張，先單點或AB測試，驗證過後再鋪開。

方法與方向：很多時候方法比方向重要，好的方法可以不斷糾正方向，釋出較單純的功能來驗證問題和方案，應該避免堆積功能，盲目發散方向，沒有經過驗證的方向就是假設。

創新與迭代：精益創業的MVP策略有助於大多功能性或服務性新創公司檢驗產品，而創新型產品靠產品本身和培育市場拉動需求，但都需要事實檢驗和迭代完善。

手動和自動：初期能手動解決的問題動手解決就挺好的，一開始就考慮自動化機器化可能會延誤時間，或者高成本解決了一個頻率並不高的問題。

親為和團幹：沒有經過實踐驗證的事情負責人最好自己先親為，才能深切體會，形成一定感知後優化，或者交給團隊一起幹。

靈感和總結：靈感稍縱即逝，總結過期不候！應該有自己的全端雲筆記，和部落格。短期記筆記，長期入部落格，靈感可能就在你瑣碎的一瞬間，很多東西經過三五個月一忘而光。

2. 團隊 

一個公司的產品和服務，是其自身組織結構和溝通、工作方式的反映（康威定律）。

人員的架構會改變和影響產品的架構，產品一大，人分組拆開了，專案也跟著拆開了，越多人一起工作就更需要科學的流程和協作方法。所以說人和組織會決定或影響產品。

如果說初期目標是打造一個良好的產品或服務，隨著發展應該慢慢更著力於打造一個能開發良好產品的團隊。

以下幾個層面是我們去實踐的幾個點，其他沒想到的後邊再補充吧：

關於招聘：找到合適的人是關鍵，不要貪多貪大，創業公司招人較好的時機是不招就會死，注意避免青黃不接。交流技術的同時感受性格，性格不合適早點終止面試，相信直覺，年限、學校不重要，重要的是作品和能力。

明確職責：團隊應該明確關鍵人物的角色，公開規定好一個角色由誰來擔任，職責和指標是什麼，甚至可以約定任期是多久，因為角色是活的。我的主專案裡有一個PM角色（協助跟蹤進度等），一個PA角色（輔助協調、構建打包等），都是主工程師兼任。

充分授權：一個完整的團隊應該有充分的決策權，角色應該有比較明確的職責，可以給建議但不要隨意干涉個人的職責或決策。

關於協作：我的團隊就是統一IDE（idea）和構建環境，統一碼風，統一版本控制策略的。合理建立Tag、Branch，儘量規範使用協作工具。

關於溝通：我的做法是讓隊員遇到鎖事直接和當事人溝通，重要問題反饋Leader，保持充分溝通我們每週都要有一次全體碰面會議，最好有點零食。

團隊提升：選定一個主題、此項以周為節奏，每人都要充當講師，我們客戶端團隊已經系統的學了物件導向6大原則和23種設計模式，我們android、iOS、前端一起溝通技術。

開誠佈公：私下溝通為主很多時候是解決不了團隊、個人衝突的，要開誠佈公的面對面談，將衝突事情一一列出，對事不對人，根據輕重緩急，綜合當前狀況給出解決方案，是公司是全域性是狀況不能讓所有人滿意，而不是誰不能讓你滿意。

前途錢途：不談錢就是耍流氓，不要妄圖用成長壓制待遇，不要總想用青春換取血汗，做得好就是要好的回報，但是也要講規矩，一般能力先到位再要求待遇，當然其實還要看你的位置可替代性如何。

回報遠與近：眼前看能力，近期看薪水，遠期看期權（股份），看好公司一般略側重期權，看空則略側重薪水。心情、成長、待遇、期權組成一個人的主要回報，Leader應明白隊員想法並努力為團隊爭取合適的回報。

一些福利：公司每天會買些水果當下午茶，像蘋果、桔子、香蕉、哈密瓜、葡萄、etc，看季節的。員工慶生蛋糕、年度旅遊、節日活動等。

3. 技術

技術負責人最好是技術水準不錯，最差也要知識面廣，否則可能導致疑難無法解決，產品不穩定。

我們從以下幾個方面做了實踐：

風格統一：團隊內統一風格、規約、編譯環境，開始是idea作為IDE，年底整體遷移到AS、Gradle環境開發和管理。

鍛鍊思維：集體學習6大設計原則和23種設計模式，理論結合實踐，更深刻的認知物件導向的設計理念。

技術提升：優先完成業務，此項以更長時間為週期，在專案不那麼緊張時開立個人技術專案，我們選一個方向量化形成博文或者小類庫，Leader支援並協助隊員完成，培養人才，各有所長。

關於類庫：儘量選擇穩定專注、知根知底的框架，如果沒有，那就選擇知名開源框架，仍要深刻研究其程式碼。

關於業務：我們客戶端業全部的務統一構建在SDK子專案中，和View剝離，便於切到多種終端裝置。

關於架構：我們核心方向其實全部使用我寫的類庫，由通用元件、網路、非同步、資料庫等組成通用的底層專案，叫做LiteSDK，任何App幾乎都可以用它，可謂用之四海，它是可拆解並獨立發展的，剛才提到的業務SDK專案是基於它的。

學習前沿：盡力去接觸新技術吧，我們今年精力放在業務上了，2016年的技術方向涉及了React Native、rxjava、程式碼生成、自動構建等，雖然已不是新技術^_^。

我們第一個版本App五臟俱全，登陸、簽收等業務功能、二維碼掃描、友盟統計、圖片載入、下拉重新整理等檢視開源專案，但安裝包體積只有800K，極致的小。

兩款App友盟總錯誤率目前仍在0.00%（線上App版本的錯誤列表還是有零星的bug列出，難道友盟總bug率計算有問題麼 ）。

非常感謝團隊裡的每一位同事，團隊一起完成了這些，今年要有更好的進步和成長！2016加油。

哦對了，如果你的公司也有android app端，可以考慮下我的開源類庫：litesuits.com

也能做到極致的小吧，還挺穩定高效嘿。

關於作者

作者馬天宇，杭州一家創業公司客戶端負責人，5年客戶端開發經驗，開源愛好者，樂於分享，Github上釋出了一系列開源專案和框架，涉及網路、資料庫、藍芽、通用、併發等方向，開源站點：litesuits.com