七年前端，如何做好一个team leader

一、前言

为什么走上这条路？

那是一个悲伤的故事。22年8月，被裁，之后就走上了漫长的仲裁之路。

被裁后，调整了一周心态，开始了为期一个多月的疯狂的面试，打破自己最高记录，一天7家。

在大学期间，在学生会干了两年；在毕业第一份工作中，做过半年TL。在现在的这家公司，才有了这么一次机会。

二、作为leader的工作内容

1、业务开发

为什么还在开发业务？

1. 目前团队就4个人，需求量也不小，需要站出来承担一定的工作量；
2. 熟悉业务的最快方式，个人理解还是开发。一行一行的敲出来业务流程，不熟悉都难；
3. 需要把持住代码质量。平日的CR比较片面，在开法过程中，才能更详细的理解成员的代码；

2、人员调配

1. 需要根据成员个人的特性、擅长的事、经验、个人技术水平，来安排不同的工作内容；
2. 保障每周每个人都有事可做，不能有人做了一个项目后，处于闲置状态；

3、各环节撕逼

前端常涉及到的其他人员，产品、设计、后端、测试，有的还涉及到其他项目组提供的组件或者api。

当意见不统一的时候，就需要撕逼了。

当然，这里的撕逼，不是为了甩锅而甩锅，而都是为了能把项目做好，为了能把KPI完成。

友情提示：撕逼请勿上头，都是为了工作。

1. 比如和UI
   非要让你实现比较费时费力的效果，但是目前的工作量大，不允许浪费时间在这个上面，你就需要用自己的三寸不烂之舌头来说服他们。
2. 比如和后端
   一个post，非要在url上携带参数，明显事后端大佬们想懒省事。
3. 比如测试
   人提的bug多了，你的绩效肯定不合格，需要和测试沟通好提bug的数量标准

4、承上启下

1)-承上

领导们是不会盯着每个开发的，他们不知道每个人的进度，也不关心；不知道每个人诉求；

这个时候，作为小组leader的功能就需要呈现出来了，你需要汇总当前各个模块的进度，总结团队需要领导支撑的地方，然后汇总给领导。

2)-启下

有些时候，领导讲的事，下边人不一定能理解，或者就是领导单独给你讲的，这时，就需要leader把领导的意思转化为工作，分配到具体的人，并且持续跟踪进度、难点，及时反馈。

5、保障项目可持续发展

保障项目稳定的同时，需要保障项目使用的技术，项目的代码，项目的结构，足够清晰明了，要不然时间一长，就是屎。

1. 保障技术符合主流，不必最新
2. 保障readme和注释
3. 保障业务代码不混乱

需要code review来保障代码质量

6、一起进步

成员上班，要么是为了钱，要么是来养老，要么是为了学技术，作为一个没有权利的leader，你能为大家做的，就只有技术提升。

1)-深度

搞点技术文章，搞点技术培训，小群里时不时聊聊技术问题

2)-广度

带领探索一些新颖的技术，使用新技术做一些项目、工具之类；
再不济，如何讲现有的烂项目做好，也是个大学问

3)-其他本领

比如ppt，不可否认，除了极个别真正搞技术的人，其他大多数，也是需要讲ppt的，写好，讲好一份ppt，考验的点也不少。

比如团队协作沟通。江湖不是打打杀杀，是人情世故。

比如独立负责。总归有些项目，是需要一个负责的，一个人负责，可不仅仅是开发完就可以的，需要文档，需要进度掌控，需要难点攻克等等

三、如何提升自己

尽快掌握业务流程
使用技术手段，解决业务痛点
依葫芦画瓢，别人公司有的，看看能不能搬过来自己牵头搞
和各流程保持紧密联系

四、感悟

• 不要以来就着急做成绩，能保障业务稳步进行就行
• 完成自己的kpi，吹出去的牛，总归还是要实现的，要不转正都是事
• 稳定之后，开始整合公司难点，挑容易的搞，可以最快的出成绩
• 做成绩的时候，不要就自己做，尽可能带着组员们，一是可以推动个人成长，二是可以在合作中尽快的熟悉对方。