技术管理入门-目标设定
Posted 方丈的寺院
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了技术管理入门-目标设定相关的知识,希望对你有一定的参考价值。
背景
新晋升为管理者总是手忙脚乱的。领导管你要技术规划;一堆业务需求提过来了,如何判断做不做,任务应该分配给谁;原来和组里同事都是平级,现在我是领导了,好像有几个人不太服,我该怎么处理呢。千头万绪,第一件该干的事就是设定团队目标。
Why
为什么优先是设定团队目标呢?因为晋升为管理者之后,你就不再是大头兵了,你不再是一个人冲锋陷阵了,你是带着一组人去冲锋了,没有目标,技术人就是工具人,被动接受他人输入。找不到工作价值。没有意义和使命感,工作都是浑浑噩噩的。
没有目标,你不知道你团队需要多少人,应该申请多少hc?团队重心在哪?怎么排兵布阵?
没有目标,就是一堆人拼凑在一起,劲使不到一起。说散就散。没有任何凝聚力。
How
目标设定,业界比较通用的就是OKR,从我的实践经历来看,非常好用。
目标定义
O就是Object,目标。目标的输入来源一部分是技术团队自上而下的拆解,一部分是关联业务方的支撑。如果两个都没有输入,纯自己设定,即无中生有(阿里P8的能力模型)作为新晋管理者,如果你接手的是这样一团队,建议有合适机会就跑路,这绝对是个烂摊子,持续不久。最近互联网公司大裁员,这种情况绝对是第一梯队的。因为技术团队是支撑团队,解决问题的。现在连问题空间都没有,怎么定义问题,解决问题。
目标的输入来自他人,但是定义确实你自己,你设定的目标首先应该是你想去的地方,你想带领团队完成的。
目标调整
作为技术,经常头疼的一个问题是业务经常调整来,调整去。刚设定好的目标,过了2月就变了。之前的设定都白费了,所以有些人就想干脆别设定了。这样就是因噎废食了。业务经常变,那我们就在其中找不变。找底层逻辑。比如业务开发团队可以设定 代码质量、性能指标、系统稳定性等技术指标。也可以设定提升研发效能、优化系统架构、解决历史债等架构指标。同样作为业务技术团队,还可以设定提升项目管理能力、提高业务sense等指标。 把这些作为团队的内核。
但是公司不是白养技术的,技术目标是要围绕业务目标,要不然你述职、晋升时也会被挑战。此外业务不问题,有些员工焦虑感很强,觉得是白忙,瞎忙。觉得代码质量是提升了,但是业务不做了,代码都要下线了。这些工作都白费了。这是很常见的问题,那么如何解决呢?
这个需要从3个方面解决
-
设定技术目标时要贴合业务,这要求管理者必须深入到业务,知道哪块业务有长期价值,是公司重点投入对象,那么你的专业目标也是围绕着这块优先落地。 -
抽象,剥离业务属性,比如我在 微服务如何划分一文中介绍的,你的技术目标应该设定在基础能力、核心领域层,而不是在应用系统上 -
和组员多沟通,统一思想,业务的成功不代表技术的成功,技术要有自己的价值,同样业务失败并不代表技术要走人。通常公司某块业务不做了,程序员不会被裁掉,而是调到其他部门。这就是技术人的可迁移能力,不能换了业务就不会做了。学习的技能在新的业务就找不到落脚点了。退一步讲,及时业务不做了,公司裁员了,设定的技术目标也是有利于组员能力成长,能帮助组员去找到一份更好的工作。
目标衡量
目标衡量就是KR,Key Result。限定时间内,完成哪些工作。这些工作怎么被衡量。
KR有什么特点呢
时效性
KR是对O的拆解,是检查和监控我们如何达到目标的标准。所以必须是相关的。KR完成了理论上讲O能完成,但是实际不一定。因为通常O是指引,是个长远目标,指导行动的。但是KR是半年/一年,一个考核周期内要完成的事。
比如你的目标是提升研发效率,当前影响研发效率的可能是应用启动优化。你们组负责的应用有10个,在一个考核周期你可以只能完成部分应用启动优化。你的KR就是完成5个核心应用,启动时长<3分钟,提效50人日。
明确可衡量
所以KR必须要非常明确,不能笼统。比如提高单测覆盖率就不对,必须是提升某某模块单测覆盖率从XX到YY
目标传达
目标设定好了,一定要拉组员一起通晒,而不是直接拆解,让组员负责具体工作。因为团队里每个人都需要非常清楚团队的目标,知道团队要往哪里去。此外这也是一个收集信息的好机会,看看大家有什么困惑,建议,想法,都在一起聊聊。 同时向团队成员传达你对团队的期望,统一阵型,打造开放的文化。之后团队成员再了解了整体方向后,在不影响你的排兵布阵情况,可以让他们适当选择自己感兴趣的方向承接,达到双赢。
以上是关于技术管理入门-目标设定的主要内容,如果未能解决你的问题,请参考以下文章