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

導讀：成長即意味着改變，而改變自己是一件很痛苦的事情。改變會有連鎖反應，一次改變以後，你的心態和認知可能會和之前大有不一樣。平凡的人老是類似，不凡的人各有各的不凡，技術人的成長道路依然很長！本文由阿里巴巴前端技術專家悟尋將他在阿里的成長思考進行分享，但願可以給正在業務中深耕細做的你帶來一些思考和方向。

前言

我將我經歷過的或者正在經歷的狀態，分紅三個階段進行總結：求生存，謀發展，修體系。

階段一：埋頭苦幹求生存

做爲一個服務一線業務的前端同窗，支撐好業務佔據咱們 50%-60% 左右的 KPI，縱觀行業前端自己很容易成爲整個業務的資源瓶頸，而身爲業務的前端我相信必定經歷過疲於奔命，常常線上救火的事情。

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

需求管理

首先需求是作不完的，因此要有取捨，集中人力和精力作核心的業務需求，才能發揮最大的價值，若是你所在團隊目前處於各類零散的需求紛至而來致使沒法應節的狀況，則有必要進行相應的需求管理措施：

1.需求雙週排期會

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

固然好比業務方靠譜或者有大的規劃，則通常會對財年的目標進行戰役級別的拆解，而且梳理出業務今年必需要要拿下的幾場戰役，那麼技術同窗就能夠根據戰役來排兵佈陣了，業務和技術同窗也有明確的統一的戰線和目標，好比咱們目前就是以各類戰役爲主，平常需求穿插爲輔。

2.如何拒絕一句話需求

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

• 1.多問幾個爲何：這好比你這個需求背後的目的和價值是什麼？作了以後有什麼預期的收益，爲何這麼作就能夠達到這個收益，你能夠不直接問業務方，可是你也須要問本身，業務方的這個目標和作這個需求的路徑是否能夠匹配得上，若是實現路徑存在邏輯漏洞或者不是最佳的則這個需求也就沒有作的必要性；

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

• 3.不能直接說不，但能夠有條件的說是：當你肯定這個需求是 ok 的，但你確實暫時抽不出時間來搞定這個事情的時候，這時關鍵在於咱們不能直接拒絕業務方，久而久之會影響到後續的合做關係，這種狀況你能夠說：這個需求我接受，可是我可能須要較長一些的緩衝時間或者砍一些需求(部分知足)。又或者必需要按時上的話，不能保證項目的上線後的效果、質量等，讓業務方來作部分的取捨。

提高開發效率 & 質量

固然做爲技術人員，需求管理只是一方面，還須要從自身的角度出發，提高開發效率和質量，這個我相信你們都深有體會，儘可能不要作低質量的重複事情。

好比經過統一開發技術體系和封裝相應的可複用的組件和提效工具等來釋放本身和團隊同窗的生產力，千萬不要由於太忙而放棄思考和作這些事情，這樣只會欠下更多的技術債。固然這裏也有個誤區，並非鼓勵你們造輪子，身爲業務團隊的同窗，儘可能把眼光能放到行業或者集團內藉助現有的技術方案快速的定製來知足本身的業務訴求，好比以前咱們藉助舒文團隊的魔系列產品定製了海外本身的魔石模塊來知足海外營銷場景的需求開發，如今基本上大促相似坑位模塊都獲得了比較好的解決。

再者就是質量問題，須要抽空對線上常常出現問題的產品和代碼進行梳理和方案的從新設計，在作國際時我通常是利用週末的時間來作這種事情，進行部分的重構來達到這種問題的完全解決，避免三更半夜出現「連環奪命 call」。剩下的方式和手段就是增長開發環節質量保證和必要線上監控了。

關注上線效果 & 及時總結

有的時候咱們認爲項目提測上線後就完成了，這是一個很差的習慣，久而久之本身也就在合做方當中淪落爲一個項目資源的角色，處於被動的狀態。其實仔細分析下上線以後的業務數據和效果 & 分析總結，有以下好處：

1.提升本身對業務的理解能力，你在關注業務數據的同時，也就會更多地從業務的角度來看到這個功能所帶來的價值是否符合預期，當出現不符合預期的時候，能夠和業務方一塊兒進行數據漏斗的分析從而找到問題所在，避免咱們的勞動成果成爲一次性的工做；

2.總結的同時能夠幫助本身梳理這個項目中本身哪些地方作的不足，或者相關推動中存在什麼問題，以及後面怎麼改進，提升了下次項目中的迭代效率和質量。好比這個項目是否存在需求理解不到位存在返工，或者溝通 & 聯調低效，環境不穩定，本身設計的方案是否合理等問題，後續要怎麼解決；

3.也能夠從數據和總結中判斷出什麼樣的需求是靠譜的 & 什麼的樣業務方是靠譜的，頻繁爭取資源上線效果又很差的業務方，下次再有需求過來則須要多增長一個心眼和思考的過程。

小結

以上就是我在應對業務需求井噴所總結的一些經驗，整體來講就是雖然業務佔據咱們大部分的 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 承風），因此這裏須要作到取捨並非全部的子項都是值得在現階段作或者須要花費較大成本去作的。須要抓住其中的核心子項，也就是核心抓手。

小結

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

最後

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

 

本文做者：悟尋

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。