本文基于作者在餓了么 4 年和阿里巴巴 2 年研發(fā)經(jīng)歷，從技術(shù)、業(yè)務(wù)、管理和架構(gòu)四個層面總結(jié)的一些經(jīng)驗。

[[332299]]

 

圖片來自 Pexels

我是在 2014 年入職餓了么，從前端和 PHP 一直做到后端架構(gòu)和團隊，從 2014 年到 2017 年陸續(xù)負責過公司客服、銷售、代理商、支付、清結(jié)算、訂單這些業(yè)務(wù)的產(chǎn)研與團隊。

2018 年從業(yè)務(wù)研發(fā)團隊抽身，6 個人組起一個小組投身機器學習，試圖結(jié)合實際的業(yè)務(wù)場景通過技術(shù)改造業(yè)務(wù)。

2019 年回歸到平臺(中臺)研發(fā)，負責交易、金融、營銷三個中臺的研發(fā)和團隊工作。

基于我在餓了么 4 年和阿里巴巴 2 年研發(fā)經(jīng)歷，下面我將以下四層面分享一些我的思考：

• 技術(shù)
• 業(yè)務(wù)
• 管理
• 架構(gòu)

技術(shù)層面

對開發(fā)同學而言，技術(shù)是立身之本，雖然往往面試造火箭入職擰螺絲，但不可否認的是，技術(shù)就是你從業(yè)的的基石。

不管是基本的動手能力還是問題分析能力，包括你的思維邏輯乃至對事物認知的能力，技術(shù)思維都會時刻影響你。

最明顯的影響就是當你面對無數(shù)個問題的釘子時，技術(shù)是不是你最順手的那把錘子。

技術(shù)上我比較關(guān)注的幾個層面：

基本功(語言、編碼這個層面，主要是動手能力)

大型分布式系統(tǒng)的實戰(zhàn)經(jīng)驗(RPC、SOA、MySQL、Redis、MQ)

項目( DB 設(shè)計、API 契約、DDD 抽象、鏈路設(shè)計、項目風險把控)

穩(wěn)定性(可用&資損)

穩(wěn)定性

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

2014 年下半年，各方人馬開始殺入外賣市場，餓了么啟動百城計劃進行業(yè)務(wù)擴張，短時間內(nèi)從 10+ 城市覆蓋到 100+ 城市，日訂單量也很快從 10 萬上漲到 100 萬。

業(yè)務(wù)井噴的同時，技術(shù)還沒有做好足夠的準備。我印象中，2014 年下半年幾乎每天中午交易量都有新高，但同時也伴隨著系統(tǒng)宕機、限流擴容、緊急調(diào)優(yōu)、客服爆線、技術(shù)加班熬夜的問題。

我曾在新鄉(xiāng)的客服中心看到有的客服同學突然崩潰，耳機直接摔下來離開工位，因為每天會接收到大量用戶的來電責問。

就在那一刻，你才會清晰且直觀的感受到：你在編輯器的每一行代碼，你在服務(wù)器的每一次發(fā)布，會對現(xiàn)實世界很多活生生的人有直接的影響，你會突然意識到你的工作比你之前以為的要重要且有意義。

所謂研發(fā)要對生產(chǎn)環(huán)境有敬畏，就是你知道你的作品會對別人產(chǎn)生不好的影響，你會為不好的結(jié)果感到慚愧與內(nèi)疚，這就產(chǎn)生了敬畏。

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

 

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

鏈路設(shè)計

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

我的建議是，對你所負責的系統(tǒng)，它關(guān)鍵的上下游、核心業(yè)務(wù)的鏈路一定要熟悉，包括數(shù)據(jù)、接口(調(diào)用、功能、邏輯)、各種異常的處理和特殊的設(shè)計。

能幫你達成這一目的的最簡單的辦法就是畫圖、畫圖、畫圖!重要的結(jié)論說三遍，一定要自己能把系統(tǒng)的大圖畫出來，然后做到可以根據(jù)大圖隨意放大和縮小。

放大到將鏈路畫到業(yè)務(wù)場景里，突出業(yè)務(wù)邏輯和上下游交互，縮小到某一次調(diào)用的處理邏輯大致是怎樣，數(shù)據(jù)是怎么變化。

經(jīng)常畫圖，不用糾結(jié)形式和標準，重要的是形成自己理解系統(tǒng)的一個框架，一個自己的思維方式，需要的時候可以隨時拿出來用。

日常不管是聊需求還是做系統(tǒng)設(shè)計，習慣性的把圖畫出來，就達成了一半。剩下的一半就要看圖去想、去找問題。

技術(shù)債務(wù)

永遠不要騙自己說，現(xiàn)在為了這個需求先挖一個坑，過一段時間再來填(重構(gòu)or重做)。

技術(shù)債務(wù)和金融債務(wù)一樣，它必然存在，并且會像無賴一樣一直賴著，隔三差五會爆發(fā)一下。

隨著時間的推移和業(yè)務(wù)的發(fā)展，你會發(fā)現(xiàn)架構(gòu)越來越混亂，不同系統(tǒng)的領(lǐng)域邊界越來越模糊，系統(tǒng)和需求與組織關(guān)系的映射越來越復(fù)雜，服務(wù)內(nèi)編碼風控越來越不一致，重復(fù)的輪子一個接一個隱蔽的出現(xiàn)。

“太忙了沒時間梳理哪些問題”、“改那些問題需要上下游一起改，費時費力，推不動”、“現(xiàn)在還沒出問題，而且正在整理了，別催”。這是我們經(jīng)常會聽到的聲音。

其實，技術(shù)同學多少都有點代碼潔癖，有很多問題不處理不是主觀的原因，而是客觀上因為精力、時間、ROI 等因素，往往要等問題真的爆發(fā)后，大家才能狠下心去處理那些問題 。

我以前處理技術(shù)債務(wù)的思路，是要有一個檢查清單，我會定期的復(fù)盤所有的系統(tǒng)，并且結(jié)合自己團隊和其他團隊的事故去全量掃雷。

系統(tǒng)本身是一個平衡的產(chǎn)物，是時間、功能、風險、未來可能性等幾個方向平衡的結(jié)果。

所以技術(shù)債務(wù)對于研發(fā)同學的考驗，不在于你怎么在日常工作中保證系統(tǒng)技術(shù)債為 0，而是你要評估清楚在有限的資源和時間下，哪些問題是刻不容緩的，哪些問題是可以往后放的。

很難想象一個沒有技術(shù)追求的團隊能開發(fā)出一個健壯的、可維護性好、可擴展性好的系統(tǒng)。

相反，這種業(yè)務(wù)代碼的堆砌，從短期看也許是“較快”實現(xiàn)了業(yè)務(wù)需求，但是從長遠來看，這種爛系統(tǒng)的增加會極大地阻礙業(yè)務(wù)的發(fā)展，形成一個個的黑洞應(yīng)用，而工程師被裹挾在業(yè)務(wù)需求和爛系統(tǒng)之間，疲于應(yīng)對，心力交瘁。

這種將就將導(dǎo)致系統(tǒng)腐化墮落，技術(shù)債越壘越高，丑陋的代碼瘋狂滋長，像腫瘤一樣消耗你所有的能量，最后還要你的命。

警惕大項目

并不是所有人都有能力操盤大項目，也不是所有人都能夠平衡好交付壓力、上線質(zhì)量、產(chǎn)品邏輯以及時間窗口。

這是一個非常有挑戰(zhàn)的工作，需要純粹的技術(shù)能力之外的很多軟性能力來輔助，比如組織的溝通協(xié)作能力、向上要權(quán)要責的能力、平衡產(chǎn)品業(yè)務(wù)期望的的能力、突發(fā)情況應(yīng)急轉(zhuǎn)變的能力等。

越大的項目對于 Owner 的要求也越高，真能把大項目做好不怎么留大坑的少之又少。

大項目從啟動到立項所用的時間很多時候是遠超項目實際的開發(fā)周期的，項目的順利推進需要“妥協(xié)”，但項目的成功需要堅持。

很多項目之所以失敗，是在做的過程中方方面面不斷妥協(xié)，最后做出來的東西已經(jīng)遠離了最開始想要的樣子。

業(yè)務(wù)層面

除了技術(shù)之外，研發(fā)同學對業(yè)務(wù)層面也需要提升認知與重視。

對于研發(fā)而言，業(yè)務(wù)就像是外語，你不理解業(yè)務(wù)就好比人在異國，與周圍的環(huán)境格格不入，并且容易吃虧!

相比產(chǎn)品、業(yè)務(wù)、運營等其他工種，技術(shù)更喜歡和技術(shù)打交道，業(yè)務(wù)在大多數(shù)同學眼中是混沌且缺少秩序的，沒有技術(shù)那樣清晰的實現(xiàn)路徑和穩(wěn)定共識的知識結(jié)構(gòu)。

并且技術(shù)相對容易證偽，而業(yè)務(wù)往往就是不停的嘗試，研發(fā)都討厭“不確定性”。

但是在一個龐大的組織里想把技術(shù)做好，就必然要與業(yè)務(wù)打交道，畢竟業(yè)務(wù)才是一家公司存在的核心價值。

基于業(yè)務(wù)規(guī)劃做技術(shù)規(guī)劃

很多同學習慣于把計劃等同于規(guī)劃。阿里是一家尊重技術(shù)的商業(yè)公司，所有的團隊都在談業(yè)務(wù)、規(guī)劃里是業(yè)務(wù)規(guī)劃、周報里是業(yè)務(wù)項目、匯報里是業(yè)務(wù)成果、晉升的時候也要突出你的“戰(zhàn)功”。

相比技術(shù)本身，大家更關(guān)注技術(shù)改變了什么，在業(yè)務(wù)部分聊技術(shù)團隊如何做規(guī)劃的原因就在于此，這是公司運營的的起點(目的)，延伸出來才有具體的技術(shù)規(guī)劃和組織設(shè)計作為解決方案。

深刻理解業(yè)務(wù)并設(shè)計戰(zhàn)略，拆解戰(zhàn)役與項目，通過組織和各種機制確保項目的執(zhí)行與落地，最終拿到業(yè)務(wù)結(jié)果，這是一個大公司的標準戰(zhàn)略執(zhí)行方式。

研發(fā)同學做技術(shù)規(guī)劃以及團隊規(guī)劃的時候，一定要考慮到你所在環(huán)境，公司今年要主打什么，所在大部門的目標是什么，對口的產(chǎn)品和業(yè)務(wù)現(xiàn)狀如何，純粹的技術(shù)迭代在業(yè)務(wù)上的好處在哪兒。

另外，團隊目前有哪些不可抗力，或者影響規(guī)劃推進的阻力。

很多同學做規(guī)劃的時候會習慣性按照這個思路進行：

• 總結(jié)現(xiàn)狀(痛點)
• 對應(yīng)的解決方案和策略
• 展望未來

有時候第二和第三的順序會反過來。很多時候大家發(fā)現(xiàn)最終的部門規(guī)劃和自己做的規(guī)劃沒什么關(guān)聯(lián)，不知道怎么往哪個方向用力，或者干脆繼續(xù)按照自己的計劃先走著。

對大部分同學，我建議規(guī)劃要實在。做技術(shù)規(guī)劃前，找你周邊的研發(fā)團隊聊一下，找你對口的產(chǎn)品、運營聊一下，知道他們的目標是什么，知道公司幾個重點是什么。

然后再結(jié)合你們目前的痛點，在現(xiàn)在和未來之前找平衡、找現(xiàn)在和未來都有收益的那部分。

規(guī)劃中需要包含一些硬性的內(nèi)容，比如這個目標要解決什么問題，怎么確定它解決了，解決得好不好，好的結(jié)果誰認可等。規(guī)劃一定要有重點，沒有重點那不叫規(guī)劃，那是日程計劃。

很多同學對做規(guī)劃不投入，也有自己的“想法”，比如公司業(yè)務(wù)或者戰(zhàn)略變化太快、組織調(diào)整太頻繁，下半年在哪個團隊工作甚至做什么都不一定，所以規(guī)劃做得并不認真。

不否認變化頻繁的存在，以及這種組織架構(gòu)變化對規(guī)劃的影響，但是如果你一直這樣思考，你永遠無法從變化中獲得價值，因為你一直在置身事外。

研發(fā)要比產(chǎn)品還懂業(yè)務(wù)

雷軍說過：“永遠不要試圖用戰(zhàn)術(shù)上的勤奮，去掩蓋你戰(zhàn)略上的懶惰。”對于研發(fā)同學，你要比業(yè)務(wù)同學更懂業(yè)務(wù)，才能找到技術(shù)與業(yè)務(wù)平衡的空間。

對大部分同學而言，常常是只熟悉自己負責的系統(tǒng)，但是對于想要更大空間和更多成長的同學，我可以給出明確的結(jié)論：只熟悉自己負責的系統(tǒng)是不夠的。

首先，不同的人對熟悉的定義不一樣。對于你負責、你貢獻代碼、你進行設(shè)計并且完成需求交付的系統(tǒng)，單是熟悉遠不夠。

你不僅要知道它的前世今生，思考它的一路成長，糾結(jié)它的未來發(fā)展，同時還要清楚它的風險與隱患，它的生與死。

基于你最清楚的核心系統(tǒng)，由它開始做業(yè)務(wù)場景上的外延，以此了解你的上下游，并且能做到結(jié)合業(yè)務(wù)場景去挖掘。

從業(yè)務(wù)的角度、從產(chǎn)品的鏈路、從技術(shù)的調(diào)優(yōu)和隱患多個視角去切，讓自己的設(shè)計維度與視角不斷拉升，這樣你有把握或者有掌控力的范圍會越來越大，未來才會有更多的機會。

管理層面

團隊是一個宏觀與微觀并存的事物，宏觀上我們說組織、講戰(zhàn)略、定規(guī)劃、要排兵布陣，微觀上我們關(guān)注溝通、成長、情緒。大部分同學之所以在微觀上受挫，就是因為沒能把握到宏觀的節(jié)奏。

公司是一個盈利組織，技術(shù)中心是一個成本部門，技術(shù)中心之所以會有某一個組織，那么一定是：“公司期望這個組織解決某一類問題，并且解決到一定程度。”

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

擁抱變化

其實大多數(shù)時候不需要你去擁抱，變化會突如其來的抱住你，勒緊你的脖子讓你有那么一瞬間覺得呼吸困難。

互聯(lián)網(wǎng)公司之所以變化快，很大程度取決于它的業(yè)務(wù)屬性，相比傳統(tǒng)公司，互聯(lián)網(wǎng)公司能更快、更清晰地感受到與市場的契合程度，并且及時調(diào)整策略。

結(jié)合這幾年的經(jīng)歷，到最近兩年加入阿里巴巴，我的核心感悟有兩個：

一是對業(yè)務(wù)的發(fā)展和環(huán)境的變化要敏感。如果能在變化到來之前主動發(fā)起變化，那么化被動為主動是最好的。

即使不能，也要清晰地去感受和思考變化背后的動力在哪兒，去找到關(guān)鍵的發(fā)力點，讓自己可以適應(yīng)變化。

二是變化帶來的工作內(nèi)容的調(diào)整、匯報線的調(diào)整、團隊的變化等，不管好壞，在一個時間段內(nèi)都是相對的，而不是一個人工作生涯中絕對的。

在不可能事事如意的情況下，調(diào)整自己的心態(tài)，讓自己從情緒中跳出來，更多關(guān)注事情本身會是一個更好的選擇。

加人不能解決問題

即使嘴上再怎么說“不能”，但是動作會很誠實，依然會盡可能多地要 HC，希望把更多“核心”的系統(tǒng)建設(shè)在你的職責范圍內(nèi)。

其實，從管理的角度，你可以看一下你有沒有“有效加人”，一些技術(shù) Leader 不關(guān)注新人的 Landing ，相當于只盯數(shù)量不盯質(zhì)量，最后結(jié)果肯定是一塌糊涂的。

從絕對理論的角度，加人肯定是有幫助的，你的資源變多了，周轉(zhuǎn)的空間和操作的余地都豐富了。

但是從經(jīng)驗看，大部分情況下，加人沒有產(chǎn)生最終的價值變化(項目的結(jié)果、業(yè)務(wù)的成敗)。

因為系統(tǒng)的開發(fā)、項目的推進并不是單純的資源堆砌，1000 人日的系統(tǒng)哪是 1000 個人做一天就做出來的。

真實的世界里，我們往往不是敗在資源的使用量上，而是資源的使用方向和使用效率上。

有意識地向上管理

這個問題源于過去經(jīng)歷的兩個點：

一是我經(jīng)歷了無數(shù)次的組織關(guān)系調(diào)整，我發(fā)現(xiàn)不管是我自己還是我團隊的同學，大家相比于自己做什么以及帶不帶人、帶多少人外，更關(guān)注的是自己的匯報線。

自己匯報給誰，誰是我 Leader，我和他處不處得來，他能不能讓我有提高、有成長。

二是很多同學會對與 Leader 的相處關(guān)系有困惑。

基于這兩個點，我把向上管理作為一個單獨的話題加了進來，先說結(jié)論：要!要!要!必須要!一定要!

連馬老師都說員工離職的三大要素之一就是和 Leader 處不來，你怎么還能心安理得的忽略它。

如果大家對于向上管理還停留在服從甚至諂媚的態(tài)度來處理你們的關(guān)系，我只能說太稚嫩了。

我沒有系統(tǒng)地學過向上管理，也沒有體系化地看過這方面的書，所以我只說一下自己的理解。

個體在一個組織里想得到報酬和收益，基本的方法就是促進組織的成長與提高，并且同步提高自己，這樣就可以從中分得自己的那份收益。

這就要求你產(chǎn)出的結(jié)果是要對組織有正向溢出的，但是這個方向與標準并不是所有人都清楚或者能準確地把握到。

經(jīng)常有績效差的同學很沮喪甚至抱怨說自己經(jīng)常加班，甚至是部門走的最晚的，周末也要處理工作等。

先不討論背景，如果命中上面這一條的，我先給你個忠告：除了按件計費的工廠，其它任何地方體力上的付出與最終結(jié)果都沒有明顯的直接關(guān)系。

就像你上學的時候一定有那么幾個別人家的孩子，要么就是特別努力學習特別好，要么就是看上去每天和你一起玩，但是成績總是碾壓你。

從學校到社會，這個現(xiàn)象并沒有消失，別迷信加班和體力上的付出，大多數(shù)人只要能不去思考，在體力上愿意做出的付出，遠超你我的想象。

與 Leader 相處和溝通，本質(zhì)上是為了達成一致的目標和互相認可的結(jié)果。這是一個非常關(guān)鍵的初衷，我有時候開玩笑和團隊的同學聊，說你們要好好看看我的 Leader 到底想干嘛，這樣你們做出來，我好去匯報。

方向、節(jié)奏、結(jié)果的對焦對于工作的展開和拿成績是至關(guān)重要的，同時你要從他身上獲取更多的信息以便于自己的判斷決策和學習，不斷從他們身上吸取養(yǎng)分。

在一些環(huán)境中，體力上的付出是必須的，但是僅有體力上的付出最終只能感動你自己，你的團隊并不想每天陪你加班到 11 點或者發(fā)布到凌晨 2 點，更沒有興趣凌晨 1 點半還拉個電話會討論方案。

所以一定要做好“期望管理”，Leader 對你的期望、對項目的期望、你對他給予你空間和支持的期望，大家一定要對焦清楚，并且目標一致。

架構(gòu)層面

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

最關(guān)鍵的是定義問題

愛因斯坦說過：“提出問題比解決問題更重要!”定義問題是個腦力活，解決問題是個體力活。

大家往往習慣于看到一個問題就沖上去錘它，從概率上來講，很大可能會陷入一個解決問題的黑洞，就是你不停地在解決問題，但是最終你的情況沒有變好。

當你面臨一個困難或者一個情況時，首先比較重要的是定義問題，這到底是要解決什么、解決了有什么好處、怎么確定解決了。

其次是定義結(jié)構(gòu)，這個問題的關(guān)鍵點組成，你對應(yīng)的解法是怎樣的，這其中得失要怎么權(quán)衡輕重，并且最終解決的效果如何貫穿和透傳，由點及面。

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

問題的本質(zhì)沒那么高深

有時我們做一個項目，可能有一個產(chǎn)品需求，大家看完覺得不好做或者做不了，因為系統(tǒng)現(xiàn)在不支持，改造成本太高，并且還伴有很多不確定的技術(shù)風險。

相信很少有人在這種情況下會無腦的要求加人、加工期來解決這個問題。

大多數(shù)情況下我們會看有沒有捷徑或者其他方案，讓產(chǎn)品效果達成，哪怕技術(shù)實現(xiàn)臟一些、繞一些。

其實這時候橫向縱向多挖一下或者多問幾個問題，有可能就會有不一樣的答案。

這個需求在解決用戶什么問題，目前這個解決方案是不是業(yè)務(wù)(產(chǎn)品、技術(shù))上唯一的，這個解決方案會帶來哪些成本和新的問題，目前正在推進的其他項目和這個問題會不會有關(guān)聯(lián)，有沒有其他團隊也在解決類似的問題或者曾經(jīng)解決過。

達成目標

在工作中小到聊定一個 API 契約、中到上線一個需求、大到完成一次晉升，所有的事情都是有成功的方法的。

找出短板、設(shè)定計劃、抗住挫折、反復(fù)訓練、根據(jù)反饋調(diào)優(yōu)，就可以解決任何問題。

《債務(wù)危機》的作者——橋水基金 CEO 達里奧總結(jié)了一個五步成功法，很有意思：

 

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

 

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

時代在持續(xù)發(fā)展和變化，現(xiàn)在正是波瀾壯闊的年代，在這樣的環(huán)境下，不管當前如何積累，都有可能隨著發(fā)展的變化在短時間跌落谷底。

公司能發(fā)展，一定是在某一個時期內(nèi)非常契合環(huán)境的要求，但隨著時間的變化，如果它的變化不能跟上來，那么也只會被時代拋棄。

正所謂讓你成功的，最終也將讓你失敗，比如柯達、諾基亞不能幸免，個體也難逃這樣的規(guī)律。

這樣的情況下，持續(xù)的學習和改變自身的能力才是研發(fā)同學最大、也是最強的優(yōu)勢。

技術(shù)本身的日新月異要求你持續(xù)學習，同樣的習慣放射到各個領(lǐng)域上，才會慢慢的取長補短，優(yōu)化自身，所以如果說研發(fā)同學最需要什么，我認為持續(xù)的學習能力是最關(guān)鍵的。

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

作者：石佳寧

編輯：陶家龍

出處：轉(zhuǎn)載自微信公眾號阿里巴巴中間件(ID：Aliware_2018)