写点什么

一名优秀的技术 Leader 是如何炼成的?

发布于: 1 小时前
一名优秀的技术Leader是如何炼成的?

开篇

相信大部分人对于团队管理和技术管理在认知上,存在一定隔阂,无形之中会将【管理岗】和【技术岗】进行对立比较。

在国内一些大研发团队,一般会同时设置两类角色来更好地做团队运行管理。

  • 研发经理/总监,主要负责团队价值输出和业务目标管理;

  • 技术 Leader/架构师,主要负责技术攻坚和技术架构落地。 

曾子曰:“吾日三省吾身”,反思是人类进化出来的一项异常宝贵的能力。

我个人在工作中带团队也有四年多的时间,本文结合本人自身一些浅薄的技术管理认知,跟大家聊一下一名优秀的技术 Leader 是如何炼成的,为有意向将技术 Leader 作为发展目标的同学们做个参考。

是否需要一个技术 Leader?

首先,第一个问题:我们是否需要一个技术 Leader?

也许会有人反对这个角色,并觉得优秀的开发人员可以自己做出决策,并做好部分技术 Leader 的工作。

即使存在以上这些完美的情况,在团队成员间公开谈论彼此,在达成一致同意的解决方案之前讨论利弊,这些种种工作 vs 利益间微妙的平衡,或许需要技术 Leader 这样的一个角色。

我觉得不应该关注于这个角色是否应该存在,而最好将思考的重点放在这个职责可能会带来的价值收益上。

技术 Leader 与每个领导职位一样,糟糕的领导者会使事情变得更糟。

技术 Leader 需要具备什么能力?

可以明确的一点是:一个合格的技术 Leader 有责任来帮助团队的进步

作为该角色的人员,他应该具有非常不错的技术视野/经验以及良好的沟通技巧。他对项目或产品的技术方向负责(准确地说是对结果负责),并作为跨团队沟通的首选人。

对于大中型团队而言,Tech Leader 主要的职责包括:

1)指导项目的技术设计及制定开发规范

例如。我们将使用什么技术,我们将如何交付项目,我们将使用哪些模式等。

2)分析风险和跨功能要求

分析风险意味着降低风险:我们可以选择某种方法,还是说有太多未知数。

在承担一定风险时,对项目的影响是什么?例如。介绍您在会议上看到的新技术。

3)指导/教练经验不足的新人

很可能在你的团队中有不同的经验的同学。一旦谈到项目成本,考虑匹配技能和经验时,它就变得很有意义。因此,需要重视对经验不足新人的培养。

4)关注跨团队协助与沟通

一个项目团队包含各个相关联角色群体,研发、测试、产品、运营甚至需求业务方等等,其他角色同学可能在技术上不如开发人员,他们将使用不同的语言,技术 Leader 将需要关注于这一点,并做好协调与沟通。

如何做一个优秀的技术 Leader?

正如职位所描述的那样,技术 Leader 是一份包含技术和管理双重责任的工作,准确地说应该是:先技术,后领导

那在实际工作过程中,需要注意做好哪些点呢?

1)倡导技术创新与变革

倡导技术创新与变革,建立积极的思维模式。

当一个流程缓慢或者繁琐时,要尝试去改变它,使其变得更好。这样做的一种方法是使用 OODA 循环:

  • 观察(Observe)

  • 定位(Orient)

  • 决定(Decide)

  • 行动(Act)

为了正确观察缓慢或繁琐的流程细节,最好的方式就是成为其中的一员(例如:著名的“现场主义”),并体验与团队中其他人一样的痛苦。

你应该采取一种不断改善某种状况的心态。日本称之为“Kaizen”(改善法,其起源于丰田公司在生产、机械和商务管理中持续改进的管理法)。

在我们的研发过程中,希望改进的是团队的效率和乐趣,以及软件项目的最终交付。

2)坦然面对失败与成功

  • 事情有可能会失败,不用过分担心失败

技术方案落地可能失败,项目开发建设可能失败、部署上线可能失败、系统重要监控点可能被遗漏、系统宕机崩溃可能会发生。如果你已经为失败做好了十足的准备,那么应该会比较容易应对。

当事情失败时,不要寻找责怪的人!你是技术 Leader,有承担的责任和义务。

花费你的精力来解决手头的问题并从中吸取教训。当然,不要在一个坑里摔倒两次,如果你需要经历两次相同的失败来解决同一个错误,那么你应该是做出了错误的决定。从失败中汲取教训,将塑造您的方向,并在未来做出更好的决策。

  • 学会为成功喝彩

当团队有成就感时,成员们会感受到快乐,同时积极的情绪会让后面的工作尽可能做到最好。庆祝阶段的小成就非常重要,例如成功地冲刺或完成的功能。

当有人想出一个新想法时,也许是他们在会议上看到的一种方法或框架,如果这个想法得以实现,重要的是任何带有新想法的人都应该被认可。这是非常有益的,将带来更多的合作,创造力和开箱即用的思维。

形式也许没那么重要,一顿小午餐,也许是一个团队建设都是一个很好的想法,同样可以凝聚一个快乐和积极的团队。

3)保持技术

技术主管有很多非编码职责,但不要忽视实践技术活动是非常重要的:

  • 编写代码,进行概念验证,定义接口等

根据团队的成熟程度,您的参与会有所不同。

  • 进行代码 CR,并审核自己的代码。

当新人参与项目时,我倾向于进行大部分代码审查,而且我会非常严格:我会编写导致 NullPointerExceptions 的测试,我会要求他们遵守惯例,使用单一责任原则,小心包装和命名等。我还将详细说明这些评论的推理和所做出的选择。这可能会挑战现有的工作方式并提高代码库的成熟度。他们必须做的更改(审核后)将很快变得更少。

  • 明确技术愿景目标,并同团队分享。

不同的公司、业务、产品线,对技术的要求也许不同,但是对于技术的思想是相通的。需要有能够实操的能力,而不仅仅停留在纸面上,技术还是要解决实际问题来落地。

关于技术愿景目标,这一点需要符合客户的需求。通常情况下,客户的需求并不是完全与技术规划相一致,其实更多的时候,还需要自己发现、创造机会,来争取提升能力。尝试让团队成员参与到技术规划中来,并确保他们知道如何为实现这一目标而做出贡献。

  • 密切关注代码的演变过程

一段时间后,您所做的实际编码量可能会更低,但您需要及时了解代码的演变。您需要了解系统及其技术限制。

实际工作中,大多数的研发人员将乐于定义框架,提倡某些方法等。但是,一些非功能性需求(也称为质量属性)(如网络,安全性,部署和一致性)经常被忽视。

4)良好的时间管理

作为技术 Leader,您其实应始终为整个团队服务。其中包括:提问、支持、指导或做出决定。

  • 技术设计:为团队(包括您)准备工作。确保清楚需要实施什么以及如何实施。这通常会考虑很多质量属性,如网络,安全性等。

  • 业务:与客户交谈,查看他们的需求和目标,并将这些与项目的技术愿景相匹配。

  • 项目管理:定义用户故事,估算,跟进。

  • 代码:编写代码,进行代码审查等。

对于每个人和每个项目,分配的百分比显然会有所不同。及时查看并 Review 实际开发情况也很重要,因为这些可以帮助您了解所花费的时间。

5)成为团队导师

  • 调解员:技术主管应该是调解员,便于讨论。当人们有不同的意见时,你应该接受这一点。因为这意味着他们足够关心某些事情来讨论它。最后,我们朝着同一个目标努力。每个人都可以从别人的意见中学习。获得团队的意见并尝试达成共识。如果达成共识真的不可能并且需要做出决定,那就做出决定。不决定总是会引发更多的讨论。

  • 导师:技术主管应该是开发人员的导师,当老师。当您查看代码或解释某些约定时,请务必清楚地解释您为何以特定方式执行某些操作的原因。

  • 有效的授权:一段时间后,您的团队将采用某些最佳实践,并且需要较少(严格)的审核或更多人将进行审核。在这一点上,您还可以向更多开发人员提供用户故事的所有权。通过将所有权转让给开发人员,他们将非常积极地做好工作。技术主管不应该试图承担所有责任。技术主管需要确保某人承担责任。

  • 匹配目标:将开发人员的个人目标与项目和组织的更大目标相匹配。这是专门针对性的动态指导。动态,因为目标可以改变。在匹配目标时,沟通非常重要:它会让人感到受到重视。

  • 针对小组进行优化:团队中的个人非常重要,但是当难以找到共识时,您应该关注的是团队。合作良好的团队将表现得更好,表现良好的团队成员是快乐的成员。


一个好的技术 Leader,需要具备以下判断:

  • 知道什么时候给予输入

  • 知道何时做出决定

  • 知道什么时候退后一步,让团队获得更多的所有权

  • 分担责任,给予所有权,但同时要保持负责。

6)学会做评估

霍夫施塔特定律:即使考虑到霍夫施塔特定律,它也总是比你预期的要长。——Douglas Hofstadter


项目工时评估很难,如果你经常这样做,你会变得更好,但你仍然会有可能犯错。

作为技术 Leader,可能需要在团队实际需求开发之前进行预估,更便于了解实现成本及优先级的安排调整。

为了达到这个目的,我建议使用三点估计:做一个乐观的(Optimism 简称:O),一个最好的猜测(Best Guess 简称:BG)和一个悲观的估计(Pessimism 简称:P),并使用这个公式:

(O + 4BG + P)÷ 6 //得到加权平均值
复制代码


掌握评估是一生的旅程,它会让你与众不同。合作方会将你与专业、稳定和高质量的工作联系起来。

7)擅长与外部沟通对接

项目中的非技术人员使用的语言可能与开发团队的语言是不同的。技术 Leader 必须找到一种以非技术人员可以理解的方式交流思想的方法。与客户密切合作,尝试从他们那里检测需求,并不断地将他们的需求与正在进行的实施相关联。

这在 DDD (领域驱动设计)世界中,这意味着建立一种连接上下文通用语言。


作为技术 Leader,在外部沟通合作中作为关键联系人,与其他技术 Leader 的沟通协作同样也不可或缺。

有很多理由将自己与其他技术 Leader 联系在一起。

  • 在个人层面上,它提供了向同行学习的机会

他们如何为团队提供意见,以及他们如何在角色的不同职责之间分配时间。

  • 在组织层面,应该考虑到是否有明确理解的总体目标

跟进技术架构设计的落地非常重要,以确保您的产品能够很好地与其他组件一起使用,并确保更大的系统保持一致。有可能依赖于其他团队的产品或其他团队的成员,要确保在编制项目排期时考虑到这些因素。

这种协调在较大型的团队或项目时是一个真正的问题,投入一些时间是必要的,以避免超出您的控制范围的意外。

总结

作为技术 Leader,也许除了以上列举的几项内容之外,还存在其他很多软性的素质能力。

所谓:“欲求木之长者必固其本, 欲求流之远者必浚其源”,说的主要就是以下两点:

  • 业务感知的背后, 是对商业社会的理解, 是对需求的洞察;

  • 人员培养激励的背后, 是对人的理解, 是对人性的洞察。


拥抱文化差异,多样性非常宝贵。所有人都不同,过着不同的生活。

总结就是:每个人都是团队的一员,应该重视每个人的意见。

因为你团队的力量不是单个成员的才能,而是他们的合作,坚韧和相互尊重的整体效能的体现。

如果十个同学中有一两个因为你的指导,在职业生涯上突破了自己的一些瓶颈,那已经作为技术 Leader 能实现的巨大成就了。


希望今天的讲解对大家有所帮助,Thanks for reading!



发布于: 1 小时前阅读数: 16
用户头像

坚持分享接地气儿的架构技术文章! 2018.02.26 加入

同名微信公众号「架构精进之路」,专注软件架构研究,技术学习与职业成长!坚持原创总结、沉淀和分享,希望能带给大家一些引导和启发,感谢各位的支持(关注、点赞、分享)!

评论

发布
暂无评论
一名优秀的技术Leader是如何炼成的?