您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 其他 > 正文

如果我是一线技术Leader……

发表于:2019-05-06 作者:谦行 来源:阿里技术

技术主管和团队成员应该是什么关系?只能是普通的领导与被领导的关系吗?如果,你作为一个一线技术主管,你会怎么管理团队?


今天我们试试换位思考,假设自己是技术主管,反推团队成员如何做事才能获得更好的成长。

如果我是一线技术主管,那我可能是团队曾经综合实力最强的,我可能会被时间支配而不能再天天写代码,并且,团队充满各种挑战。

如果我是一线技术主管,依然是每周要写周报,每年要写绩效,想晋升,想加薪、想人生巅峰等等。

如果我是一线技术主管,在团队只有五、六个人的情况下还好,如果是十几个人的团队的话,会希望有人可以站出来帮我。

如果我是技术主管,我更希望:

不抱怨


如果我是一线技术主管,我不会喜欢团队有喜欢抱怨的同学:

  • 主管每天也很忙,听抱怨很消耗时间。
  • 团队有人抱怨,说明团队自然是有问题了,需要花一定的时间梳理出问题,需要及时给出解决方案,甚至要安抚对方情绪。
  • 一个喜欢抱怨的人会影响整个团队的士气。

其实大部分开发抱怨的工作内容很相似,团队成员不配合做事,PD 提了无理的需求等。

大促中我们的后端主管说了些很好理解的话:“看到大促有这么多问题,我很激动,这种情况很好。

问题越多说明机会越大,如果都是稳定健壮的系统、完善的流程、合作良好的团队,那么,要大促 PM 干什么呢?”

如果问题都是机会的话,那就没有抱怨的必要。但是,如果真的就是有问题,还不能说了吗?


向上管理


一个管理十几人的团队主管很难有精力做到面面俱到,去了解所有人的细节,给大家找出合适的方向和机会,甚至认真读完每个人的周报都要用一个下午,很难做到你有一个不错的想法的时候,主管就有时间找你聊聊。

如果我是一线主管,我更希望团队同学主动找我聊。作为主管每天既要处理大量一线信息,又要领导团队做出正确的决策,还要照顾团队的每个成员,做出健康的梯队建设计划等,大部分人是没有这个精力的。

刚开始工作的时候,我们误解主管和下属的关系就是领导与被领导的关系,但其实主管也需要被下属管理,这也就是“向上管理”的由来,简单来讲就是主管也需要下属的协助和推动。

主管大部分时间很忙,这就要求下属在向上管理的时候要尤其注意高效、有质量的沟通,如果我是一线主管,我更希望团队和我交流的方式是让我做选择题、判断题,而不是问答题、思考题。

很多鸡汤文提到老板训斥高管:我请你来不是告诉我为什么不行,而是告诉我怎么实现我的构想。

在主管不是拍脑子就做的决定的时候,困难肯定是已经想过了,更希望得到的是下属的帮助。

如果我是一线主管,我希望下属这样帮助我:

  • 主动承担团队面临的挑战,给出合理的解决方案。
  • 及时向我反馈经过整理的信息和数据,甚至是结论,辅助决策。
  • 主动关心同事,组织学习,帮助大家(包括我)进步成长。

除了面对面的交流,和主管最多的沟通机会可能就是周报,这是向上管理的重要途径,然而很多同学把周报当做一种负担,写的极其敷衍,就是一周的流水账,发送出来都是浪费自己和收件人的时间。

团队不会有人认真读完所有人的周报,读谁的取决于周报的质量。个人习惯粗略浏览组内所有人周报(周报有 highlights 多重要),坚持几周就能识别一些需要关注的周报。

然后会针对这些人的周报设置邮件规则,必须认真看的,遇到不理解的还要过去问的,其他人的周报就被自动过滤掉了。

一个普通员工都是如此,更何况一线主管。可见这么写周报可能在无意中浪费了许多次向上管理的机会。


每天忙不完的业务怎么办


还有一种抱怨的声音是:自己每天很辛苦,想拼命忙完业务后做一些技术的东西,造个轮子什么的,但一个需求还没做完,另外一个需求就安排过来了。

如果我是一线主管,我会把团队面临的问题分一下级:

  • 重要&紧急,不能按时完成,则都是失败。
  • 重要不紧急,是个很好的机会。
  • 技术想法,很好的撬动业务的点。
  • 单分析只是个业务需求,看不出明显的兴奋点。

团队的人可能也有几种特性:

  • 能力强,在某领域是专家。
  • 能力一般,有潜力,但是非常有积极性。
  • 能力一般,主动性一般。

其实不用特意说明就知道大部分主管分配任务的思路:

  • 重要&紧急的事情只能交给能力强的人去做,意愿上如果有问题,也要说服对方去做,因人成事,可见能力强有多重要。
  • 重要不紧急的事情就可以借事修人,如果做得好,这个人以后就有信心了,团队多了一员干将,做不好也有能力强的人给保底,不会造成业务问题。
  • 技术想法也可以交给有积极性的人做,这必然占用一些时间,那么这个人手头上无关痛痒的事情只好交给能力一般,主动性一般的人来做。

实际上按照这个向上管理的思路,需要主管去分配任务的时候,你就已经输了,甚至主管来找你问进度的时候也已经输了。

当然每个合格的主管都需要发现、解决团队人才培养的问题,不可能放任问题发生。


什么样的人有积极性


能力强的人很好识别,那什么样的人才是有积极性的,看过一个 AE 快速升 P8 的同学写的文章,他有个很好的习惯:无论大小难易,永远不满足于做出来指定的事情,一定要给人惊喜。

如果我是一线主管,我不会凭空把一件重要的事情交给某个人去做,我会更期望:

  • 团队同学来教育我某件事情很重要,想去尝试。
  • 在很多微不足道的小事情上做出了惊喜,有理由相信这件更大的事情也可能做出惊喜。
  • 我被分配了纯业务事情怎么办?

上面也提到了简单分析只是业务需求,近五年在阿里看见了太多事在人为的案例,每个人身边肯定也有不少这样的案例。

我们以为自己在做业务,很多时候是因为两个误区:

  • 这不是技术项目:没有什么所谓的技术项目,所有的技术项目除非是显而易见的项目,否则肯定脱胎于业务。

只有业务一线的同学才可以抽象出来,做业务需求不是坏事情,拿着完成任务的心态做业务才是最要命的。

  • 没目标:所有做的事情都要契合自己的目标,而自己的目标大部分时候应该和团队目标 Match。

今天让我开发一个前端组件,我要看到的是这个需求反映了我营销体系对某个分类能力的缺失,需求归纳到我营销可视化体系完善的目标中,在阿里这种人才济济的环境中目标不清晰的人和咸鱼没什么区别。


怎样才算业务负责人


很多小伙伴已经是实际的业务负责人,和三、四个小伙伴一块解决特定业务领域问题。

但尴尬的是级别相同,在分配任务的时候会不好意思,觉得对方也有自己的"技术项目"要做,我得求他把这个业务需求做一下。

这种其实不算真正的业务负责人,如果业务负责人仅仅是分配任务,那么任何人辛苦一些都可以做。

业务负责人的核心特质应该是有一条是了解业务的发展、引导相关人的个人目标。

这样可以把业务需求转换成每个人目标中的一环,和上面提到的自己做事情思路是一样的,无非就是写代码的那个人不自己。

其实即使主管也不可能命令团队成员去做某事,采用命令那样的方式,团队早晚散伙。

最后,如果我是一线技术主管,我希望团队的业务负责人时刻在两个方面提醒自己:可衡量、可体系化。