[TOC] ## 前言 本文主要借鑒宋小菜的大前端的部門結構以及一些分享列出可參考內容。 ## 基本認知 ### 鏈路足夠長，就可以出工具 鏈路足夠長，每個節點都可以變成產品，必要時可以通過技術的手段形成工具。 ### 以人為核心的做事 創業公司的技術團隊本質就是人和事，用合適的人做合適的事就能得到理想的效果，人才的瓶頸是公司產品落地速度和質量的瓶頸。 之前的管理 ，如果一視同仁，對于人員過于扁平化，大家做一樣的事，認為能力是一樣的，培養或者基本不培養能力，關心或者不關心興趣方向，跟進相同的業務線或或者隨機分配，技術人員經過1-3年的職場工作之后就會對技術缺乏初心，覺得在公司受到了極大的限制or瓶頸。那么公司的技術團隊就會不斷的流失人才，而留下來的員工或者是按部就班的做事并不能發揮額外的價值，或者是公司做一定的改革或者變更團隊的人事任命。 ## 團隊管理 ### 人才梯隊層次 基礎架構，基礎建設，業務上層 ### 人才成長規劃 興趣棧，能力棧，公司關系 ### 人才能力拓展 單人能力和團隊能力形成互補 ## 梯隊講解 ### 架構 技術最專精，有豐富的項目經驗（不局限于當前項目），技術采用前衛的技術，為公司提供技術儲備 ### 技術基礎建設 采用穩定成熟的技術成果，盡量減少風險技術、兼容成本技術，上手難度高的技術 ### 業務層 可以用技術基礎建設解決80%以上的風險和問題，具有一定的底層開發能力，如果沒有，需要進行系統的培訓，開發演練，注意事項等。（可以讓實習期或者試用期的人常嘗試開發歷史項目），這就要求再之前的開發中保留某階段開發的產入和產出，這樣可以通過這段的適應以及無風險常識，更早的暴露問題。 ## 技術選型結果 ### 工具類 依賴node ；周邊mongodb,redis,mysql,shell,python ### 業務類 強依賴react/react native ,適度集成其他技術，比如redux,graphql,apollo ### 框架類 react，其他的會謹慎，node端會有koa,thinkjs,eggjs 配置文件可以使用某模塊的配置，尤其不同配置的情況，減少人為的修改失敗 。 ## 組件庫 分為基礎組件 業務組件 盡量脫離或者團隊內禁止使用第三方庫，如果使用的話 進行使用約定，對于每個組價進行詳細的編寫約定。花費足夠的時間去討論組件是夠是合理的，有用的。 ## 其他 node可以做接口聚攏或者接口拆分，實現基于頁面的api優化 通用的工具技術方案 通用的技術模塊和業務模塊 團隊整體問題解決套路：解決問題的思維方式