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

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

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

以下是常見認知誤區：

1. 帶人的是技術一号位，不帶人的不是技術一号位。
2. 級别高的是技術一号位，級别低的不是技術一号位。

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

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

當産品經理、運營、研發共同做一個業務的時候，某個研發同學獨自或者帶領其他幾個研發同學，或者帶領跨 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，不要推脫

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

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

作者：賀科學（晨末）

本文為阿裡雲原創内容，未經允許不得轉載。