“
本文基於作者在餓了麽 4 年和阿里巴巴 2 年研發經歷，從技術、業務、管理和架構四個層面總結的一些經驗。
圖片來自 Pexels
我是在 2014 年入職餓了麽，從前端和 PHP 一直做到後端架構和團隊，從 2014 年到 2017 年陸續負責過公司客服、銷售、代理商、支付、清結算、訂單這些業務的產研與團隊。
2018 年從業務研發團隊抽身，6 個人組起一個小組投身機器學習，試圖結合實際的業務場景通過技術改造業務。
2019 年回歸到平台（中台）研發，負責交易、金融、行銷三個中台的研發和團隊工作。
基於我在餓了麽 4 年和阿里巴巴 2 年研發經歷，下面我將以下四層面分享一些我的思考：
技術
業務
管理
架構
技術層面
對開發同學而言，技術是立身之本，雖然往往面試造火箭入職擰螺絲，但不可否認的是，技術就是你從業的的基石。
不管是基本的動手能力還是問題分析能力，包括你的思維邏輯乃至對事物認知的能力，技術思維都會時刻影響你。
最明顯的影響就是當你面對無數個問題的釘子時，技術是不是你最順手的那把錘子。
技術上我比較關注的幾個層面：
基本功（語言、編碼這個層面，主要是動手能力）
大型分布式系統的實戰經驗（RPC、SOA、MySQL、Redis、MQ）
項目（ DB 設計、API 契約、DDD 抽象、鏈路設計、項目風險把控）
穩定性（可用&資損）
穩定性
穩定性是一個先有意識再有能力的事兒。記得在 2015 年年初，張雪峰加入餓了麽擔任 CTO 之後，從他嘴裡最常聽到的一句話就是“研發要對生產環境有敬畏”。
2014 年下半年，各方人馬開始殺入外賣市場，餓了麽啟動百城計劃進行業務擴張，短時間內從 10+ 城市覆蓋到 100+ 城市，日訂單量也很快從 10 萬上漲到 100 萬。
業務井噴的同時，技術還沒有做好足夠的準備。我印象中，2014 年下半年幾乎每天中午交易量都有新高，但同時也伴隨著系統宕機、限流擴容、緊急調優、客服爆線、技術加班熬夜的問題。
我曾在新鄉的客服中心看到有的客服同學突然崩潰，耳機直接摔下來離開工位，因為每天會接收到大量用戶的來電責問。
就在那一刻，你才會清晰且直觀的感受到：你在編輯器的每一行代碼，你在伺服器的每一次發布，會對現實世界很多活生生的人有直接的影響，你會突然意識到你的工作比你之前以為的要重要且有意義。
所謂研發要對生產環境有敬畏，就是你知道你的作品會對別人產生不好的影響，你會為不好的結果感到慚愧與內疚，這就產生了敬畏。
應急處理有一個基本原則：“以業務影響最小為主，優先恢復為核心目的，不要糾結手段和根因。”
別把你的懊悔、決心、對穩定性的思考、各種奇妙的 idea 以及執行力體現在事故複盤會上，系統的安全生產和火災一樣，事前才有意義。
鏈路設計
大部分產研缺少全鏈路的視角，往往看到的是自己負責的點，但是對於一條線乃至整個面是看不到的，也沒有機會去思考這些，而對於一些大項目和長鏈路系統而言，這是致命的。
我的建議是，對你所負責的系統，它關鍵的上下遊、核心業務的鏈路一定要熟悉，包括數據、接口（調用、功能、邏輯）、各種異常的處理和特殊的設計。
能幫你達成這一目的的最簡單的辦法就是畫圖、畫圖、畫圖！重要的結論說三遍，一定要自己能把系統的大圖畫出來，然後做到可以根據大圖隨意放大和縮小。
放大到將鏈路畫到業務場景裡，突出業務邏輯和上下遊互動，縮小到某一次調用的處理邏輯大致是怎樣，數據是怎麽變化。
經常畫圖，不用糾結形式和標準，重要的是形成自己理解系統的一個框架，一個自己的思維方式，需要的時候可以隨時拿出來用。
日常不管是聊需求還是做系統設計，習慣性的把圖畫出來，就達成了一半。剩下的一半就要看圖去想、去找問題。
技術債務
永遠不要騙自己說，現在為了這個需求先挖一個坑，過一段時間再來填（重構or重做）。
技術債務和金融債務一樣，它必然存在，並且會像無賴一樣一直賴著，隔三差五會爆發一下。
隨著時間的推移和業務的發展，你會發現架構越來越混亂，不同系統的領域邊界越來越模糊，系統和需求與組織關係的映射越來越複雜，服務內編碼風控越來越不一致，重複的輪子一個接一個隱蔽的出現。
“太忙了沒時間梳理哪些問題”、“改那些問題需要上下遊一起改，費時費力，推不動”、“現在還沒出問題，而且正在整理了，別催”。這是我們經常會聽到的聲音。
其實，技術同學多少都有點代碼潔癖，有很多問題不處理不是主觀的原因，而是客觀上因為精力、時間、ROI 等因素，往往要等問題真的爆發後，大家才能狠下心去處理那些問題 。
我以前處理技術債務的思路，是要有一個檢查清單，我會定期的複盤所有的系統，並且結合自己團隊和其他團隊的事故去全量掃雷。
系統本身是一個平衡的產物，是時間、功能、風險、未來可能性等幾個方向平衡的結果。
所以技術債務對於研發同學的考驗，不在於你怎麽在日常工作中保證系統技術債為 0，而是你要評估清楚在有限的資源和時間下，哪些問題是刻不容緩的，哪些問題是可以往後放的。
很難想象一個沒有技術追求的團隊能開發出一個健壯的、可維護性好、可擴展性好的系統。
相反，這種業務代碼的堆砌，從短期看也許是“較快”實現了業務需求，但是從長遠來看，這種爛系統的增加會極大地阻礙業務的發展，形成一個個的黑洞應用，而工程師被裹挾在業務需求和爛系統之間，疲於應對，心力交瘁。
這種將就將導致系統腐化墮落，技術債越壘越高，醜陋的代碼瘋狂滋長，像腫瘤一樣消耗你所有的能量，最後還要你的命。
警惕大項目
並不是所有人都有能力操盤大項目，也不是所有人都能夠平衡好交付壓力、上線質量、產品邏輯以及時間窗口。
這是一個非常有挑戰的工作，需要純粹的技術能力之外的很多軟性能力來輔助，比如組織的溝通協作能力、向上要權要責的能力、平衡產品業務期望的的能力、突發情況應急轉變的能力等。
越大的項目對於 Owner 的要求也越高，真能把大項目做好不怎麽留大坑的少之又少。
大項目從啟動到立項所用的時間很多時候是遠超項目實際的開發周期的，項目的順利推進需要“妥協”，但項目的成功需要堅持。
很多項目之所以失敗，是在做的過程中方方面面不斷妥協，最後做出來的東西已經遠離了最開始想要的樣子。
業務層面
除了技術之外，研發同學對業務層面也需要提升認知與重視。
對於研發而言，業務就像是外語，你不理解業務就好比人在異國，與周圍的環境格格不入，並且容易吃虧！
相比產品、業務、運營等其他工種，技術更喜歡和技術打交道，業務在大多數同學眼中是混沌且缺少秩序的，沒有技術那樣清晰的實現路徑和穩定共識的知識結構。
並且技術相對容易證偽，而業務往往就是不停的嘗試，研發都討厭“不確定性”。
但是在一個龐大的組織裡想把技術做好，就必然要與業務打交道，畢竟業務才是一家公司存在的核心價值。
基於業務規劃做技術規劃
很多同學習慣於把計劃等同於規劃。阿里是一家尊重技術的商業公司，所有的團隊都在談業務、規劃裡是業務規劃、周報裡是業務項目、匯報裡是業務成果、晉升的時候也要突出你的“戰功”。
相比技術本身，大家更關注技術改變了什麽，在業務部分聊技術團隊如何做規劃的原因就在於此，這是公司運營的的起點（目的），延伸出來才有具體的技術規劃和組織設計作為解決方案。
深刻理解業務並設計戰略，拆解戰役與項目，通過組織和各種機制確保項目的執行與落地，最終拿到業務結果，這是一個大公司的標準戰略執行方式。
研發同學做技術規劃以及團隊規劃的時候，一定要考慮到你所在環境，公司今年要主打什麽，所在大部門的目標是什麽，對口的產品和業務現狀如何，純粹的技術迭代在業務上的好處在哪兒。
另外，團隊目前有哪些不可抗力，或者影響規劃推進的阻力。
很多同學做規劃的時候會習慣性按照這個思路進行：
總結現狀（痛點）
對應的解決方案和策略
展望未來
有時候第二和第三的順序會反過來。很多時候大家發現最終的部門規劃和自己做的規劃沒什麽關聯，不知道怎麽往哪個方向用力，或者乾脆繼續按照自己的計劃先走著。
對大部分同學，我建議規劃要實在。做技術規劃前，找你周邊的研發團隊聊一下，找你對口的產品、運營聊一下，知道他們的目標是什麽，知道公司幾個重點是什麽。
然後再結合你們目前的痛點，在現在和未來之前找平衡、找現在和未來都有收益的那部分。
規劃中需要包含一些硬性的內容，比如這個目標要解決什麽問題，怎麽確定它解決了，解決得好不好，好的結果誰認可等。規劃一定要有重點，沒有重點那不叫規劃，那是日程計劃。
很多同學對做規劃不投入，也有自己的“想法”，比如公司業務或者戰略變化太快、組織調整太頻繁，下半年在哪個團隊工作甚至做什麽都不一定，所以規劃做得並不認真。
不否認變化頻繁的存在，以及這種組織架構變化對規劃的影響，但是如果你一直這樣思考，你永遠無法從變化中獲得價值，因為你一直在置身事外。
研發要比產品還懂業務
雷軍說過：“永遠不要試圖用戰術上的勤奮，去掩蓋你戰略上的懶惰。”對於研發同學，你要比業務同學更懂業務，才能找到技術與業務平衡的空間。
對大部分同學而言，常常是隻熟悉自己負責的系統，但是對於想要更大空間和更多成長的同學，我可以給出明確的結論：隻熟悉自己負責的系統是不夠的。
首先，不同的人對熟悉的定義不一樣。對於你負責、你貢獻代碼、你進行設計並且完成需求交付的系統，單是熟悉遠不夠。
你不僅要知道它的前世今生，思考它的一路成長，糾結它的未來發展，同時還要清楚它的風險與隱患，它的生與死。
基於你最清楚的核心系統，由它開始做業務場景上的外延，以此了解你的上下遊，並且能做到結合業務場景去挖掘。
從業務的角度、從產品的鏈路、從技術的調優和隱患多個視角去切，讓自己的設計維度與視角不斷拉升，這樣你有把握或者有掌控力的範圍會越來越大，未來才會有更多的機會。
管理層面
團隊是一個宏觀與微觀並存的事物，宏觀上我們說組織、講戰略、定規劃、要排兵布陣，微觀上我們關注溝通、成長、情緒。大部分同學之所以在微觀上受挫，就是因為沒能把握到宏觀的節奏。
公司是一個盈利組織，技術中心是一個成本部門，技術中心之所以會有某一個組織，那麽一定是：“公司期望這個組織解決某一類問題，並且解決到一定程度。”
所以在這裡你要理解一個關鍵詞，“結果和 KPI”並不取決於你怎麽定義它，而是給你下放目標的組織與管理者對你的期望是怎樣的，你們的 GAP 往往未必是結果的差別，而是期望的落差。
擁抱變化
其實大多數時候不需要你去擁抱，變化會突如其來的抱住你，勒緊你的脖子讓你有那麽一瞬間覺得呼吸困難。
互聯網公司之所以變化快，很大程度取決於它的業務屬性，相比傳統公司，互聯網公司能更快、更清晰地感受到與市場的契合程度，並且及時調整策略。
結合這幾年的經歷，到最近兩年加入阿里巴巴，我的核心感悟有兩個：
一是對業務的發展和環境的變化要敏感。如果能在變化到來之前主動發起變化，那麽化被動為主動是最好的。
即使不能，也要清晰地去感受和思考變化背後的動力在哪兒，去找到關鍵的發力點，讓自己可以適應變化。
二是變化帶來的工作內容的調整、匯報線的調整、團隊的變化等，不管好壞，在一個時間段內都是相對的，而不是一個人工作生涯中絕對的。
在不可能事事如意的情況下，調整自己的心態，讓自己從情緒中跳出來，更多關注事情本身會是一個更好的選擇。
加人不能解決問題
即使嘴上再怎麽說“不能”，但是動作會很誠實，依然會盡可能多地要 HC，希望把更多“核心”的系統建設在你的職責範圍內。
其實，從管理的角度，你可以看一下你有沒有“有效加人”，一些技術 Leader 不關注新人的 Landing ，相當於隻盯數量不盯質量，最後結果肯定是一塌糊塗的。
從絕對理論的角度，加人肯定是有幫助的，你的資源變多了，周轉的空間和操作的余地都豐富了。
但是從經驗看，大部分情況下，加人沒有產生最終的價值變化（項目的結果、業務的成敗）。
因為系統的開發、項目的推進並不是單純的資源堆砌，1000 人日的系統哪是 1000 個人做一天就做出來的。
真實的世界裡，我們往往不是敗在資源的使用量上，而是資源的使用方向和使用效率上。
有意識地向上管理
這個問題源於過去經歷的兩個點：
一是我經歷了無數次的組織關係調整，我發現不管是我自己還是我團隊的同學，大家相比於自己做什麽以及帶不帶人、帶多少人外，更關注的是自己的匯報線。
自己匯報給誰，誰是我 Leader，我和他處不處得來，他能不能讓我有提高、有成長。
二是很多同學會對與 Leader 的相處關係有困惑。
基於這兩個點，我把向上管理作為一個單獨的話題加了進來，先說結論：要！要！要！必須要！一定要！
連馬老師都說員工離職的三大要素之一就是和 Leader 處不來，你怎麽還能心安理得的忽略它。
如果大家對於向上管理還停留在服從甚至諂媚的態度來處理你們的關係，我只能說太稚嫩了。
我沒有系統地學過向上管理，也沒有體系化地看過這方面的書，所以我隻說一下自己的理解。
個體在一個組織裡想得到報酬和收益，基本的方法就是促進組織的成長與提高，並且同步提高自己，這樣就可以從中分得自己的那份收益。
這就要求你產出的結果是要對組織有正向溢出的，但是這個方向與標準並不是所有人都清楚或者能準確地把握到。
經常有績效差的同學很沮喪甚至抱怨說自己經常加班，甚至是部門走的最晚的，周末也要處理工作等。
先不討論背景，如果命中上面這一條的，我先給你個忠告：除了按件計費的工廠，其它任何地方體力上的付出與最終結果都沒有明顯的直接關係。
就像你上學的時候一定有那麽幾個別人家的孩子，要麽就是特別努力學習特別好，要麽就是看上去每天和你一起玩，但是成績總是碾壓你。
從學校到社會，這個現象並沒有消失，別迷信加班和體力上的付出，大多數人只要能不去思考，在體力上願意做出的付出，遠超你我的想象。
與 Leader 相處和溝通，本質上是為了達成一致的目標和互相認可的結果。這是一個非常關鍵的初衷，我有時候開玩笑和團隊的同學聊，說你們要好好看看我的 Leader 到底想幹嘛，這樣你們做出來，我好去匯報。
方向、節奏、結果的對焦對於工作的展開和拿成績是至關重要的，同時你要從他身上獲取更多的信息以便於自己的判斷決策和學習，不斷從他們身上吸取養分。
在一些環境中，體力上的付出是必須的，但是僅有體力上的付出最終只能感動你自己，你的團隊並不想每天陪你加班到 11 點或者發布到凌晨 2 點，更沒有興趣凌晨 1 點半還拉個電話會討論方案。
所以一定要做好“期望管理”，Leader 對你的期望、對項目的期望、你對他給予你空間和支持的期望，大家一定要對焦清楚，並且目標一致。
架構層面
還有一點我覺得也很重要，就是在架構層面，包括業務架構、技術選型和細節實現上，要有清醒的認知。
最關鍵的是定義問題
愛因斯坦說過：“提出問題比解決問題更重要！”定義問題是個腦力活，解決問題是個體力活。
大家往往習慣於看到一個問題就衝上去錘它，從概率上來講，很大可能會陷入一個解決問題的黑洞，就是你不停地在解決問題，但是最終你的情況沒有變好。
當你面臨一個困難或者一個情況時，首先比較重要的是定義問題，這到底是要解決什麽、解決了有什麽好處、怎麽確定解決了。
其次是定義結構，這個問題的關鍵點組成，你對應的解法是怎樣的，這其中得失要怎麽權衡輕重，並且最終解決的效果如何貫穿和透傳，由點及面。
一個團隊可以不停歇的埋頭乾，但是未必會乾出成績。大部分習慣羅列面對的問題，但是對這些問題並沒有做一個全局的分析和梳理，其實最難的就在“找問題”上。
問題的本質沒那麽高深
有時我們做一個項目，可能有一個產品需求，大家看完覺得不好做或者做不了，因為系統現在不支持，改造成本太高，並且還伴有很多不確定的技術風險。
相信很少有人在這種情況下會無腦的要求加人、加工期來解決這個問題。
大多數情況下我們會看有沒有捷徑或者其他方案，讓產品效果達成，哪怕技術實現髒一些、繞一些。
其實這時候橫向縱向多挖一下或者多問幾個問題，有可能就會有不一樣的答案。
這個需求在解決用戶什麽問題，目前這個解決方案是不是業務（產品、技術）上唯一的，這個解決方案會帶來哪些成本和新的問題，目前正在推進的其他項目和這個問題會不會有關聯，有沒有其他團隊也在解決類似的問題或者曾經解決過。
達成目標
在工作中小到聊定一個 API 契約、中到上線一個需求、大到完成一次晉升，所有的事情都是有成功的方法的。
找出短板、設定計劃、抗住挫折、反覆訓練、根據反饋調優，就可以解決任何問題。
《債務危機》的作者——橋水基金 CEO 達裡奧總結了一個五步成功法，很有意思：
著名的大數學家波利亞有一本名著《怎樣解題》，其中給了一個四步解題法，可能站在研發的角度看會更有感覺：
持續學習才是根本
時代在持續發展和變化，現在正是波瀾壯闊的年代，在這樣的環境下，不管當前如何積累，都有可能隨著發展的變化在短時間跌落谷底。
公司能發展，一定是在某一個時期內非常契合環境的要求，但隨著時間的變化，如果它的變化不能跟上來，那麽也只會被時代拋棄。
正所謂讓你成功的，最終也將讓你失敗，比如柯達、諾基亞不能幸免，個體也難逃這樣的規律。
這樣的情況下，持續的學習和改變自身的能力才是研發同學最大、也是最強的優勢。
技術本身的日新月異要求你持續學習，同樣的習慣放射到各個領域上，才會慢慢的取長補短，優化自身，所以如果說研發同學最需要什麽，我認為持續的學習能力是最關鍵的。
正如餓了麽創始人汪淵在之前接受採訪時有一句話，讓我很難忘：最重要的是選擇，最困難的是堅持。
作者：石佳寧
編輯：陶家龍
香港九龍灣馬來街興發大廈15樓D室