技术管理的抓手

lupkpu9

背景

随着团队规模逐渐增长，管理者对具体事情的涉及越来越少，团队里面很多人甚至一个月都说不上几句话。由于精力不够，对细节的关注变得不可能，同时过多关注细节，会导致对全局类的事情关注不够，反而造成更大的危害。

而此刻往往会伴随着巨大的不安全感：

• 团队在好的方向走，还是坏的方向走？
• 代码质量怎么样？
• 系统稳定性怎么样？
• 大家的工作效率怎么样？
  9 G1 y+ V* v3 s

完全不了解！！

抓手

在公司里面频繁听到『抓手』这个词，之前每次听到总是很懵逼。最懵逼的是在职级答辩的时候，被问到做某件事情的『抓手』是啥。距现在大约半年过去了，才大概理解一点点『抓手』的含义。

百度百科里面的解释：

“抓手”的原义是指人手可以把持（抓握）的部位，只要把手“抓”在上面，人便有了依托，有了凭借，如果没有“抓手”，某些活动和工作就无法开展。买电视机，纸箱上有“抓手”。乘公共汽车，车厢里有“抓手”。

由此联想到工作中，很多工作细节繁杂多变，问题层出不穷。想解决问题又无从下手。而这个时候，若有一个地方被你抓住之后，从这一点发力，就可以把事情往自己想要的方向推进。

『抓手』就是『提纲挈领』的『纲』。

技术管理的目的

管理就是通过别人拿到结果。而管理的两个着眼点就是：成事、育人。把事情搞定，把人培养起来，团队就带起来了。

涉及到技术，成事可以拆分成：工程质量和工程效率。

由此，技术管理关注三件事情：

• 工程质量
• 工程效率
• 人才培养
  9 N0 r  ^7 I0 v4 E, M4 Y- S

下面从这三个方面来分析一下抓手

工程质量的抓手

服务的SLA

服务的稳定性、延时等等指标需要有统一的标准。

例如，低于4个9，TP99超过1s的服务，需要有单独的报表统计，需要每天邮件发出。提醒当前服务处于亚健康状态，甚至已经出现问题。

故障数量

定期统计故障数量，每个故障都有详细的casestudy。故障密集出现的服务凸现出来服务质量有问题。

代码质量

千行代码bug数量。分子是QA测试出的bug数量，分母是RD开发的代码总行数。相除得到该指标。

可以更快速反馈每个人的代码质量。从而把bug消灭于前期。

业务指标

从业务也就是从结果的角度考察，识别出系统的异常。尤其是多个服务之间交互的异常。例如：支付成功率、下单成功率等等

工程效率的抓手

效率不好衡量，就如同不能用工作时长来衡量工程师的产出一样，也不能使用代码行数来衡量工程师的产出。

惯用手段还是需要对当前项目拆分出明确的里程碑，给出合理的排期。然后看执行的过程：

• 若有延期，需要有充分的理由
• 若有失误，需要有详尽的复盘
• 若有临时性需求，需要扛得住压力
  

最终看按时交付的比例。

其他也有一些指标来作为参考：

• 修复bug的数量
• 响应紧急需求的数量
  + S8 m# I# h5 Q8 R

人才培养的抓手

人才培养是最困难的环节。

• 首先，改变一个人本身就非常困难，很多时候是需要挑选愿意改变自己的同学
• 其次，培养的周期特别长，很有可能半年才会看到效果
• 最后，每个人的个性不一样，欠缺的点各不相同，由此需要增强的地方也不相同
  

由此，人才培养的抓手需要从特别抽象的地方用力：

• 复盘：定期复盘总结的习惯是个人快速成长的必由之路。可以通过『日报/周报的感想部分』作为着手点，强迫同学养成定期复盘自己的工作的习惯
• 输出：优秀的人才都会做高质量的输出。一方面融会贯通，另一方面形成自己影响力。高质量的wiki + 分享 的数量也是抓手。
• 新人培养计划：对于新人，培养计划是很好的加快融入以及严格考核的工具。这个在上篇文章中详细介绍过。
  - k1 y# I7 R/ \% i& n# \7 w

正因为人才培养成本极高，需要先筛选出一小部分人来重点培养。忌讳平均用力。针对有潜力的同学：

• 定期one by one聊天，解答困惑，会少走很多坑。
• 分配有挑战的工作，加速成长。一年遇到了别人十年遇到的困难，而且都高质量的克服了，成长速度就是别人的10倍。
  5 X# w( M9 D/ G2 `1 o. H

后记

管理不仅仅需要思路，重点还在于高质量的执行。执行落地的过程需要倾注自己大量的心血，是对心力很大的考验。

" X* Z! l  h" F* O3 U
2 M* U$ T# Z' l4 R7 X5 a  W. l2 J

cichishia

管理不仅仅需要思路，重点还在于高质量的执行