如何成为一名前端组长？

本文介绍: 但是重心变了，以前得靠自己的一行行代码来体现价值，而需要将自己的能力转化成别人的能力，通过团队来完成最核心事情，如果还是万事靠自己，一切都亲力亲为，那样肯定是不行的。但是转换到技术管理者，真正的技术开发工作只是自己工作的一小部分，因为即使你的技术能力再优秀，也不可能完成所有的事情的，相反，自己有更多更重要的事情要去完成。从开发人员-＞技术管理者，工作内容已经不仅仅是实施开发了，帮助团队成员成长，发现团队的问题，修正团队的方向，才是技术管理者最核心要做的事情，最重要的转变是思维的转变。

我认为要管理好前端团队：
本质上：让团队少走弯路，并引领团队走在正确的道路上。
理念上：让团队高效工作、快乐工作。
实施上：要想尽办法给团队、给成员赋能。
个人角度：
角色转变，开发人员 -&g t; 技术管理者
需要对团队的产出结果负责，对团队成员的成长负责。
从开发人员-＞技术管理者，工作内容已经不仅仅是实施开发了，帮助团队成员成长，发现团队的问题，修正团队的方向，才是技术管理者最核心要做的事情，最重要的转变是思维的转变。

作为一名开发人员，对代码逻辑，细节斤斤计较，对代码严苛，对结果负责，这是非常优秀的品质。
但是转换到技术管理者，真正的技术开发工作只是自己工作的一小部分，因为即使你的技术能力再优秀，也不可能完成所有的事情的，相反，自己有更多更重要的事情要去完成。当你专注于代码的细节，逻辑的细节，很容易会陷入一种思维死胡同，失去对大局的把控。

重心转变，靠自己 -&g t; 靠他人
从开发人员 -&g t; 技术管理者，形式上我认为没有太大变化也还是要经常关注技术，经常写代码。但是重心变了，以前得靠自己的一行行代码来体现价值，而需要将自己的能力转化成别人的能力，通过团队来完成最核心事情，如果还是万事靠自己，一切都亲力亲为，那样肯定是不行的。遇到团队问题可以用沟通解决的一定不要自己动手，动手自己干了，团队就没成长了。时间要多花在培养人上，和团队成长上。

当你还是个人贡献者时：
有问题 ==&g t;自己动手 ==&g t;解决

而你是管理者时，你的能力要求，完全发生了变化：
有问题 &g t;分析问题、解决问题&g t;分配问题 ==&g t;跟踪问题 ==&g t;解决问题

保持自我成长，提升综合能力
作为前端组长，必然是需要提高自己各方面的能力，来胜任这样的角色
1、技术能力：这是技术管理者的立身之本，肯定需要不断精进，如果技不如人，是无法服众的
2、业务能力：对业务有正确的理解，能理解到业务的本质需求，才能让技术实现价值
3、规划能力：技术管理者需要明确团队目标，并以结果为导向，做出合理的规划，如：

技术体系规划：项目技术选型，技术文档沉淀等等。
任务规划：根据任务难易程度分配不同开发人员，任务时间安排等等。
人员安排规划：根据组员的实际情况和特点，安排合适的事情给合适的人做，使团队利益最大化。
4、沟通协作能力：技术管理者不仅在项目团队内，可能还需要跨组甚至跨部门进行沟通协作，技术管理者需要转达上级战略，战术和任务，不仅需要跟开发人员沟通清楚你需要什么，还要沟通清楚你为什么要这么做。
5、判断能力：技术管理者需要全局把控项目，并且有底气在项目当中对于事项进行判断和决策。如：
风险判断：业务实现方向有问题，任务排期超时等等。
决策判断：某个时间段，应该做哪些内容，哪些做不了等。
技术判断：实现成本，实现方向，针对业务评审的具体实现判断等。
6、领导力：技术管理者需要有责任，有担当，团队有问题，必然反映到团队负责人身上有问题。
7、架构能力：治理好系统复杂度才是最务实的。

严格要求自己，以身作则
作为团队负责人，要正确传达价值观，以身作则，做好榜样，一个团队的状态如何，往往从团队负责人的状态就能直观的看的出来

3、团队角度
1.** 建立良好的团队氛围和价值感**

鼓励知识创作，知识分享，技术沉淀，这样可以促进团队成员的个人成长和业务上的开发能力。
加强团队的沟通合作，可以是定期的复盘会，代码评审会，技术问题的讨论，提升团队的沟通氛围。
营造学习进步氛围，可以自上而下的提供一些学习知识和分享（告诉大家先进的、流行的是什么样子，开阔视野）。
周期性的一对一沟通和指导。作为技术管理者很重要的一点在于为团队内的其他成员服务，了解他们的诉求，分析他们阶段性的问题，了解他们的职业规划，并帮助他们去解决和落实，所以周期性的一对一沟通是很有必要的，将你看到成员问题及时反馈出来，并且给出指导建议，对于团队成员的成长是非常有利的

2、团队基础建设

落实公司内制定的前端开发规范，发掘目前还欠缺的地方，确认可行后去落地并推广。
规范＆文档：规范意味着标准，是整个团队的共识。而文档可用来记录团队的技术沉淀，达到信息共享的目的。
完善前端监控和告警系统，保持项目线上稳定运行，出现问题易于追踪。
代码 code re view，发现并解决潜在的问题，带领团队成员攻克难点并持续把控代码质量。
对于可抽象可复用的逻辑或组件，可以提取出来作为团队的基础资产，并可共享出来，让公司内其他需要的项目组也可以用。

3、合理的人员分配

类别	定义
优秀的工程师	技术优秀，认同公司目标，有很强的自驱力，喜欢发现问题，解决问题
有一定工程师思维的潜力程序员	认同公司目标，有很强的自驱力，技术尚在快速成长期
有一定工程师思维的普通程序员	认同公司目标，有很强的自驱力，技术潜力一般
熟练的程序员	技术比较扎实，但是没有太多工程师思维
普通程序员	技术一般，也没有太多工程师思维

不同的成员类别采用不同的策略管理

类别	应对策略
优秀的工程师	让他承担更多的责任，负责更多的事情（比如负责一大块的技术架构），提供更多的资源
有一定工程师思维的潜力程序员	提供更多专业的指导和更大的舞台的参与关键项目，在技术上严格要求，从代码细节抓起，提供更多的资源。
有一定工程师思维的普通程序员	让他们负责一些技术难度不高但要求非常严谨认真的工作，提供一定的指导，不用给太多压力，让他们慢慢成长。
熟练的程序员	更对地要去提升他的思考方式（非技术），需要谨慎考虑他的潜力和价值比，在思考方式没有提升前，可能只能去做一些相对独立，对团队协作要求不高的工作。可以让他们在技术上给新员工做出指导，但不能是思考方式。
普通程序员	维持现状，无资源倾斜。