大前端组规划
1.人员能力分层
首先不可避免的前端技术人员会出现能力的差别，从入门级别到专家级别,很多公司或者领导会讲，实现扁平式的管理，但是这不等于所有人的能力是扁平的，更不意味着所有人最终是扁平的，责任和权限也是和能力挂钩的。
首先需要对人员进行分层，将人员按照技术水平首先分层，按照简单的评级标准：
后面可以根据公司的技术等级b1-b10划分对应的等级。
- 初中级：初级工程师、中级工程师，可以完成简单的业务需求，在有较好较完整的项目基础上可以复制粘贴代码；
- 技术专家：高级工程师、技术专家，可以完成项目的完整开发，独立的完成技术攻关，项目的整体把控，和其他职能共同推进项目；
- 资深专家：可以组织团队或者搭建平台，完成团队目标，进行项目立项等。
2.研发分层
公司研发人员达到一定规模，项目达到一定的复杂度，具体的研发任务会分层。简单的可以分为业务以及技术基础建设，复杂的会分为业务组，技术基础建设组，架构组。根据每个人擅长的东西，建立研发人员画像，划分项目归属 小程序 后台管理 可视化等
其中业务层： 主要负责依赖于基础建设的部分，完成业务开发，要求对业务逻辑更加清楚。
基础建设层： 主要是根据业务提炼技术方向的基础平台和组件部分，前端服务部分，也可以做一些对开发流程有帮助、优化的工具。
架构层： 主要是进行技术的预研究，大型技术架构的整理与搭建，时兴技术的学习与成品演示。
然而就算这样分层，其实其具体的工作还是分不开的，不太可能有些人只做业务或者架构，也和大家的职业诉求有关。比较好的融合是每个人的各个层次的工作都有涉及，只是比重不同。就结果论导向而言，是需要各个层次有其对应的负责人，首先保证技术成果，业务成果，然后是尽可能的满足大家每个阶段对技术的成长、使用的需求。
与其他职能耦合关系
与后端
主要体现在后端提供业务需要的数据接口或者业务逻辑接口。所以开发开始之前会有详细的接口评审，接口文档约定。
与产品
恐怕与产品沟通最多的是前端了，这里沟通的部分主要工作会分为以下几种：
ui验收，符合设计稿，ui验收有时候也会与设计师沟通。
交互验收，保证用户体验，也可能是与交互设计师、测试沟通。
性能，尤其用户高频页面，保证用户在各种条件下的性能包括显示速度、动画、延迟等。
兼容问题，需要知道产品对兼容性的要求
功能开发以及验收，主要是与需求对应，主要是产品验收
与测试
- 确认测试用例范围以及细节
- 测试阶段的测试以及验收，可以抽样检测
- 不同测试环境以及不同功能的回归测试
- 测试的常识：测试问题分类，以及对应不同问题的处理方案，责任问题鉴定以及分工
与设计
- 确认ui效果，包括基本效果以及交互效果
- 确认需要从设计中获取的素材
- 确认需要从设计中年获取的样式代码
- 与设计统一ui标准，减少重复工作量，约定组件标准以及可复用组件
3.人员归属方式
资源池
如果按照资源池的形式，是最符合人员层次以及大前端团队的矩阵的，可以最大程度的实现价值最大化，以及充分利用人员资源，也可以抽调部分人完成较大的技术突破，同时也可以较好的完成前端内部职能的技术沟通以及学习。
缺点：对业务会相对不够清楚，尤其是业务模块没有固定归属，随机分配的时候。所以针对这种情况，建议分业务流分模块分配具体的人，其次针对每个业务都设置ab角色。
项目组
按照项目组的优势就是人员可以长期投入到项目中，对项目以及业务流要较大的熟悉，更容易形成与其他职能的默契协作。
缺点：资源不能更好的集中使用，对技术的视野也会因为这个受限。对其他人的业务范围以及技术细节并不清楚。建议，即使按照项目团队，也要在职能角度，让一些人有公共的上级可以进行职能的辅助以及考核。
4. 制定规范
通过代码规范来约束开发人员，统一的编码规范对团队项目的长远维护不无裨益. 一致性的代码规范可以增强团队开发协作效率、提高代码质量、减少遗留系统维护的负担
制定代码规范，约束代码风格。
开发需求规范，版本规范，版本控制系统规范，git提交信息规范，定期code review。
流程规范，一切需求tapd建立，保证需求可追踪。
5. 员工状态
通过员工状态来把控资源池状况和获取计划性任务情况,营造技术氛围
- 通过晨会来把控开发人员工作状态
- 通过对应的TL获取开发人员工作状态
- 周一主动获取员工计划性的任务和工作状态
- 鼓励成员写技术博客，或者建立自己的团队专栏
- 新人培训，保证新人更快融入
