從兩位前阿里 P10 身上,我學到了這些

語言: CN / TW / HK

theme: smartblue

大家好,我是 shixin

最近看完了專欄《超級訪談:對話畢玄》,這個專欄和年初看的《超級訪談:對話湯崢嶸》類似,都是對阿里 P10(程式設計師金字塔頂端大佬)的訪談,介紹了他們的成長經歷和人生感悟,讓我受益頗多。這篇文章裡我將對這兩個專欄的內容做一個對比總結。

本文主要包括這些內容:

  1. 阿里 P10 大概是什麼概念
  1. 兩位 P10 大佬的成長經歷
  1. 兩位 P10 大佬關於常見話題的見解

  2. 成長心得

  • 職業發展

阿里 P10 是什麼概念

可能很多人對阿里 P10 是什麼概念還不清楚,這一節我們來簡單瞭解下。

P 序列是阿里內部評價研發等職能人員的級別體系。

一般來說剛畢業是 P4(本科) 或者 P5(研究生);工作三年左右達到要求者可以升至 P6 高階工程師;工作五年左右、技術達到一定深度可以升至 P7 技術專家,這個階段確定性還是很強的,一般只要投入一定的努力就可以實現。

再往上走就不單單是個人努力這麼簡單,天時(大環境和業務所屬賽道前景)、地利(業務發展情況)、人和(個人能力和領導)缺一不可,運氣不好可能一輩子都沒機會再往上升,因此 P7 是大部分程式設計師的職級天花板。據統計,阿里停留在 P7 級別的開發約有萬人。

如果足夠優秀並且幸運,可以負責較大業務的一端技術(比如 Android/iOS/前端/後端),就能達到 P8 技術主管級別。據統計,阿里 P8 級別的開發約有五千人。

再往上,不僅具備某一端的技術能力和管理能力,還具備跨端溝通協作和商業思維,可以為業務整體技術保駕護航,就達到了 P9 總監級別。據統計,阿里 P9 級別的開發約一千餘人。

再往上走就到了我們今天要學習的兩位大佬的級別:P10 研究員/資深總監。P10 不僅在公司內很有話語權,同時在行業內也有很大的影響力。據統計,P10 在阿里大概只有五百人。

通過以上資料我們可以看到,在二十多萬員工的阿里集團中只有幾百人可以達到 P10 級別,幾乎可以算的上千裡挑一、人中龍鳳。他們的身上一定有很多優秀的習慣和個人素質值得我們學習。

兩位 P10 大佬的成長經歷

相信不少人和我一樣,對這些高段位大佬的成長經歷有很強的好奇心,想知道他們是如何達到這一步的,這期間有什麼關鍵的選擇。這一節我們來看下他們的成長經歷,通過了解前輩是如何成長的,可以幫助我們站在更高的角度審視自己。

湯崢嶸的成長經歷

首先來看下湯崢嶸前輩成長的關鍵節點和值得我們參考的點。

關鍵節點一:到美國留學

湯崢嶸在讀書時就很優秀,90 年代在清華讀書,大學期間選擇退學去美國留學,在美國半工半讀的經歷,讓他逐漸學會自己做選擇、對結果負責。

湯崢嶸提到,在大學時他知道中國的計算機水平比美國差的很遠,於是選擇去更發達的美國去看看。當時(九十年代)國內的網際網路剛起步,在美國學習、工作會比在國內機會更多。

中國網際網路大事記

值得我們參考的:

湯崢嶸之所以能夠去國外留學,一方面是因為他知道國外計算機更好,另一方面是因為他有很強的“選擇更先進的環境“的思維,即使換個環境會面臨很多不確定和孤獨,但他更關注確定的一面。這一點值得我們學習。

有時候我們只知道低頭做事,卻不知道環境對結果的影響,同樣的力氣,在平地上走和在自動人行道上走,明顯後者速度更快。

在成長階段,去更發達的環境裡會讓我們事半功倍,比如去更好的學校、更大的公司、更發達的國家/城市。環境的影響雖然短期內可能沒有那麼明顯,但假以時日,差異便會凸顯出來。

那如何知道“什麼是更好的“呢?這其實有點“馬太效應”,所處的環境越好,有效資訊密度越大,知道的好東西、好方向更多,於是“富人“越富。

過去已然無法改變,我們能做的就是在日常生活裡,主動去參與一些有價值的活動、專案,在其中認識更多的人,從而獲取更多有效的資訊,並且調整自己的行動。

關鍵節點二:美國工作十年

1995 年碩士畢業後,湯崢嶸選擇留在美國工作。前六年在匹茲堡,後四年在矽谷。

在找第一份工作時,湯崢嶸投了兩百份簡歷,並且每份都做了個性化修改。他把這種行為叫“過度努力”,就是把 60 分就可以的事做到八九十分。

第一份工作中他很快就做到了技術主管的職位,究其原因主要是亮點:

  1. 通過“過度努力”的精神做好接手的所有任務,讓領導逐漸對他簡歷信任
  1. 比如在地圖上展示不同地區的需求,如何繪製不規則的地圖在那時候網上還沒有現成的例子可以參考。他花了些“笨功夫“把 50 個多邊形都標記出來,然後逐一繪製出來,演示結果讓老闆很滿意
  1. 經常看別人的程式碼,看到寫的不好的就順手改了,改完之後就變成他來維護,後來到 80% 程式碼都是他一個人在維護

在匹茲堡工作時,業務發展經歷了快速發展(招了很多人)、錢燒完(裁員)、被收購(又招人)多個階段,由於湯對業務和程式碼的熟悉程度,始終沒有影響到他的工作。

第一份工作讓他明白:做技術程式設計能力是第一位的,只要有能力,公司倒了都不怕。

後來湯崢嶸去矽谷工作了四年,在那裡換了好多家小公司。相較於第一份工作中的踏實做事成長,在矽谷他遇到職業發展的迷茫:是做管理還是往技術上發展。最終由於沒有適合的工作,決定回國加入淘寶。

值得我們參考的:

首先值得學習的一點是“利用優勢打出價值”

我們需要知道自己當下在什麼方面是比普通人有優勢的,趁著自己優勢還在,選擇能夠發揚優勢的方向,而不是丟掉優勢和別人同起點競爭。

湯崢嶸畢業後的第一份工作年薪四萬美金,在當時這是相當高的,要知道同一時期的北京平均年薪只有 8144元。

北京歷年平均工資

在 1995 年,美國 GDP 大約是中國的十倍,能夠在更發達的國家做網際網路,這就是湯當時的優勢。如果他畢業時選擇回國工作,就相當於丟掉了優勢,浪費了一把好牌。

中國、美國曆年GDP資料比較

另外一個值得學習的點是“過度努力”思維

湯崢嶸說“做所有事總是喜歡多做一點,我才放心”,這其實是他個人素質的外在表現,說明他是一個有高標準的人,事事力求做到較好,不隨便,用常說的話就是“很靠譜”。 

在讀書時,我們的努力程度可以通過成績和排名看出來,因此有時候會迫於外界壓力逼著自己做一些事。但工作以後,很少有人會直接告訴你,你做的事可以得幾分。在標準變得模糊後,事情要做到什麼程度,就完全看做事者的內在要求。

對公司來說,肯定希望員工都盡職盡責把事情做到更好。在招聘的時候之所以優先選擇學歷更好的人,一部分原因也是因為能夠上好學校的人,往往對自己要求比較高,做事有高標準。

對個人來說,我們需要積累一個個成功案例,讓別人可以快速的知道自己是靠譜的。因此在面臨“隨便一點還是認真一點“時,儘可能的認真一點吧!

關鍵節點三:八年阿里時光

2003 年看到吳炯(阿里第一任 CTO)在清華 Email 群組發的招聘廣告,由於當時處於職業發展的迷茫期,看到國內網際網路的氛圍越來越好,湯崢嶸決定參加面試,最終也通過了。

在保留一年 offer 後,2004 年湯崢嶸決定回國加入淘寶,作為主架構師,負責架構遷移工作。在當年 10 月轉到支付寶部門負責技術,帶領 Sun 外包開發專案。後來做了六年 B2B 業務,前三年負責國際網站的技術,三年後任日本阿里巴巴 CTO。

阿里大事記

加入阿里後,湯崢嶸的職業發展不再迷茫,走上了管理路線。

在阿里的幾年裡他逐漸認識並接受了阿里文化,在專欄裡分享了很多關於管理的話題,後面的部分我們會具體檢視。

值得我們參考的:

首先一點是獲取高質量資訊

湯崢嶸能夠看到淘寶的招聘廣告,源自他的清華 Email ,這本質上就是高質量資訊渠道。這讓我開始反思自己平時關注的資訊,有多少資訊是對以後有價值的,資訊來源是否是高質量的。現在我獲取資訊主要來自公眾號、新聞網站、書籍、付費課程網站、技術網站,很多是二手資訊,並且還侷限在某一技術領域,少了些更高層面的資訊,比如國內外網際網路行業發展等。

還有一點是有意識的積累信心

湯崢嶸認為阿里給他最大的價值是讓他積累了很多信心:“一個人往前走,你的信心是怎麼來的很重要,我想就是因為我過去做成功的幾件小事情,然後複用這個經驗,或者憑藉這些成功給我的信心,不斷向前”。

當我們做成一件事後,即使這件事很小,心裡也會有微小而充實的幸福感。這個時候,我們最好有意識地記錄下這件事的因與果,在大腦中不斷強化選擇和結果的對映,這樣在後面遇到類似的事情後,可以最快的做出選擇。

比如前段時間在公司內的黑客馬拉松獲獎後,我及時覆盤並記錄下偶然背後的必然,這樣後面遇到類似的比賽,我就會多一些經驗。

關鍵節點四:加入途牛和 VIPABC

2013 年湯崢嶸離開阿里,加入了途牛擔任 CTO。之所以選擇途牛,是因為他覺得途牛創始人比較年輕(80後),對移動網際網路的機會更有敏感度。湯崢嶸選擇的時間點很好,一年後途牛就在納斯達克上市了。

途牛 2013 年前後大事記

在途牛任職期間公司高速增長,技術團隊從 200 人擴張到 1500 人。作為 CTO,湯有很大的發揮空間。他的核心任務:

  1. 一個是能夠理解老闆要做什麼事情,甚至能夠站在他的角度去思考
  1. 另一個就是要快速組建團隊

在這個過程中,除了思考如何招到這麼多優秀的人、能在隊伍快速增長的時候保持好隊形(招培育留),還需要不斷地根據業務發展調整技術架構和組織架構。

離開途牛後,湯崢嶸加入了 VIPABC,在專欄裡他聊了很多關於 2018 年裁員的事情。

為什麼公司要裁員?一方面是公司為了應對市場變化防禦性調整,另一方面也是由於每個主管的淘汰惰性(沒有壓力不會主動淘汰人),需要公司層面出壓力逼著去劣存優。

當外部環境要求企業快速擴張的時候,管理者要冷靜思考招什麼樣的人,怎麼搭組織結構。企業快速擴張起來以後,一定要花足夠精力去管理團隊,並且不斷灌輸危機感,告訴大家隨時會裁員。當真的遇到需要收縮的時候,同樣要冷靜思考讓哪些人離開。

關於招人和裁人,他總結了這幾點:

  1. 招人的標準要高
  2. 面試的時候盯著一些細節去問
  3. 經歷裡選幾件重要的事問技術細節,看是自己做的,還是隻是參與下甚至其他人的專案
  4. 把專案裡遇到的真實問題拋給他,看他如何解決
  5. 根據進來後的表現,優化自己的面試問題和判斷方式
  6. 看重的特質:聰明、可以沉下心搞技術、有責任心
  7. 淘汰的標準要讓團隊清晰
  8. 技術能力是首位
  9. 在專案管理這塊,我希望他們能讓我提前預知風險,有什麼問題預感到不妙,要提前讓我知道,不要拖到最後一刻

值得我們參考的:

作為程式設計師,我們在換工作或者加入新專案組時,很多時候可能只考慮了專案盈利情況、工資和職責,湯崢嶸給了一個更高層面的思考內容:考慮“要加入的領域在這段時間內,技術能否發揮重要價值”

在回顧途牛那段時間的快速增長時,湯崢嶸說到:“我們做出來的東西能產生商業價值,因為它確實改變了原來旅遊業的商業模式”,比如發明新模式“目的地成團”,改變原有的出發地成團模式,提升成團概率。

如果在這個行業裡,技術做的只不過是線下轉線上,並沒有帶來實質性的改變,那發展空間可能就不大。

“網際網路應該是解決長尾資源的問題,假如這個資源多出來了,網際網路可以幫你賣掉,但是如果本身就是個稀缺資源,就不適合放在網際網路上,網際網路恰恰是要賣那些不太好賣的東西”。

畢玄的成長經歷

上一節我們瞭解了湯崢嶸的成長經歷,相較於湯的高起點(清華、美國留學),畢玄的起點更接近普通人。在阿里工作十四年中,畢玄主導實現了三個非常牛的技術專案。這一節我們來看下他的成長經歷。

關鍵節點一:小公司裡脫穎而出

畢玄大學專業是生物。雖然不是計算機本專業,但他從大二開始就為外面的公司寫商業網站,這讓他有了行業經驗,讓後面入行多了些優勢。

2002 年畢業後,進入一家做政府專案的公司。一開始由於不會 VB(Visual Basic),做專案實施(現在叫交付工程師)。半年後組裡缺程式設計師,經理出了道程式設計題,答出的可以轉崗。畢玄在截至日期前解決了問題,成功轉為程式設計師。

在小廠的第五年,他花半年寫了 OSGi(Open Service Gateway Initiative,開放服務閘道器協議,基於外掛體系,拓展能力強,Eclipse 就是一個例子) 的 OpenDoc,由於當時 OSGi 在國內關注度很大,但是相關文章比較少,他的文章獲得了比較大的關注,因此被稱為“國內 OSGi 第一人”。

值得我們參考的:

畢玄在淘寶多年工作中做了很多高價值的專案,其中很多都是轉方向以後做的,技術方向的判斷力著實讓人佩服。

回過頭來看他鋒芒初露時,我們會發現他之所以能夠在 OSGi 領域有知名度,是因為他在國內對 OSGi 還沒那麼瞭解時就已經對 OSGi 很熟悉,並且花時間撰寫了開放文件。這種學習一手知識、緊跟國外的技術趨勢並及時引進國內的思維值得我們學習。

關鍵節點二:加入淘寶,負責 HSF

2007 年年底,畢玄加入淘寶。加入淘寶是通過熟人內推,而熟人就是通過 OSGi 文章認識他。

雖然面試回答的不怎麼樣,但當時淘寶招聘要求沒有那麼高,只要有一個點是非常專業的就可以,畢玄的專業點就是 OSGi。

進淘寶後他負責 HSF(High-speed Service Framework,分散式 RPC 服務框架) 的設計和實現,現在 HSF 每天還都承擔著百億次以上的服務呼叫。這個複雜的專案讓畢玄認識到:

  1. 負責流量越大的系統,就越需要對整個系統的所有環節都要非常非常清楚
  1. 以前可能認為十萬分之一的問題不會出現,但在一個大型系統裡,它是必然會出現的

反思當時的技術選型時,畢玄認為 HSF 使用 OSGi 是錯誤的選擇:

  1. 程式設計師技術選型容易主觀,夢想用一個很先進的技術去做一件事情
  1. 技術選型,關鍵是反思選擇把原來的東西改造新的,對當時這家公司來講,對客戶、使用者來講,意味著什麼?到底有沒有幫助?是不是一個很好的長期發展選擇?
  1. 商業是一個妥協的問題
  1. 面試很多 P8 升 P9 的架構師,問的核心話題都是你在這一輪架構設計裡面做過什麼選擇和平衡
  1. 越高級別的人,越需要回答的問題是你為什麼要幹這件事情,而不是你怎麼幹這件事情,以及怎麼解決裡面各種各樣的技術難題,這些是偏執行層面的

值得我們參考的:

在淘寶面試時,雖然畢玄很多問題沒答上來、演算法問題也沒寫出來,最終還是由於深入瞭解 OSGi 被錄取。

今天很多公司的面試其實也是這樣,除了考察基本技能,更重要的是確定面試者是否有某個方向很擅長。只要有一個方向掌握的很好,那就說明他具備深入學習的態度和方法,工作裡遇到問題需要學習新知識時應該也不會花太多時間。

當我們為了換更好工作而學習時,什麼都學不如找一個有價值的方向深入瞭解。

關鍵節點三:轉崗做淘寶私有云 T4

在 HSF 比較成熟後,畢玄又去做了 NoSQL 資料庫 HBase 的改進和落地。HBase 推廣落地一段時間後,覺得自己對團隊幫助不大,又開始迷茫自己到底該乾點啥。

2011 年他從《Web 容量規劃的藝術》中找到靈感,決定去做容量成本優化的事。找運維同事拉了份資料發現機器的利用率有很大提升空間,於是轉崗去負責淘寶私有云 T4 的設計和落地。

雖然畢玄對 T4 的相關技術也不是很瞭解,但他知道目標和價值,於是找了很多專業的人組成一個虛擬團隊。因為大家對目標理解完全一致並且認可,因此願意花時間在這個專案中,最終真的做成了。

覆盤這個專案時,畢玄做了這些總結:

  1. 一家公司到了一定的規模,你想做的事情肯定也會有另外的人感興趣,就看你能不能找到這樣一幫人並且組織起來做成
  2. 關鍵看你做了什麼事情對這家公司好,都是看結果
  3. 技術人員如果對你有信任,並且他也相信這個事情是有價值的,其實大家是願意用業餘時間去幹的
  1. 對技術 Leader 來講,其實判斷是對是錯不重要,因為對方向的判斷是很主觀的,沒到那個時候很難說誰對誰錯。但最怕你沒有判斷,外面怎麼樣,你覺得就是怎麼樣,那這就不要乾了
  1. 帶了一個很大的虛擬團隊去做一個很大的事情,也拿到了一個相對不錯的結果,但比起對我的影響,對其他人的影響是小很多的,這個狀況我不是很喜歡。對一家公司來講,以戰養兵是最重要的。

值得我們參考的:

最近幾年,降本增效成了各個公司的普遍口號。讓人敬佩的是,畢玄從 2011 年就開始關注企業的運維成本,在網際網路業務高速發展的當時能夠關注這點,足以證明他的先見性。

對於企業來說,需要攻守雙管齊下。除了關注業務拓展、收入增加,我們也可以向畢玄學習,多關注公司的支出成本,從日常的資源使用出發,思考如何降低成本提高效率。

關鍵節點四:轉崗運維,做異地多活改造

2013 年畢玄決定從研發轉到運維,之所以轉變,是為了從全域性瞭解公司的技術運維情況。正好當時要做淘寶異地多活,於是花了幾年時間做了廣為外界所熟知的淘寶異地多活改造。

在當時做異地多活的難點是全世界完全沒有可參考方案,花了半年多才逐步把方案試出來。畢玄感慨道:“技術圈子的人,見過豬跑太重要了”。做這種大的架構,一般是先有一個系統全貌,然後有解決的思路,就可以大概知道需要哪些人來做。然後去找各領域的人,告訴他我的思路是這個,你看這個系統裡怎麼改能做成這樣。

異地多活專案,涉及的人太多,必須要先提一個思路,然後大家開始探討,最重要的是,參與的各方都要獲得利益。

運維這段經歷,一方面讓大家覺得他是能做整個大系統架構的人,另一方面也拓寬了他的知識面,讓他知道了一個系統真正的全貌。做系統設計,不可能忽視下面的基礎設施完全當它是個黑盒。研發作為一個系統的掌控者,這些應該要掌握的。

值得我們參考的:

做異地多活後畢玄剛好做 P10 晉升面試,有人問他這些人都不向你彙報,為什麼要聽你的?他說最關鍵的就一點:“因為我還掌握著所有人的機器“。

話糙理不糙,在做內部的架構升級或者優化時,如何推動業務改造、使用,是個讓人頭疼的話題。很多時候業務方都會忙著做需求,對於依賴的基礎功能漠不關心。

畢玄的經歷告訴我們,要想真的推動改革,必須把控核心資源,通過資源限制才能強推落地。

關鍵節點五:做統一排程和研發效能

2016 年畢玄開始帶系統軟體事業部跟研發效能部,一開始大概三四百人,後面有五六百人。

當時的兩個目標(本質都是成本):

  1. 做好統一排程
  2. 離線業務和線上業務使用同一個機器池,提高利用率
  3. 可以用一個指標直接體現:公司所有伺服器全天的平均利用率
  4. 大部分公司應該都小於 10%,阿里 16 年開始做的時候是 8%,Google 發表論文的時候大概是 50%
  5. 現在阿里這個團隊還在做,去年做到了 30% 左右,天花板是 60%
  1. 解決研發效能團隊的定位問題
  2. 研發工具鏈條特別長:寫程式碼、編譯、打包、測試
  3. 程式碼編寫:IDE 的改進,程式碼智慧化 (GitHub Copilot)
  4. 編譯:Google Bazel 
  5. 希望短期能不能稍微集中力量做出一兩個亮點,只要有一兩個亮點就足以證明這個團隊對公司的整體研發效能是有價值的

第一個目標最終實現的比較好,從 2016 年到 2018 年,大概跑到了 1 萬臺機器,相當於線上有 1 萬臺可以給離線用,那一年離線少採購了 5000 多臺機器,1 臺假設 10 萬,一年省了 5 個億。

第二個目標做的比較艱難,本質上是因為研發效率無法直接量化,公司層面只會看到最後的人員增長。研發效率提升是個複雜的問題,因為它其實是個協作問題:

  1. 第一個問題:協作開發模式

  2. 公司有這麼多種型別的業務,要高度抽象出一個很好的協作模式,太難了

  1. 第二個問題:環境干擾問題

  2. 測試環境不穩定,測試效率如果很低,意味著最終上線的週期肯定會被拉長

為什麼很多公司想提升研發效能?

  1. 大廠到了後面人效比是下降的
  1. 每年都會覺得業務增長是這樣,但研發人員怎麼還在不斷增長
  1. 公司層面只看最後的人員增長

值得我們參考的:

做技術選型的時候,如果開源界已經有一個很成功的東西,自己又沒有什麼很顛覆性的思想,還是擁抱開源比較好,沒必要挑戰。

關鍵節點六:創業擔任 CEO

畢玄在 2022 年創立貝聯珠貫公司,擔任創始人和 CEO,主要做資源排程產品。對於現在很多公司而言,人員和 IT 資產是最主要的兩塊成本投入。他們選擇的賽道是提升 IT 資產利用效率,降低成本。

談到創業方向的選擇,他給了三個建議:

  1. 選一個自己相對有優勢的領域
  2. 第一次創業的人,八成只能做自己擅長的,其他的概率非常低
  1. 從商業模式上來講具不具備盈利的可能性

  2. 盈利,最重要的是你對客戶的價值是什麼

  1. 可以被產品化和規模化

  2. 邊際效應

談到 CEO 的工作內容,他說 CEO 就是一個打雜的,公司什麼事沒人幹就是 CEO 幹,如果有人幹,你最好就不要乾了。

雖然夢想很重要,但盈利是第一要事:

  1. 現在的融資環境,至少要一年半以上,我們都是按照18 個月準備的
  1. 辦公司當然要賺錢,但選擇還是需要的
  1. 在資金還夠用的情況下,短期有些錢如果對公司業務發展沒什麼意義,就不要賺好了(個人也是,時間要緊)
  1. 提升金錢支出敏感度

  2. 很多大廠出來創業的人,錢都不知道花哪去了

  1. 有了很好很健康的現金流,再考慮一些夢想

  2. 阿里雲能做為什麼?就是有淘寶,能持續產生健康的現金流

對於 ToB 業務要想盈虧平衡需要積累多久,他認為至少需要三年以上:

  1. 第一年,種子客戶培養
  2. 相對烏托邦階段,矇頭做一個自己覺得對這個世界很有價值的產品
  3. 拿了融資尤其,一你不缺錢,二業務增長也不是你這個階段最重要的目標

  4. 等見到真正的客戶讓他付錢的時候,你可能就發現原來根本不是這樣

  5. 太高調在中國真不是好事,卷得非常厲害的,抄襲也非常嚴重

  1. 第二年,基於種子客戶的賽道做規模化複製
  1. 第三年,擴到一個更大的領域,不限賽道通用的

兩位 P10 大佬關於常見話題的見解

上一節我們瞭解了湯崢嶸和畢玄的成長經歷,從關鍵節點中學到很多。除了成長經歷,專欄中還有很多話題的討論,這裡我摘錄幾個感興趣的話題,看看大佬們的見解,主要包括:

  1. 如何更快地成長
  1. 如何換更好的工作/做對選擇
  1. 該怎樣做技術
  1. 如何做好管理

如何更快地成長

關於個人成長,湯崢嶸有這些建議:

  1. 向優秀的人靠近

  2. 每個人在一個階段到達天花板的時候,就需要有人能帶你看到上一層的風景,多和貴人請教(貴人就是把你拉到上面讓你看一眼的人

  3. 要想成為優秀的人,就得有意識地向優秀的人靠近,同時接受他們指出你身上的缺點
  1. 過度努力:

  2. 核心是積極爭取,不計較得失,也不讓自己後悔

  3. 現在很流行選擇大於努力的理論,但我更相信努力。因為只有努力是自己可以控制的,選擇、機遇、貴人、天分等都是自己無法控制的。
  1. 像老闆一樣思考

  2. 當我把自己想象成老闆的時候,我在提可選方案時會跟老闆說:如果我是你,我會選擇其中哪個方案。這相當於我給了自己一次機會跟老闆交流,如果老闆比較厲害的話,還可以給我指點,我不就學到了嗎

  3. 獨立承擔責任:核心是自己有思考、做決定,接受任何後果,不把期望值放到其他人身上

  4. 當你覺得你是這件事的主人的時候,你會冒著非常大的風險去管理這個事情,去做選擇。你可能會搞砸,失敗了你沒啥大損失,成功了有大收穫的

  1. 笑對問題

  2. 當你看到的問題越多,那就說明你的機會越多。對純技術人來說,你就是要去解決公司裡最難的問題,這就是你的捷徑

  3. 普通人可能沒有機會解決難題,牛人天天都在解決難題。給我們問題,就是在給我們機會
  1. 晉升

  2. 在公司人緣好,認識的人多,而且做的事情委員會的人都瞭解,可能在晉升的時候就會佔便宜,另一個人和技術委員會的人不熟,只用一個小時的彙報時間說服評委,總是有點難度

  1. 無論是對商業、產品還是技術類的知識,你都要有一個系統化的積累過程,這樣才能進步和成長

畢玄的建議:

  1. 對自己負責

  2. 每家公司不對個人成長負任何責任,反正你沒成長,公司大不了換一個人

  3. 但你自己應該有追求,用到的所有東西都應該去了解它背後是怎麼回事,否則很容易被淘汰

  1. 檢驗自己的水平

  2. 有一個很簡單的方法:能分享多少

  3. 講多久能把自己講空掉,就是你能力的極限

  4. 很多人用中文隨便能講兩個小時,一換成用英文講,10 分鐘就講完了,這其實就是你的英語水平
  1. 很多新招來的人,都想一上來就鋪天蓋地做一件很大的事,真的想多了

  2. 你先從一件很小的事證明你就是比別人做得好,然後慢慢的別人對你有了信任,那你機會多了去

如何換更好的工作/做對選擇

湯崢嶸:

  1. 我絕大部分過去的選擇都不是因為對前面的企業不滿意,而是說在比較兩個機會的時候,考慮下一個機會是否明顯可以給我更大的提升
  1. 要了解自己,你自己是什麼樣的人,喜歡什麼樣的環境,在去大公司或者小公司之前,把公司情況、團隊情況、你自己的情況統統考慮進去,再做選擇,而不是盲目地認為公司大小對個人就有決定性影響,還是要關注具體的人
  1. 每一次換公司我都遵循一條主線,那就是:這個公司做的業務或者這個領域在這段時間內,能否通過技術進行比較大的變革,是的話我覺得投入就有價值

  2. 反例:掛號業務,不過是讓醫療體系的技術往前趕一趕,沒有讓行業產生變革

  1. 我是有意迴避一些我認為悲觀的東西,我覺得當你看到太多負面東西,或多或少就會在你腦海裡沉澱下來,對你做判斷會有影響

畢玄:

  1. 正確的做事和做正確的事

  2. 公司大了以後,不同部門的職責不一樣,有些時候基礎部門會出於自己的考慮,拒絕業務部門的要求(正確的做事)。其實這個時候更應該做的事,圍繞業務目標,給出規避或者解決的辦法(做正確的事),否則業務不好誰都不好

  1. 高級別的人換工作最大的風險:別人會對你的期待太高

  2. 如果去另外一家大公司,多數給的職位能比現在更高,大家對你的期待是完全不一樣的,比如同樣的事,我在阿里做要三年,別人就可能希望你在一年內帶來很革命性的變化

  3. 工程就是工程,工程落地的節奏是很難壓縮的,加速肯定會有風險
  1. 沒有平臺,你有能力也沒用
  2. 平臺不夠大,碰到的問題就不是世界級,可能別人早就碰到並且已經解決掉了,那你就不可能做很創新性的

關於該怎樣做技術

湯崢嶸:

  1. 做技術的還得聽業務的需求,但是牛人可能就會在做業務需求的時候,發現技術有顛覆性的苗頭,這個時候就可以跳出來說,本來這個技術是為這個需求去做的,但是我打算拿這個技術幹別的
  1. 阿里有行癲這樣非常牛的人,他在一開始就把架構搭得很清楚了,在執行業務時候也很清楚

  2. 他指揮得好,中臺搭建的速度就快

  3. 但如果公司的架構沒做好,各個部門各自為政,這個大中臺的轉換就不會這麼順利。
  1. 很多做技術的人特別喜歡定規則,他們自認為規則很好,但是這些規則常常反過來變成束縛了
  1. 業務人員說今天要把刀,技術人就得今天扔個刀給他

  2. 技術人先不要想做一把多厲害殺傷力多強的刀,業務的人可能也不 Care 這個,他們就是想要把能用的刀,能大概砍幾下就行了

  1. 關於出問題

  2. 只要做東西就容易出 Bug,所以必須得在效率和錯誤率之間找到平衡

  3. 優秀的技術團隊要能比使用者先知道系統問題

    • 我們用真實的一小批使用者試錯,等到大規模使用者來臨前,我已經把 Bug 修好了

畢玄:

  1. 程式設計師的價值關鍵體現在作品上,作品裡很重要的一點是對業務、技術趨勢的判斷
  1. 判斷新技術是否有價值

  2. 圍繞痛點去想,技術現在有沒有可能把這個痛點往前推進一代產生很大的改變,你的新東西要解得更好,而不是小修小補

    • 比如大資料的演進,圍繞算更快的訴求:Hadoop 解決能算出來,但有點慢;Spark 解決的是我通過架構改造,讓你整個具備了算更快的能力;Flink 就更快,因為已經實時化了
  3. 第一步想清楚使用者的問題是什麼,第二步想具體怎麼去解這個問題

  1. 關於技術影響力

  2. 千萬不要為了做影響力而做影響力,只看你對公司業務的影響

  3. 影響力是很容易培養的,你有了結果,也有貢獻,做的方法也具備引領性,剩下的只要炒作包裝一下就可以

  1. 技術難度,不能光定義成純技術側的東西,其實還有很多是複雜性問題、抽象問題
  2. 做業務技術的人,他不是沒有技術難度,他的技術難度在業務複雜度,能不能抽象成一個非常簡單的東西,去支撐非常複雜的業務
  1. 什麼是架構師

  2. 根據需求設計解決方案,判斷出每個系統要解決好的幾個問題,有時候也負責核心程式碼的編寫

  3. 第一是目的,第二是目標(目標即指標,如何考核你做到了),第三是系統組織設計
    • 第一要非常清楚知道你做的這個事情的意義,從意義出發思考解決方案,不侷限手段,做取捨
    • 對未來專案技術發展趨勢有判斷,儘量支援拓展
    • 處理團隊分工問題
  4. 越大的架構師越是個框架,是個方向性指導,定義了一個目的,最後確保這麼多人協作不會走偏
  5. 必須說清楚我的總體思路是什麼,然後你這部分最重要的是要做好什麼
  6. 技術上的架構師是我必須要設立一些指標,可以確保你們上線了我也能看
    • 如果不能量化,應該是這個架構師沒有想得很清楚
  7. 解決思路有很多種,你為什麼選擇這種?你的思路是不是最好的?如果不是最好的,你要知道最好是什麼

  8. 取捨:到底哪幾個地方是一定要解決的,哪些在當前階段是不重要的

    • 先落地,優先選擇從工程落地上效率最高的,即使不夠優雅
    • 逐步優化,最重要的是快速證明可行
  9. 架構最大的問題是如果解決思路有問題,最後的返工可能非常嚇人
    • 如果你不知道這個世界上已經有的、最好的解決方法到底有哪些,你就會覺得自己的解決特別牛,但其實可能是別人玩剩的
    • 見過豬跑是很重要的
    • 架構師,對視野的要求非常高
    • 必須主動天花板的發展情況
      • 先找你的領域含金量最高的學術會議,看論文
      • 中國計算機學會推薦的計算機頂級會議目錄:https://www.ccf.org.cn/c/2019-04-25/663625.shtml
  10. 面試判斷的核心就是看你對自己專案背後技術的理解程度,包括這個專案的問題、你的解法、業界對這個問題的解法、最後你為什麼選擇了這個方法而沒有選擇業界的方法
  1. 技術最重要的是帶來了什麼
  2. 技術好,那你到底用什麼來證明呢?
    • 你做的東西,對這家公司的整個業務發展是否有所作用?
  3. 對技術人來講,只在乎你過往做了什麼,你做了一個東西還能被很多人用,就是最牛的

關於如何做好管理

湯崢嶸:

  1. 如果你真想做好 CTO,首先確保自己的技術不能差。千萬不要放棄自己對技術的追求和對技術的研究,不能變成一個純管理崗位,千萬不要放棄在公司裡一些小的技術上的溝通,那個是讓你保持技術敏感的一個很重要的途徑
  1. CTO 的責任
  2. 我要把這些人都帶起來,讓他們成為發動機,他們只要能力強了,他們成為每個部門的 CTO 了,我就輕鬆了。我花了蠻多時間,跟他們做各種溝通的
  3. 管理的責任之一就是要把你下面技術很牛的人,介紹給別人,要不然他上不去是你的責任。
  4. 如何培養人
    • 首先選對要培養的人,特質:聰明、單純、有責任心
    • 給他一個比水平略微高一點的任務
    • 適當的時候給一些暗示,告訴大方向,但又要讓他覺得是自己努力做的,有滿足感
    • 多聊天,鼓勵、激勵(激將)
  5. CTO 要花很多精力去跟業務人明確問題,然後協調解決問題
  6. 管理的人太少也不是好事,當 CTO 離一線越來越遠的時候,會真的看不見問題的。因為下屬給你展示的基本上都是經過包裝的真相
  1. 技術人轉管理可能第一步遇到的問題,就是由管事到管人的轉變,這幾乎是兩種不同的方法。
  2. 技術的好壞是黑白分明的,但人和事不是
  1. 做管理者,一個很重要的核心是把上級的剛性的、標準的需求,變成一個柔性的、可執行的方案,這才是管理的本質。
  2. 中層的管理者是連線作用,他要把向上的不確定性轉為向下的確定性。因為管理者越往上走,他承受的不確定性越大
  1. 管理的一個重要部分是讓團隊的價值觀匹配

  2. 做管理,就是要你來給這些人打分,你決定了他們的去留、工資,你就有這麼大的責任。

  3. 在此以前總想追求一個完美的管理方案,想誰也不得罪,應該我打出的分所有人都叫好,老闆也說好,員工也說好,後來你發現這根本不存在
  4. 你要把你不喜歡的和你喜歡的人的畫像畫出來,告訴大家,你鼓勵什麼和不鼓勵什麼

畢玄:

  1. 建立管理認知:如果你想對這個公司有更大的貢獻,就必須帶領更大的團隊
  1. Leader 的幾件事:把方向定好(長期、短期),陣型布好(組織形態,閉環還是依賴外部),位置放好(每塊的一號位),另外是事情的跟進,還有一點整個團隊的成長,就是人才培養問題

  2. 落實環節需要對團隊很瞭解,需要花精力去了解他們,看到一個更立體的人

  3. 人才培養很重要,通常來說,只要團隊的成員都成長了,事情就做成了
    • 人才的資產負債表,團隊人才是在虧損還是盈利(職業發展向上就是盈利、向下就是虧損)
  4. 公司變大之後,業務多元化,要橫向擴張,面臨的問題就需要一個厚的人才梯隊池來解決,如果不特意培養就沒有了,公司就會斷崗
  1. 人數少的時候,管理比較簡單,只需要知道他們的能力狀況和在做的事情
  1. 如何對成員瞭解更多
  2. 三個問題增加了解
    • 離開阿里巴巴的時候,你會找一份什麼工作?(確認職業規劃,根據他的規劃可以更好的安排工作
    • 過去一年你覺得對你職業生涯是加分、減分還是持平,能不能寫進簡歷?(確認目前工作安排是否有價值,如有否定的回答,需要考慮是否給的方向、空間有問題
    • 對團隊的看法,有沒有什麼問題(如果對問題有思考和想法,可以結合發展潛力和職業規劃安排工作)
  3. 經常聊,會發現有些人其實有潛質去承擔更大的事情
    • 不同級別的人,無非是看問題的角度不一樣
    • 好的領導會和下面講為什麼做這個決定,考慮點是什麼
  1. Leader 最重要的是思考方向
  2. 經常問手下的 leader,理想中你的團隊陣型是什麼樣的,幾個人、分別放什麼級別
    • 考察他的規劃和境界,是否會限制下面的人
    • 一個 Leader 要做好,核心是先要對整個團隊的方向有思考,你有自己的觀點很重要
    • 可以跟我觀點相悖,這都不重要,但關鍵你想過,並且有邏輯,那我覺得就可以了
  3. 其他所有技能都是可以彌補的,但對方向的感知這個技能是很難被彌補的,否則只能做執行
    • 對技術 Leader 來講,其實判斷是對是錯不重要,因為對方向的判斷是很主觀的,沒到那個時候很難說誰對誰錯。但最怕你沒有判斷,外面怎麼樣,你覺得就是怎麼樣,那這就不要乾了
  4. 結合團隊和自己的位置,往上看
    • 站在公司的角度,越高的層級,要考慮的就會越貼近公司的核心
  5. 越大的 Leader,肯定是越難被影響
    • 你會覺得他很偏執,建立在自己很強的相信上,否則他很難走到這個位置。這其實沒錯,如果他太容易被影響,這樣的 Leader 也太可怕了
    • 當 Leader 最好不要太急做決定
    • (我就有些容易被說服,沒有完整的自我邏輯閉環)
  1. 心態

  2. 打造開放透明的環境,做決策時告知決策的原因,同時接受挑戰

  3. 杜絕這種心態:Leader 一定要什麼都懂;被問到不會的問題,會沒有面子損失權威
    • 在被挑戰後,即使不會,直說沒有想到這點,不想太多
    • 在到新崗位上,不要因為在乎自己的權威,就必須強裝的比其他人都懂,外行指揮內行
  4. 保持這種心態:Leader 是幫下屬解決問題的(如果解決不了,可以直說,不必耽誤大家時間)

總結

好了,這篇文章到這裡就結束了。

本篇文章介紹了阿里 P10 的大概概念,回顧了兩位 P10 前輩成長過程中的關鍵節點,然後針對一些年輕人關注的話題記錄了兩位前輩的感悟。

通過兩位前輩的分享,我們可以對如何成長為阿里 P10 有更多的認識。

成長最快的方式是從前輩身上學習,相信在將來的某天,他們的話語會給我們帶來啟發。