今天的文章是我个人对过去6,7年技术管理经验的一个简单总结,每一个点都经过我的实践,并试图找到一些可供参考的方法,特别感谢过去帮助我的朋友和前辈们,文中提到很多方法也来源于他们。
技术管理的不安全感
技术管理的一大特点就是必须要深入到技术细节中去,在我刚做技术经理时,那时候团队还在10人的规模,团队成员用的框架或者工具都是我亲自搭起来的,而且我还有时间亲自上阵写代码,所以,细到项目中每一行代码,我都能清楚的了解,每个组里同事每天完成的工作我都可以做到亲自过问一遍,细节把控自然不在话下。
然后当团队扩大后,我需要投入更多精力到全局上,需要花更多的时间做好对内对外的沟通上,和产品及业务方对产品进行更深入的研究,还需要花更多时间在招人上面,我逐步发现我已经不能像过去一样,把细节掌握得那么清楚了。
此刻,在我内心里产生了明显的不安全感:
团队在好的方向发展,还是往坏的方向倒退?
大家的代码质量怎么样?
系统稳定性怎么样?
大家的工作效率怎么样?
可以使用的抓手
对技术团队而言,涉及到我们日常的研发流程,可以简单归纳为:工程效率和工程质量。说到这两点,我一直认为这绝非简单是开发工程师或者测试同学的事,而是整个技术团队共同要为之努力的事情。
接下来讲讲这两件事,分别有哪一些抓手:
工程效率的抓手
对于技术管理者,需要带领团队对当前的各个项目进行有效的拆分,并明确对应的里程碑,给出合理的排期。
对项目进行分析:
若有延期,需要有充分的理由
若有失误,需要有详尽的复盘
若有临时性需求,需要扛得住压力
其次,关注工程效率的指标
按时交付的比例,分析每个月发布的项目中的交付率。
处理线上bug的时效,是否能及时修复
响应紧急需求的时间,能否快速实施
最后,团队自动化的应用比例,是否建立起有效的自动化测试+发布+报警体系
工程质量的抓手
1. 建立业务指标
服务的稳定性、延时等等指标需要有统一的标准。例如:支付成功率、下单成功率等等
例如,对于每天对外暴露的API调用情况,需要有单独的报表统计,如果发现问题,需要及时响应和处理。
2. 控制故障数量
每周和每月统计故障数量,每个故障都有详细的总结和回顾。故障密集出现的服务凸现出来服务质量有问题。
3. 关注代码质量
每次提测后发现的bug数量,包含bug的分布和等级,更快速反馈团队每位同事的代码质量,控制bug的发生趋势。
梯队建设的抓手
人才培养是技术管理中一大难点
首先,改变要一个人本身就非常困难,所以从面试环节,就需要挑选愿意改变自己的同学
其次,培养的周期特别长,很有可能半年才会看到效果
最后,每个人的个性不一样,欠缺的点各不相同,由此需要增强的地方也不相同。
由此,人才培养的抓手需要从以下地方入手:
定期复盘:定期复盘的习惯是个人快速成长的必由之路。可以通过『周报的个人反思』作为着手点,让团队养成定期复盘自己的工作的习惯
技术输出:让团队中的优秀成员将项目中的经验和好的实践记录下来,达到融会贯通的效果,建立团队的技术影响力,例如高质量的wiki + 定期的技术分享也是抓手。
新人培养计划:对于新人,培养计划是很好的加快融入以及严格考核的工具。
人才培养成本极高,绝对不要期望一下子将团队中的每个人都向上拉一层,需要先筛选出一小部分有潜力的成员来重点培养,努力将他们变成团队中的中坚力量,形成人才梯队。具体的做法如下:
定期1V1的聊天,解答困惑,指出他们的不足,给他们更有效的工作方法。
不断分配有挑战的工作,加速成长,让团队充满饥饿感。
最后
技术管理就是带着大家将项目通过技术落地,并拿结果。而管理的两个着眼点就是:成事、育人。把事情搞定,把人培养起来,团队就带起来了。
描二维码或手动搜索微信公众号【架构栈】:ForestNotes
欢迎转载,带上以下二维码即可
点击“阅读原文”,所有【架构栈】近期的架构文章汇总
↓↓↓