技術管理進階——如何規劃團隊的技術發展方向

原創不易，求分享、求一鍵三連

前段時間有個粉絲問了一個問題：

小釵你好，我剛從大公司以P8的職級離職，新入職了一家中型公司做技術負責人，當前團隊士氣低下，無論技術體系還是團隊建設都十分落後，坑的一逼！請問在這種情況下應該如何規劃技術發展方向呢？

網際網路發展到今天已經有些年頭了，特別是大公司的技術體系建設十分完備，甚至達到了潤物細無聲的地步，這也導致了很多同學背靠體系，認為很多事情是“理所當然”的，但出來到中小型公司後卻發現一片狼藉很難適應，但就我這幾年的工作經歷，一篇狼藉可能才是常態...

所以，中小型公司去大公司撈人，多半是想讓他們協助建設相對完善的技術體系，而多數人是沒有能力推動體系化建設的，更多是罵兩句傻逼，最後悻悻的離開，而導致這個問題的根本原因是什麼呢？

根本原因如前文所述是基建與業務投入比例問題，中小型公司只能在技術基建投入合適的份額，這個份額多半就是一個CTO加幾個架構師的錢，再多就要失衡。

所以無論從資源投入還是時間視窗，中小型公司的技術建設只能以小步快跑，區域性翻新的策略進行，其中要講究時間點要拿捏火候，想要一口吃個胖子的人多半活不下去。

之前我們說了技術基建的投入應該在20%以內，今天來討論如何做技術基建規劃。

技術發展方向

規劃技術發展方向絕對不是無腦造輪子，更不是虛無縹緲的事情，要講究一個標準、兩個原則：

一個標準：技術發展結果要看ROI；

決策上強調投入產出比之外，還須強調戰損意識。戰損即個人、團隊的時間精力消耗是不可回收的消耗，比如團隊花一週時間完成了一個專案，這個專案上線之後發揮了預期作用，即合理戰損；

如果專案沒有發揮預期作用，甚至沒上線或者上線失敗，即無理戰損。要強調 100%資源投入 = 100%合理戰損 + 0%不合理理戰損。

然後是兩個原則：

原則一：技術發展方向必須圍繞效率、質量、體驗，三者之一展開；
原則二：技術發展方向必須解決當前實際痛點；

原則一是基礎，原則二是指導方向，因為多數時候效率和質量是互斥的，所以當兩者間有衝突時，要看當前團隊的主要痛點是效率問題還是質量問題，總的來說：

對於業務：效率>=質量>體驗；
對於技術：質量>=效率>體驗；

舉個例子，團隊之初，都是小專案開發，不會有什麼效率問題，稍微關注下質量即可，但隨著時間推移，小專案變成大專案；多個大專案串聯成專案矩陣，於是錯綜複雜的系統就出現了。

以文中粉絲案例來說，他接手的是一個“老舊”技術團隊，面對的是年代久遠的系統，就會出現一個現象：團隊中個體素質都很高，隨便拉出去開發一套新專案都是一把好手，但在體系內就是效率低、質量差。

這就是典型環境拖累個人的情況，個人雖然能力不錯，但還不足以解決環境問題，這裡需要影響力更大，資源更多的一號位做系統性治理，這個系統性治理，就是我們所謂的技術發展方向規劃。這樣說太虛，舉個例子：

案例·單點突破

兩年前剛接手團隊時候情況與粉絲案例類似，這個時候可以不用急著做技術規劃，因為大家都沒信心，當時技術團隊最迫切的問題是一個系統老是出BUG：

工作臺是醫生經紀人的重要工作工具，從上線以來BUG不斷：

使用者量大，進入工作臺空白/使用系統卡頓

工作臺新訊息不置頂

工作臺使用者列表區頭像裂開

以及難復現的各種各種偶發性問題

...

該系統小規模優化10多次；大型優化2次，結果依舊不理想。

面對業務方不停的謾罵，相關技術人員鍋多不壓身早已躺平，破罐子破摔，這種情況下什麼技術規劃都沒用，直接成立專案組讓技術能力過硬的小孫任Leader開始診斷，三大問題逐漸浮出水面：

組織建設問題

管理單點凸顯，上下鎖死，Leader無力推進，執行左右橫跳；
一米五九問題嚴重，關鍵人凋零；
組織執行力跟不上；

質效問題

產品質量低下並且研發質量意識不足；
專案流程混亂，文件基無沉澱；
業務單點問題嚴重，整體業務意識偏低；

工程問題

歷史包袱過重，工程建設停留在兩年前；
現有數量級一定會有效能問題，更不能滿足10倍增長；
非單系統問題，單系統優化好，但依賴的系統依舊會有問題，所以整體依舊不穩定；

看似一個獨立專案的問題，其實是整個技術體系的問題，技術系統就很容易引起蝴蝶效應，面對如此問題該怎麼做呢，答案是一規劃二甩鍋三拿資源：

技術Leader首先需要快速診斷團隊問題，並提供基本解題思路以及人員部署，這是其一；

而後技術Leader可以以新人之姿，大罵技術垃圾，將所有的鍋儘量往前任頭上丟，贏得業務方部分諒解，並承諾兩個月調整週期，為團隊取得時間視窗；

最後技術Leader需要向老闆要一些額外預算，用以成功後激勵眾人，提升團隊信心，老闆不給可以立軍令狀，因為第一個問題不能解決，那就可以提前滾蛋了。

技術有部署，時間有視窗，事後有激勵，一個小而美的成功案例就形成了，小團隊有信心了，自然就會影響大團隊，這個時候便可以進行第二輪設計了。

系統性升級

如果僅僅是在各種小戰役上玩策略，那麼整體實力永遠不可能提高，所以小案例成功後大家士氣正高，就應該趁熱打鐵擴大戰果追求系統性升級。

既然是系統性解決方案，就要有系統性的過程，這裡我的思維與前B站Leader基本一致：

技術規劃方法論

mission -> SWOT -> 目標 -> Context -> Structure -> tradeoff(ROI) -> 定賞罰標準 -> HowTo -> BestPractice -> 結果驗收 -> 覆盤反思

充分學習和讀懂業務，想清楚要做到什麼目標，想清楚怎麼匹配業務的發展趨勢，進而計算清楚需要具備哪些技術系統、技術設施和技術能力；
盤一盤，手上有哪些資源，可以借用哪些資源；
SWOT，查漏補缺和完善細節。注意充分收集一線資訊；
tradeoff & ROI，什麼模組適合Tech-redefine、什麼模組適合投多少資源、什麼模組適合借力、什麼模組適合花錢買；
定好目標，定好關鍵人，想清楚事項依賴、人員協作和組織結構，做好OKR & KPI，明確定性和定量標準。可以根據一線反饋及時更新；
過程中，隨時討論落地路徑和方法論，確保戰術符合戰略及動態解讀；
參考最佳案例和做出最佳案例，微創新；
結果驗收，以單點打透為目標，以細節完成度為評分標準，務求極致；分清楚職位角色、自然人，賞優罰劣，予以公平的認可和正確的引導；
對於執行同學，態度、戰術執行力度、參與度和實操過程中起到的作用是主要評估內容；負責指揮目標或結果的Manager & Leader，首要標準仍然是最終目標或結果的好壞，執行上的要點是更好、更壞這種程度上的差別；
覆盤反思。

實操案例

具體實操方面依舊是先做大量有用資訊輸入，形成此圖：

再做系統性分析，找出當前的核心問題：

最終，從人事物方面可以做的事情也就出來了：

再進一步就是對四個大方向設立四個S級的OKR，確定技術選題再挑選負責人不斷推動執行即可，最後再舉個複雜點的例子：

案例·團隊合併&技術規劃

在某種情況會出現公司合併的場景，公司合併會帶來技術體系的合併，這可能導致很大的難題：

兩個團隊初期規模300多人，當前兩個APP同時維護；
A團隊使用騰訊雲；B團隊使用阿里雲；
A團隊後端技術棧為Java；B團隊後端技術棧是golang，還有部分php；
A團隊APP體系之前可能放棄治療了，居然使用的是原生+Flutter+Hybrid；B團隊使用的原生+RN；
前端體系Vue、React都在用...
...

真可謂是神仙打架啊！好在合併後人員還算充裕，可以各自安好，但去年行業不景氣，技術側也不好過，結果就是100人不到的團隊要維護這個體系，而且還有進一步萎縮的風險，我真的是佛了！

不考慮業務熟悉度、團隊穩定性，單這個技術體系就很令人頭疼了...

技術人員減少了，而服務規模未減少，在人員急劇減少的情況下需要從工程建設、團隊管理、服務資源、需求控制等四方面進行降本增效的規劃且同時還要穩固團隊來保障業務穩定增長，所以怎麼做呢？

巨集觀診斷

團隊合併、多技術棧、歷史悠久，加上人員一大波流失，所有負面條件都佔齊了，什麼都想要註定什麼都失敗，所以可以得到第一個結論：

翻新老樓顯然不可能

好訊息是，合併回來的業務產品也走的差不多了，所以暫時做保守維護即可，新業務全部使用未來規劃技術體系。所以這裡的整體思路是：

維持老系統，重開新局

具體幾個大決策是：

統一雲服務；
統一DevOps等基礎服務；
統一前後端技術棧；
其中一個APP只維護不迭代，有大的迭代就集中所有力量，全部推翻重來；

之所有做這些決策是因為資源確實有限，另外老業務年久失修，熟悉的人也不在了，沒有更好的辦法，就當不破不立，先破後立吧！

說服老闆

光是你想還不行，至少還得說服老闆與產品！

讓他們知道你有多難，那隻會同情你不會支援你；
告訴他將會獲得什麼好處，那麼結果會有所不同；

這其實是一次向上彙報，可以用這個彙報結構：

比如說明問題嚴重性，不要光說現在有多少服務，每個人維護了多少個服務，做張表出來，技術棧問題也是：

問題清晰了，後續工作會更好繼續。但由於專業性，最終他們的關注點會留到概覽的專案列表，所以你需要清楚告訴他們：

到底要做哪些事；
做這事有撒好處；
做這事有撒成本；
做這事有撒風險；

具體到每個專案怎麼做，他們聽不懂也不會感興趣了...

卡點·技術棧合併

統一雲服務，大家都不會有什麼問題；

統一前端技術棧，前端React和Vue學習成本較低，所以也問題不大；

但統一後端技術棧，比如讓Java同學轉golang這就很有點困難了，但是資源不足的情況下，比如後端技術只有30人，如果還是一半一半的話，人員根本沒有流動的可能，那麼團隊也早晚要崩，這個情況怎麼辦呢？方案也很簡單：

柔性轉移

如果時間視窗充裕的情況下這個是比較好的策略，具體操作是好的專案用你想要的技術棧去做，並且匹配獎勵，有獎懲激勵，自然就會流動起來。

硬性轉移

如果迫不得已，上層也需要做決策，承擔相應風險，做硬著陸。

所有的技術規劃都是權衡利弊後的決策，有決策就有得失，這個時候堅持就好。

結語

最後回到粉絲問題本身，大家首先要有個預期：中小型公司的技術建設多半就是很差，然後作為技術負責人的職責是系統性的提升團隊戰鬥力，如果沒有這個認知，事情是沒有辦法做好的，具體到方法論層面：