做技術(shù)越久越發(fā)現(xiàn)技術(shù)本身沒那么重要干了十幾年開發(fā)從最初的C、Java一路折騰到云計算和AI應(yīng)用這幾年最深的體會不是哪個框架又多牛了也不是又優(yōu)化了多少毫秒的響應(yīng)時間反而是一個聽起來有點“喪”的結(jié)論技術(shù)本身真的沒那么重要。別急著反駁我說這話不是勸大家別學(xué)技術(shù)恰恰相反。我是說當(dāng)我們把技術(shù)當(dāng)成解決問題的手段而不是目的本身時很多糾結(jié)就突然解開了。剛?cè)胄心菚何腋蠖鄶?shù)人一樣覺得技術(shù)就是一切。為了一個技術(shù)方案能跟同事爭得面紅耳赤為了用上最新版本的語言特性不惜把老項目重構(gòu)一遍看到別人用了冷門框架就覺得對方“高級”。那幾年確實成長得快但也累得慌主要是在一些不值得的地方死磕。后來參與的項目多了角色也從執(zhí)行者慢慢變成了設(shè)計者我才發(fā)現(xiàn)一個殘酷的事實在真實的業(yè)務(wù)場景里決定一個項目成敗的往往不是技術(shù)選型而是那些技術(shù)之外的東西。比如對需求的理解是否到位比如團(tuán)隊協(xié)作是否順暢比如在關(guān)鍵時刻敢不敢砍功能、敢不敢推遲上線。技術(shù)只是工具箱里的扳手和螺絲刀真正能把活兒干漂亮的是那個拿工具的人——他的判斷、他的溝通、他對業(yè)務(wù)的理解。這篇文章就想把這些年的想法好好捋一捋。如果你剛工作沒幾年可能覺得我在扯淡如果你也熬過了幾個大項目說不定能會心一笑。不管你現(xiàn)在處在哪個階段我希望你看完能有一個感覺技術(shù)要學(xué)但更重要的是想清楚“為什么學(xué)、學(xué)了干什么用”。1. 技術(shù)能力的真實邊界我們得先承認(rèn)一個事實技術(shù)能力是有邊界的。它能解決的問題遠(yuǎn)沒有我們想象的那么多。1.1 技術(shù)解決不了的“業(yè)務(wù)之痛”我剛帶團(tuán)隊那會兒接手了一個數(shù)據(jù)可視化的項目。業(yè)務(wù)方提需求時說得天花亂墜什么大屏、實時監(jiān)控、三維展示。我們團(tuán)隊技術(shù)底子不錯選型也新潮用了一堆開源組件加了各種炫酷動效。結(jié)果項目交付時業(yè)務(wù)方看了一眼說“這不是我想要的”。當(dāng)時我就懵了需求文檔上寫得清清楚楚怎么就不是你想要的了后來私下聊了好幾次才搞清楚真實原因。業(yè)務(wù)方要的不是酷炫的大屏而是想通過可視化發(fā)現(xiàn)數(shù)據(jù)里的異常但是原始數(shù)據(jù)本身質(zhì)量太差各種臟數(shù)據(jù)、重復(fù)數(shù)據(jù)圖做得再好看也是白搭。他們真正缺的是數(shù)據(jù)治理的規(guī)矩——誰錄入、誰校驗、誰負(fù)責(zé)修訂。這些是業(yè)務(wù)規(guī)范和管理制度技術(shù)團(tuán)隊能幫忙實現(xiàn)校驗?zāi)_本但不可能替他們制定考核標(biāo)準(zhǔn)。這個case讓我印象特別深。技術(shù)能幫你看清數(shù)據(jù)但數(shù)據(jù)是什么、業(yè)務(wù)怎么運轉(zhuǎn)、指標(biāo)怎么定義全是業(yè)務(wù)層面的問題。代碼寫得再好也沒法幫業(yè)務(wù)方“想清楚自己要什么”。1.2 技術(shù)選型的“沉沒成本陷阱”做技術(shù)的人很容易陷進(jìn)一個坑里對一個方案投入了大量時間和感情之后即使發(fā)現(xiàn)它不適合項目也不愿意換。這個在心理學(xué)上叫沉沒成本謬誤落到技術(shù)上就是災(zāi)難。曾經(jīng)有個后臺管理系統(tǒng)最開始定的方案是用微服務(wù)架構(gòu)前前后后忙活了兩個月服務(wù)拆了十幾個中間件堆了一籮筐。結(jié)果做出來之后發(fā)現(xiàn)這系統(tǒng)每天的訪問量也就幾百用單體架構(gòu)一個實例都綽綽有余。微服務(wù)帶來的分布式事務(wù)、服務(wù)治理、部署復(fù)雜度全是在給自己加戲。但那時候已經(jīng)拆了再改回去總覺得前兩個月的功夫白費了團(tuán)隊里也吵了很久。最后我拍板新版本直接重寫成單體兩周搞定運行得穩(wěn)穩(wěn)當(dāng)當(dāng)。這段經(jīng)歷讓我明白一個道理技術(shù)選型的第一標(biāo)準(zhǔn)從來不是“新”或“炫”而是匹配。殺雞用牛刀不算本事知道什么時候用牛刀、什么時候用水果刀才算。做技術(shù)久了你就會發(fā)現(xiàn)再牛的架構(gòu)也頂不住需求的一通亂改而合適的簡單方案往往能撐很久。1.3 決定技術(shù)上限的“非技術(shù)因素”而且你仔細(xì)觀察那些技術(shù)大牛會發(fā)現(xiàn)他們厲害的不僅僅是代碼寫得好。他們能準(zhǔn)確預(yù)判技術(shù)架構(gòu)未來的走向能在項目啟動時就把風(fēng)險梳理得清清楚楚能三兩句話就讓業(yè)務(wù)方點頭認(rèn)可方案。這些本事屬于技術(shù)但遠(yuǎn)超技術(shù)。有一回我跟一個特別資深的架構(gòu)師合作他連代碼都不怎么寫每天就是在白板上畫圖。但他畫的每一張圖都把業(yè)務(wù)流、數(shù)據(jù)流、異常處理梳理得明明白白。他花了兩周時間做技術(shù)方案我們團(tuán)隊照著方案寫代碼一遍過幾乎沒返工。那次給我的觸動很大所謂的技術(shù)能力強(qiáng)不是靠堆代碼體現(xiàn)的而是靠“不寫代碼”的思考深度。所以技術(shù)本身的邊界在哪里我的理解是它能解決“怎么做”的問題但解決不了“做什么”和“為什么做”的問題。后者恰恰是項目能不能成的關(guān)鍵。越是往高處走越需要花精力在技術(shù)之外。2. 從“技術(shù)視角”切換到“業(yè)務(wù)視角”說句扎心的話大多數(shù)技術(shù)人包括以前的我都挺高傲的總覺得自己懂代碼就高人一等看業(yè)務(wù)的同事就像看傻子。但實際上業(yè)務(wù)才是整個項目的起點和終點技術(shù)只是實現(xiàn)業(yè)務(wù)的手段。2.1 需求分析里的“潛臺詞”做技術(shù)的人最怕聽到的一句話是“需求很簡單就是做個某某功能?！蓖ǔＵf出這句話的人腦子里根本沒有細(xì)節(jié)。而技術(shù)人的職責(zé)不僅僅是實現(xiàn)功能更要幫對方把模糊的愿望變成清晰的方案。我舉個特別簡單的例子。業(yè)務(wù)方說“幫我做一個導(dǎo)出Excel的功能?！蹦阋侵苯哟饝?yīng)那就等著加班改需求吧。你得問清楚導(dǎo)出多少行數(shù)據(jù)數(shù)據(jù)量大不大是一次性導(dǎo)出還是按條件篩選導(dǎo)出的格式有沒有模板是導(dǎo)出當(dāng)前頁還是全部數(shù)據(jù)導(dǎo)出之后需不需要自動發(fā)送到郵箱這些追問看起來很煩但恰恰是避免后期返工的關(guān)鍵。很多技術(shù)人覺得業(yè)務(wù)方不懂技術(shù)懶得溝通悶頭就開寫結(jié)果做完發(fā)現(xiàn)完全不是對方想要的返工兩三次然后開始抱怨業(yè)務(wù)方需求變來變?nèi)ァＦ鋵嵏驹蚴悄阋婚_始就沒挖掘出完整需求。我自己踩過這個坑之后養(yǎng)成一個習(xí)慣接需求時先寫一份“我理解的業(yè)務(wù)場景”用一兩百字講清楚這個功能是給誰用的、解決什么問題、什么情況下觸發(fā)。發(fā)給業(yè)務(wù)方確認(rèn)對方一看哦對就是這樣?；蛘卟皇沁@樣是那樣。確認(rèn)之后再動手效率翻倍。2.2 技術(shù)與業(yè)務(wù)的雙向翻譯技術(shù)在業(yè)務(wù)方眼里有時候像黑魔法。你覺得很簡單的事情他們覺得難上天你覺得很復(fù)雜的事情他們反而覺得理所當(dāng)然。這時候技術(shù)人就要當(dāng)一個“翻譯官”。比如說業(yè)務(wù)方提了個“實時數(shù)據(jù)大屏”的需求他根本不知道實時背后意味著什么。你需要用他能聽懂的話告訴他實時可以分三種程度——秒級、分鐘級、小時級。每一種的技術(shù)成本不一樣價格也不同。秒級意味著需要搭建流處理管道數(shù)據(jù)要走消息隊列要有完整的監(jiān)控體系成本至少翻三倍。如果只是小時級只要定時跑批任務(wù)就行了成本低得多。這么一翻譯業(yè)務(wù)方立刻明白然后會做出自己的選擇。這個過程里技術(shù)不是難題溝通和理解才是。很多時候業(yè)務(wù)方不是非要最貴最炫的方案他只是不知道技術(shù)上的取舍關(guān)系而已。類似的反過來的翻譯更重要。業(yè)務(wù)方跟你說了一堆業(yè)務(wù)術(shù)語你得把他們翻譯成技術(shù)語言這個“審核通過后自動同步”聽起來簡單實際上要加一張任務(wù)表、兩個狀態(tài)機(jī)、三個回調(diào)接口。翻譯清楚了開發(fā)量就有數(shù)了排期也就不虛了。2.3 “業(yè)務(wù)思維”倒逼技術(shù)方案優(yōu)化有時候技術(shù)方案的優(yōu)化不是從性能入手的而是從業(yè)務(wù)規(guī)則入手的。我見過一個很有意思的案例某系統(tǒng)的計算邏輯非常復(fù)雜每條數(shù)據(jù)要跟歷史數(shù)據(jù)做比對響應(yīng)時間要幾秒鐘。技術(shù)人員天天優(yōu)化SQL、加索引效果一直不理想。后來資深的業(yè)務(wù)專家看了一眼規(guī)則說這個比對不需要用歷史全量數(shù)據(jù)只看上個月的數(shù)據(jù)就行了因為業(yè)務(wù)上只關(guān)心月度變化。就這么一句話SQL查詢量直接少了90%系統(tǒng)瞬間就流暢了。這種優(yōu)化寫代碼再厲害也想不到但懂業(yè)務(wù)就能想到。所以我一直覺得純粹的技術(shù)優(yōu)化是有天花板的但業(yè)務(wù)理解能讓技術(shù)方案的優(yōu)化空間無限變大。技術(shù)人如果只盯著代碼看永遠(yuǎn)只是把方案實現(xiàn)出來但如果你能理解業(yè)務(wù)背后的邏輯你就能反過來優(yōu)化方案本身。3. 協(xié)作比代碼更考驗功力我剛工作的時候以為寫代碼是一個人的事。后來才發(fā)現(xiàn)真正的工作里寫代碼的時間可能只占三成剩下的七成都在溝通——和產(chǎn)品經(jīng)理溝通需求和測試同學(xué)溝通邏輯和設(shè)計師溝通交互和運維溝通部署還有和項目經(jīng)理對齊進(jìn)度。3.1 跨團(tuán)隊協(xié)作的“信任賬戶”跨團(tuán)隊協(xié)作這件事特別像銀行賬戶。你每一次靠譜的交付都是在存款每一次延期、返工、出線上事故都是在取款。賬戶里沒錢的時候你說什么別人都不信做什么都被質(zhì)疑。賬戶里余額充足的時候偶爾出點小問題大家也都愿意給你機(jī)會。我曾經(jīng)接手過一個跟算法團(tuán)隊合作的項目對方給的接口文檔寫得稀爛聯(lián)調(diào)時各種報錯。換作以前我可能就當(dāng)場開噴了。但那次我沒急而是耐心地和對方一起排查問題發(fā)現(xiàn)是他們某個環(huán)境變量配置錯了。我不僅沒抱怨還順手幫他們補(bǔ)全了接口文檔。從那以后這個團(tuán)隊每次對接都特別配合有什么問題第一時間告訴我。這個事讓我體會到技術(shù)能力強(qiáng)可以幫你解決業(yè)務(wù)問題但把協(xié)作關(guān)系處好能幫你解決“人的問題”。而“人的問題”往往是項目里最棘手的問題。技術(shù)人如果只盯著代碼忽略了協(xié)作很容易陷入“明明我技術(shù)沒問題為什么項目還是搞砸了”的困惑。3.2 技術(shù)評審中的說服力技術(shù)評審是技術(shù)人展現(xiàn)專業(yè)度的重要場面但同時也非?？简灉贤芰ΑＮ野l(fā)現(xiàn)不少技術(shù)人包括曾經(jīng)的我評審的時候喜歡用專業(yè)術(shù)語碾壓別人什么最終一致性、CAP定理、分布式事務(wù)。聽著很有道理但別人根本沒法接話也聽不懂你要干嘛。后來我換了一種策略講方案之前先用一分鐘講清楚業(yè)務(wù)背景然后說清楚我打算怎么做再講為什么這么做最后需要大家配合什么。用大白話講講完再補(bǔ)一句“技術(shù)細(xì)節(jié)我們會后單獨聊”。這樣一來評審會的效率高了很多大家也會更重視你的方案。說到底技術(shù)評審的核心不是證明“我比你強(qiáng)”而是讓所有人理解并認(rèn)同這個項目為什么要這么走。說服力不是靠術(shù)語堆出來的是靠清晰的邏輯和坦誠的態(tài)度換來的。3.3 “對事不對人”的反饋藝術(shù)做技術(shù)的人普遍直來直去看到代碼寫得爛就直接說“這寫的什么玩意兒”看到方案有問題就當(dāng)面指出。這種性格在工作里好的一面是溝通效率高壞的一面是容易得罪人對推進(jìn)項目反而沒幫助。我自己也經(jīng)歷了一個轉(zhuǎn)變期。以前做代碼Review我習(xí)慣直接給結(jié)論“這個接口設(shè)計有問題重寫吧?！苯Y(jié)果對方就不高興了明明是技術(shù)討論變成了情緒對抗。后來我改成描述事實加建議“這里如果并發(fā)量上來可能會有性能瓶頸我們要不要換個思路比如做個異步處理”不說“你錯了”只說“這個場景下可能會有問題”效果天差地別。項目是大家一起做成的把團(tuán)隊關(guān)系搞僵了再牛的技術(shù)也施展不開。除非你是一個人寫一個項目不然“會做人”確實比“會寫代碼”更重要。4. 懂業(yè)務(wù)的程序員更有競爭力技術(shù)人都有一個困惑我技術(shù)不錯的為什么晉升那么慢為什么那些技術(shù)看起來不如我的人反而混得風(fēng)生水起其實答案往往就是人家懂業(yè)務(wù)。4.1 業(yè)務(wù)理解力決定了技術(shù)天花板同樣是寫代碼懂業(yè)務(wù)和不懂業(yè)務(wù)寫出來的東西完全不是一個量級。不懂業(yè)務(wù)的人按需求文檔一行一行地寫懂業(yè)務(wù)的人一眼就能看出需求的邏輯漏洞知道哪些是核心路徑、哪些是異常分支甚至能在產(chǎn)品設(shè)計階段就提出改進(jìn)建議。拿電商系統(tǒng)來說不懂業(yè)務(wù)的人只知道“創(chuàng)建訂單、支付、發(fā)貨”這三步。懂業(yè)務(wù)的人會知道下單之前有庫存鎖定支付之后有對賬核銷發(fā)貨之前有風(fēng)控攔截售出之后還有售后退款、財務(wù)結(jié)算、發(fā)票開具。每一個環(huán)節(jié)都有不同的邊界情況缺少業(yè)務(wù)理解就開發(fā)不出真正好用的系統(tǒng)。很多技術(shù)人以為自己只要把接口寫好、性能調(diào)優(yōu)就算厲害但在他寫接口之前連業(yè)務(wù)規(guī)則都沒搞清楚寫出來的東西大概率是要返工的。反過來說一個懂業(yè)務(wù)的程序員技術(shù)選型會更貼近實際架構(gòu)設(shè)計會更穩(wěn)定代碼也能更好地支撐業(yè)務(wù)變化。4.2 從“執(zhí)行者”到“設(shè)計方案的人”的轉(zhuǎn)變剛開始做技術(shù)的時候我們的工作模式是“給我需求我來實現(xiàn)”。這個階段技術(shù)能力確實最重要。但如果你想往上走想成為那個定方案的人就必須完成一次思維轉(zhuǎn)變從“怎么做”到“做什么”。定方案的人要面對的是模糊的、不完整的、經(jīng)常變化的需求。在信息不完整的情況下做出合理的判斷這種能力跟編程能力關(guān)系不大更依賴業(yè)務(wù)敏感度和邏輯推理能力。舉個例子某業(yè)務(wù)方想做一個會員積分系統(tǒng)他給你的需求只有一句話“讓用戶能攢積分、花積分”。你是直接開寫還是先問清楚“積分獲取規(guī)則是什么”“積分能抵扣多少錢”“積分過期怎么辦”如果你不問那你做出來的東西大概率離業(yè)務(wù)方心里的預(yù)期差了十萬八千里。4.3 用技術(shù)思維反哺業(yè)務(wù)決策懂業(yè)務(wù)的價值不只是能更好地實現(xiàn)需求。反過來技術(shù)思維也能幫業(yè)務(wù)方發(fā)現(xiàn)機(jī)會、規(guī)避風(fēng)險。我看到過一個很精彩的真實案例。某團(tuán)隊負(fù)責(zé)用戶增長業(yè)務(wù)方一直靠“下載APP送優(yōu)惠券”做推廣。技術(shù)團(tuán)隊分析數(shù)據(jù)后發(fā)現(xiàn)真正提升留存的是“綁定郵箱后送的積分”而不是“下載APP送的優(yōu)惠券”。于是技術(shù)團(tuán)隊建議把預(yù)算傾斜到郵箱場景結(jié)果轉(zhuǎn)化率提高了好幾倍。這就是用技術(shù)思維反哺業(yè)務(wù)決策。技術(shù)人天天和數(shù)據(jù)、邏輯打交道對系統(tǒng)的運轉(zhuǎn)規(guī)律最清楚。如果能在代碼之外多留心業(yè)務(wù)的數(shù)字和規(guī)則很容易發(fā)現(xiàn)一些業(yè)務(wù)方看不到的盲區(qū)你的價值也會成倍增長。5. 長期主義心態(tài)與技術(shù)“保鮮”文章開頭我說技術(shù)沒那么重要不是讓大家不學(xué)技術(shù)而是讓大家別把技術(shù)當(dāng)成一個“鐵飯碗”想去拿在手里不放。技術(shù)這個東西迭代太快你今天用的框架可能明年就被淘汰了。如果把職業(yè)安全感建立在“我會某門技術(shù)”上你會永遠(yuǎn)焦慮。5.1 技術(shù)不是收藏品是工具我見過不少技術(shù)人花大量時間“收藏”技術(shù)看到新的框架、新的庫先收藏然后學(xué)習(xí)、研究但工作中根本用不上。問起來他會說“萬一以后用到呢?！边@種心態(tài)能理解但效率真的太低了。更好的做法是以解決實際問題為目標(biāo)“順便”學(xué)習(xí)技術(shù)。比如你工作中遇到了并發(fā)問題那就去學(xué)并發(fā)處理的方案你遇到了大數(shù)據(jù)量存儲瓶頸那就去學(xué)分庫分表。技術(shù)是學(xué)來用的不是學(xué)來屯的。用到的技術(shù)才能真正內(nèi)化成你自己的。我之前帶過一個剛畢業(yè)的A同學(xué)基礎(chǔ)扎實學(xué)習(xí)能力很強(qiáng)花了幾個月自學(xué)了很冷門的技術(shù)棧。但到了實際項目里碰到業(yè)務(wù)場景復(fù)雜的需求還是抓瞎不知道該用什么方案不知道怎么權(quán)衡取舍。后來我讓他別學(xué)那些花架子了而是專心做項目里的實際功能遇到不懂的再去查、去學(xué)。半年之后他的實戰(zhàn)能力明顯進(jìn)步比泛泛地學(xué)一堆用不上的技術(shù)強(qiáng)多了。5.2 保持空杯心態(tài)但要警惕“技術(shù)追新癖”技術(shù)圈普遍有一股“追新”的風(fēng)氣新框架出來就說老框架是垃圾新語言出來就說老語言要完蛋。做技術(shù)久了你會發(fā)現(xiàn)很多東西都是換湯不換藥。業(yè)務(wù)層面的問題就是那些技術(shù)方案翻來覆去也就是那幾種套路。所以對于新東西我現(xiàn)在的態(tài)度是保持了解但不盲目追逐。看到一個新技術(shù)先問三個問題它解決什么問題它比老技術(shù)好在哪里它適合什么場景這三個問題想清楚了再去學(xué)也不遲。舉個例子容器化剛火的那兩年很多人不分場景地全上容器結(jié)果把簡單的項目搞得更復(fù)雜了。后來熱度退下來了大家才回歸理性小項目用傳統(tǒng)部署反而更省事。技術(shù)迭代不可怕可怕的是今天學(xué)這個、明天追那個卻從沒想過自己到底需要什么。5.3 真正的護(hù)城河學(xué)習(xí)能力與解決問題能力如果你問我做技術(shù)到最后到底什么是你的核心競爭力我的答案是學(xué)習(xí)能力以及用技術(shù)解決實際問題的能力。技術(shù)每天在變但底層的學(xué)習(xí)方法、問題拆解方法、系統(tǒng)設(shè)計思路是相通的。你只要掌握了這些“元能力”不管未來出現(xiàn)什么新技術(shù)你都能很快抓住它的關(guān)鍵并且用到實處。其實說白了技術(shù)本身確實不復(fù)雜復(fù)雜的是理解需求背后的邏輯、權(quán)衡方案的利弊、推動團(tuán)隊的協(xié)作、保障系統(tǒng)的穩(wěn)定。這些能力離開技術(shù)崗位之后同樣管用。它們才是你真的可以帶走的東西。所以我的心態(tài)也慢慢變了不只是學(xué)技術(shù)而是學(xué)“怎么用技術(shù)創(chuàng)造價值”。只要這個底層邏輯是通的技術(shù)上的一時領(lǐng)先或者落后都沒那么重要了。6. 常見困惑與心態(tài)調(diào)整聊了這么多最后把大家經(jīng)常遇到的幾個困惑拿出來說說。這些都是我自己經(jīng)歷過、也看周圍人反復(fù)踩過的坑。6.1 “我技術(shù)很好了為什么還是做不了核心項目”常見誤區(qū)以為技術(shù)好就能拿到核心項目。實際上核心項目之所以核心往往是因為業(yè)務(wù)價值高、邏輯復(fù)雜、需要多方協(xié)同。你技術(shù)再好如果只埋頭寫代碼不了解業(yè)務(wù)全貌也很難勝任核心項目里的關(guān)鍵角色。我的建議主動找項目負(fù)責(zé)人聊業(yè)務(wù)提出自己的見解。你聊得多了別人自然會把你當(dāng)成懂業(yè)務(wù)的人遇到核心需求時第一個想到的就是你。6.2 “團(tuán)隊里有人技術(shù)比我差憑什么他當(dāng)leader”這個問題挺現(xiàn)實。但要明白leader需要的核心能力是統(tǒng)籌、協(xié)調(diào)、決策。這些能力跟寫代碼水平?jīng)]有必然關(guān)系。那個人技術(shù)不如你但他能讓項目順利推進(jìn)讓領(lǐng)導(dǎo)和客戶滿意這本身就是一種能力。你如果也想走管理路線就別再糾結(jié)“技術(shù)高低”了。試著去承擔(dān)更多協(xié)調(diào)類的工作安排迭代、對接需求、組織評審。慢慢你會發(fā)現(xiàn)這些工作并不比寫代碼輕松。6.3 “遇到業(yè)務(wù)方改需求就想發(fā)火怎么破”改需求是常態(tài)不改成藝術(shù)。發(fā)火沒用還會讓你的人際關(guān)系變差。我一般用兩個方法調(diào)節(jié)一是告訴自己改需求說明業(yè)務(wù)還在進(jìn)展比需求凍結(jié)、業(yè)務(wù)要沒了強(qiáng)二是把“改需求”當(dāng)成免費的容災(zāi)演練鍛煉自己的設(shè)計能力看你的系統(tǒng)能不能快速適應(yīng)變化。長此以往你的系統(tǒng)設(shè)計會越來越柔性改起來也越來越快。到那時候改需求不但不讓你煩躁反而成了你展示實力的機(jī)會。6.4 “我怎么才能更快地提升自己”最快的方式不是看更多的書、學(xué)更多的課而是去做難而正確的事。主動接手別人不愿意做的項目主動去解決線上疑難故障主動承擔(dān)跨團(tuán)隊協(xié)調(diào)工作。做的事情難度上去了能力自然就上去了。技術(shù)這東西練多了就熟熟了就精精了就通。但通的那一下往往不是靠代碼堆出來的而是靠一次一次把事情做成、把問題解決掉積累出來的。做技術(shù)這么多年我最大的體會是技術(shù)永遠(yuǎn)在變但你解決問題的能力、對業(yè)務(wù)的理解、與人協(xié)作的方式這些才是真正值錢的東西。剛?cè)胄袝r我花了很多時間鉆研技術(shù)的犄角旮旯覺得這才叫專業(yè)?；剡^頭看那些啃過的細(xì)節(jié)大多沒什么用真正幫我把項目做成、把團(tuán)隊帶順的反而是那些“技術(shù)之外”的東西。我不是說技術(shù)不重要——沒有技術(shù)我們連入場的資格都沒有。而是說技術(shù)就像一個基本功到這個程度就夠了但真正拉開差距的是基本功之上的判斷力、溝通力、業(yè)務(wù)理解力還有在復(fù)雜環(huán)境里把事做成的那種韌勁兒。想明白這件事之后我反而能更輕松地學(xué)技術(shù)了不焦慮、不攀比遇到問題就研究研究透了就放下。這樣的心態(tài)讓我走得更穩(wěn)也走得更遠(yuǎn)。