最近團隊人數漲到了接近50，自己也逐漸感覺吃力，也借此機會好好的總結了一下，50人左右的開發團隊如何做好技術管理。
自己本身也不太算manager，只不過因為跟領導分工，我更多是在技術或者技術管理上，而我領導本身幫我屏蔽了很多非技術無關的會議、任務、扯皮、需求拉齊、驗收等，所以我領導給我倆定義的方式叫做“搭班子雙人管理的方式”。所以整體來說，我幾乎從事的都是技術相關的，但是本身人數已經接近50，所以管理本身無論如何也繞不過的去點，因為這篇文章也會從技術、管理以及個人三個層次來分析，如何做好50人軟件團隊技術管理。
本身還是需要介紹一下自己的背景：
1.自己本身在蔚來大概有10人左右的團隊管理經驗，從結果看，雖然只有大半年的時間，但是效果還是很好的。
2.新公司屬于造車新勢力的一種，團隊主要是做中間件平臺的開發，包含mcu和soc。
3.自己負責范圍包含：s2s,comm(someip/dds/zmq/iceoryx),tsn,diagnostic(doip/uds/otx/ota/flash/rvdc)以及soa開發。
4.團隊成員背景基本上來自很多行業：互聯網、游戲、物聯網、汽車行業、手機以及其他桌面軟件開發等。
5.開發內容幾乎全是從0到1的過程。
6.老板和領導均是技術出身（很重要！！）
7.在這個團隊，自己原本算是普通工程師吧，然后慢慢在開發過程中，任務越來越多，在入職沒幾個月后開始帶著小伙伴一起干活，在23年下半年開始慢慢逐漸對團隊整個技術負責。整體來說，算是團隊搭建過程中的主要人物之一吧。
目前從結果來，我覺得團隊做的還是非常不錯的，從過去的23年成果來看，在組織橫向對比來看，基本算是比較頂尖的團隊了。所謂技術管理，首先想到的是技術。
02.技術
整體來說，車載中間件不算是天頂星級別的科技，在我看來難度并沒有高到不可逾越的程度，否則作為一個工作年限不長的95后，也不可能駕馭的住。因為本身要做好技術管理，本身需要對團隊的工作內容和方向有一個很好的認知，至少需要了解到整個團隊在未來1-2年內產品應用場景和落地方案。
1-2年較長期的技術規劃能力、保障質量
以車載中間件為例，尤其通信相關的組件，本身是平臺屬性，首先想到的就是易用性、性能、穩定性以及深度，相對需求開發團隊來說，開發內容相對固定，長期規劃相對來說好做。以我在極氪的第一個從0到1的項目--s2s來說。s2s（signal 2 service）本身是軟件定義汽車--SOA的關鍵過渡組件，不管如何變化，從功能安全、歷史包袱來看，can/lin信號依然是整車最為關鍵的通信方式，從面向信號開發到面向服務開發，信號轉服務就變成了很關鍵的組件。正因為如此，s2s貫穿了整個SOA流程，如果了解了s2s的原理和開發過程，不僅了解SOA的開發方式，而且還會了解到基于信號的開發以及如何將兩者粘合到一起。所以在我開發完成s2s組件并且在實車落地后，我基本上對我們整個大團隊2-300人開發內容以及上游電氣架構工作流程、下游集成測試工作比較熟悉了。從具體內容來看：
1.基本上非常熟悉cp對can/lin信號如何打包以及打包策略，了解了ub位的使用，對于不同信號優先級的處理方式
2.信號到服務轉換關系涉及到“兼容性”問題
3.所謂SOA開發需要包含的組件：comm組件、serviceframework、service代碼生成原理以及序列化的具體實現，原子服務劃分的原則
4.基于SOA開發方式的測試流程
在s2s的開發過程中，雖然是從0到1的過程，但是本身又做了長遠規劃。在開發過程中，意識到的信號超多、并且超多高頻一樣數值的信號，所以提出了兩大方向：
1.零拷貝、零手工代碼
2.全鏈路、端到端的自測試
所以如果做好技術管理，首先本身對技術必須要有1-2年的規劃能力，尤其作為基礎組件來說，架構、方向必須定下來的，在實現本身不斷突破自己的邊界，充分了解自己組件在整個系統的作用以及相關模塊的功能、實現細節，這樣自己在后續迭代中不需要投入很多精力調整方向等。
抓住主要矛盾、項目管理能力、重視測試
在23年4月中旬，臨危受命需要對comm重構的整個技術負責，在接到這個任務的時候，整體來說，原有的小伙伴做了不少事情。下面是我使用STAR模型對整個事情的過程總結。
所以在我了解清楚到整個事情背景后，快速了定義目標：6月必須發版、達到重構前功能以及完成適配。在我梳理清楚目標后，我開始梳理具體需要的事項，除了上述目標外，還有一個潛在目標，我們必須完成相關技術方案驗證（重構肯定為了拓展），當時發現在技術方案驗證上，花了太多的時間。因此我自己親自去參與的非必須功能的方案驗證，完成驗證后立馬放棄開發法，節省有限的人力開發最主要的功能。剩下就是比較老套了，涉及項目管理的一些知識：
1.拆解任務
2.拆分小組
3.并行開發
而我自己為了快速熟悉所有的代碼，選了一個貫穿始終的組件--listener開發，這個選擇讓我幾乎掌握了項目的所有細節。在掌握了較多技術細節后，我就具備了對外溝通的能力，作為技術負責人，溝通能力是必可不少的，但是很多開發恰恰相反，技術很行，溝通拉胯。因此保證技術強、溝通能力弱同事安心開發是必不可少的，我承擔了不少對外的溝通，包括：方案確認、適配時遇到的問題、合作開發遇到的情緒問題等。在后續交付迭代的過程中，基本參與到了好幾個對外重難問題的解決，這個過程保障了，我進一步熟悉了關于性能相關的代碼細節以及架構。
并且還有一點，在重構的過程中，我將幾乎最優秀的工程投入到開發測試代碼，全面的保證質量。因為我必須在快的過程中保證質量，這樣才是真正的快，否則反工則是最嚴重的效率低下。
所以在技術管理，尤其任務緊、人數多時，抓住最主要的問題點，做好項目管理和質量保障是及其重要的。
交流中快速獲取關鍵信息以及給出結論
在所需要管理的人員達到30人以上時，即使你不去找別人，也會遇到各種各樣的同事因為各種事情找到你，如果每天平均5個人來找你討論技術，每個人半小時，看起來是2-3時沒了，實際上是4-5個小時沒有了都不止，因為包括你必須從已有工作中恢復上下文。因此在與小伙伴溝通過程中，快速抓住重點，了解到他們的困難到底是什么，就變的很重要了，否則自己就沒時間搞其他的了。當然，每個人遇到的困難都是不一樣的，是方向？還是方法？還是技術積累不夠？我自己抽象了一個模型，以物理中求當前的速度為例：我們都知道：速度v = 初速度v0 + at（加速度*時間）。
如果小伙伴找你討論時：
1、首先要問他是否知道自己的目標是求出當前的速度v，
a. 如果不知道，先明確自己的目標是什么？或者給小伙伴說清楚你要求的目標是什么！
2、在明確了目標之后，我們需要明確，初速度v0是否知道？加速a是否知道？t又是否知道？
如果不知道，我們需要跟小伙伴討論為什么不知道？是因為沒法知道？還是什么？目標就是幫小伙伴把所有需要的條件都找到。
3、所有條件都滿足，至于at（加速度*時間）是需要積分、擬合亦或者a是常量，這些都是小伙伴自己去考慮的。當然如果時間充足的話，也可以幫他一起分析，但是想說的是，需要控制時間以及給小伙伴的時間。
4、在明確目標、確定條件后，在討論的過程中，作為技術負責人一定要給一個明確的結論，并跟小伙伴明確清楚是否還有其他困惑，同時自己的內心需要有一個工作量的評估，這個可以小伙伴也可不和他說，只是自己作為技術管理、項目管理的一個參考指標。
我自己用這個模型后，從過去1年的效果來看，給自己節省了不少時間，在這個過程也培養到了小伙伴的思維。所以作為技術負責人，明確目標、找到必備條件以及給出結論是不可少，同時還得有難度、工作量的評估。
參與、甚至親自實現初版代碼+并且保持技術在整個團隊的中上水平
作為技術管理者，自己水平是必須保持在中上的，如果團隊成員是小于15個人的，我認為還得是top級別的；如果是多于15人后，也必須保持在整個團隊的中上水平。因為只有這樣，你才能做到其那面提到的各種要求：規劃能力、項目中的主要矛盾、個人困惑中的解答以及工作量的評估。并且作為技術管理者來說，本身的技術水平決定了團隊成員對你話的信服是成正比的，在團隊成員中建立了技術影響力之后，你的很多結論、方向和方法可以得到推廣，這樣又能一定程度降低溝通成本。如果從0到1的項目（并沒有這么多從0到1的項目），我的建議是初版代碼必須自己去寫，甚至可以通過代碼來替代軟件架構文檔，對于組件來說，如果滿足技術水平中上時，前期做好構想，寫初版代碼和寫詳細的軟件架構文檔時間不會相差很多的。這樣做至少有兩個好處：
-
軟件架構和初版實現都是按照自己的想法去寫的，在后續迭代過程中、review代碼時，可以極大的降低心智負擔，并且如果小伙伴開發時沒有按照既定要求開發時，也能很敏感的感知到。
-
交付（架構）代碼，然后軟件架構文檔交給小伙伴去寫，這樣有助于小伙伴從設計角度去審視組件，也有助于小伙伴的能力提升
我自己還是上述工作模式中受益很多，比如s2s、sox、comm、service template都是從0開始搞起來，作為一個合格以上的組件架構就在心中很明確了。實際中，s2s我接近1年都沒有做過開發，但是需要遇到新需求、有bug時，我基本都能快速反應過來應該在哪里；平常技術時，小伙伴溝通，我也是無障礙可以get到他們想表達的意思。
沒有銀彈，快速原型很重要
“沒有最好的技術，只有正確的技術，選擇一個方向先把困難點找出來，再做優化。”這是我對小伙伴說的最多的話。當然這句話本身是有一點片面性，所以我更想說的是，作為技術負責人在做決定以及技術探索時，一定不要瘋狂內耗，東一榔頭、西一棒槌的。針對一個任務、項目尤其是一個全新的任務，路上會遇到很多困難，當我們遇到困難時，我們首先想到的就是是不是當前路線有問題，此時就會考慮換一種方式，但是大多數時候，換一種方式也會遇到另一種困難。如果一個人的時候還好，浪費的是自己的時間，當需要對整個團隊負責的時候，如此反復橫跳，帶來的后果是災難性的：失去信任、以及浪費時間。
1、在前期充分調研，可以把時間拉長一點。
-
比如我在做mcu自研時，我們其實在10月份才真正的開始，但是我在7月份就已經開始著手調研、實操，把未來可能遇到的問題、困難點，都列出來，然后找到對應的資料定性、定量的分析。
- 當我的一個想法提出來或者要讓團隊開始做時，基本我已經把所有任務的難點都評估到70%以上了，所以在后續小伙伴提出質疑時或者畏難時，我基本可以把他們說服。
2、定好基調（做或者不做、方案、時間點）后，不要再改變
- 基于第1點，大概率是不會出錯了，這個時候千萬不要瞻前顧后的，我們應該一往無前的把一個大致目標完成，把所有困難點再進一步細化解決方案或者反向。
3、優化、迭代
- 沒有最好的方案，但是有更好的方案，在小細節中，我們為了快速達成目標，多多少少都會用一些workaroud或者stub的地方，這個時候，我們一定不要忘了這些點，我應該通過多次優化、迭代甚至重構來達到整體更好的方案
我們做的大多事情，都不是天頂星科技的，所以不管如何最終都能完成，但是在時間、資源都有限的情況下，我們只能通過合理的安排我們的計劃，才能達到“最優解”。很多時候，我都認為，技術在對一個項目中不是最難的，尤其對于技術責任來說，更多的是在于：項目管理能力、隨機應變能力、做事思路、以及堅持。
03.管理
如果技術方面是讓團隊方向不會錯、目標不會錯，那么管理我想談的是，如何讓團隊所有人一起參與，從而真正的達到目標。從個人感情來說，我是一個不太會做管理的人，個人比較推崇所謂的“發揮個人自主性”，所以真實來說，我不太會push，算是一個“重過程”的人，所以考慮更多的是共情。從另一方面來說，我的職業生涯從18年開始，一直也是比較自由的，而且自己也算一個比較懶的人，因此我的管理是有重大缺陷的，幸好在我現有團隊中，我領導幫我彌補了很大一部分。就管理來說，我想從四方面來談：團隊文化、團隊成員培養、目標制定和回顧、獎勵與懲罰。
團隊文化
在23年團隊快速擴張過程中，我給領導，我們要有自己的文化了。文化整體是一個很虛的東西，但是在實際過程中，又是一個很實際的東西：當年你要完成任務時的思想一致！當你提出質量要求時的響應！當你面對困難時的信心！以及當面對壓力的支持。在我看來的文化，始于招聘。招聘到最優秀的人，其實很難，但是找到服務我們氣場的人，相對來說簡單一些。所以我面試時（過去1年面試了100多人），我很少關注候選人當前完成的一些成果，我更多的會關注候選人在完成任務時的一些思路、心理變化以及扎實的計算機基礎，在我看來，這個優秀的人，即使不是這個行業的，相信即使轉變也是很快的。扎實基礎的人，往往會對技術有敬畏之心，在后續交流中可以較少出現激進、蠻橫的行為。
關于高效不加班，我也是很推崇的，但是但是不細說了。
寫到這，突然卡殼了。只能說，文化這個東西，是體現在日常工作中的一點一滴，很難評判一個好的文化是什么樣的。但是如果在合作過程中，經常出現在非技術問題上看法不一致時，那文化一定是有問題的。
團隊成員培養
團隊培養，我自己喜歡分為三個階段：融入，成長，獨擋一面。在人數很少的時候，成員的融入，我基本都會從當前項目中，抽出很獨立且核心部分，然后提供函數級的實現，這樣在他完成函數級編寫，并且完成聯調之后，他基本上了解項目的內容、目標以及現狀了。后面在人數變多時，我做的其實并不夠好，因為自己忙的暈頭轉向了，但是我后面又想了解決辦法：在融入的過程中，應該盡早識別后續有可能成為別人入職導師的人，并告訴他，以后有新人進來時，要把這個做法重復一遍，并且把自己融入過程中的困難，讓后續新人避免過去。這個在團隊從小到大的過程中特別重要，算是團隊文化的一部分。我自己從恒潤出來的，深受其益。對于大部分人來說，這個時間不會太長，基本1-2個月就過來了。但是，但是，這個過程，你會發現有些人難以融入，這個時候，我的做法是，即使人數很多的情況下，也需要花時間，幫小伙伴分析融入困難的原因，是因為背景？還是喜好？甚至還是個人問題（人品、技術、動機），如果前兩者的話，我們需要站在團隊的角度、并且結合個人背景合理的安排；如果是后者的話，我建議根據大團隊通俗做法、該勸退、勸退；這樣對大家都好，避免內耗。但是，即使分手，我建議還是和平一點、人性一點，能夠幫小伙伴爭取到的，盡量爭取。
成長的過程，每個人的時間長短不一樣，這也是一個人是否能夠成為獨當一面的的關鍵，對于很多優秀的小伙伴，即使跨行也是能很快的上手的。在小伙伴成長的過程中，我覺得保持客觀極其重要的，沒有十全十美的人，一定要發現小伙伴的長處，并且利用其長處，團隊都4-50人，一定會有人家合適位置的。比如有些人技術牛逼，但是不愛說話，那應該給他有挑戰、需要埋頭干活的位置；有些人默默不聞，但是對于瑣碎、需要耐心的活，無怨無悔，那應該給讓小伙伴指定具體的任務給到他；有些人完全具備端到端的能力，測試、開發、bug修復一條龍全部完成，如果遇到這種人，就應該往獨當一面的反向培養；而有些人技術整體平均水平，但是很會吆喝、甚至很愛表現，那就應該配置一些默默干活、且沒有規劃的人跟他一起干活，把這些攢在一起共同完成任務；在人數有點多的時候，不管是奇葩的、優秀的、中庸的人都會遇到，在這個過程中，處理作為技術負責人必須盡早的識別出來，然后給到合適的位置以及工作內容。在我看來，這個過程其實不僅考慮負責人的識人、用人的水平，而且也是經驗負責人是否達到了一定技術水平的關鍵。只有在自己技術水平中上以上，才有能力評估，有些人是真不行，還是只是不愛說話；有些人是真的牛逼，還是會匯報。有一個事實不得不承認，大部分在很長的職業生涯都會在成長過程中，很難成長為獨當一面的人，而對于我們這種4-50人團隊來說，技術負責人更應該關注的應該是有特點的人：長短明顯或者各方面都很不錯的人。
在經歷過成長后，我們應該選出能夠獨當一面的人或者在某方面有特長的人，我們后續的關注重點也基本上都是在這些人身上。針對到了這個地步的人，我比較喜歡或者我自己認為正確的做法時，給予足夠的空間，幫其背足夠多的鍋。很多時候，有些人都是遇難則強，在這個時候難免會做的不好，那作為技術負責人，必須有足夠的擔當的，在我看來，讓其沒有后顧之憂是最大的支持。我也經常在他們遇到困難時，會說，別怕，決定是我做的，盡管做，我會經常check，做爛了，我也會擔著。能夠走到這一步的人，多少還是很要強的，他幾乎不會讓你失望，即使真的做爛了，背鍋又如何。但是如果小伙伴做出成果了，一定要在各種場合明確的說，這是哪個小伙伴做的，沒必要含糊不清，更不要說自己做的功勞，作為負責人，成果本身就就是你自己共享的。
目標制定和回顧
目標制定尤其考驗技術負責人能力，必須意識到，很多底層執行者是沒有辦法制定自己的中長期目標的，這不是他們能力的問題，而是負責人不能很好的制定清晰、工作量可評估的目標，甚至團隊目標也是多變的，那對于底層執行者來說，太難了，自己心中的目標變成了大海中漂浮的燈塔，所以這時候千萬不要對小伙伴說，你們先制定，我來整合！整合個毛！在前面技術章節，我提到了目標制定，必須能夠清晰的知道產品最終要達
1.到目標以及需要的時間和工作量
2.為了達到最終目標過程中的小目標
3.下一代產品或者新業務需要的事情
團隊大部分成員應該關注的前兩者，而負責需要著重考慮第三個。坦白來說，目標制定，是一個很虛的事情，但是有一個綜合素質的體現，技術、項目管理、人員能力識別，缺一不可。讓合適的人、使用正確的技術在合理的時間內完成任務。
與目標制定同樣重要的，還有回顧?；仡櫡謨刹糠謥碚f：個人回顧和團隊回顧。
作為負責人首先需要自己回顧，自己定的目標是否達成了，總結做的好，尤其還需要總結做的不好，是否有因為決策失誤導致加無用的班。我自己在回顧2023 q2時，就發現了，對原來的目標沒有牢記心中，到時團隊在一個短期不需要交付的事情長，讓自己、團隊加了很多沒用的班，導致自己灰色q2產生了。在后面的過程中，我基本上都會反復檢查自己的目標。而回顧是避免自己作為領航人做出有較大的偏差。
團隊回顧，我自己更多的是以正面為主，當然這個可能跟我們本身做的還不錯有關系，不過我依然認為即使做的不夠好，依然應該以正面回顧為主，因為所有人都希望得到肯定，如果把回顧作為復盤會，那么回顧會已經失去了很多人的興趣了。團隊回顧中也應該做檢討自己做的不足，然后在指出其他小伙伴做還有進步的地方。在面對全員暴露自己的弱點也是拉近距離的方式。
目標制定需要根據組織的方式按季度、按年來規劃，以前我在比較輕松氛圍的公司時，更多的是按照自己喜好（關鍵節點、成果以及失誤）來展開，在現在公司基本上是按季度制定。而內心其實季度、1年度、2年度都有自己的目標。
獎勵和懲罰
績效是所有人最關心的問題，關于這部分，我的做法是，開誠布公說清楚，團隊績效規則：丑話當先，no surprise。
而懲罰的話，其實是我不想談的，年底有一個小伙伴拿低績效，我自己是不愿意的和愧疚的，因為我覺我沒給到最好的，好在是我領導去聊的。所以我想表達的，當小伙伴做的不夠好時，自己是否有責任呢？如果小伙伴真的做的不好，只能走PIP（貌似現在這個詞很負面了！?。?。
坦白來說，我對管理中的人員管理并不是很擅長的，包括我的管理經驗基本都是靠技術影響力在支撐，所以主打的是共情力，共情力在有重大缺陷，那就是對目標認可多不夠高，會為團隊的不及預期找各種借口。另外，其實底層管理者很難做，兩面為難，所以不管對任何人來說，打工人何必為難打工人。
04.個人
本來不想寫這個塊的，說到個人這塊，那肯定就是認為自己做的好，然后從自己身上總結經驗，這多少有點吹噓的成份，但是后面想了下，我自己其實做的也不夠好，對個人這塊的總結，也算是對自己的鞭策吧。所以談到個人，除了前面談到的技術，我想從以下方面來說：情緒以及演講能力、總結能力以及持續學習方面，三個方面來談:
情緒以及演講能力
為什么我講情緒跟演講能力放到一起？因為在我看來，管理者很多情緒波動都是由談話引起的，而談話的目標又大部分是為了輸出某個觀點，因此我認為要管理好情緒，就需要很好的演講技巧來推銷自己的觀點和理念。因為自己畢竟比較年輕，所以針對情緒控制，我自己也沒有很好的辦法，所以就側重演講績效了，結合周鴻祎的演講，我自己總結三點：
1.不裝不端有點2（stay hungry stay foolish）
保持謙卑，我自己很多情緒變化是在應該得到被認可時，卻遭受正確、不正確的質疑。這也是人性的弱點，但是后面我學聰明了：我上來就躺地上，我就是一個傻子，別人說的話，或多或少對我會有啟發。包著學習的心態，好像情緒一下好轉了，就像當初老師質疑學生時，你首先懷疑的是自己。
2.why? what? how？
很多時候，我都喜歡講，是怎么做的，再講這是一個什么，最后再講為什么。發現效果奇差，大家都是有自己看法的，我為啥要知道你怎么做的？這個時候，大家心里估計就是想著挑刺??！所以我后面換了，先講為什么，讓觀眾帶入我的思考方向，如果不對的，立馬反思；然后再將這是一個什么，告訴大家產品形態；最后基于原因和目標，講為什么是這么做！發現效果奇好。
3.總結、確認
基于大家的反饋，給出總結，是讓參與者感受到參與感，同時也是對大家的結論再做最后確認，提高溝通效率和準確性。
持續學習
05.總結：大部分都是草臺班子
最后不得不感慨一下，團隊的優秀總是會在每次打績效中深刻的意識到。
轉自汽車電子與軟件
