Editor‘s Notes：
CTO 都是一羣“善變”的人，上半年還在爲了“996”是否合理吵得天翻地覆，下半年就開始琢磨除了 996，還能怎樣提升團隊效能。其實這也不怪 CTO 們，當下時代技術開發的核心詞就是“快”，敏捷開發、快速反應，只是“快”也要講求合理高效的方法。9 月 22 日，二維火 CTO & TGO鯤鵬會杭州董事會小組委員蘆宇峯出席杭州分會活動《技術團隊效能提升的創新與突圍之道》，分享主題《通過強化組織、過程提升技術團隊效能》，從將組織系統化、量化工作過程兩個維度闡述了提升團隊效能的實踐經驗。當 996 的效果不再明顯，項目時間越來越緊張，你或許應該讀讀這篇分享。
編者注：查看蘆宇峯完整版 PPT，請在 TGO 鯤鵬會公衆號回覆“杭州”自動獲取。
大家好，自我介紹一下，我叫蘆宇峯，現任二維火 CTO。
今天我要分享的是如何提升技術團隊效能。其實話說回來，我覺得加班就是提升效率最快的途徑。加班能不能提升效率？從我的角度看是可以的，每天多幹一兩個小時，其實你付出的時間本來就比別人多，如果再保持一定的效率，那就一定會提升。當然了，長期看肯定是不科學。
如果大家不太贊成這個方案，我們繼續往下看。
首先我們講到組織，其實大家都聽說阿里巴巴的組織能力很強。一個事情、一個調整，隨時可以到位，不像很多團隊應對變化的壓力很大，其實組織也是由人組成的，調整組織就是在調整人。那麼人在這個過程中怎麼合理地組織和調整？首先要說一下我對組織理解：
組織是戰鬥的陣型。我們面對的變化太多了，市場不斷變化、客戶需求不斷變化，老闆一天到晚折騰，團隊產品經理有些有新的想法，甚至工程師也有自己的新想法，有這麼多變化，我們想用一套陣型包攬天下很難。那麼怎麼面對這些情況及時做調整，使用什麼樣的調整方法？
這時就會出現很多陣型，根據不同情況變化陣型，沒有聽說哪個團隊就是衝鋒就是幹。戰場的情況這麼多變，我們也要及時調整。當然了，也有傳說中最牛逼的陣型——八卦陣，可攻可守，但八卦陣本身的原理就是利用變化來應對變化。如今唯一不變的事情就是“變化”，我們要學的是背後的方法論，就是主動擁抱變化。
一、如何將組織系統化？
組織結構是一種組織形式，是一種陣型。把整個組織系統化是應對市場和公司變化的一個有利手段。所以接下來我主要聊怎麼把整個組織系統化的過程。
很多組織會糾結是職能化還是垂直化，垂直化就是將很多工作直接和業務單元耦合在一起，每個人的責任就和業務單元綁定了。當然，職能化也有好處，同樣專業領域的人在一起，可以更好協調資源和分工。
我們都經歷過創業，可能手上寫 Java 的就 5 個人。當面對變化的時候，今天這個人幹 A 項目，3 天以後不管他的代碼有沒有測試完成，他都要去做 B 項目。如果人是資源，可以放在一個池裏調整，作爲管理者會非常系統。同一個工種在一起成長性會很好，不然有一些技術的話題，大家的關注點不一樣；同樣專業的工程師在一起成長性會好一些。垂直化的好處就是資源直接面向業務負責，所有的人背同樣的 KPI，這會使業務更好地去落地。
關於組織系統化，我提出三種方式：
第一，整個組織結構要向軟件系統一樣靈活；
第二，組織結構要像城市交通系統一樣；
第三，組織結構要像人體的生態系統一樣。
我分別講一下這三種系統的形式。
1、組織架構像軟件系統
這種結構強調大中臺、小場景、重突破、輕邊界，可以根據客戶需求和商業場景快速落地。
像現在比較流行的中臺策略，其實不僅僅指的是把我們的系統，軟件的架構去中臺化。更重要的是提出一個組織保障，如果我們把中臺做得足夠強大，我們可以說中臺變大業務場景變小，每個場景會更靈活，當然邊際也很清楚，可以根據不同的場景進行落地。去年，我們公司遇到一些危機，大家突然發現原來我們面對商業的場景很單薄，面對門店和連鎖的總部，在原來的產品的基礎上挖掘出很多的場景，使原來的產品和系統變成中臺的支撐。同時，我們看到所有的場景可以基於中臺快速構建，不是說現在把大量的人投入到這個場景，商業的場景需要嘗試，試成功纔有然後，如果走不下去，這個場景很快就銷燬掉。
當然缺點很明顯，比如我們現在抽離一箇中臺的團隊做這個事情。如果給中臺投入的資源過少，中臺會變成整個效率的瓶頸。早期遇到這個問題時，我們抽掉了訂單中心，結果導致所有的需求都會涉及這些系統的改動，這些工程師比以前更忙，其中就涉及到怎麼劃分業務顆粒度的問題。如果用此類辦法，一定要在中臺上投入更多的人。
我剛到二維火時，我們的研發團隊就 20-30 個人，很簡單的組織結構。最早按照職能劃分，大家先按照自己職能工種打散組織在一起。有一定規模後將數據獨立出來，自己寫了數據庫的中間件，自己搭搜索引擎，探索底層的應用，當然這個時候有新的部門叫 PMO。後面我們開始將整個業務中臺做成基礎產品，包括之後的事業部都是指剛纔提到的小場景。
你會發現每一個小的場景都涉及到一個或多個產品的組合，面對不同的場景有自己的解決方案和落地的方式。如商務談判的方式不同，門店是隻負責收銀和取餐櫃的場景，零售是負責收銀和供應鏈管理的場景。我們發現這樣拓展開來，整個業務場景變多，客戶羣也變多了。
前兩年，面對美團的市場競爭，打得很兇殘，後來我們發現拼餐飲門店是拼不過的。於是我們換了個方法，繞過去，通過智慧商圈直接觸達商場。商場在接受 CIM 和管理系統之後，會主動將所有門店的收銀 POS 機換成二維火。很多問題從另外一個維度看一樣可以解決，就像在這裏，不是一對一和品牌門店談，而是和虛擬連鎖的共同體談。
所以在組織結構設計方面，我們依據市場環境做了調整。在事業部，我們都招聘了很多 BD 銷售人員。但在基礎產品部也投入了部分研發力量。這麼看會發現，組織結構也是根據中臺化的原則進行劃分，所以我們將組織結構以這種方式抽象，就像軟件系統來設置，這就是實踐的過程。
2、組織架構像城市交通系統
交通系統型組織架構適合有大量常規工作，又需要快速響應的團隊。
這一類指的其實是項目管理體系。項目管理體系每天有大量日常常規的項目在操作，又要面臨海量突發事件，做好緊急響應的準備。
爲什麼我形容它是城市交通系統呢？在二維火，我們經歷過最高併發 120 個項目的情況，其中 70-80% 的項目是常規型的，即客戶提需求，商務、研發聯合評估，最後按照研發計劃推進。這些項目就像公交體系，我們知道它什麼時候發車，經歷哪些站點，最多延誤幾分鐘到達目的地，可以衡量可以預期。而對於“市長”來說，他一定希望公交體系承擔交通體系的大部分運載任務，這樣纔可以緩解擁堵現象。
除了公交體系，出租車體系也可以因爲借鑑，當有大客戶到來，他需要從出發點直到終點，中途不停靠。當然，除了公共交通體系，還有一些私家車。在組織體系內，“私家車”是服務老闆的。我們的 CEO 經常會有很多新的商業想法，不管靠譜不靠譜我們都要做，他希望有直接指揮的權利，在公共體系之外，直接調度人員，分配職責。
公交 + 出租車 + 私家車，就構成了基本的交通體系。這種體系的優點是資源利用率高，規劃清晰；缺點就是對項目管理能力有相當的要求，需要專職的項目經理。相比工程師，項目經理帶團隊更專業一些。很多工程師、架構師在帶領項目的時候，會侷限於寫代碼，技術攻堅等一系列問題。我們從 2016 年開始設置專職 PM，效果非常不錯。
3、組織架構像生態系統
像生態系統一樣是說要讓組織快速分裂、自主進化、強調結果、優勝劣汰。這樣做的優點是既能改善自上而下的官僚主義風氣，又能解決自下而上的效率問題。同時也縮小了團隊規模，使之更加靈活聚焦。缺點是資源較爲分散，溝通成本上升。
6 月份的時候，我去一個朋友的公司參訪，這是一家即將 IPO 的大型公司，技術團隊規模超過 2,000 人。他們基本將團隊劃分得很細，甚至有一個“袖珍”部門完全就是敏捷化團隊，不超過 9 個人，負責快速推進不同的商業場景。而且大部分小項目團隊都在盈利，發育得很好，我很佩服，但他們也存在問題。他們公司有大量共性的基礎設施沒有人研發，或者研發了以後沒有人用，因爲他們沒有一箇中臺部門負責將這些需求抽象出來。
最後我想說如果說還是回到戰爭陣型上，兵無定式、水無常形，方法有很多，職能化、大業務小中臺，大中臺小業務，或者完全摒棄中臺，都可以，只要對業務有好處就可以。以前反感組織結構調整，很折騰。結果當自己身處這個崗位上的時候才發現，不折騰是不行的。無論是外部還是內部問題，如果不去變化和調整，就會一直阻塞在這裏。
二、量化過程，從方法上優化效率
我的老闆每天都會問我：“研發效率可否提升一點？”
可我們現在的研發效率屬於什麼水平，我們都不清楚。通常我們要縮短交付時間，就是單純的砍需求，或者多投入一些研發力量，很難做到細緻的量化。這時候 CTO 和 CEO 的博弈就很有意思，對於效率這個命題，沒有證據，全靠揣測。但身爲管理者，這其實是一種內耗，所以我們要學會發現過程中的問題。
2016 年，我曾接觸過一個大客戶，往往要求一個需求的上線時間就是一個月。我們迅速地組織了一個“出租車”團隊，幾個產品經理上車調研發現不難，產品與架構設計只花了一週時間，編碼一週、聯調一週、最後測試一週、完美上線四周，準時交付，客戶很開心，老闆也很開心，我們也很開心。於是召開了項目總結會，準備爲我們這次快速響應表功。
總結會上，大家吃着火鍋唱着歌聊着天，聊到一半項目經理殺進來，說項目進程有點混亂。說好的一個月，但事實上原定的聯調時間只有兩三天，編碼要佔用更長時間。本來看到編碼效率加快了，很開心，但爲什麼聯調需要一週呢？
於是，大家的笑容凝固在臉上，全都不想聊這個問題。可既然開了頭也不好冷場，於是慶功會就變成吐嘈會，客戶端的同學吐嘈服務端的大爺，寫好的接口完全不按照文檔來，出參入參都不太一樣。最後編碼效率雖然很高，加班熱情高漲，但到了聯調第三天就沒有一個接口跑通。
我們當時就在想既然已經發現了問題，那麼能不能去優化這個過程？
這就需要量化，最粗糙的量化方法就是時間。我們有個習慣，我們先給這個事情定了目標，提升研發過程的效率，關鍵結果是聯調時間縮短一天，我們想看看我們能不能竭盡所能去縮短它。後來一位工程師引進了 Mock 工具，後來又強制調整了一些研發流程和研發手段，最後通過兩個季度左右的時間，我們將服務端和客戶端的聯調時間縮短至一天。
所以，過程數字化的意義便在於衡量，進而便於去改進和優化。量化的目標是爲了優化，量化可以很多，但優化得一件一件做，最後落在每項工作上有實實在在的改革措施。
關鍵結果一定是要數字化的，一些關鍵里程碑的時間、關鍵交付時間也需要數字化。以前我們不講究成本，花投資人的錢比較隨意。現在不一樣，每個項目我們都講成本，我們需要盈利，我們需要有更多的報價出去，全部數字化，這是最大的改變，用數字衡量方方面面。
其實說了這麼多，效率的關鍵還是要回到人自身。包括團隊文化，也是提高效率的重要手段，最終團隊文化能否讓成員保持高昂的士氣，培養體系能否讓成員能力逐步提升，都很重要。
活動推薦
10 月 26 日，GTLC 成都站將在成都市高新區正式拉開帷幕。環球易購 CTO& 前蘇寧科技集團副總裁喬新亮、TGO 鯤鵬會成員 & 知道創宇 CTO & COO 楊冀龍等一批業界優秀的技術領導者，將悉數到場，分享領先的技術管理思考與理念，從而爲成都本地的技術人提供一次豐富的、深度的探討學習及拓展人脈的平臺或機會。點擊「詳情」查看 GTLC 成都站相關內容，現在購買 3 張以上門票還可以享受團購優惠——169 元 / 張，多買多優惠哦！
TGO鯤鵬會，是極客邦科技旗下高端技術人聚集和交流的組織，旨在組建全球最具影響力的科技領導者社交網絡，線上線下相結合，爲會員提供專享服務。目前，TGO鯤鵬會已在北京、上海、杭州、廣州、深圳、成都、硅谷、臺灣、南京、廈門、武漢、蘇州十二個城市設立分會。現在全球擁有在冊會員 800+ 名，60% 爲 CTO、技術 VP、技術合夥人。
會員覆蓋了 BATJ 等互聯網巨頭公司技術領導者，同時，阿里巴巴王堅博士、同程藝龍技術委員會主任張海龍、蘇寧易購 IT 總部執行副總裁喬新亮已經受邀，成爲 TGO 鯤鵬會榮譽導師。