大前端团队规划蓝图

前言

随着前后端分离，前端越来越多的承担着产品开发的工作，而且更多的涉及产品逻辑尤其是页面之间的逻辑以及关联，而后端从繁杂的页面逻辑中脱离出来，更多的是会开发微服务的部分，当然过度阶段，后端还会写为某些页面服务的接口代码，我们称之为胶水代码。

人员能力分层

首先不可避免的前端技术人员会出现能力的差别，从入门级别的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架构

人员归属方式

资源池

如果按照资源池的形式，是最符合人员层次以及大前端团队的矩阵的，可以最大程度的实现价值最大化，以及充分利用人员资源，也可以抽调部分人完成较大的技术突破，同时也可以较好的完成前端内部职能的技术沟通以及学习。

缺点：对业务会相对不够清楚，尤其是业务模块没有固定归属，随机分配的时候。所以针对这种情况，建议分业务流分模块分配具体的人，其次针对每个业务都设置ab角色。

项目组

按照项目组的优势就是人员可以长期投入到项目中，对项目以及业务流要较大的熟悉，更容易形成与其他职能的默契协作。

缺点：资源不能更好的集中使用，对技术的视野也会因为这个受限。对其他人的业务范围以及技术细节并不清楚。建议，即使按照项目团队，也要在职能角度，让一些人有公共的上级可以进行职能的辅助以及考核。

其他

待续 。。。。。。