## 前言 隨著前后端分離，前端越來越多的承擔著產品開發的工作，而且更多的涉及產品邏輯尤其是頁面之間的邏輯以及關聯，而后端從繁雜的頁面邏輯中脫離出來，更多的是會開發微服務的部分，當然過度階段，后端還會寫為某些頁面服務的接口代碼，我們稱之為膠水代碼。 ## 人員能力分層 首先不可避免的前端技術人員會出現能力的差別，從入門級別的p3,到總監級別的阿里p7-8,很多公司或者領導會講，我們是扁平式的管理，但是這不等于所有人的能力是扁平的，更不意味著所有人最終是扁平的，責任和權限也是和能力掛鉤的。 那么首先需要對人員進行分層，我們將人員按照阿里技術水平首先分層，按照簡單的評級標準： - 初中級：對應技術等級4-5 ，初級專員、高級工程師，可以完成簡單的業務需求，，在有較好較完整的項目基礎上可以復制粘貼代碼； - 技術專家：對應等級6-7，資深工程師、技術專家，可以完成項目的完整開發，獨立的完成技術攻關，項目的整體把控，和其他職能共同推進項目； - 高級專家&&資深專家：對應等級8-9 ，可以組織團隊或者搭建平臺，完成團隊目標，進行項目立項等。 - 研究員：對應阿里10，對應的為公司技術總監。 那么進行分層之后，對應能力的人就應該做對應的事情，而不是全部按部就班的做常規業務，在其他方向毫無建樹。同樣，在職能方向上，每個人也應該有其可以管轄和請教的上下級。在每個員工的技術等級晉升通道上，為其準備較為詳細的技術棧的補充以及提升的機會。 ## 研發分層 很早之前有分析過，實際公司研發人員達到一定規模，項目達到一定的復雜度，具體的研發任務會分層。簡單的可以分為業務以及技術基礎建設，復雜的會分為業務組，技術基礎建設組，架構組。 **其中業務層：** 主要負責依賴于基礎建設的部分，完成業務開發，要求對業務邏輯更加清楚。 **基礎建設層：** 主要是根據業務提煉技術方向的基礎平臺和組件部分，前端服務部分，也可以做一些對開發流程有幫助、優化的工具。 **架構層：** 主要是進行技術的預研究，大型技術架構的整理與搭建，時興技術的學習與成品演示。 然而就算這樣分層，其實其具體的工作還是分不開的，不太可能有些人只做業務或者架構，也和大家的職業訴求有關。比較好的融合是每個人的各個層次的工作都有涉及，只是比重不同。就結果論導向而言，是需要各個層次有其對應的負責人，首先保證技術成果，業務成果，然后是盡可能的滿足大家每個階段對技術的成長、使用的需求。 ## 與其他職能耦合關系 ### 與后端 主要體現在后端提供業務需要的數據接口或者業務邏輯接口。所以開發開始之前會有詳細的接口評審，接口文檔約定，數據的mock部分。 而后端除了這部分工作，還有的工作是提供微服務，以及支撐業務的底層服務。 ### 與產品 恐怕與產品溝通最多的是前端了，這里溝通的部分主要工作會分為以下幾種： 1 ui驗收，符合設計稿，ui驗收有時候也會與設計師溝通。 2 交互驗收，保證用戶體驗，也可能是與交互設計師、測試溝通。 3 性能，尤其用戶高頻頁面，保證用戶在各種條件下的性能包括顯示速度、動畫、延遲等。 4 兼容問題，需要知道產品對兼容性的要求 5 功能開發以及驗收，主要是與需求對應，主要是產品驗收 ### 與測試 1 確認測試用例范圍以及細節 2 測試用例的自我測試以及與測試的對照，寫對應的自測報告 3 測試階段的測試以及驗收，可以抽樣檢測 4 不同測試環境以及不同功能的回歸測試 5 測試的常識：測試問題分類，以及對應不同問題的處理方案，責任問題鑒定以及分工 ### 與設計 1 確認ui效果，包括基本效果以及交互效果 2 確認需要從設計中獲取的素材 3 確認需要從設計中年獲取的樣式代碼 4 與設計統一ui標準，減少重復工作量，約定組件標準以及可復用組件 ## 大前端團隊矩陣 ### 業務模塊設計 包括分業務線的模塊，以及二級業務線的關系 ### 前端底層服務 包括公共ui組件，前端服務比如圖片上傳，自動部署等，性能監控 ### 研究院 主要是做架構層的工作，預先完成需求的技術攻關，項目的長久規劃，解決歷史債務以及未來的技術儲備問題。 ### 內部工具展示層 比如除了基本業務之外，很多內部工具包括前端、后端、測試、ui甚至客服、銷售的系統都是需要界面，而需要界面就需要前端完成。 ### 網關&&bff架構 主要負責前端為主的產品接口集中管理，安全性校驗。 其中BFF架構主要是為客戶端，h5,pc等前端產品提供專業化的接口服務，其主要工作是根據微服務完成接口整合和數據整合，讓其更符合前端業務和交互的需求需要。 ## 人員歸屬方式 ### 資源池 如果按照資源池的形式，是最符合人員層次以及大前端團隊的矩陣的，可以最大程度的實現價值最大化，以及充分利用人員資源，也可以抽調部分人完成較大的技術突破，同時也可以較好的完成前端內部職能的技術溝通以及學習。 缺點：對業務會相對不夠清楚，尤其是業務模塊沒有固定歸屬，隨機分配的時候。所以針對這種情況，建議分業務流分模塊分配具體的人，其次針對每個業務都設置ab角色。 ### 項目組 按照項目組的優勢就是人員可以長期投入到項目中，對項目以及業務流要較大的熟悉，更容易形成與其他職能的默契協作。 缺點：資源不能更好的集中使用，對技術的視野也會因為這個受限。對其他人的業務范圍以及技術細節并不清楚。建議，即使按照項目團隊，也要在職能角度，讓一些人有公共的上級可以進行職能的輔助以及考核。 ## 其他 待續 。。。。。。