成为优秀 Tech Lead 的 12 个提示

原文链接：Twelve tips to become an awesome Technical Lead

什么是 Technical Leadership？

一个 Technical Lead 有责任来帮助团队前进。作为该角色的人员，他/她应该具有非常不错的技术方面的经验以及强大的沟通技巧。他或她将对项目或产品的技术方向负责，并作为跨团队沟通的首选人。

对于大中型团队而言，有一位全职的 Tech Lead 在场，负责重要的领导方面的活动，诸如：

指导项目的技术愿景

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

分析风险和跨功能要求

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

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

教练（Coaching）经验不足的人

你很可能会在你的团队中有不同的经验的人。一旦谈到项目成本，混合和匹配技能和经验时，它就变得很有意义。也因此，需要培养经验不足的人。

利益相关者和团队之间的沟通

业务利益相关者通常在技术上不如开发人员。他/她们将使用不同的语言，Tech Lead 将需要关注于这一点。

我们需要一个 Technical Lead 吗？

有人反对这个角色，并声称一个运作良好的开发人员团队可以自己做出决策，并优先考虑重要的工作。即使存在这些完美的条件，在此期间团队成员公开谈论彼此，在达成一致同意的解决方案之前讨论利弊，也不需要花费太多时间来破坏这种微妙的平衡。

Technical Lead 就是这样的一个角色。而不是关注于角色是否应该存在，最好将重点放在确保满足所有 Technical Lead 的职责上。与每个领导职位一样，糟糕的领导者会使事情变得更糟。有了如下的这些提示，我想帮助您确保不会发生这些。

两个故事

正如职位所暗示的那样，Tech Lead 是一份混合责任的工作：技术和领导。我将分享双方的提示，尽管区别并不总是很清楚。这些方面不太可能平分秋色。关于这一点内容，可以看提示 4。

Techn Lead 提示 1： 倡导变革

倡导变革，意味着安装竖立起积极进化的思维模式。当一个流程缓慢或者繁琐时……，要尝试改变它，并使其变得更好。这样做的一种方法是使用 OODA 循环：

• 观察（Observe）
• 定位（Orient）
• 决定（Decide）
• 行动（Act）。

PS：有关OODA的更多信息，请参见此早期博客文章。

为了正确观察缓慢或繁琐的流程，重要的是成为团队的一员，并体验与团队中其他人一样的痛苦。你应该采取一种不断改善某种状况的心态。日本称之为“Kaizen”（改善法，其是起源于丰田公司在生产、机械和商务管理中持续改进的管理法）。在我们的案例中，您希望改进的情况是团队的效率和快乐感，以及软件项目的交付。

去寻找妨碍良好团队合作的问题。

Techn Lead 提示 2： 经历失败和成功

事情会失败

事情会失败。不要过分担心失败。构建将失败。部署将失败。时间表将被遗漏。崩溃将会发生。如果你为失败做好准备，那么应该更容易应对。

当事情失败时，不要寻找责怪的人。你是 Tech Lead。承担责任，用你的精力来解决手头的问题并从中吸取教训。当然，不要两次修复同一个 bug。如果您需要两次修复相同的错误，那么你应该是做出了错误的决定。

从失败中汲取教训，将塑造您的方向，并在未来做出更好的决策。

庆祝成功

当团队有成就感时，他们会感到快乐和积极，尽可能做到最好。庆祝较小的成就非常重要，例如成功的冲刺或完成的功能。我做过一次项目，在那里我们交付了一个系统，客户对它非常满意……不幸的是，客户的愿景发生了变化，项目从未投入生产。如果那是你等待的那一刻……

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

星期五晚上喝一杯，一顿小午餐，也许是一个团队建设都是一个很好的想法，可以让一个快乐和积极的团队。哦，这很有趣。

Techn Lead 提示 3： 保持技术

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

• 编写代码，进行概念验证，定义接口……根据团队的成熟程度，您的参与会有所不同。
• 进行代码审查，并审核您的代码。当新人到达项目时，我倾向于进行大部分代码审查，而且我会非常严格：我会编写导致 NullPointerExceptions 的测试，我会要求他们遵守惯例，使用单一责任原则，小心包装和命名等。我还将详细说明这些评论的推理和所做出的选择。这可能会挑战现有的工作方式并提高代码库的成熟度。他们必须做的更改（审核后）将很快变得更少。
• 确保技术愿景存在，并由团队共享。这一愿景需要符合客户的需求。客户需求将导致重要的限制，例如。关于重用（一个一次性的营销项目与多年的企业努力……但要注意这种类型的约束也可能会改变）。分享您与团队实现这一愿景的方式，将会对其采用产生巨大影响。尝试让团队参与到技术愿景中。并确保他们知道他们如何为实现这一愿景做出贡献。
• 密切关注代码的演变：一段时间后，您所做的实际编码量可能会更低，但您需要及时了解代码的演变。您需要了解系统及其技术限制。

大多数（如果不是全部）开发人员将乐于定义框架，提倡某些方法等。但是，一些非功能性需求（也称为质量属性）（如网络，安全性，部署和一致性）经常被忽视。

Techn Lead 提示 4： 始终可用 （时间管理）

作为 Tech Lead，您应始终为您的团队服务；提问、支持、指导或做出决定。我开始写这篇博文时所说，Tech Lead 角色有两个重要方面，将这些结合起来绝非易事。对我来说很有意义的东西是写下你期望投入某些任务的努力量，例如：

• 技术设计 为团队（包括您）准备工作。确保清楚需要实施什么以及如何实施。这通常会考虑很多质量属性，如网络，安全性等。
• 业务：与客户交谈，查看他们的需求和目标，并将这些与项目的技术愿景相匹配。
• 项目管理：定义用户故事，估算，跟进。
• 代码：编写代码，进行代码审查等。

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

Techn Lead 提示 5： 成为团队的导师

• 调解员：技术主管应该是调解员，便于讨论。当人们有不同的意见时，你应该接受这一点。因为这意味着他们足够关心某些事情来讨论它。最后，我们朝着同一个目标努力。每个人都可以从别人的意见中学习。获得团队的意见并尝试达成共识。如果达成共识真的不可能并且需要做出决定，那就做出决定。不决定总是会引发更多的讨论。
• 导师：技术主管应该是开发人员的导师，当老师。当您查看代码或解释某些约定时，请务必清楚地解释您为何以特定方式执行某些操作的原因。
• 有效的授权：一段时间后，您的团队将采用某些最佳实践，并且需要较少（严格）的审核或更多人将进行审核。在这一点上，您还可以向更多开发人员提供用户故事的所有权。通过将所有权转让给开发人员，他们将非常积极地做好工作。技术主管不应该试图承担所有责任。技术主管需要确保某人承担责任。
• 匹配目标：将开发人员的个人目标与项目和组织的更大目标相匹配。这是专门针对性的动态指导。动态，因为目标可以改变。在匹配目标时，沟通非常重要：它会让人感到受到重视。
• 针对小组进行优化：团队中的个人非常重要，但是当难以找到共识时，您应该关注的是团队。合作良好的团队将表现得更好，表现良好的团队成员是快乐的成员。

一个好的 Tech Lead：

• 知道什么时候给予输入
• 知道何时做出决定
• 知道什么时候退后一步，让团队获得更多的所有权。

分担责任，给予所有权……但要保持负责。

Techn Lead 提示 6： 与其他/她 Tech Lead 相联系

有很多理由将自己与其他/她 Tech Lead 联系在一起。在个人层面上，它提供了向同行学习的机会：他/她们如何为团队提供意见，以及他/她们如何在角色的不同职责之间分配时间。在组织层面，您应该验证是否有明确理解的总体目标。如果是这种情况，您可能需要调查是否需要跨组织协调才能实现目标。跟踪架构指南非常重要，以确保您的产品能够很好地与其他组件一起使用，并确保更大的系统保持一致。有可能依赖于其他团队的产品或其他团队的成员。确保在编写冲刺时考虑这些因素。

这种协调在许多（较大的）组织或客户中是一个真正的问题。投入网络时间是必要的，以避免超出您的控制范围的意外。

Techn Lead 提示 7： 大处着眼，偏袒行动

大处着眼（Think Big）和偏袒行动（Bias for Action）是亚马逊十二项领导原则中的两项。

大处着眼，意味着为项目或产品创建和传达大胆的方向。它将激发结果，因为人们正在努力做大事。有所作为的东西。关注未来可能出现的机会。 做出不受限制的决定。Dave Gray的 Liminal Thinking 是一本很好的书。

偏袒行动，意味着承认许多行动和决定是可逆的，不需要进行广泛的研究。完成任务……很重要。当飞轮运动时，它会继续旋转。专注于简单的事情，让飞轮移动。它将鼓励人们在最初的障碍下进行交付。

Techn Lead 提示 8： 面试潜在的新团队成员

知道你面试的是什么。你是在寻找一个长期的人，还是在寻找一个短期任务的人？当你查看简历时，寻找模式：例如。任务的持续时间。这符合您的需求吗？如果没有，请确保您询问候选人是否有某些偏好。有些人喜欢长期项目，有些人则不喜欢。这不一定是阻塞问题。但这是值得讨论的问题。除此，请查看使用过的语言，库和框架。这些与您当前的选择匹配吗？当您在寻找长期的团队成员时，使用某些工具的经验不如意志、能力和学习的热情重要。我总是试图关注开发人员的心态：从逻辑上思考，确定解决某个问题的多种方法。就个人而言，我强烈反对使用 StackOverflow 查找问题。提出与您的项目相关的问题更为重要。我个人面试的模式如下：

• 安慰（Comfort）
• 提供选项
• 建立在回应上
• 展示兴趣
• 奖金问题

当然，总是保持礼貌。如果候选人与您的具体目标不符，请不要让他/她带着糟糕的感觉回家。

注意：即使我们没有时间，资源或影响来修复团队组成，我们仍然需要完成任务。

Techn Lead 提示 9： 拥抱文化差异

多样性非常宝贵。 所有人都不同，过着不同的生活。它非常有价值，因为您的用户也会有所不同。 用充满激情的人围绕自己。

如今大多数（如果不是全部）团队都使用某种即时消息。与不同时区的团队合作时，这变得更有价值，因为它可以实现异步通信并扩大潜在的答案。我之前提到过：每个人都是团队的一员，应该重视每个人的意见。

Techn Lead 提示 10： 评估很难

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

评估很难。如果你经常这样做，你会变得更好……但你仍然会不时地弄错。

在敏捷项目中，整个团队可以参加计划扑克会议（估点会议）。规划扑克可以在估计用户故事时暴露未知数。通常，有两种方法可以应对这些未知因素：在开始用户故事之前进行技术设计（例如，通过定义峰值）或接受风险，以及您的业务利益相关者。

作为 Tech Lead ，您可能还需要在团队实际构建某些内容或响应 RFP（请求提案）之前进行估算。这可以让业务利益相关者了解潜在成本，决定优先级或评估员工。

为了达到这个目的，我建议使用三点估计，你做一个乐观的，一个最好的猜测和一个悲观的估计，并使用这个公式：（O + 4BG + P）÷ 6 得到加权平均值。根据估算的性质，未知未知数的数量可能很大：项目可能与其他项目非常相似或完全不同。将这些考虑在内。对将要实施的团队进行估算：您可能正在估算一个真实的项目。在最好的条件下，这不是您可以做的事情的最快时间。估计代表了团队执行的能力；不是你自己实施的能力。还要确保，你知道你的可交付成果。这可能比代码和部署工具更多，例如。代码质量保证报告，使用手册，……

记录假设。

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

Techn Lead 提示 11： 与外部世界的接口

非技术利益相关者使用的语言可能与开发团队的语言非常不同。Tech Lead 必须找到一种以非技术人员可以理解的方式交流思想的方法。例如，通过使用类比和使用其他人可以轻易涉及的术语。

在 DDD （领域驱动设计）世界中，这意味着建立一种通用语言。

与客户密切合作，尝试从他们那里检测需求，并不断地将他们的需求与正在进行的实施相关联。

作为 Tech Lead，我认为您不应该是单点联系人。 因为那时你在项目中引入了潜在的责任：对你的强烈依赖。在某些讨论中包括您的团队，但请确保您防止团队成员持续中断……所以不要成为单点联系人，而应尽量成为第一联系人。

Techn Lead 提示 12： 促进（敏捷）团队工作

我会敦促所有 Tech Lead，促进敏捷团队的工作。当然，当涉及到业务时，这也会更好。但即使他们没有参与，也要指定代理产品所有者。这机会将是你。

无论你使用 Scrum，Kanban 或其他东西都重要，重要的是缩短开发周期，反馈循环等。

结论

你的团队的力量不是个人成员的才能。它是他们的合作，坚韧和相互尊重的功能。

如果您想了解有关 Tech Lead 的更多信息，可以在 Devoxx 上查看我在 SlideDeck 上的幻灯片或 YouTube 上的视频。