方丈的寺院

V1

2022/05/26阅读:31主题:默认主题

技术管理之目标设定

背景

新晋管理者总是手忙脚乱的。领导管你要技术规划;一堆业务需求提过来了,如何判断做不做,任务应该分配给谁;原来和组里同事都是平级,现在我是领导了,好像有几个人不太服,我该怎么处理呢。千头万绪,第一件该干的事就是设定团队目标。

Why

为什么优先是设定团队目标呢?因为晋升为管理者之后,你就不再是大头兵了,你不再是一个人冲锋陷阵了,你是带着一组人去冲锋了,没有目标,技术人就是工具人,被动接受他人输入。找不到工作价值。没有意义和使命感,工作都是浑浑噩噩的。

没有目标,你不知道你团队需要多少人,应该申请多少hc?团队重心在哪?怎么排兵布阵?

没有目标,就是一堆人拼凑在一起,劲使不到一起。说散就散。没有任何凝聚力。

How

目标设定,业界比较通用的就是OKR,从我的实践经历来看,非常好用。

目标定义

O就是Object,目标。目标的输入来源一部分是技术团队自上而下的拆解,一部分是关联业务方的支撑。如果两个都没有输入,纯自己设定,即无中生有(阿里P8的能力模型)作为新晋管理者,如果你接手的是这样一团队,建议有合适机会就跑路,这绝对是个烂摊子,持续不久。最近互联网公司大裁员,这种情况绝对是第一梯队的。因为技术团队是支撑团队,解决问题的。现在连问题空间都没有,怎么定义问题,解决问题。

目标的输入来自他人,但是定义却是你自己,你设定的目标首先应该是你想去的地方,你想带领团队完成的。

目标调整

作为技术,经常头疼的一个问题是业务经常调整来,调整去。刚设定好的目标,过了2月就变了。之前的设定都白费了,所以有些人就想干脆别设定了。这样就是因噎废食了。业务经常变,那我们就在其中找不变。找底层逻辑。比如业务开发团队可以设定 代码质量、性能指标、系统稳定性等技术指标。也可以设定提升研发效能、优化系统架构、解决历史债等架构指标。同样作为业务技术团队,还可以设定提升项目管理能力、提高业务sense等指标。 把这些作为团队的内核。

但是公司不是白养技术的,技术目标是要围绕业务目标,要不然你述职、晋升时也会被挑战。此外业务不问题,有些员工焦虑感很强,觉得是白忙,瞎忙。觉得代码质量是提升了,但是业务不做了,代码都要下线了。这些工作都白费了。这是很常见的问题,那么如何解决呢?

这个需要从3个方面解决

  1. 设定技术目标时要贴合业务,这要求管理者必须深入到业务,知道哪块业务有长期价值,是公司重点投入对象,那么你的专业目标也是围绕着这块优先落地。
  2. 抽象,剥离业务属性,比如我在微服务如何划分一文中介绍的,你的技术目标应该设定在基础能力、核心领域层,而不是在应用系统上
  3. 和组员多沟通,统一思想,业务的成功不代表技术的成功,技术要有自己的价值,同样业务失败并不代表技术要走人。通常公司某块业务不做了,程序员不会被裁掉,而是调到其他部门。这就是技术人的可迁移能力,不能换了业务就不会做了。学习的技能在新的业务就找不到落脚点了。退一步讲,即使业务不做了,公司裁员了,设定的技术目标也是有利于组员能力成长,能帮助组员去找到一份更好的工作。

目标衡量

目标衡量就是KR,Key Result。限定时间内,完成哪些工作。这些工作怎么被衡量。

KR有什么特点呢

时效性

KR是对O的拆解,是检查和监控我们如何达到目标的标准。所以必须是相关的。KR完成了理论上讲O能完成,但是实际不一定。因为通常O是指引,是个长远目标,指导行动的。但是KR是半年/一年,一个考核周期内要完成的事。

比如你的目标是提升研发效率,当前影响研发效率的可能是应用启动优化。你们组负责的应用有10个,在一个考核周期你可以只能完成部分应用启动优化。你的KR就是完成5个核心应用,启动时长<3分钟,提效50人日。

明确可衡量

所以KR必须要非常明确,不能笼统。比如提高单测覆盖率就不对,必须是提升某某模块单测覆盖率从XX到YY

目标传达

目标设定好了,一定要拉组员一起通晒,而不是直接拆解,让组员负责具体工作。因为团队里每个人都需要非常清楚团队的目标,知道团队要往哪里去。此外这也是一个收集信息的好机会,看看大家有什么困惑,建议,想法,都在一起聊聊。 同时向团队成员传达你对团队的期望,统一阵型,打造开放的文化。之后团队成员再了解了整体方向后,在不影响你的排兵布阵情况,可以让他们适当选择自己感兴趣的方向承接,达到双赢。

分类:

后端

标签:

后端

作者介绍

方丈的寺院
V1