一、前言
为什么走上这条路?
那是一个悲伤的故事。22年8月,被裁,之后就走上了漫长的仲裁之路。
被裁后,调整了一周心态,开始了为期一个多月的疯狂的面试,打破自己最高记录,一天7家。
在大学期间,在学生会干了两年;在毕业第一份工作中,做过半年TL。在现在的这家公司,才有了这么一次机会。
二、作为leader的工作内容
1、业务开发
为什么还在开发业务?
- 目前团队就4个人,需求量也不小,需要站出来承担一定的工作量;
- 熟悉业务的最快方式,个人理解还是开发。一行一行的敲出来业务流程,不熟悉都难;
- 需要把持住代码质量。平日的CR比较片面,在开法过程中,才能更详细的理解成员的代码;
2、人员调配
- 需要根据成员个人的特性、擅长的事、经验、个人技术水平,来安排不同的工作内容;
- 保障每周每个人都有事可做,不能有人做了一个项目后,处于闲置状态;
3、各环节撕逼
前端常涉及到的其他人员,产品、设计、后端、测试,有的还涉及到其他项目组提供的组件或者api。
当意见不统一的时候,就需要撕逼了。
当然,这里的撕逼,不是为了甩锅而甩锅,而都是为了能把项目做好,为了能把KPI完成。
友情提示:撕逼请勿上头,都是为了工作。
- 比如和UI
非要让你实现比较费时费力的效果,但是目前的工作量大,不允许浪费时间在这个上面,你就需要用自己的三寸不烂之舌头来说服他们。 - 比如和后端
一个post,非要在url上携带参数,明显事后端大佬们想懒省事。 - 比如测试
人提的bug多了,你的绩效肯定不合格,需要和测试沟通好提bug的数量标准
4、承上启下
1)-承上
领导们是不会盯着每个开发的,他们不知道每个人的进度,也不关心;不知道每个人诉求;
这个时候,作为小组leader的功能就需要呈现出来了,你需要汇总当前各个模块的进度,总结团队需要领导支撑的地方,然后汇总给领导。
2)-启下
有些时候,领导讲的事,下边人不一定能理解,或者就是领导单独给你讲的,这时,就需要leader把领导的意思转化为工作,分配到具体的人,并且持续跟踪进度、难点,及时反馈。
5、保障项目可持续发展
保障项目稳定的同时,需要保障项目使用的技术,项目的代码,项目的结构,足够清晰明了,要不然时间一长,就是屎。
- 保障技术符合主流,不必最新
- 保障readme和注释
- 保障业务代码不混乱
需要code review来保障代码质量
6、一起进步
成员上班,要么是为了钱,要么是来养老,要么是为了学技术,作为一个没有权利的leader,你能为大家做的,就只有技术提升。
1)-深度
搞点技术文章,搞点技术培训,小群里时不时聊聊技术问题
2)-广度
带领探索一些新颖的技术,使用新技术做一些项目、工具之类;
再不济,如何讲现有的烂项目做好,也是个大学问
3)-其他本领
比如ppt,不可否认,除了极个别真正搞技术的人,其他大多数,也是需要讲ppt的,写好,讲好一份ppt,考验的点也不少。
比如团队协作沟通。江湖不是打打杀杀,是人情世故。
比如独立负责。总归有些项目,是需要一个负责的,一个人负责,可不仅仅是开发完就可以的,需要文档,需要进度掌控,需要难点攻克等等
三、如何提升自己
尽快掌握业务流程
使用技术手段,解决业务痛点
依葫芦画瓢,别人公司有的,看看能不能搬过来自己牵头搞
和各流程保持紧密联系
四、感悟
- 不要以来就着急做成绩,能保障业务稳步进行就行
- 完成自己的kpi,吹出去的牛,总归还是要实现的,要不转正都是事
- 稳定之后,开始整合公司难点,挑容易的搞,可以最快的出成绩
- 做成绩的时候,不要就自己做,尽可能带着组员们,一是可以推动个人成长,二是可以在合作中尽快的熟悉对方。