技术管理中的抓手

今天的文章是我个人对过去6,7年技术管理经验的一个简单总结，每一个点都经过我的实践，并试图找到一些可供参考的方法，特别感谢过去帮助我的朋友和前辈们，文中提到很多方法也来源于他们。

技术管理的不安全感

技术管理的一大特点就是必须要深入到技术细节中去，在我刚做技术经理时，那时候团队还在10人的规模，团队成员用的框架或者工具都是我亲自搭起来的，而且我还有时间亲自上阵写代码，所以，细到项目中每一行代码，我都能清楚的了解，每个组里同事每天完成的工作我都可以做到亲自过问一遍，细节把控自然不在话下。

然后当团队扩大后，我需要投入更多精力到全局上，需要花更多的时间做好对内对外的沟通上，和产品及业务方对产品进行更深入的研究，还需要花更多时间在招人上面，我逐步发现我已经不能像过去一样，把细节掌握得那么清楚了。

此刻，在我内心里产生了明显的不安全感：

• 团队在好的方向发展，还是往坏的方向倒退？

• 大家的代码质量怎么样？

• 系统稳定性怎么样？

• 大家的工作效率怎么样？

可以使用的抓手

对技术团队而言，涉及到我们日常的研发流程，可以简单归纳为：工程效率和工程质量。说到这两点，我一直认为这绝非简单是开发工程师或者测试同学的事，而是整个技术团队共同要为之努力的事情。

接下来讲讲这两件事，分别有哪一些抓手：

工程效率的抓手

对于技术管理者，需要带领团队对当前的各个项目进行有效的拆分，并明确对应的里程碑，给出合理的排期。

对项目进行分析：

• 若有延期，需要有充分的理由

• 若有失误，需要有详尽的复盘

• 若有临时性需求，需要扛得住压力

其次，关注工程效率的指标

• 按时交付的比例，分析每个月发布的项目中的交付率。

• 处理线上bug的时效，是否能及时修复

• 响应紧急需求的时间，能否快速实施

最后，团队自动化的应用比例，是否建立起有效的自动化测试+发布+报警体系

工程质量的抓手

1. 建立业务指标

服务的稳定性、延时等等指标需要有统一的标准。例如：支付成功率、下单成功率等等

例如，对于每天对外暴露的API调用情况，需要有单独的报表统计，如果发现问题，需要及时响应和处理。

2. 控制故障数量

每周和每月统计故障数量，每个故障都有详细的总结和回顾。故障密集出现的服务凸现出来服务质量有问题。

3. 关注代码质量

每次提测后发现的bug数量，包含bug的分布和等级，更快速反馈团队每位同事的代码质量，控制bug的发生趋势。

梯队建设的抓手

人才培养是技术管理中一大难点

• 首先，改变要一个人本身就非常困难，所以从面试环节，就需要挑选愿意改变自己的同学

• 其次，培养的周期特别长，很有可能半年才会看到效果

• 最后，每个人的个性不一样，欠缺的点各不相同，由此需要增强的地方也不相同。

由此，人才培养的抓手需要从以下地方入手：

• 定期复盘：定期复盘的习惯是个人快速成长的必由之路。可以通过『周报的个人反思』作为着手点，让团队养成定期复盘自己的工作的习惯

• 技术输出：让团队中的优秀成员将项目中的经验和好的实践记录下来，达到融会贯通的效果，建立团队的技术影响力，例如高质量的wiki + 定期的技术分享也是抓手。

• 新人培养计划：对于新人，培养计划是很好的加快融入以及严格考核的工具。

人才培养成本极高，绝对不要期望一下子将团队中的每个人都向上拉一层，需要先筛选出一小部分有潜力的成员来重点培养，努力将他们变成团队中的中坚力量，形成人才梯队。具体的做法如下：

• 定期1V1的聊天，解答困惑，指出他们的不足，给他们更有效的工作方法。

• 不断分配有挑战的工作，加速成长，让团队充满饥饿感。

最后

技术管理就是带着大家将项目通过技术落地，并拿结果。而管理的两个着眼点就是：成事、育人。把事情搞定，把人培养起来，团队就带起来了。

描二维码或手动搜索微信公众号【架构栈】：ForestNotes

欢迎转载，带上以下二维码即可

              

点击“阅读原文”，所有【架构栈】近期的架构文章汇总

↓↓↓