一、膨脹的團隊、膨脹的複雜度
書接上文：新晉總監生存指南開篇之總監二三事
按照之前的邏輯：如果你想創造一個能夠維持一定秩序、不會分解的系統，那麼這個系統必然是一個開放系統，就需要為他注入能力，並讓其在系統中流動以維持這種秩序。管理的動作就是為團隊注入能量，能量停止系統就會開始退化，這種持續為組織注入能量的行為，正是領導力的核心。
以上的話比較晦澀，他要表達的意思是：團隊一定會出問題。規模越大問題越多，並且問題會越來越愚蠢、越來越不可思議！
如果沒有管理動作的介入，團隊會變得十分混亂，效率接近為0，根據熵增定律，封閉的系統，最終會由有序變成無序。
這裡舉個簡單的小例子，大家去食堂打飯，沒人維護秩序會怎麼樣；增加規模，變成市民去火車站買票沒人維護秩序會怎麼樣；持續增加規模，變成國慶期間外灘遊客如果沒人維護秩序會怎麼樣。
所以管理的核心其實是有效的解決團隊的問題，保證他有效的運轉，而團隊不同的階段（不同的規模）下他所產生的問題以及對leader的依賴是有所不同的，如圖所示：
每個團隊在形成初期，溝通往往是單向的，需要一個強有力的leader，成員之間瞭解度低，對環境乃至公司團隊戰略不清晰，很容易產生焦慮困惑和不安全感。
比如新同學是非常容易無所適從而導致離職的，這個時期主要需要解決的是兩個點：信任與目標，即員工之間的信任問題，和明確團隊的目標問題，這個可以由五維能力模型的戰略入手。
這個時期的團隊一般50人以下（更常見於20人以下），由leader凝聚起來，如果leader足夠優秀，團隊會非常有凝聚力，適合區域性作戰，打一些小戰役，而隨著團隊發展，接下來就會進入風暴期。
由於團隊規模變大，不可避免的團隊和團隊之間會產生合作，但是因為各個團隊風格各異，衝突會因為文化、理念、利益、工種等問題不斷爆發，這個時候我們主要解決團隊之間的問題，這裡除了機制解決以外，更好的辦法是劃分賽道，並且確定更大的戰略目標。
風暴期的團隊已經有一定體量，人數因公司團隊情況而有所不同，這個時候的團隊衝突往往很難自己解決，因為一旦涉及到所謂團隊利益，很多人就會很容易失去冷靜，所以這個時候更需要一個好的leader解決一些衝突，把各個團隊串聯起來，避免團隊各自為戰，各自埋怨產生內耗，形成效率豎井，事實上風暴期是很多創業公司的送葬場。
團隊經歷痛苦的磨合，開始進入規範期，這個時候團隊之間已經找準自己的定位以及對方的價值，彼此間開啟高效的合作模式，之前良好的機制迭代，也形成了統一的文化，所以團隊問題變得更可控了（未必變少了），合作共贏、配合執行成為團隊主旋律，leader的更多是參與決策，而不是主導決策，只有在一些比較膠著的情況才會推動問題解決。
團隊最終階段，我這邊缺少經歷無法建立認知，便不多說了。
分而治之是解決規模過大的良藥（正如上圖中的team小圓圈），多數公司都會分為事業部，繼續將關注點聚焦，技術團隊一般是按業務線或者按技術職能線劃分（前後終端...）分為幾個組。
於是管理整個技術團隊變成了管理各個小組，這樣雖然會導致“屁股問題”，但管理難度會小很多。這裡最核心的問題依然繞不開：CEO不可能承擔所有角色（技術、財務），技術負責人也很難精通各個技術棧，那麼各個陌生的部門、陌生的領域如何管理？
二、為什麼要建立資料指標
實際推進資料指標落地可能非常費力，需要不停的建立共識，瞭解全貌可以更好實施，所以我們首先介紹團隊膨脹到複雜度增加，並最終選擇分而治之的方案，至於資料指標是什麼，我們以一個案例開始：
因為產研是公共資源，所以會存在業務方搶佔產研資源的現象，而限制創造力的內部競爭會導致制度性的內卷，於是某一天老闆提出誰使用誰埋單的規則，產研剛以為可以少做一些低價值需求後，來了一句神來之筆：
產研團隊對於公司的意義是什麼，如何評價產出。
角色定位決定關注點，我們直接聚焦到研發團隊，研發團隊對於公司的意義是什麼，如何評價產出；這裡再進一步，各個技術棧團隊的產出如何評價？
雖然當時的真實反應是：艹！又要做一堆無效的作業去應付這莫名其妙的疑問。但如果細細思考，這裡卻觸發了本質問題：
我們的團隊與外包團隊有何不同，我們與其他研發團隊的差異是什麼，如何評價優劣
技術負責人應該如何評價各個單元組的產出，可以主觀的定性，卻需要客觀科學的定量，於是便需要建立資料指標。
然後在具體實施落地的時候，很多同學不容易理解資料指標是什麼，認為“資料指標”在瞎折騰，不能理解這塊的用意，內心抵制是不容易做好的，就算做好了也可能只是運氣好（蒙對了，反而會埋下更大的坑），這裡跟大家強調下，資料指標至少有兩個作用：
1 想不出來資料指標，說明是對這塊事（團隊要做的事）沒有一個清晰的認知
2 想得清楚資料指標，卻做不出來，說明對整個團隊缺少掌控，不能推動落地
不能建立資料指標，根本沒法做資料驅動，看似簡單的資料指標把團隊是否在裸奔指了出來，是因為慣性還是被動向前跑，一目瞭然。
綜上，資料指標其實是想真實反應我們的團隊是什麼狀態，我們做的事是什麼狀態的一個指向標。究其原因，組織執行力、產品健康度需要某種程度的量化，資料指標的作用從更巨集觀的角度看是這樣的：
資料指標提供了航行方向，北極星的作用，這裡再來一張圖，看看資料指標在全域性中的角色：
其中牽引指標就對應我們的業務資料指標，牽引指標不健康的時候可以預警是不是團隊方向跟目標走偏了，leader要考慮調整目標還是修正團隊方向。
三、研發資料指標
3.1 比價模型
先回答上面的靈魂一擊：你的研發與外包團隊有什麼區別？
一般來說研發團隊的工作是“做專案”，其工作產出物是“程式碼”，作為偏執行團隊的評價指標一般是三個：
1 成本指標
2 過程指標，執行效率
3 結果指標，交付質量
粗粒度的表格可以是這樣的：
| 你的團隊 |
競品團隊 |
||
|
成本 |
人均成本 |
||
|
人力成本 |
|||
|
維護成本 |
|||
|
交付質量 |
過程BUG數 |
100（個） 冒煙通過率：90+% |
|
|
上線一月BUG數 |
3（個） |
||
|
安全性 |
中 |
||
|
事故處理能力 |
中 |
||
|
交付效率 |
人日（單位） |
||
在資料準確的情況下，上述評價模型基本是可用的（只不過大概率拿不到，所以老闆的問題大概率還是瞎扯淡......）
3.2 質效指標
事實上比價模型被作為一個作業交差了，但其中的質效相關指標作為了衡量整個研發團隊的指標被保留下來，持續迭代後變成了這個樣子：
實際執行效果如圖：
上述是周常規指標，每週週會我們會過這個資料，除此之外我們還有一個專案維度的指標，大概是這樣的：
這個表格用於每個專案結束後覆盤的重要參考材料。
3.3 其他指標
上述是比較通用的質效指標，各個業務團隊皆需要遵守，是兜底的存在。
具體到前端團隊的資料指標、後端團隊的資料指標、NA團隊的資料指標，又會有很大的差異，端更傾向於體驗指標、後端更傾向於穩定性指標。
而業務團隊的資料指標提取就“奇妙”了，除了通用的質效指標需要遵守，還需要侵入業務，而這個資料指標又不能是諸如訂單量之類的業務指標，所以純業務團隊的研發資料指標，很長一段時間我也沒想明白，後來迴歸本質，我認為依舊需要在效率和質量上做文章。
其中效率可以具體細化為很多元件化工具的建設，技術升級，這裡最終會反饋到整體的效率指標提升，但如果單項的工具建設，由於耗費人力，可能還會在某個時間段降低效率，這裡取捨需要leader自己判斷，比如測試環境治理要不要做，需要付出什麼成本，能達到什麼效果，這些都需要決策。
業務質量部分可以更多的考慮業務埋點，比如P0頁面乃至介面的監控，這裡要達到的效果是，大流量場景下，一旦某個使用者觸發了邊界場景，這個是有預警的。
關於業務側的技術類指標問題，我認知有限，如果大家有什麼建議，請不吝賜教
最後，資料團隊、工程團隊、產品團隊的指標各有不同，大家可以自由補充。
四、資料的使用
建立資料指標，才能儲存正確的資料，隨後資料便可以產生價值了，我們這裡的資料使用依舊是聚焦到研發領域：
1）周常規資料，比如我們每次週會都會過上一週質效週報，裡面資料一旦有波動，就一定是某個團隊出了問題，這裡首先暴露了該團隊這個週期內可能的問題，我們可以繼續深入這個團隊，看他這個週期是什麼因素導致了指標不達標，再協助做整改即可。
某些程度來說，資料指標有“緊箍咒”的作用，沒有團隊想在會議上被人“覆盤”，於是平時就會刻意的做建設，那麼團隊整體的產出就有基礎的保障。
這裡要注意的是，大家都可能出問題，萬不可以某個團隊指標不合理大做文章，成為噴子。
2）專案維度指標，我們記錄了專案維度的執行指標（如上圖），在對“問題”專案、“典型”專案覆盤的時候，我們發現這次專案過程中，產品與研發的合作十分糟糕，battle不斷，對比資料一看，發現需求更改10次，於是便更需要產品同學做覆盤；我們發現技術側耗時遠遠超出平均專案時間，跟進去一看發現原來測試環境泳道出了問題，專案的執行測試環境，不斷的被其他團隊修改，那麼就該在測試環境治理一塊做工作......
諸如此類
3）週期內某業務線整體質量覆盤，大概是這樣的：
四、結語
無論個體、單元組、團隊都需要切實瞭解自身狀態如何，為了更具象的描述這種“狀態”，我們要求每個單位需要提出自己的衡量指標，這個就是我們所謂的資料指標。這裡要注意一個點：
資料指標絕對不是leader獨立提出來的，財務的資料指標需要財務提出、產品的資料指標需要產品提出、研發的資料指標需要研發提出，誰瞭解誰提出，leader更多的是考察其科學性（leader缺少認知、資訊很難提出系統的指標，但總會有幾個行業好友吧）
建立資料指標——>資料開始有指導作用——>資料可說話——>資料驅動，這是每個團隊都想要達到的狀態，他需要每個“山頭”的leader都對自己的領域有足夠的認知，提得出相關指標，還需要切實的落地指標記錄，到最後的應用指標，這個要求其實比較高，那麼有沒有相對簡單的辦法可以更好的建立指標呢，事實上可能還真有：
在某種意義上說好的OKR實踐，會經歷完整的指標建立過程
所以下次，我們一起學習下OKR工具的使用，關於資料指標一塊的淺薄的認識就到此，希望大家多多討論。