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

正好寫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
本文連接：http://www.codeceo.com/article/tech-team-managment.html
本文做者：碼農網 – 馬天宇

​