從求生存到修體系，我在阿裡找到了技術人的成長模式

作者 | 悟尋 阿裡巴巴前端技術專家

導讀：成長即意味着改變，而改變本身是一件很痛苦的事情。改變會有連鎖反應，一次改變之後，你的心态和認知可能會和以前大有不同。平凡的人總是相似，不凡的人各有各的不凡，技術人的成長道路依然很長！本文由阿裡巴巴前端技術專家悟尋将他在阿裡的成長思考進行分享，希望能夠給正在業務中深耕細作的你帶來一些思考和方向。

前言 

我将我經曆過的或者正在經曆的狀态，分成三個階段進行總結：求生存，謀發展，修體系。 

階段一：埋頭苦幹求生存 

作為一個服務一線業務的前端同學，支撐好業務占據我們 50%-60% 左右的 KPI，縱觀行業前端本身很容易成為整個業務的資源瓶頸，而身為業務的前端我相信一定經曆過疲于奔命，經常線上救火的事情。

我入職後的前一年主要做進口業務：天貓國際，一個包含平台和自營的業務。當時的進口業務還處于野蠻生長，競争激烈的階段。經常面臨一年兩大改，日常需求不斷，期間還要應付一年的 5 個 S 級的大促和一些小促，我記得最忙的時候是 17 年雙十一，面臨着自營和平台兩塊業務的大疊代，同時還需要面臨雙十一大促各種需求，每天除了做業務幾乎沒有什麼思考和總結的過程。而經過那次之後我也深刻體會到對于需求管理和時間管理 & 如何避免線上起火的重要性。這裡我結合自身和團隊的經驗梳理了如何打破這種狀态的方法，也歡迎各位補充。 

需求管理 

首先需求是做不完的，是以要有取舍，集中人力和精力做核心的業務需求，才能發揮最大的價值，如果你所在團隊目前處于各種零散的需求紛至而來導緻無法應節的情況，則有必要進行相應的需求管理措施： 

1.需求雙周排期會

比如拉上老闆，PD 和業務方 & 開發一起，每兩周(時間可自定義)坐到一起對焦這兩周的項目進展和接下來所有需求，并且确定好優先級，哪些是應該安排資源進行開發，哪些應該進行取舍，讓更多的精力和人力 focus 在業務的重要事情上。

當然比如業務方靠譜或者有大的規劃，則一般會對财年的目标進行戰役級别的拆解，并且梳理出業務今年必須要要拿下的幾場戰役，那麼技術同學就可以根據戰役來排兵布陣了，業務和技術同學也有明确的統一的戰線和目标，比如我們目前就是以各種戰役為主，日常需求穿插為輔。

2.如何拒絕一句話需求

在需求雙周排期會中基本能搞定 80% 的核心需求和優先級，但在平時還是會存在一些業務方/PD 會找你提一些沒有經過梳理和思考的一兩句話的需求，比如：這個商品坑我想從一排一換成一排二的，或者想這個地方的 icon 或者營銷标我覺得字型不好看想修改下等等這樣的訴求。那面對這樣的訴求，在左耳朵耗子的極客專欄中 & 小胡子哥的部落格都有提到如何拒絕一句話需求的方法，結合我自己的經驗覺得有如下三個遞進的方法來解決：

• 1. 多問幾個為什麼：這比如你這個需求背後的目的和價值是什麼？做了之後有什麼預期的收益，為什麼這麼做就可以達到這個收益，你可以不直接問業務方，但是你也需要問自己，業務方的這個目标和做這個需求的路徑是否可以比對得上，如果實作路徑存在邏輯漏洞或者不是最佳的則這個需求也就沒有做的必要性；

• 2. 給出替代方案：經過上面的步驟，其實你會發現你已經過濾了一批無效的一句話需求，而有些需求可能是有一定的存在價值，但是可能業務方提到的點并不是有效的方案或者說成本太大的方案，這時你就需要思考替代方案，盡量通過現有方案或者小成本的方式來滿足業務方，間接的達到“拒絕”的效果；

• 3. 不能直接說不，但可以有條件的說是：當你确定這個需求是 ok 的，但你确實暫時抽不出時間來搞定這個事情的時候，這時關鍵在于我們不能直接拒絕業務方，長此以往會影響到後續的合作關系，這種情況你可以說：這個需求我接受，但是我可能需要較長一些的緩沖時間或者砍一些需求(部分滿足)。又或者必須要按時上的話，不能保證項目的上線後的效果、品質等，讓業務方來做部分的取舍。

提升開發效率 & 品質

當然作為技術人員，需求管理隻是一方面，還需要從自身的角度出發，提升開發效率和品質，這個我相信大家都深有體會，盡量不要做低品質的重複事情。

比如通過統一開發技術體系和封裝相應的可複用的元件和提效工具等來釋放自己和團隊同學的生産力，千萬不要因為太忙而放棄思考和做這些事情，這樣隻會欠下更多的技術債。當然這裡也有個誤區，并不是鼓勵大家造輪子，身為業務團隊的同學，盡量把眼光能放到行業或者集團内借助現有的技術方案快速的定制來滿足自己的業務訴求，比如之前我們借助舒文團隊的魔系列産品定制了海外自己的魔石子產品來滿足海外營銷場景的需求開發，現在基本上大促類似坑位子產品都得到了比較好的解決。

再者就是品質問題，需要抽空對線上經常出現問題的産品和代碼進行梳理和方案的重新設計，在做國際時我一般是利用周末的時間來做這種事情，進行部分的重構來達到這種問題的徹底解決，避免三更半夜出現“連環奪命 call”。剩下的方式和手段就是增加開發環節品質保證和必要線上監控了。

關注上線效果 & 及時總結

有的時候我們認為項目提測上線後就完成了，這是一個不好的習慣，長此以往自己也就在合作方當中淪落為一個項目資源的角色，處于被動的狀态。其實仔細分析下上線之後的業務資料和效果 & 分析總結，有如下好處：

1. 提高自己對業務的了解能力，你在關注業務資料的同時，也就會更多地從業務的角度來看到這個功能所帶來的價值是否符合預期，當出現不符合預期的時候，可以和業務方一起進行資料漏鬥的分析進而找到問題所在，避免我們的勞動成果成為一次性的工作；

1. 總結的同時可以幫助自己梳理這個項目中自己哪些地方做的不足，或者相關推進中存在什麼問題，以及後面怎麼改進，提高了下次項目中的疊代效率和品質。比如這個項目是否存在需求了解不到位存在返工，或者溝通 & 聯調低效，環境不穩定，自己設計的方案是否合理等問題，後續要怎麼解決；

1. 也可以從資料和總結中判斷出什麼樣的需求是靠譜的 & 什麼的樣業務方是靠譜的，頻繁争取資源上線效果又不好的業務方，下次再有需求過來則需要多增加一個心眼和思考的過程。

小結

以上就是我在應對業務需求井噴所總結的一些經驗，總體來說就是雖然業務占據我們大部分的 KPI，但不能在業務中迷失了自己，需要給自己安排總結和反思的時間，做到主動掌握節奏的支撐業務。

階段二：四顧茫然謀發展 

當然做到主動掌握節奏支撐業務還是不夠的，如何讓自己在做業務的同時能獲得更好的沉澱和成長呢？下面說說我經曆的第二個階段，我把它稱為四顧茫然謀發展。這個階段你會發現你雖然能較好地支撐了業務和有一定的時間來思考了，但是作為業務前端有個困境就是似乎不知道往哪些方向來發力來提升自己，特别是在每次制定規劃和寫 KPI 時，總會出現除了業務不知道該做啥的困境。在我看來身處在業務團隊的前端可以試着從兩個角度去探索和思考。 

業務賦能角度

業務賦能其實是需要我們緊貼業務規劃，制定技術規劃和方案。這裡建議從财年開始後就需要陸續和老闆，以及自己對口的業務 PD 去聊，找一些線索和輸入，了解業務方今年的 KPI 重點是什麼，預計的拆解和實作路徑是什麼？再結合自己的和團隊情況，想想自己能做哪些事情來幫助業務實作其 KPI，其實這并非是一個簡單的事情，我自己也在慢慢的鍛煉和訓練的自己，目前有兩點感受可以談下：

1.抓住本質從點及面，通盤考慮

很多時候，我們收到的痛點和業務需求都是單點的，這時我們不能着眼于眼前的單點問題，而需要通盤來考慮，比如 SEO 的頁面對性能非常敏感，經常會收到一些業務方來回報，說目前我們的 SEO 有這個地方，那個地方需要優化下，而單點解決這些問題可能對業務帶來的收益并不大，對自己的技能也沒有什麼成長。這時候如果通盤考慮這個命題，其實會發現做 SEO 頁面的優化，其實目的是為了提升 SEO 頁面的收錄和排名。提升 SEO 頁面的收錄和排名不僅有前端性能優化這一個路徑，還有一些其他的路徑：比如優化關鍵詞&長尾詞，采用 Google 的 AMP 技術改造 SEO 頁面，優化爬蟲爬取頁面的耗時，提升爬取率等等。這樣就能把點的問題轉化為面的問題，才能制定更有效和全面的抓手來賦能業務。

2.既要解決眼前痛點，也要長遠謀劃

很多時候我們不能僅滿足于眼前的 KPI，還需要了解業務方長遠的想法和可以預見的規劃。比如我們目前正在做一個集團非常重要的項目，這個項目時間非常緊張（前端需要 300 多個人日, 且隻有 48 個工作日，一度成為項目的風險點），業務和技術的第一要務就是按時上線。這時如果按着常理，規劃的目标肯定圍繞着如何按時上線的事情，而可以預見的未來，可能還需要基于這個模式落地到其他的站點，是以這裡在規劃和需要做的事情又增加了：如何做到技術方案的可以複制性？未來能新開站點如何做到縮短前端人力的問題？如何幫助業務做到海外站點快速規模化？這就是第二個次元的事情了，而當我把這個項目中所有可能的、近的問題和遠的問題都挖掘一遍，那我們要做的事情其實就是海外分站前端整體解決方案。 這就需要我們不斷挖掘問題和定義問題，然後再找到對策，才能找到更好的的賦能業務抓手。

技術體驗角度

技術體驗角度相對前端同學來說比較熟悉，而身在業務團隊，前端這塊也可以做比較多的事情，比如研發效能的提升，性能體驗優化，新技術試點和落地，與端的融合等等。如果想重點投入在這方向裡面有幾個點我覺得是需要重點關注的：

1.避免重複造輪子

當你需要制定一個産品化的方案或者工具和架構的時候，最好先放眼集團内部和行業，進行一番調研，看看業界和其他同僚是怎麼解決這個問題的。盡量站在别人的肩膀上做出創新或者參與共建，避免小團隊内造出重複和品質低的輪子，這裡建議可以多關注集團前端委員會的規劃和動态，多關注集團内外的分享，當發現有感興趣和共同有需要面對的問題和場景時，參與共建和共享。

2.方案的深度和廣度

這個比較好了解，就拿前端的性能優化來說，目前我們已經不怎麼談資源壓縮、combo 請求之類正常操作了，而是進入了和用戶端深入結合的深水區進行優化(深度)，如之前天貓的 Webbased 方案，而之前我在做海外性能優化 Global Lite 方案的時候也是從全鍊路的角度來規劃和思考的(廣度)。是以規劃方案的深度和廣度，決定了這個方案的收益面，而提升深度和廣度的方向或者說技巧我覺得可以是：

• 一是多跨出一步，以上下遊和合作方的角色來思考，和其他團隊&角色深度合作，探讨可能的方案；
• 二是以終局的思維來思考，比如這個事情最後應該是要做成什麼樣的，然後和現實做 match 考慮落地方案。

3.關注方案的 ROI

這裡其實涉及到你規劃的方案，完整實施下來的成本和收益問題，這個會最終衡量你做這個事情或者方向的價值。那如何衡量成本和收益呢？成本可以考慮從兩個角度來說：一個是平時我們了解的成本, 比如投入了多少人日，花費了多少經費等，還可以從另一個經濟學的機會成本來考慮，即放棄了的最大代價。收益其實比如提高了多少人效，提升了多少業務資料，提升了多少性能等，建議采用對比的方式來凸顯。

4.引進來&走出去

引進來的意思是盡量基于現有的方案和能力來進一步創新或者定制，走出去其實是将成果和方案能反哺出去，比如将方案覆寫到集團其他行業和 BU，解決類似場景的問題，或者開源，申請專利 & 多參與集團内外的分享交流等等。 

關于思考業務賦能和做技術規劃，其實是一個非常值得不斷探讨&鍛煉過程，建議平時多和老闆 & 團隊内高 P 溝通和交流，一般他們會比較有經驗，可以在思考的深度和格局給出非常多的建議，有的時候這種交流會有一種醍醐灌頂的感覺。 

階段三：千錘百煉修體系

有的時候當我們找到一個覺得可以深耕的方向 & 機會的時候，腦子裡面也許就已經有了大緻的思路和方案，這時候可能會迫不及待的就想要開工，陷入了各種技術方案的細節之中，這樣的壞處在于可能會導緻我們做着做着偏離了主航道，導緻最後的産出不理想。這裡我們需要有一套理論和方法來保證對問題了解是準确的，完整的 & 足夠高度的。這個塊有沒有方法和套路呢，答案是：有！那就是養成結構化思考和做事方式。

結構化的思維

1.建立核心目标

當我們在面對一個問題和挑戰(挑戰即機會)的時候，需要明确我們做這個事情的核心目标是什麼，建立問題的核心目标。舉個簡單的列子，比如在開發中遇到了項目編譯慢的問題, 目标可以定義為解決項目編譯問題，但是我們也可以升華一層為提升整個開發流程的效能，這時的核心目标就是對整個開發流程進行提效。進一步升華的目的是為了提升整個事情的價值和解決問題的覆寫面。

2.進行目标拆解

這裡可以根據不同的場景選擇不同的邏輯順序(時間/結構/程度)來進行拆解，比如開發提效這個目标我們就可以按開發的時間順序來進行拆解，比如: 本地開發 & 調試 -> 聯調 -> 預發驗證 -> 釋出上線等。這裡面需要關注的點就是需要做到拆解的完備和獨立，拆解出來的子項能夠做到互相獨立和完整。

• 時間順序：中心執行的步驟、流程等；
• 結構順序：中心的空間、地理位置、内部外部條件等；
• 程度順序：中心的輕重緩急、重要性等。

3.子項的清理

事業是無限的，人力總是有窮、認知高度總是不夠（from 承風），是以這裡需要做到取舍并不是所有的子項都是值得在現階段做或者需要花費較大成本去做的。需要抓住其中的核心子項，也就是核心抓手。

這裡我建議大家可以直接閱讀下《金字塔原理》一書（我自己也在學習中）和一些職業發展的其他書籍，補充自己除了技術方面之外一些思考和項目管理&人際溝通等方面的知識，當然書和文章都是理論知識，還是需要在工作當中千錘百煉的去修煉這種思考和做事的方式，才能展現出它的價值。這塊我目前也在不斷的在工作中嘗試，等後續如果有較多的體會和經驗再來分享。

最後

以上就是我在這幾年摸爬滾打出的一些經驗，借此機會也在這裡感謝下我的老闆和幫助過我的朋友，你們一直都是我學習和參考的榜樣。