書接上文：“年終盤點一對一”之很剛的同事
繼續整理技術團隊最近的年終盤點，【採用我問他答的形式】主要是聆聽，這裡是跟第三位同學質效負責人脫敏後的交流。
這位同學年級比我稍大點，是從美團來過來的，跟上個同學不一樣的是他有自己相對完備的工作認知，有一套大公司工作方法論，顯然這在現在的團隊有些“不適應”，這種“不適應”有時會讓人覺得不近人情，有時會讓人覺得不知變通，有時讓人覺得有點“遲鈍”。
正文開始前，我們先來看看他一年以來自我認知的變化（美女看手相嗎，我們聊聊管理玄學？）：
可以看到，在一年的拉扯下，該同學被我“折磨”的很慘，活生生從一個Leader變成了金牌執行者！那我們來看看為什麼會有如此大的變化呢？
— 1 —
你是什麼樣的人
我是一個顧全大局的人
清晰的記得，2021年的開篇是在公司跨年開始的（我們因XX專案在公司加了一週通宵）。回顧一年最大的感觸就是公司很Agile，變化快，變化多。我個人而言，也是在不斷擁抱變化，組織需要哪裡我就去哪裡。
每一個找我的人，我都會盡量及時解決他們的問題；釘釘資料可以佐證，釘釘訊息多，被艾特數很高，由於響應快於是被釘率比較低：
我是一個多面手
今年直接服務以下Leader：
1）研發Leader，也就是區區小釵；
2）產品Leader；
3）研發副班長；
4）其他同級Leader；
5）其他高管；
負責的團隊多種多樣：除了QA和CIO團隊，還有交接過來產研PMO, 北京IT, 公司客服，我這裡還總結了一套接手新團隊的方法論：
1）收集/分析部門問題；
2）收集/分析部門人才梯隊問題-識別核心；
3）產出具有指導意義的部門指標；
4）知識沉澱-建立wiki文件和迭代優化-週會制度；
我是一個有產出的人
團隊質量提升明顯：從9.88 提升到79.7。
2021年質量相對2020年有質的飛越，周平均線上問題小於10個（2020年月均52個線上問題，幾乎發版必出問題，2021年下降到月均19）；
質量提升也讓大家經常上線到12點後這個現象幾乎看不見了（只有少數大專案由於種種原因還會發到12點後）：
舉一個工具建設（devops、質效平臺）的例子：
devops工程部建設這裡不多講了。質效平臺就像親兒子一下，框架設計、資源傾斜、努力推廣。最終質效平臺在質量這塊的建設基本達到目標，有提測流水線和釋出流水線。做到了流程線上化，所測即所發，也解決了發版衝突，防範錯誤配置上線等：
另外質效平臺上的自動建設也同樣有不錯成績（從0開始的建設）：
-
場景覆蓋：353，介面巡檢48,UI巡檢315;
-
介面覆蓋率：84.26%;
-
UI覆蓋率：......;
-
自動化發現的問題：介面巡檢：12，UI巡檢：8;
小釵點評，這個結果來源兩點：
1）我們自己的質量體系、環境、工具（devops，質效平臺）建設和人員培訓；
2）上游需求把控和壓縮，所以未必是技術團隊進步真的如此神速，要注意看全域性；
— 2 —
你的問題是什麼
今年以下事情令我印象深刻：
迷茫過
1）遇到過困難：“0”人力交接產研PMO, CEO駕駛艙遇阻，核心離職；
2）做過重複勞動：三次飛書與釘釘調研，最終終於選擇釘釘；
3）被CFO罵過：因為網路問題，但這個是CFO素質低（小釵表示贊同！）；
4）被罰款過：因為業務故障和網路故障；
5）努力白費過：產研成本歸集、產研工時填報（由於當時資訊輸入、能力、勢能都不足以完成這些事背後的目標，最終還是小釵的CEO駕駛艙從根本上解決問題）；
但也有收穫
除2021部門產出外，個人能力、認知、勢能都有所增長。最重要是小釵不止一次公開給我畫餅，這是種認可也是一種精神上的激勵。
PS：畫的餅當然未必會實現嘛
2021部門產出外，個人能力，認知提升，個人勢能也有所增長。最重要是小釵不止一次公開給我畫餅，這是種認可也是一種精神上的激勵。
— 3 —
你有什麼心得
做到知行合一
有些同學在破壞流程，比如倒排、濫用緊急需求，繞過提測流水線，繞過釋出流水線，APP隨意發，濫用QA環境，繞過預發等，簡單的告知他們尊重流程是行不通的，會有各種理由來讓你開綠燈。
在得到更多的輸入，認知提升的同時，需要更好的實踐，做出標杆案例。像泳道成功推廣就是一個很好的案例。2022年真正做到知行合一，打造更多成功案例。
更多的獨立思考
2022年，投入更多思考在以下三大塊：
1、產研質效
研發過程改進，質效運營，流程化/線上化建設等質效保障工作。
2、協助公司PMO建設
CEO駕駛艙，公司數字化轉型。
產研質效是我最擅長，但存在巨大挑戰的地方。各級對流程的認知、優先順序的認知是最難統一的。大部分人都盯著手裡的東西，偏愛舒適的做事，所以經常想要破壞流程。但優秀公司的應該有完善的流程規範，這也是我追求的目標。
我之前老是被小釵笑著說：
1）不思考，不獨立思考；
2）不解決問題，習慣做簡單的事情；
3）總期望尚方寶劍，但就算給你把尚方寶劍你也把這個事情做不好，沒人會真的聽你的，事實上後面拿著公司紅標頭檔案要做一件事也確實很難；
在2022年希望通過自己的獨立思考，可以給到Leader更多助力，幫助其實現目標。
產研管理事情比較雜，這塊在2021年沒有抽象出什麼方法論，接到任務就是想快準狠完成。2022年希望能摸索出一套切實可行的方法論，幫助各Leader減少常規管理上的干擾，專注重要事項上。
PS：事實上該同學最大的問題就是獨立思考能力有限，這裡算是根節點。
更好的向上管理
向上管理並非PUA領導來達成自己的目標。這裡的向上管理指管理leader的目標，根據部門的目標，甚至公司的目標，調整自己的工作重心去幫助實現leader的目標把蛋糕做大，這需要獲取更多的資訊輸入，認知對齊，目標對齊，也希望得到小釵的支援。這裡我以CEO駕駛艙為例：
一開始捲入進來的時候，只看見了點線面：研發迭代（優化列表），知識庫（產品說明，Q&A），推廣(推廣手冊，海報，全員培訓，CIO反饋群)；
做完後才發現CEO駕駛艙本身就是公司未來推廣專案化的案例，而這一開始就是Leader的目標。
所以更好的向上管理是在leader給你輸入20%關鍵資訊的後，要有意識挖掘其真實目標，把Leader的目標當自己的目標去努力達成，而且是超越100%達成。
更好的向下管理
最簡單的管理就是拿結果。對於人才密度大的團隊是可行的。
但對於人才密度低，整體自驅性不足，主動性不高的團隊，管理得多做一些才能拿到更好的結果，也能培養提升下屬的能力。
我原來喜歡用PDCA方法論來管理部門活動：
如果是新組建的團隊，我會做P(lan)-識別問題，抽象問題，具體規劃；C(heck)-檢查結果, A(ct)-提供解決路徑, 實施最佳解決方案，然後D(o)-做做看；
機制運轉順暢後，參與C(heck)-檢查結果，A(ct)-實施最佳解決方案；
團隊梯隊完善後，本以為可以拿結果就行，結果還是出現了兩個流程case：
1）CS 問題：leader參與度低，導致CS質量不高，重複掉坑可能性大；
2）測試APP上傳應用市場（還好是未推廣APP，未造成損失）；
之前做的CS流程和APP測試流程，是運轉的不錯的，由於缺少週期性review和迭代，導致上兩個case發生，所以2022年用好PDCA迴圈方法論，杜絕管理黑洞，不斷迭代我們的組織和流程，最終達到部門目標：
— 4 —
你有什麼想對小釵說的
不要只有「公司要求」
公司流程制度我們當然是會遵守，希望出現明顯不太合理要求時，能給大家透傳一下為什麼我們要這麼做。目標對齊，資訊透明，才能引導團隊積極向上。
加強遵守流程規範的重要性
公司流程我們嚴格遵守，同樣被審批通過定為部門級的流程，我們也應當嚴格遵守。