我是在2014年入職餓了么，從前端和PHP一直做到后端架構和團隊，從2014年到2017年陸續(xù)負責過公司客服、銷售、代理商、支付、清結算、訂單這些業(yè)務的產研與團隊；2018年從業(yè)務研發(fā)團隊抽身，6個人組起一個小組投身機器學習，試圖結合實際的業(yè)務場景通過技術改造業(yè)務；2019年回歸到平臺（中臺）研發(fā)，負責交易、金融、營銷三個中臺的研發(fā)和團隊工作。基于我在餓了么的4年和阿里巴巴的2年研發(fā)經歷，從技術、業(yè)務和架構層面分享一些我的思考。

一、技術層面

對開發(fā)同學而言，技術是立身之本，雖然往往面試造火箭入職擰螺絲，但技術就是你從業(yè)的的基石。不管是基本的動手能力還是問題分析能力，包括你的思維邏輯乃至對事物認知的思路，技術思維都會時刻影響你，最明顯的影響就是當你面對無數個問題的釘子時，技術是不是你最順手的那把錘子。

技術上我比較關注的幾個層面：

基本功（語言、編碼這個層面，主要是動手能力）
大型分布式系統的實戰(zhàn)經驗（RPC、SOA、MySQL、Redis、MQ）
項目（DB設計、API契約、DDD抽象、鏈路設計、項目風險把控）
穩(wěn)定性（可用 & 資損）

1、 穩(wěn)定性

穩(wěn)定性是一個先有意識再有能力的事兒，記得2015年初，張雪峰加入餓了么擔任CTO之后，從他嘴里最常聽到的一句話就是“研發(fā)要對生產環(huán)境有敬畏”。

2014年下半年，各方人馬都開始殺入外賣市場，餓了么啟動百城計劃進行業(yè)務擴張，短時間內從10+城市覆蓋到100+城市，日訂單量也很快從10W上漲到100W。業(yè)務井噴的同時，技術還沒有做好足夠的準備，我印象中2014年下半年近乎每天中午交易量都有新高，但同時也伴隨著系統開始宕機、限流擴容、緊急調優(yōu)、客服爆線、技術加班熬夜。

我曾在新鄉(xiāng)的客服中心看到有的客服同學突然崩潰，耳機直接摔下來離開工位，因為每天會接收到大量用戶的來電責問，就在那一刻其實你才會清晰且直觀的感受到：你在編輯器的一行代碼，你在服務器的一次發(fā)布，會對現實世界很多活生生的人有直接影響，你會突然意識到你的工作比你之前以為的要重要且有意義。
所謂研發(fā)要對生產環(huán)境有敬畏，就是你知道你的作品會對別人產生不好的影響，你會為不好的結果感到慚愧與內疚，這就產生了敬畏。

應急處理有一個基本原則：“以業(yè)務影響最小為主，優(yōu)先恢復為核心目的，不要糾結手段和根因。”

別把你的懊悔、決心、穩(wěn)定性的思考、各種奇妙的idea以及執(zhí)行力體現在事故復盤會上，系統的安全生產和火災一樣，事前才有意義。

2、 鏈路設計

大部分產研缺少全鏈路的視角，往往看到的是自己負責的點，但是對于一條線乃至整個面是看不到的，也沒有機會去思考這些，而對于一些大項目和長鏈路系統而言，這是致命的。

對你所負責的系統，它關鍵的上下游、核心業(yè)務的鏈路一定要熟悉，包括數據、接口（調用、功能、邏輯）、各種異常的處理和特殊的設計。

能幫你達成這一目的的最簡單的辦法就是畫圖、畫圖、畫圖！重要的結論說三遍，一定要自己能把系統的大圖畫出來，然后做到可以根據大圖隨意放大和縮小。放大到就是將鏈路畫到業(yè)務場景里突出業(yè)務邏輯和上下游交互，縮小就是細到某一次調用的處理邏輯大致是怎樣，數據是怎么變化。經常畫圖，不用糾結形式和標準，重要的是形成自己理解系統的一個框架，一個自己的思維方式，需要的時候可以隨時拿出來用。

日常不管是聊需求還是做系統設計，習慣性的把圖畫出來，就達成了一半了。剩下的一半就要看著圖去找想、去找問題。放兩個雙十一貓晚在公開渠道的大圖，可以找找感覺，自己畫的話一定要鉆到服務、接口和數據上，類似我上面說的你有一個放大鏡，隨時能放大也能縮小。

3、 技術債務

永遠不要騙自己說，現在為了這個需求先挖一個坑，過一段時間再來填（重構 or 重做）。
技術債務和金融債務一樣，它必然存在，并且會像無賴一樣一直賴著，隔三差五會爆發(fā)一下。隨著時間的推移和業(yè)務的發(fā)展，你會發(fā)現架構越來越混亂，不同系統的領域邊界越來越模糊，系統和需求與組織關系的映射越來越復雜，服務內編碼風控越來越不一致，重復的輪子一個接一個隱蔽的出現。

“太忙了沒時間梳理哪些問題”、“改那些問題需要上下游一起改，費時費力，推不動”、“現在還沒出問題，而且正在整理了，別催”。其實通常情況下，技術同學多少都有點代碼潔癖，有很多問題不處理不是主觀的原因，而是客觀上因為精力、時間、ROI等因素，往往要等問題真的爆發(fā)后，大家才能狠下心來去處理那些問題 。

我以前處理技術債務的思路，是要有一個檢查清單，我會定期的復盤所有的系統，并且結合自己團隊和其他團隊的事故去全量掃雷。系統本身是一個平衡的產物，是時間、功能、風險、未來可能性等幾個方向平衡的結果。所以技術債務對于研發(fā)同學的考驗，不在于你怎么在日常工作中保證系統技術債為0，而是你要評估清楚在有限的資源和時間下，哪些問題是刻不容緩的，哪些問題是可以往后放的。

很難想象一個沒有技術追求的團隊能開發(fā)出一個健壯的、可維護性好、可擴展性好的系統。相反，這種業(yè)務代碼的堆砌，從短期看也許是“較快”實現了業(yè)務需求，但是從長遠來看，這種爛系統的增加會極大的阻礙業(yè)務的發(fā)展，形成一個個的黑洞應用，而工程師被裹挾在業(yè)務需求和爛系統之間，疲于應對，心力交瘁。這種將就將導致系統腐化墮落，技術債越壘越高，丑陋的代碼瘋狂滋長，像腫瘤一樣消耗你所有的能量，最后還要你的命。

4、警惕大項目

并不是所有人都有能力操盤大項目，可以平衡好交付壓力、上線質量、產品邏輯以及時間窗口，這是一個非常有挑戰(zhàn)的工作，需要純粹的技術能力之外的很多軟性能力來輔助，比如組織的溝通協作能力、向上要權要責的能力、平衡產品業(yè)務期望的的能力、突發(fā)情況應急轉變的能力等。越大的項目對于Owner的要求也越高，真能把大項目做好不怎么留大坑的少之又少。

大項目從啟動到立項所用的時間很多時候是遠超項目實際的開發(fā)周期的，項目的順利推進需要妥協，但項目的價值成功需要堅持。很多項目失敗其實在做的過程中，方方面面不斷妥協，最后做出來的東西已經遠離了最開始想象的樣子。

二、業(yè)務層面

除了技術之外，研發(fā)同學對業(yè)務層面也需要提升認知與重視。
對于研發(fā)而言，業(yè)務就像是外語，你不理解業(yè)務就好似人在異國，與周圍的環(huán)境格格不入，并且容易吃虧！相比產品、業(yè)務、運營等其他工種，技術更喜歡和技術打交道，業(yè)務在大多數同學眼中是混沌且缺少秩序的，沒有技術那樣清晰的實現路徑和穩(wěn)定共識的知識結構。并且技術相對容易證偽，而業(yè)務往往就是不停的嘗試，研發(fā)都討厭“不確定性”。但是在一個龐大的組織里想把技術做好，就必然要與業(yè)務打交道，畢竟業(yè)務才是一家公司存在的核心價值。

1、基于業(yè)務規(guī)劃做技術規(guī)劃

很多同學習慣于把計劃=規(guī)劃。阿里是一家尊重技術的商業(yè)公司，所以你看所有的團隊都在談業(yè)務、規(guī)劃里是業(yè)務規(guī)劃、周報里是業(yè)務項目、匯報里是業(yè)務成果、晉升的時候也要突出你的“戰(zhàn)功”。相比技術本身，大家更關注技術改變了什么，在業(yè)務部分聊技術團隊如何做規(guī)劃的原因就在于此，這是公司運營的的起點（目的），延伸出來才有具體的技術規(guī)劃和組織設計作為解決方案。

深刻理解業(yè)務并設計戰(zhàn)略，拆解戰(zhàn)役與項目，通過組織和各種機制確保項目的執(zhí)行與落地，最終拿到業(yè)務結果，這是一個大公司的標準戰(zhàn)略執(zhí)行方式。研發(fā)同學做技術規(guī)劃以及團隊規(guī)劃的時候，一定要考慮到你所在環(huán)境，公司今年要主打什么、所在大部門的目標是什么、對口的產品和業(yè)務現狀如何、純粹的技術迭代在業(yè)務上的好處在哪兒、另外團隊目前有哪些不可抗力、或者影響規(guī)劃推進的阻力。

很多同學做規(guī)劃的時候會習慣性按照這個思路進行：① 總結現狀（痛點）=> ② 對應的解決方案和策略 => ③ 展望未來。有時候②和③的順序會反過來。很多時候大家發(fā)現最終的部門規(guī)劃和自己做的規(guī)劃沒什么關聯，不知道怎么往那個方向用力，或者干脆繼續(xù)按照自己的計劃先走著。

對大部分同學，我建議規(guī)劃要實在。做技術規(guī)劃前，找你的周邊研發(fā)團隊聊一下，找你對口的產品、運營聊一下，知道他們的目標是什么，知道公司幾個重點是什么，然后結合你們目前的痛點，在現在和未來之前找平衡、找現在和未來都有收益的那部分。
規(guī)劃有一些很硬的內容，這個目標解決什么問題、怎么確定它解決了以及解決的好不好，好的結果誰認可等。規(guī)劃一定要有重點，沒有重點的那不叫規(guī)劃，那是你后面的日程計劃。很多同學對做規(guī)劃不投入，也有自己的想法，比如公司業(yè)務或者戰(zhàn)略變化太快、組織調整太頻繁，下半年在哪個團隊工作甚至做什么都不一定。不否認變化的頻繁以及對規(guī)劃的影響，但是如果一直這樣思考，你永遠無法從變化中獲得價值，因為你一直在置身事外。

2、研發(fā)要比產品還懂業(yè)務

研發(fā)要比產品還懂業(yè)務。雷軍說過：“永遠不要試圖用戰(zhàn)術上的勤奮，去掩蓋你戰(zhàn)略上的懶惰。”對于研發(fā)同學，你要比業(yè)務同學更懂業(yè)務才能找到技術與業(yè)務平衡的空間。對大部分同學而言，常常是只熟悉自己負責的系統，但是對于想要更大空間和更多成長的同學，我可以給出明確的結論：只熟悉自己負責的系統是不夠的。

首先，不同的人對熟悉的定義不一樣。對于你負責、你貢獻代碼、你進行設計并且完成需求交付的系統，單是熟悉遠不夠，你不僅要知道它的前世今生，思考它的一路成長，糾結它的未來發(fā)展，同時還要清楚它的風險與隱患，它的生與死。

基于你最清楚的核心系統，由它開始做業(yè)務場景上的外延，以此了解你的上下游，并且能做到結合業(yè)務場景去挖掘。從業(yè)務的角度、從產品的鏈路、從技術的調優(yōu)和隱患多個視角去切，讓自己的設計維度與視角不斷拉升，這樣你有把握或者有掌控力的范圍會越來越大，未來才會有更多的機會。

三、管理層面

團隊是一個宏觀與微觀并存的事務，宏觀上我們說組織、講戰(zhàn)略、定規(guī)劃、要排兵布陣，微觀上我們關注溝通、成長、情緒。大部分同學之所以在微觀上受挫就是因為沒能把握到宏觀的節(jié)奏，公司是一個盈利組織，技術中心是一個成本部門，技術中心之所以會有某一個組織那么一定是：“公司期望這個組織解決某一類問題，并且解決到一定程度。”

所以在這里你要理解一個關鍵詞，“結果和KPI”并不取決于你怎么定義它，而是給你下放目標的組織與管理者對你的期望是怎樣的，你們的GAP往往未必是結果的差別，而是期望的落差。

1. 擁抱變化

其實大多數時候不需要你去擁抱，變化會突如其來的抱住你，勒緊你的脖子讓你有那么一瞬間覺得呼吸困難。互聯網公司之所以變化快，很大程度取決于它的業(yè)務屬性，相比傳統公司能更快更清晰的感受到與市場的契合程度并且及時調整策略，所以沒有時間和信息上的延遲與滯后。

結合這幾年的經歷，到最近兩年加入阿里，一直說擁抱變化感覺就比較自然了。核心的體悟有兩個：

（1）對業(yè)務的發(fā)展和環(huán)境的變化要敏感，如果能在在變化到來之前主動發(fā)起變化，那么化被動為主動是最好的。即使不能，也要清晰的去感受和思考變化背后的動力在哪兒，去給找到關鍵的發(fā)力點，讓自己可以適應變化。

（2）變化帶來的工作內容的調整、匯報線的調整、團隊的變化等，不管好壞都是在一個時間段內相對的，而不是一個工作生涯中絕對的。不可能事事如意的情況下，調整自己的心態(tài)，把自己從情緒中摘出來更多關注事情會是一個好的選擇。

2. 加人不能解決問題

即使嘴上再怎么說“不能”，但是動作會很誠實，依然會盡可能多地要HC，更多的拼命的把更多“核心”的系統建建設在你的職責范圍內。
另外可以辯證的看類似于有效灰度，你可以看一下你有沒有“有效加人”，一些TL不關注新人的Landing，相當于只盯數量不盯質量，最后結果肯定是一塌糊涂的。

從絕對理論的角度加人肯定是有幫助的，你的資源變多了，周轉的空間和操作的余地都豐富了。但是從經驗看，大部分情況下加人沒有產生最終的價值變化（項目的結果、業(yè)務的成敗）。因為系統的開發(fā)、項目的推進并不是單純的資源堆砌，1000人日的系統哪是1000個人做一天就做出來的。真實的世界上，我們往往不是敗在資源的使用量上，而是資源的使用方向和使用效率上，但是因為加人這件事兒上最容易的、最無腦的，所以大多數情況下也最被優(yōu)先選擇。

3. 有意識地向上管理

這個問題源于過去經歷的兩個點，一是我經歷了無數次的組織關系調整，我發(fā)現不管是我自己還是我團隊的同學，大家相比于自己做什么以及帶不帶人、帶多少人外，更關注的是自己的匯報線。自己匯報給誰，誰是我老板，我和他處不處的來，他能不能讓我有提高、有成長。二是很多同學，尤其是P5、P6和少部分P7的同學，會對與老板的相處關系有困惑。
基于這兩個點我把向上管理作為一個單獨的話題加了進來，先說結論：要！要！要！必須要！一定要！

連馬老師都說員工離職的三大要素之一就是和老板處不來，你怎么還能心安理得的忽略它。如果大家對于向上管理還停留在服從甚至諂媚的態(tài)度來處理你們的關系，我只能說親，你真是硬生生把這么高大上的詞兒給解釋的特別的接地氣。我沒有系統的學過向上管理，也沒有體系化的看過這方面的書，所以我只說一下自己的理解。

個體在一個組織里想得到報酬和收益，基本的方法就是促進組織的成長與提高并且同步提高自己，這樣就可以從中分得自己那份收益。這就要求你產出的結果是要對組織有正向溢出的，但是這個方向與標準并不是所有人都清楚或者能準確的把握到。經常有績效差的同學很沮喪甚至抱怨的說，我自己經常加班，甚至是部門走的最晚的，周末也要處理工作等。先不討論復雜的背景上下文，如果命中上面這一條的，我先給你個忠告：除了按件計費的工廠，其它任何地方體力上的付出與最終結果都沒有明顯的直接關系。就像你上學的時候一定有那么幾個別人家的孩子，要么就是特別努力學習特別好，要么就是看上去每天和你一起玩，但是成績總是碾壓你。從學校到社會，這個現象并沒有消失，別迷信加班和體力上的付出，大多數人只要能不去思考，在體力上愿意做出的付出，遠超你我的想象。

與老板的相處和溝通，本質上是為了達成一致的目標和互相認可的結果。這是一個非常關鍵的初衷，我有時候開玩笑和團隊的同學聊，說你們要好好看看我老板到底想干嘛，這樣你們做出來，我好去匯報。方向、節(jié)奏、結果的對焦對于工作的展開和拿成績是至關重要的，同時你要從他身上獲取更多的信息以便于自己的判斷決策和學習，不斷從老板身上吸取養(yǎng)分。

在一些環(huán)境中，體力上的付出是必須的，但是僅有體力上的付出最終只能感動你自己，你的團隊并不想每天陪你加班到11點或者發(fā)布到凌晨2點，更沒有興趣凌晨1點半還拉個電話會討論方案。所以一定要做好“期望管理”，你老板對你的期望、對項目的期望、你對他給予你空間和支持的期望，大家一定要對焦清楚并且目標一致。

四、架構層面

還有一點我覺得也很重要，就是在架構層面，包括業(yè)務架構、技術選型和細節(jié)實現上，要有清醒的認知。

1. 最關鍵的是定義問題

愛因斯坦說過：“提出問題比解決問題更重要！”定義問題是個腦力活，解決問題是個體力活。大家往往習慣于看到一個問題就沖上去錘它，從概率上來講，很大可能會陷入一個解決問題的黑洞，就是你不停地在解決問題，但是最終你的情況沒有變好。

當你面臨一個困難或者一個情況時，首先比較重要的是定義問題，這到底是要解決什么、解決了有什么好處、怎么確定解決了。其次是定義結構，這個問題的關鍵點組成，你對應的解法是怎樣的，這其中得失要怎么權衡輕重，并且最終解決的效果如何貫穿和透傳，由點及面。

一個團隊可以不停歇的埋頭干，但是未必會干出成績。大部分習慣羅列面對的問題，但是對這些問題并沒有做一個全局的分析和梳理，其實最難的就在“找問題”上。

2. 問題的本質沒那么高深

有時我們做一個項目，可能有一個產品需求，大家看完覺得不好做或者做不了，因為系統現在不支持，改造成本太高，并且還伴有很多不確定的技術風險。相信很少有人在這種情況下會無腦的要求加人、加工期來解決這個問題。大多數情況下我們會看有沒有捷徑或者其他方案，讓產品效果達成，哪怕技術實現臟一些、繞一些。其實這時候橫向縱向多挖一下或者多問幾個問題，有可能就會有不一樣的答案。這個需求在解決用戶什么問題，目前這個解決方案是不是業(yè)務（產品、技術）上唯一的，這個解決方案會帶來哪些成本和新的問題，目前正在推進的其他項目和這個問題會不會有關聯，有沒有其他團隊也在解決類似的問題或者曾經解決過。

3. 達成目標

在工作中小到聊定一個API契約、中到上線一個需求、大到完成一次晉升，所有的事情都是有成功的方法的。找出短板、設定計劃、抗住挫折、反復訓練、根據反饋調優(yōu)，就可以解決任何問題。《債務危機》這本書里總結了一個五步成功法，很有意思：

著名的大數學家波利亞有一本名著《怎樣解題》，其中給了一個四步解題法，可能站在研發(fā)的角度看會更有感覺：

4. 持續(xù)學習才是根本

時代在持續(xù)發(fā)展和變化，現在正是最波瀾壯闊的年代，這樣的環(huán)境下，不管當前如何積累，都有可能隨著發(fā)展的變化在短時間跌落谷底。公司能發(fā)展一定是在某一個時期內非常契合環(huán)境的要求，但隨著時間的變化，如果它的變化不能跟上來，那么也只會被時代拋棄。正所謂讓你成功的，最終也將讓你失敗，比如柯達、諾基亞不能幸免，個體也難逃這樣的規(guī)律。

這樣的情況下，持續(xù)的學習和改變自身的能力才是研發(fā)同學最大、也是最強的優(yōu)勢。技術本身的日新月異要求你持續(xù)學習，同樣的習慣放射到各個領域上，才會慢慢的取長補短，優(yōu)化自身，所以如果說研發(fā)同學最需要什么，我認為持續(xù)的學習能力是最關鍵的。

正如餓了么創(chuàng)始人張旭豪在之前接受采訪時有一句話，讓我很難忘：最重要的是選擇，最困難的是堅持。

作者：石佳寧

原文鏈接
本文為云棲社區(qū)原創(chuàng)內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的饿了么4年+阿里2年：研发路上的一些总结与思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。