1. 程式人生 > >職場 | 工作五年之後,對技術和業務的思考

職場 | 工作五年之後,對技術和業務的思考

> 苦海無邊,回頭無岸。

01

晃晃悠悠的,在網際網路行業工作了五年,默然回首,你看哪裡像燈火闌珊處? 初入職場,大部分程式設計師會覺得苦學技術,以後會順風順水升職加薪,這樣的想法沒有錯,但是不算全面,五年後你會不會繼續做技術寫程式碼這是核心問題。 初入職場,會覺得努力加班可以不斷提升能力,可以學到技術的公司就算薪水低點也可以接受,但是五年之後會認為加班都是在不斷擠壓自己的上升空間,薪水低是人生的天花板。 這裡想說的關鍵問題就是:初入職場的認知和想法大部分不會再適用於五年後的認知。 工作五年之後面臨的最大壓力就是選擇:職場天花板,技術能力天花板,薪水天花板,三十歲天花板。 如何面對這些問題,是大部分程式設計師都在思考和糾結的。做選擇的唯一參考點就是:利益最大化,這裡可以理解為職場更好的升職加薪,順風順水。 五年,變化最大不是工作經驗,能力積累,而是心態,清楚的知道現實和理想之間是存在巨大的差距。

02

回首自己的職場五年,最認可的一句話就是:學會適應變化,並積累能力。 變化的就是,五年的時間技術框架更新迭代,開發工具的變遷,公司環境隊友的更換,甚至是不同城市的流浪,想著能把肉體和靈魂安放在一處,有句很經典的話就是:唯一不變的就是變化本身。 要積累的是:解決問題的能力,思考方式,拓寬認知。 這種很難直白的描述,屬於個人認知的範疇,不同的人有不一樣的看法,所以只能站在大眾化的角度去思考。 首先聊聊技術,大部分小白級別的,都希望自己的技術能力不斷提高,爭取做到架構師級別,但是站在當前的網際網路環境中,這種想法實現難度還是偏高,這裡既不是打擊也不是為了抬槓。 可以觀察一下現狀,技術團隊大的20-30人,小的10-15人,能有一個架構師去專門管理底層框架都是少有現象。 這個問題的原因很多,首先架構師的成本過高,環境架構也不是需要經常升級,說的難聽點可能框架比專案生命週期更高。 所以大部分公司的大部分業務,基於現有大部分成熟的開源框架都可以解決,這也就導致架構師這個角色通常由專案主管代替或者級別較高的開發直接負責,這就是現實情況。 這就導致技術框架的選擇思路就是:只選對的。即這方面的人才多,開源解決方案多,以此降低技術方面對公司業務發展的影響。 那為什麼還要不斷學習和積累技術能力?如果沒有這個能力,程式設計師崗位可能根本走不了五年之久,需要用技術深度積累不斷解決工作中的各種問題,用技術的廣度提升自己實現業務需求的認知邊界,這是安放肉體的根本保障。 這就是導致很多五年以後的程式設計師壓力陡然升高的原因,走向管理崗的另一個壁壘就是業務思維和認知。

03

程式設計師該不該用心研究業務,這個問題真的沒有糾結的必要,只要不是純技術型的公司,都需要面對業務。 不管技術、運營、產品、管理層,都是在面向業務工作。 從自己職場軌跡來看,五年變化最大就是解決業務問題的能力,職場之初面對很多業務場景都不知道如何下手,到幾年之後設計業務的解決方案。 這是大部分程式設計師在職場前五年跳槽就能漲薪的根本原因,面對業務場景,基於積累的經驗和現有的開源工具,能快速給出合理的解決思路和實現過程。 工作五年可能對技術底層的清晰程度都沒有初入職場的小白清楚,但是寫的程式卻可以避開很多坑坑窪窪,對於業務的審視也是很細節全面。 解決業務能力的積累,對於技術視野的寬度需求更甚,比如職場初期對於海量資料的處理束手無策,但是在工作幾年之後見識資料行業的技術棧,真的就是技術選型的視野問題。 什麼是衡量技術能力的標準?站在一個共識的角度上看:系統的架構與程式碼設計能適應業務的不斷變化和各種需求。 相對比與技術,業務的變化更加快速頻繁,高階工程師或者架構師之所以薪資高,這些角色一方面能適應業務的迭代,並且在工作中具有一定前瞻性,會考慮業務變化的情況下程式碼複用邏輯,這樣的能力是需要一定的技術視野和業務思維的沉澱。 所以職場中:業務能說的井井有條,程式碼能寫的明明白白,得到機會的可能性更大。

04

從理性的角度看技術和業務兩個方面,能讓大部分人職場走的平穩順利,但是不同的階段對兩者的平衡和選擇是不一樣的。 在思考如何選擇的時候,可以參考二八原則的邏輯,即在任何一組東西中,最重要的只佔其中一小部分,約20%,其餘80%儘管是多數,卻是次要的,因此又稱二八定律。 個人真的非常喜歡這個原則,大部分人都不是天才,所以很難三心二意同時做好幾件事情,在同一時間段內應該集中精力做好一件事件。 但是單純的二八原則模式可能不適應大部分職場初期的人,因為初期要學習很多內容,如何在職場生存:專業能力,職場關係,為人處世,產品設計等等。 當然這些東西不是都要用心刻意學習,但是合理安排二二六原則或其他組合是更明智的,首先是專業能力要重點練習,其次可以根據自己的興趣合理選擇一到兩個方面去慢慢了解,例如產品,運營,運維,資料等,畢竟三五年以後會不會繼續寫程式碼很難說,多給自己留個機會總是有備無患。 在職場初期,基本都是從技術角度去思考問題,如何快速提升自己的編碼能力,在公司能穩定是首要目標,因此大部分時間都是在做基礎編碼和學習規範,這時可能90%的心思都是放在基礎編碼上,另外10%會學習環境架構。 最多一到兩年,就會開始獨立負責模組需求開發,需要自己設計整個程式碼思路,這裡業務就會進入視野,要懂得業務上下游關聯關係,學會思考如何設計程式碼結構,才能在需求變動的情況下程式碼改動較少,這個時候可能就會放20%的心思在業務方面,30%學習架構方式。 三到五年這個時間段,是解決問題能力提升最快的時候,因為這個階段的程式設計師基本都是在開發核心業務鏈路,例如交易、支付、結算、智慧商業等模組,需要對業務整體有較清晰的把握能力,不然就是給自己挖坑,這個階段要對業務流付出大量心血思考。 越是核心的業務線,越是容易爆發各種問題,如果在日常工作中不花心思處理各種細節問題,半夜異常自動的訊息和郵件總是容易讓人憔悴。 所以努力學習技術是提升自己,培養自己的業務認知也同樣重要,個人認為這二者的分量平分秋色,只是需要在合適的階段做出合理的權重劃分。

05

基於技術能力和業務思維,學會在職場做選擇和生存,這些是職場前五年一路走來的最大體會。 不管是技術還是業務,這兩個概念依舊是個很大的命題,不容易把握,所以學會理清這兩個方面能力中的公共模組是關鍵。 不管技術還是業務,都不可能從一家公司完全複製到另一家公司,但是可以把一家公司的技術框架,業務解決方案學會,並且帶到另一家公司,例如技術領域內的架構、設計、流程、資料管理,業務領域內的思考方式、產品邏輯、分析等,這些是核心能力並且是大部分公司人才招聘的要求,所以這些才是工作中需要重點積累的。 人的精力是有限的,而且面對三十這個天花板,各種事件也會接連而至,在職場中學會合理安排時間並不斷提升核心能力,這樣才能保證自己的競爭力。 職場就像苦海無邊,回首望去可能也沒有岸邊停泊,但是要具有換船的能力或者有個小木筏也就大差不差了。

End

![](https://img2020.cnblogs.com/blog/1691717/202103/1691717-20210325220241166-9726298