前言

?

什么是技術一號位、有哪些關注點、怎么做技術一號位？

?

做了研發團隊的技術 leader 以后，要處理的事情非常多，如果對自己扮演的角色沒有一個清晰的認知，就會出現該做的事情沒有做，不該做的事情投入了過多的精力，造成實際行動和結果既不匹配上級的要求，又不匹配下級的期望。特別是對于剛開始帶領研發團隊的新人 leader 而言，角色的轉換和適應的過程，增加了認清自己的角色本質的難度。今天我們拋開純技術團隊的同學不談（其實本質一樣），只討論業務研發團隊的同學，如何以技術一號位的角色來做事。

?

如何識別自己是不是技術一號位

?

在開始談如何做事之前，首要任務是判斷自己是不是技術一號位，而要判斷之前，首先要明確判斷標準，跳出思維誤區。這里我們列出一些常見的思維誤區。

?

以下是常見認知誤區：

帶人的是技術一號位，不帶人的不是技術一號位。

級別高的是技術一號位，級別低的不是技術一號位。

?

以上的認知誤區，錯誤地把是否帶團隊、技術等級的高低和是否為技術一號位關聯起來。雖然事實上帶團隊的業務研發同學成為技術一號位的概率更大，但是本身這兩者不是劃等號的關系。

?

那么什么是區分是否為技術一號位的決定性因素呢？很簡單：對一個具體的業務而言，你作為該業務的直接技術參與者，是否處在技術領域責任鏈的最頂端。這句話翻譯過來就是，對一個明確的具體的業務而言，多種角色的同學一起合作的時候，你是否是技術序列的最終責任人，即：誰承擔對應的責任，誰就應該扮演對應的角色。

?

當產品經理、運營、研發共同做一個業務的時候，某個研發同學獨自或者帶領其他幾個研發同學，或者帶領跨 BU 的研發團隊，共同支撐 PD 的業務需求。那么這個研發同學就是這個業務的技術一號位，不論他是否帶不帶人，也不論他帶的人在行政上是否從屬于他。一般來說，負責單一業務的研發團隊 leader 一般就是這個業務的技術一號位；負責多業務線的研發團隊的 leader 的下屬，是每個業務線的技術一號位，而研發 leader 本身是更高層面業務的技術一號位。

?

所以，做業務開發的技術同學，不論是什么層級，帶不帶人，都可能是某個具體業務的技術一號位的。這一點非常重要，只有認清這個事情以后，業務研發同學才能在做業務的時候，明確下來自己除了需要寫代碼以外還需要做什么，關注什么；這些關注點需要做到什么程度，才能對上滿足期望，對下不讓團隊走彎路、不和下屬搶功。

?

當你經過以上判斷以后，確定自己是技術一號位時，恭喜你，你已經不再是一個僅僅需要寫代碼的研發同學了。很多研發同學眼中還是只有寫代碼這一件事情，如果以這種方式做業務，那么就會發現業務過程會有各種沒有做到位的事情，會在做業務的過程中“交很多學費”，甚至會因為自己的能力不夠而拖慢業務發展。

?

雖然成熟的研發團隊可以通過完備的研發過程管理，來避免個人能力不夠而對業務產生太多負面影響，但是本質上強制的規定和“上級要求”只是在依靠行政管理手段在強制一個人做這些事情，并沒有喚醒他的創造力和責任心，反而會被認為是“工作瑣事”。

?

這些“工作瑣事”本質上是需要他扮演的角色來負責的，但是由于他沒有意識到自己實際上已經是這樣的角色了，而僅僅把自己停留在“研發”的定位上，把“寫代碼”當做核心任務，這樣一來，會讓研發同學對那些看起來 “和寫代碼無關但是是技術一號位必須做的事情” 非常抵觸。這種抵觸情緒發生的時候，leader 再強調 Ownership 也都沒有太多效果，因為不是他不負責任，而是他沒有意識到，這是他應該負責的事情。當他的心態和認知轉變以后，一些原來看起來不怎么負責的人會變得負責（不排除有人本身就是不負責的人，那么這樣的人不是良好的技術一號位的候選人，主管要有識別能力）。

?

作為業務開發同學，一定要仔細認清辨別自己實質上是不是一個業務的技術一號位，而不用考慮自己的層級，不用管自己是不是業務其他參與者的 leader。當你意識到自己是這個業務的技術一號位的時候，就要迅速切換角色，從原來自己給自己的定位 “寫代碼的、搞技術的” 轉變為 “某個業務的技術一號位”，開始進入角色，發揮出你的價值。這也是很多研發同學通過做業務能迅速成長的原因，拋開技術上的成長之外，他比其他研發同學接觸了很多 “做事情需要思考并為之行動” 的維度，這些維度的豐富是普通業務研發同學很難看到、很難感覺到，因此更難悟到的。

?

不排除有悟性高的研發同學能夠自己悟到，但本質還是由于他所處的環境、他面臨的問題在逼迫他做出思考，然后為之實踐。如果一開始就知道自己做事情要找準自己的角色和定位，那么就會少走很多彎路。

?

分析你所在環境的局勢

?

當你意識到自己是一個業務的技術一號位的時候，不用過多懷疑自己究竟是還是不是，而是要本著“就當自己是”的心態來進行接下來的工作實踐和思考。需要大家明確的一點是，任何一個工作角色，都有對應的責任，也都有履行對應責任的方法論。我們要做的，不能再像過往做普通研發的時候那樣懵懵懂懂去做事，聽“需求”指揮，而是要開始尋找或總結一些方法論，要自頂向下地對業務有一個清晰的認知，知道自己比過去多了哪些維度的事情要關心，知道接下來會面臨什么樣的挑戰，要知道自己在挑戰中應該扮演什么樣的角色，采用什么樣的手段去解決業務在不同階段一定會出現的各種問題。

在開始所有的思考之前，先要做一件事情，就是分析你目前所處的環境的局勢。

?

業務方面

?

• 你的大團隊的業務大圖是什么
• 你負責的業務的大圖是什么
• 你負責的業務大圖是否和大團隊的業務戰略匹配
• 你負責的業務和大團隊的業務看似沒有契合點的時候，你的leader跟你對焦以后的結論是什么
• 這個業務對客戶的價值是什么
• 這個業務對組織的價值是什么
• 這個業務對你個人的價值是什么
• 這個業務是否會在未來承擔社會責任，會有怎樣的社會價值
• 這個業務目前處于什么階段，是剛開始，還是已經成型等待發展，還是已經發展一段時間需要業務規模
• 這個業務目前存在最大的問題是什么

?

?

協作方面

?

• 誰在配合你一起做這個業務
• 和你一起做業務的同學中，分別有哪些角色，他們會在哪些方面和你有交集
• 和你一起做業務的其他角色的同學，是否對業務大圖的理解和你一致
• 和你一起做業務的其他角色的同學中，誰是業務的負責人；或者關鍵角色的人員是否對自己是業務負責人有感知
• 業務上下游的同學段位怎么樣，是否能在實際落地過程中跟上你的節奏
• 業務一號位的KPI是什么，你的KPI是什么，你們兩人的KPI是否方向一致，你的KPI是否能支撐他的KPI

?

團隊研發方面

?

• 現在是否有一個研發團隊支持你一起做這個業務
• 和你一起做業務的研發團隊是否在行政上從屬于你
• 你帶的團隊人員每個人的特點是什么，有什么短板，在這個業務里面負責什么事情
• 研發團隊里面誰是你的接班人
• 研發團隊里面誰能補充你的短板
• 研發團隊里面，每個人做事都有什么個人的想法？個人的成長目的
• 研發團隊里面的每個人對業務大圖是否了解，認知是否一致，目標是否一致

?

如果你本身已經是專家級別以上了，那么下面這些維度可能是需要你繼續深入思考的：

?

業務方面

?

• 業務的愿景是什么
• 業務的愿景在不同時間維度上拆解以后的關鍵業績指標是什么
• 為了實現不同時間維度的關鍵業務指標，你準備投入什么樣的資源？投入的資源之間相互怎么配合？相互配合的原則是什么
• 這個業務現在做是否合適？現在做不合適的話，需要在什么時候做合適
• 這個業務現在做不合適的情況下，哪些因素讓你覺得現在做不合適
• 讓你覺得現在做這個業務不合適的因素中，哪些因素是可以通過人為干預讓它不再是阻礙性的，哪些是可以通過人為干預增加它對業務的積極作用
• 業務的現狀及瓶頸問題
• 業務問題的技術解法
• 業務發展趨勢
• 業務競合分析
• 業務發展策略
• 業務的終局暢想

?

團隊方面

?

• 團隊的使命是什么
• 團隊推崇的價值觀（做事原則）是什么
• 當前團隊的人才梯隊是否合理
• 當前團隊的人才儲備方向是否完備
• 當前支撐業務的團隊是否未來依然能夠支撐業務的發展
• 當前團隊不能繼續支撐業務的戰略規劃的情況下，需要做怎樣的調整

?

協作方面

?

• 業務是否可以向其他BU借力，或者借力于其他BU
• 當前的業務是否和其他BU可以相互配合形成某種合力的優勢
• 當前業務和其他業務如何配合來完成未來的布局從而獲取對應的優勢
• 未來的布局落地后，想要形成什么樣的局勢
• 局勢形成以后，對完成組織愿景，履行組織使命有什么決定性幫助

?

找準自己的定位，明確自己的定位的含義

?

當理清楚自己所處的環境以后，知道業務是什么情況，和自己配合的人又是什么情況以后，需要知道自己扮演的角色究竟意味著什么。從我個人的經驗來看，技術一號位是負責使用技術能力解決業務問題，提供穩定可靠的技術支撐，確保業務安全合規低風險地健康發展，并通過技術或業務創新來推動業務發展；負責向業務各方提供各種必要的技術支撐，通過合理的數據分析為業務決策提供依據；通過對技術領域的積累和發展，通過業務領域的理解和落地影響業務決策；負責構建梯隊完整、能力全面、制度完善的技術團隊來支撐業務發展。

?

應該有什么樣的工作原則和要求

?

1、以業務一號位的視角思考，輔助業務一號位構建合理的業務大圖。

?

2、以技術一號位的角色保障業務落地，協助業務一號位實現業務的客戶和組織價值。

?

3、掌握和業務建設過程中各種角色的上下游協作者合作的專業能力：

?

• 在產品方面具備基礎的產品規劃和設計能力；
• 在業務方面具備有一定深度的領域知識，或者具備相關的方法論可以快速向領域專家完成領域知識的學習。
• 在商業化方面能夠提供合理的商業化模型設計，包含提供合理的計費維度和技術成本清單。
• 在產品運營方面能夠了解常見的基礎運營手段和方法論，能夠結合運營策略給運營同學提供準確的專業知識的支撐。
• 在客戶溝通方面，能夠有良好的傾聽能力，理解客戶的訴求，辯證地轉換為系統改進的動力。
• 在技術方面在公共技術服務的基礎上完成全維度技術能力建設，考慮技術的投入產出比，不能只做架構或只做核心代碼的實現。
• 在團隊方面能夠建設合理的人才梯隊，儲備必要的技術領域人才，推行組織文化，確保成員對做事的風格和原則理解一致，有行之有效的方法論幫助不同層次的同學找到成長的突破口。

?

履行技術一號位的職責具體需要感知哪些事情及其要點

?

下面這張圖從大方面上列出了一個技術一號位需要感知哪些方面的事情（圖中未列出產品運營、售前售后等一系列其實很關鍵的方面，但是如果技術一號位負責的業務是有商業化需求的，則還是需要關注這些維度的事情的）。

?

?

這些事情是必須知道，但不是必須親自做的，要能夠借助團隊的力量完成該完成的事情。下面是具體從業務、技術、團隊角度來詳細理清楚技術一號位需要感知的事情及其要點：

?

業務方面（后面會有單獨的文章詳細解釋業務方面怎么做）

?

• 建大圖
• 定方向
• 找打法
• 撐業績

?

?

技術方面

?

1、技術選型

?

• 業務需要什么樣的技術能力支撐
• 需要的技術能力集團或其他BU團隊已經具備了并且可以被你復用
• 如果不能復用，差異點在什么地方
• 如果不能復用，差異點不是方向上的根本問題，是否可以通過共建或提出合理需求來完成復用
• 如果不能復用，不能共建，是否可以使用開源項目
• 如果不能復用，不能共建，需要自研，需要個人具備什么樣的技術背景，需要團隊具備什么樣的技術積累
• 團隊或組織是否已經有了相關的基礎框架或效能提升工具
• 業務是否需要考慮數據安全問題，組織或團隊是否有安全防護相關的積累可以復用
• 業務是否需要考慮業務風險問題，組織或團隊是否有業務風險控制的積累可以復用
• 業務一般情況下都需要數據服務做業務運行期的運轉情況的監控和后期業務決策的支撐，組織或團隊是否有相關的積累可以復用
• 技術投入產出比

?

2、系統架構設計

?

1）業務場景在技術側映射出來的特征是什么，對技術側的影響是什么？

?

• 一般而言，不同的業務場景會體現出不一樣的技術特征，對技術反應出不同的需求。
• 面向B端客戶的傳統企業級應用，通常情況下對穩定性要求高，對數據安全要求高，需要保證業務操作結果和實際數據匹配。業務流量不大，系統用戶對用戶體驗不如C端用戶敏感。針對這類系統，往往通過簡單的單體應用做高可用部署即可，使用單一數據庫并通過數據庫保障業務數據變更的事務，界面契合客戶業務。
• 面向C端客戶的互聯網應用，通常情況下對流量承載能力要求高，對數據安全要求高，對用戶體驗敏感，對穩定性要求高，業務流量巨大，特殊的業務場景會出現特殊的流量峰值。針對這類系統，往往需要構建分布式系統做大流量高并發高可用系統架構建設，自頂向下分層優化，從終端層的靜態資源CDN化，到應用層的前后端分離，應用邏輯和底層服務分離，再到核心業務層的微服務架構建設，從服務發現服務治理，到無狀態應用的規模化部署，從大量基礎中間件的使用，到大量公共業務服務的構建，每一層都需要做好對應場景的優化和架構設計。
  ?

2）如果業務會在某個發展階段涉及到大用戶流量，對應的系統技術架構是什么樣的？

?

• 大流量高并發高可用系統架構
• 業務流程異步化
• 使用限流手段確保系統不被突發大流量壓垮
• 使用降級手段確保下游系統不可用時能夠快速失敗避免請求堆積造成系統無法接受或響應外部請求
• 使用邏輯隔離或物理隔離手段確保多租戶模式下各租戶互不影響
• 使用合理的資源調度策略確保不同規模的租戶享受同等技術服務水平
• 使用合理的資源使用策略確保成本維持在合理水平
• 使用合理的監控手段提前發現系統承載能力的變化，及時通過擴容或縮容來應對系統流量變化
• 使用分庫分表或根據業務需求采用合適的NoSql數據庫來支撐海量數據持久化
• 使用緩存抵擋大流量對數據庫的壓力
• 使用分布式鎖處理高并發業務場景下的公共資源搶占問題
• 使用冪等服務屏蔽高并發場景下的重復請求
• 使用分布式事務服務確保業務數據的最終一致
• 使用負載均衡承接業務流量，分配給后端應用服務器，避免單點風險
• 使用同城雙機房來規避單機房風險
• 使用異地多活技術來規避單個城市的不可抵抗風險

?

3）如果業務非常復雜，領域眾多，那么采用什么樣的架構更合適？

?

• 業務復雜的情況下，采用微服務架構

?

4）如果確定要采用微服務架構來支撐復雜業務，那么領域劃分和每個微服務是否匹配，微服務拆分粒度是否合適？

?

• 如果是單體復雜業務應用拆分為微服務，則應該按照業務領域來拆分，拆分后通過服務接口對外提供標準服務。
• 如果是開始就確定要做成微服務架構，那么要先做領域劃分和建模，然后大的復雜的領域單獨形成業務服務，公共依賴的領域做成服務，使用合理的服務治理框架，選擇合理的服務通信協議，構建業務系統。
  ?

3、業務建模

?

• 業務領域知識學習。
• 業務領域建模，使用領域驅動設計完成戰略設計（領域上下文的劃分和上下文之間的協作模式的確定）和戰術設計（領域內的實體、值對象、領域服務、實體工廠、倉儲層、數據持久化層的設計）。
• 業務建模是否合理，是否采用了合適的方法論來應對不同復雜規模的業務？
• 面對復雜業務，是否有完整的領域設計和匹配當前階段的落地路徑？
  針對復雜業務，不需要最開始即按照完整的業務模型做落地，而是根據實際業務需求和時間進度合理定制業務模型的落地計劃，既確保需求能按時完成，又確保代碼落地始終在業務模型設計范圍之內而沒有腐化。
  ?

4、研發落地

略

?

5、項目管理

?

• 項目目標
• 完成時間
• 想要取得的結果
• 項目成員
• 關鍵里程碑
• 風險預警
• 多方協調溝通
• 日常進度追蹤

?

6、項目復盤

?

1）質量保障

?

• 代碼掃描
• 代碼評審
• 研發單元測試
• 團隊業務需求溝通及評審
• 測試用例編寫
• 測試用例評審
• 基礎功能測試驗收
• 上線發布驗證
• 灰度測試
• 線上驗收測試
• 自動化冒煙測試
• 每日自動化測試
  ?

2）穩定性建設

?

• 關鍵業務流程日志打點
• 全業務鏈路跟蹤
• 系統技術指標監控
• 系統業務指標監控
• 告警
• 自動化告警恢復
• 關鍵業務場景預案建設
• 關鍵業務場景預案執行
• 值班響應機制
  ?

3）風控建設

?

• 業務風險點定義
• 業務風險點識別
• 業務風險點級別定義
• 業務風險點分級處理
• 業務風險點報警
• 業務風險點觸發趨勢
• 實時業務風險控制
• 離線業務風險掃描
• 業務風險點誘因分析

?

團隊方面

?

• 成員 1v1 溝通
• 成員優劣勢分析
• 成員做事意愿分析
• 成員角色定位對焦
• 成員能力梯隊聚焦
• 方法論的探討與實踐
• 幫助不同的人看到自身不足，定制不同的成長規劃
• 根據不同人的優劣勢和做事意愿，安排調整合理的事情和責任范圍，激發做事的主動性，為其發揮出創造力營造良好的環境
• 業務大圖的解讀和 KPI 的設定
• 工作原則和工作要求達成一致認知
• 明確團隊要什么，不要什么，推薦怎么做，不推薦怎么做

• • 要創新不要墨守成規
  • 要思考不要苦勞
  • 要打破思維定式和束縛，不要自我設限
  • 要 Ownership，不要推脫
    ?

如何成長為技術一號位

?

目前還不是技術一號位的業務發開同學，雖然現在的崗位只負責一小部分，但是本質上來講，只要你負責某個事情，那么不論這個事情大小，你都是這個事情的技術一號位，只是由于事情的難易程度和規模大小，導致很多可能需要做的事情其實并不需要做，但是這些問題并不妨礙你知道技術一號位要做什么，應該怎么做，更不妨礙你以技術一號位的心態去做事。

?

先確定好心態的問題以后，接下來就需要一些可以被實踐檢驗的方法論來幫助大家打破自己層級的束縛，完成自我突破，從而在成長的基礎上獲得負責更重要的事情的機會，通過做好更重要的事情來獲取更更重要的事情的機會，這樣一定會在某個階段，你負責的事情，需要完全以真正的技術一號位的角色去落地，那么那個時候扮演技術一號位的角色也就是水到渠成的事情了。

?

作者介紹：

?

賀科學（晨末），畢業于北京科技大學，工作10年，在企業級應用架構及研發方面有長期積累。擅長分布式系統架構，擅長復雜業務的領域建模及開發落地，掌握領域驅動設計及開發相關方法論，有實際成熟線上產品案例；2014年入職阿里云，先后參與或主導過阿里云控制臺、阿里云容器服務、資源編排服務、云分期等云服務的建設。目前帶領小型團隊負責新零售業務相關的研發工作，累計C端用戶過億，承接阿里巴巴集團內外眾多流量業務的積分兌換實物商品業務。

?

除業務以外，個人精力也投入在“復雜業務系統落地過程數字化”這一命題上，目前有一定思考和實際積累。實際工作中有3年帶團隊全面獨立負責復雜業務系統的經驗，所以在技術一號位的工作方面有相關的實踐和思考。

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的「技术人生」专题第1篇：什么是技术一号位？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。