原創不易，求分享、求一鍵三連
愛恨糾葛：“年終盤點一對一”之一生之敵孫狗！
繼續整理技術團隊最近的年終盤點，「採用我問他答的形式」主要是聆聽，今天這位同學之前在騰訊工作了幾年，被我忽悠到現在的團隊，他一年的角色變化是這樣的：
凝聚者屬性降低，監督員、推進者屬性升高，和從一線技術開發到一線Leader的身份轉變有關。
作為一線leader，會更多地排程資源，做專案推進和管理，包括技術方案評審、產品需求PK，相應地，推進者、監督員屬性會有提升。
依然是實幹主義者，以事為本，執行力強，關注能不能做成事，帶著這些印象，我們來看看這一大公司登陸中型團隊是個什麼樣的情況。
你一年印象最深的事
工程輪崗業務
輪崗機制是團隊人才運營中重要一環，用以防止單點產生和骨幹Leader培養，我剛好被小釵強制調崗了......
這次調崗產生了很多後續影響：
- 工程組開發陸續離職;
- DevOps流水線被下線;
針對我的調崗，組織目的是為了讓我熟悉業務，看清並抓住研發團隊真正的痛點，能更好地推動工程落地，之前業務接觸較少，工程推動阻力很大。
目前在業務線呆了快一年了，從結果來看，個人認為這種調崗並不是必需的，每個團隊其實都有各自的痛點，有些並不是通病，深入某個業務可能會導致看不到全域性。
但作為工程線Leader，一定要主動去熟悉業務，同時要具備或者提升一定程度的外交家屬性，主動與業務線Leader多溝通多交流，從多方交流中來把握住整個研發團隊的痛點，才能更好地提出適合團隊的方案，這樣落地時也能減少阻力，更好推進。
再說工程組同事陸續離職，其實工程部的同學整體實力是比業務團隊強的，但當時在外界看來輸出不如業務團隊，作為Leader，我有一定責任的：
1）不熟悉業務、工作安排優先順序有問題，沒有及時去解決研發團隊遇到的痛點；
2）與業務團隊交流不夠，整體上有些脫產，閉門造車。
3）工程組開發陸續離職其實和「孫狗」說的「統一閘道器」沒有關係，那時候閘道器並不是工程部的重點，所以不存在爭輸贏的說法，只是工程組的同學覺得不被重視，工作成果也不被尊重(被要求改來改去，打雜的，或者做出來不被採納)，更多地是工作「成就感的問題」。
作為Leader善後工作做的不行，這裡我是有責任的。
小釵有話說：
這個同學這裡說的工程團隊的問題，「因為與業務弱繫結」容易「閉門造車」，工程線和業務線經常脫節，這樣會導致工程線同學變成「垃圾桶」和「經驗包」
業務組同學忙不過來，就丟一些基建任務外包給工程線；
業務組同學稍微優點時間，便直接以實際業務為起點，做工程建設，變成自己額外的「加分項」；
對於以上情況，工程線同學往往沒有太多辦法，因為缺少業務創新、技術創新的事情難度太低，大家都能做。
但如果任由業務線自己做基建，很容易重複造輪子，得不償失。
重複造輪子
再說DevOps流水線被下線，調崗之後DevOps流水線就下線了。
但有趣的是，後面質效平臺也做了一套流水線出來，包括提測流水線和釋出流水線，還運轉的挺好的！
後面就在反思，當時我為什麼沒做成，其實當時也是有支援的聲音的？
從事前來看，當時DevOps流水線這個概念在整個研發團隊的普及度不高，很多人對這個持懷疑態度，所以先天的勢能不足，造勢不夠，盟友不足，這其實為後續孫狗等同學集體反對已經埋下了伏筆，在這之前其實應該把質效同學先拉過來的，畢竟質效後面也做了，他應該是盟友才對。
從事中來看，整個專案的推進沒有及時和其他人同步進度以及功能點，導致專案上線時很多人覺得很突兀、不適應，導致工程一直在孤獨奮戰。
同時，當專案遇到阻力時，也沒有及時向老闆獲取支援，專注做專案，過於被動。
從事後來看，沒有及時和相關同學做好溝通和安撫，導致相關同學陸續離職。
從整件事上來看，一個團隊的貢獻度和穩定性，除了公司大環境，和一線Leader還是有很高的正相關性的。
作為Leader，提升的能力要更多地從團隊視角出發，團隊缺乏什麼樣的能力，Leader應該做相應補齊(或者招人補齊)，保持團隊的健康度和穩定性，工程團隊更應該做好對外的技術影響力和透明度。
業務壓力
於個人而言，今年同時上線了三個大的業務專案，還是蠻有成就感的。
但對於專案組的同學而言，並行開發3個專案，經常在專案間切換，負荷很高，但其實效率不高，bug較多。
作為一線Leader，整件事下來還是過於偏執行了，決策之前沒有先搞明白業務整體的規劃就開始盤點人力開幹，實屬草率。
作為持續投入的長期運營專案，節奏感和人員穩定性還是相當重要的，這樣太卷的方式對專案其實是有傷害性，一線Leader需要做好專案與團隊兼顧，把控好專案進度，也需要做好團隊健康度和穩定性。
你的心得
時間管理
作為一線開發可以一整天寫程式碼，作為Leader，幾乎不可能，需要關注團隊、需求、會議、專案管理、其他雜事。
時間分配上，從100%，變為70%處理事情，30%時間開發。
自然而然的，開發工作的分配產生了變化，分配到自己身上的開發工作，都不是核心，不會對專案產生阻塞性。
目前來看，這項是不及格的，還是要堅持技術，畢竟P9以前更多還是要靠技術吃飯，以技術驅動，管理為輔，需要做好時間管理，希望今年能做到40%處理事情，60%開發。
視角變化
個人視角轉團隊視角，個人專案視角轉整體專案視角。
會更多地關注產品需求、專案整體的規劃，團隊負責的業務邊界，跨團隊合作等問題上。
管理思路和風格
不管是負責工程還是業務，首先都會了解團隊成員的過往經歷，瞭解團隊內每個人的特點，尋找領頭羊，篩選出哪些能獨擋一面的，哪些是配合者，再給予領頭羊相應資源(導師制，配學徒)，發揮其主觀能動性，帶領團隊正向迴圈。
雙週分享，提升團隊整體技術實力。組內同學輪流做專案owner，加快團隊磨合，以戰養戰。
目前做得較差的還是在團隊思考上，業務之外，團隊應該有怎樣的輸出，發揮怎樣的技術影響力，對整個研發能沉澱哪些優秀的系統設計和工具，這個是需要認真思考的。
產品思維
發現關注開發、專案管理那點事是不夠的，需要關注產品端的需求。
有時候看著一堆堆功能的需求，其實挺困惑的，運營是ToC的，流量運營是不是該作為運營重點，而不該是功能運營？
就和一架沒油的飛機一樣，一直在修修補補或者換飛機表面的圖案，但一直沒有加油，飛不起來。
但目前還沒法驅動產品，只能砍砍需求，需要更多地補齊行業、業務、領域知識。
想對我說的話
1）希望能適當擴大資訊漏斗；
有些時候一個事情落到研發這裡來感覺沒頭沒尾，不清楚這件事的重要性、優先順序，就開始要做這做那，說實話心裡是排斥的，畢竟這樣太偏執行了。
如果手上還有事情在做，那動力就更不足了。還是希望能保持上下文相對暢通，一件事或者一個專案過來能經過5W根因法看到全貌。
2）希望能把產品的OKR做起來；
說實話，現在的OKR做得挺爛的，一個合格的技術團隊會有兩類OKR，業務OKR和專業OKR。
業務OKR會根據產品的OKR做出相應的技術規劃，如產品的OKR是日活增長一倍，那技術團隊是需要相應的OKR去支撐的，比如xx系統擴容、xx系統重構、xx系統優化等，如果有這類OKR，也不會出現技術優化完全沒有人買單的窘境。
專業OKR主要針對團隊內部的質量和效率優化，這個就是我們目前做得這些xx技術優化、xx重構、工程基建建設。
3）重視工程基建；
CEO駕駛艙這個專案正常其實應該由工程或者質效團隊來做，而不是臨時拉人去搞。
工程整體人手是不足的，目前只能做一些系統維護、bug修復，很多基建規劃沒人力去搞，2021年過去了，基建整體上改變並不大。
很多時候都是這個文件填過來，那個文件填過去，說實話挺煩躁的，還是希望能有一些系統和平臺出來，提升效率。
小釵總結
該同學作為業務Leader後，開始適應業務，接觸的面也更大了，會站在業務角度思考工程問題，這些都是好事。
另一方面，現在帶的業務團隊，後續他再輪崗回工程線做Leader時會對他產生莫大的助益，這也是輪崗的附加好處。
好了，今天的分享就到這，希望對各位有用。「原創不易，多多分享」
想要更多交流可以加群：
