技術總監(jiān)告訴你,阿里技術人才的能力模型是怎樣的?
大家好，我是小林。
今天給大家介紹我一位朋友軍哥，前餓了么技術總監(jiān)，他從業(yè)互聯(lián)網(wǎng)已經(jīng) 15 年，不管是技術、產(chǎn)品，還是管理都有非常獨到的見解，推薦大家關注，底部有關注入口哦。
下面是軍哥今天要分享的內(nèi)容。
高清圖請關注「軍哥手記」公眾號后臺回復“199”獲取
今天的文章將從「技術、業(yè)務、通用、其他和考察重點」五點逐一展開。
1.技術
按以上的思維導圖，技術部分提煉為三點：
1、有技術攻堅能力，就一個單點技術問題，可以提供有深度的解決方案，并且執(zhí)行落地；面對較復雜的技術問題有自己的解決方法，有沉淀可輸出。
解讀：比如緩存被擊穿問題，導致數(shù)據(jù)庫高負載并最終變?yōu)閼孟到y(tǒng)不可用，此時我們需要去診斷 Redis 集群被擊穿的原因，當然有可能因為緩存的 value設計不合理導致占用空間太大，也有可能是緩存的超時設計不合理等等，我們需要通過現(xiàn)場還原真相，通常的辦法是先去看看 Redis 的命中率，事故的現(xiàn)場分析出現(xiàn)問題機器的堆棧信息。
從問題的表面直到內(nèi)核，解決這種疑難問題的頂層思路是從整個緩存的使用鏈路，緩存相關的監(jiān)控信息入手，甚至業(yè)務上的一些數(shù)據(jù)變化或是否有新的代碼上線等角度。
并且對每一個重大線上問題事后要形成故障報告沉淀，這些慘痛的經(jīng)驗都將成為團隊新人引以為戒的案例。
2、對于負責的技術模塊具備一定的架構設計和選型能力，能清晰理解上下游技術團隊相關技術的架構設計和原理；對通用領域技術方案有一定了解。
解讀：比如我負責電商 C端 的訂單系統(tǒng)，我需要根據(jù)我的日訂單量和業(yè)務復雜度來設計系統(tǒng)架構，核心數(shù)據(jù)落到關系型數(shù)據(jù)庫，非核心數(shù)據(jù)針對場景可以考慮 Redis 或者 MongoDB，另外我也需要了解上游比如推薦系統(tǒng)一些原理和業(yè)務特性，也需要思考下流的履約系統(tǒng)的業(yè)務特性。
當然對 MQ，數(shù)據(jù)庫分庫分表切如何分，以及分布式定時任務這些通用技術都需要了解他們最合適的使用場景。
3、能準確闡述核心技術點和業(yè)務之間的邏輯和關聯(lián)，具備良好的定義指標的能力和數(shù)據(jù)分析意識。
解讀：比如我在餓了么時，我的一位P6下屬當時遇到場景是，從業(yè)務來說，早餐訂單渠道來自餓了么app，小程序，h5，開發(fā)平臺，那么作為技術骨干的他還需要知道哪些是自有渠道，哪些是外部渠道，在不同渠道上我們在運營策略和紅包規(guī)則下有什么不同。
并且我們需要有一個指標大盤把各種渠道的訂單做同步環(huán)比展現(xiàn)，同時對于一些內(nèi)外部訂單的數(shù)據(jù)異?？梢缘谝粫r間找到其背后的原因，我記得有一次日訂單量提升10%，我們和運營說了這事，運營回答也沒有做什么活動。
最終我們通過訂單轉(zhuǎn)化漏斗發(fā)現(xiàn)，訂單確認到支付頁轉(zhuǎn)化率提升了10%，是我們在歷史訂單上加了一個“再來一單”的功能，這些變化可以通過數(shù)據(jù)來找到核心的原因，以上就是定義一些關鍵指標和良好的數(shù)據(jù)分析意識。
2.業(yè)務
1、懂業(yè)務的核心目標和當下產(chǎn)品演進的關聯(lián)性判斷，拆解業(yè)務需求并完成自身模塊內(nèi)部技術實現(xiàn)方案，指導1到2個新人的開發(fā)工作。
解讀：比如我在餓了么負責客服產(chǎn)品時，我們的工單系統(tǒng)之所以需要規(guī)則引擎功能，是因為我們業(yè)務要定義一些靈活的規(guī)則，讓不同的工單轉(zhuǎn)到相應的業(yè)務方來處理，當時技術團隊并沒有這方面的經(jīng)驗。
我們的 P6 同學于是分析來市面上的開源規(guī)則引擎優(yōu)缺點，并最終集成到我們產(chǎn)品中，同時還有一些工單相關的邊緣工作讓新人去實踐，這就需要 P6 同學熟悉工單業(yè)務并且熟練掌握通盤的技術方案，同時對團隊不熟悉的技術可以快速學習和落地，并指導新人、培養(yǎng)新人。
2、能在業(yè)務上抽象通用解決方案，并進行平臺化沉淀（效率），影響業(yè)務發(fā)展，不止于完成需求，能熟悉業(yè)務需要的上下游技術，能夠做業(yè)務模塊的技術選型，了解技術使用場景和優(yōu)缺點。
解讀：我們的工單系統(tǒng)從外部用戶反饋到公司內(nèi)部運營處理，還有一部分內(nèi)部用戶訴求，我們也希望可以接入到我們的工單系統(tǒng)。
最終我們完成這個工作，做了工單的底層抽象，工單系統(tǒng)負責工單生成和狀態(tài)變更和調(diào)度，業(yè)務細節(jié)由客服或者內(nèi)部系統(tǒng)來決定，工單系統(tǒng)做出業(yè)務無關性的設計。
3.通用
具備良好的溝通協(xié)同能力，有基本項目管理意識。
解讀：我覺得 P6 這個層級需要具備如下項目管理意識。
1）項目關鍵節(jié)點是否有符合基本標準質(zhì)量的交付物。
2）開發(fā)人員在項目管理是一個核心資源，要保證這個資源的可用時間真的花在這個項目上。
3）整體的項目進度定期 review（按天或者團隊習慣的頻率）。
4）關鍵節(jié)點的人要有備份機制，以及遇到突發(fā)事件，比如人員請假或者技術難題都必須有 B 方案。
5）至少在上線前一天產(chǎn)品具備 UAT 條件，并讓產(chǎn)品通知業(yè)務方做UAT，規(guī)避一些上線后的各種溝通或認知不一致問題。
4.其他
1、關注人的潛力、自驅(qū)力
解讀：關于潛力，我認為重點要考察候選人，對自己的工作是否有熱情、專注，且在工作之外是否在持續(xù)學習和擁有深度思考的習慣。這些可以通過好的提問和觀察來判斷。
關于自驅(qū)力，我認為更多是洞察候選人的工作的源動力和動機是什么，通常情況下，對自己從事的工作感興趣，熱愛，就會有非常強大的自驅(qū)力，反之只是想多賺錢這單一維度則不會具備自驅(qū)力，就算有也不會持久。
2、主動性、好奇心
解讀：如果你看過《高效能人士7個習慣》和《終身學習》，你應該知道高效能一書中，最重要的習慣就是「主動積極」，而不是固定思維和被動接受，《終身學習》也同樣強調(diào)人的主動性和好奇心。
5.考察重點
1、獨當一面
解讀：作為一個 P6 職責范圍的事，必須可以獨立完成，并且完成了也只是績效考核的最低要求（剛及格）。
2、有效執(zhí)行
解讀：領導給我們布置一個任務也好，我們定義自己工作目標也罷，必須要按時按質(zhì)完成，這才算有效執(zhí)行，有行動力。
3、代碼質(zhì)量
解讀：第一保持代碼邏輯和業(yè)務相符，第二保持和團隊一致的代碼規(guī)范，第三考慮異常流程的正確處理，第四要做到架構超前于業(yè)務至少一個身位。
寫在最后
以上，是今天討論主題的全部。
我今天花了一點時間來討論阿里技術人才能力模型——初級篇，我覺得這個模型提煉還是非常干貨和準確的，希望我的解讀對你有價值。
▲?長按關注「軍哥手記」，回復"1"獲取資料