大前端团队介绍

最后更新于:2022-04-02 05:26:51

## 前言 随着前后端分离,前端越来越多的承担着产品开发的工作,而且更多的涉及产品逻辑尤其是页面之间的逻辑以及关联,而后端从繁杂的页面逻辑中脱离出来,更多的是会开发微服务的部分,当然过度阶段,后端还会写为某些页面服务的接口代码,我们称之为胶水代码。 ## 人员能力分层 首先不可避免的前端技术人员会出现能力的差别,从入门级别的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角色。 ### 项目组 按照项目组的优势就是人员可以长期投入到项目中,对项目以及业务流要较大的熟悉,更容易形成与其他职能的默契协作。 缺点:资源不能更好的集中使用,对技术的视野也会因为这个受限。对其他人的业务范围以及技术细节并不清楚。建议,即使按照项目团队,也要在职能角度,让一些人有公共的上级可以进行职能的辅助以及考核。 ## 其他 待续 。。。。。。
';