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

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

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

小釵你好，我剛從大公司以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，首要標準仍然是最終目標或結果的好壞，執行上的要點是更好、更壞這種程度上的差別；
覆盤反思。