好的 Tech Lead 在做些什么？

原文链接：What Does a Software Tech Lead Do?

在软件开发组织层次结构中，Tech Lead 是一个相对较新的角色。当我第一次听到这个角色时，我的第一个想法是

它是软件架构师 + 团队的领导者吗？

我并不认为这个定义是正确的，但这是一个很好的思考方式。在这篇文章中，我将回顾我在该职位上的 3.5 年经验，其中包括：

• 领导 Atlassian Stride 的团队之一 —— 它是一个完整的团队沟通解决方案。在近两年的时间里，该团队拥有 5 到 10 名工程师。
• 领导 KPIdata —— 一个非盈利组织，开发用于获取基辅理工学院高等教育质量的软件。该团队扩展到 10 个核心成员（仅包括我自己的 3 个软件工程师），最终，180 多个个人贡献者帮助我们完成了项目。
• 领导由 4 名工程师（包括我自己）组成的团队在 Video Internet Technologies Ltd 进行视频管理系统集成（CCTV）。

请注意，相同职位在不同公司中可能有不同的职责。

查看博客文章的内容，了解我作为软件系统全职所有者的现实。我将详细说明了在技术主管职位上的利弊。

从实际的角度来看 - 该职位最关键的技能列表在博客的最后提供。

成为一名全职业主

我在这个职位上发现的第一件事是，现在我需要100％ 负责工程组织的一个篇章。关于这一点的好处 —— 新的篇章尚未生产任何东西。所以，任何来自先前维护者的遗留代码来支持和扩展。这一点相当的棒

然而，这不是通用的规则，每家公司都不同。我认为通常你有机会增强现有的软件系统，而不是从头开始创建。因此，请准备好对您的团队未启动和设计的项目负责。

成为全职业主意味着什么？

• 您收到的任务与特定的业务目标相关联。实际上，任务是项目。而且，可以部分地定义要求。您需要继续并找出所有要求和约束。您希望尽可能多地指定项目的预期结果，以防止范围蔓延。理解和定义最终目标是第一步。
• 您可以在时间/预算范围内为您做任何合理的事情来实现目标。这一点，我们将在下一节中详细介绍。
• 为实现目标而创建的软件的所有成功（和失败）都将与您相关联。如果您的系统中的某些内容被破坏或者无法正常工作 —— 它是您的责任和错误。在目标超出预期的情况下 - 干得好！不要忘记为你们的成功归功于团队。团队应得的。

工程中的创意空间

是的，您可以做任何事情来实现工程目标。以下是我能够改变或实施的事项列表。请注意，您应该从团队中获得支持，以使更改持续存在。人们制作软件。快乐的人制作可以工作的软件。

• 软件开发方法。很大程度上取决于项目的目标和截止日期。回答以下的问题，以进行相关的定义：
  • 迭代中有多少天？
  • 什么是规划过程？应该估算哪些任务？如何估算任务？
  • 我们是否应该接受迭代之内的需求变化？
  • 不同类型/优先级的任务有哪些规则？示例：无论严重性如何，必须尽快修复付费组件的所有错误。
  • 如何向组织的其他人演示？
• 项目的技术堆栈。它可以包括但不限于编程语言，框架，数据存储，库，监控解决方案。有时您会有一些来自公司政策，规定的预定义预设。对于我们的章节，堆栈如下：
  • Python 3，异步编程，asyncio
  • MySQL，Elasticsearch，Redis
  • AWS（EC2，RDS，ElastiCache，S3，SQS，CloudFormation，CloudWatch）
  • DataDog，Elasticsearch/Logstash/Kibana，ElastAlert，Splunk
• 软件架构。您可以定义软件系统的结构部分。你可以建立新的东西。您可以重复使用现有的公司内部或第三方服务。如果您是技术主管，那么设计不同组件之间的接口也是您的责任。玩得开心！
• 非功能性要求。它是关于定义足够好和完美软件之间的边界。我从未被鼓励做出理想的商业解决方案。通常，人们只需要一个稳定的解决方案来解决他们的业务问题。解决方案应该足够灵活，以便我们快速应用新的更改。对我而言，这意味着为工程师设定合理的期望，使企业满意。例如：
  • 该组件应该能够恢复数据库重启…
  • …但如果在60秒内无法建立连接 - 请提醒
• 内部里程碑。您可以为项目的不同阶段设置团队的重点，并为此定义可交付成果。
  • 例如，可以优化项目路线图，以便尽快在生产中使用系统版本来建立 CI/CD 管道，并确保您的想法主要起作用。
  • 另一个例子 - 你可以瞄准让你的队友尽可能自主（当你们在地理上分布时都是个好主意） - 然后你需要花更多的时间来计划定义独立的工作流。
• 服务水平指标。作为技术主管，您负责定义软件何时提供所需的服务质量。选择反映业务实际情况的正确指标至关重要，因为它为您的团队设定了目标以及工程改进的方向。以我的经验来看，相关的例子有：
  • 可用性。可以使用该服务吗？
  • 已处理的作业数。我们还需要这项服务吗？我们做了多少有用的工作？
  • 主要组成部分的成功率。——帮助我们看到中间层面的问题。
• 推出计划。它包括将软件部署到不同环境的频率。
  • 一旦拉出请求（Pull Request）合并
  • 或者每 4 个月发布一次。
• 通讯。团队如何就日常进展进行沟通？
  • 每天 30 分钟的视频通话两次
  • 文字站会每周一次（也许）
• 工作切分。如何分配 Jira 中的任务？
  • 您将每项任务分配给每位工程师，如果没有您的书面许可，他们没有任何机会进行更改（不是很好的策略）
  • 无论优先级和依赖性如何，每个人都可以执行任何任务
• 代码审查政策。应该由谁批准 Pull Request，以让创作者将其合并到 master ？选项：
  • 共识 —— 所有问题都得到了解答，所有默认审核人都批准了这些更改
  • 收到高级工程师至少 2 份批准才能继续
  • 我可以批准我的 PR，并在最后一次提交后 2 小时后部署
• 回顾会议（Retrospectives）。多久做一次？我的推荐是每 4 周一次，但我知道有些团队每 2 周做一次。顺便问一下，你经常这样做吗？

我省略了一些东西，所以随意添加你的想法作为评论。

Tech Lead 需要多技术？

我的任务是使团队能够为问题实施正确的解决方案。

你不会每天写很多代码

在我成为最近团队的 Tech Lead 之前，我所在小组的成员，大多数是超过 1.5 年的中级/高级软件工程师。对于我来说，获得异步编程、关系数据库和非关系数据库、即时消息传递和高负载系统所需的实践经验至关重要。

首先要让你的项目成功，为此你应该阅读更多的相关资料：

• 代码
  • 来自团队提出的 Pull Request。
  • 您的系统重用的解决方案。
  • 您需要使用的其他团队维护的第三方服务代码。
• 技术文档
  • 您可以重复使用的服务的说明（内部和第三方服务）。
  • 解决方案的实施细节。
  • 他们已知的问题（没有什么是完美的） - 了解风险并为他们制定缓解计划。

经过大量阅读后，你写一下：

• 工程建议 - DACI 是一个有用的框架。 我喜欢它。
• 提案确定后 - 设计页面。
• 最后的最后 - 工作内容的 tickets（我们团队使用的是 Jira）。

在写完之后 - 你讨论：

• 与您的成员达成有关非平凡任务的协议。
• 如果您有不完整的规范或没有提供所有数据源，请教育您的团队成员。
• 与其他团队谈判。
• 演示您的工作成果，并在公司内推广您的解决方案。

在一天结束时，您可能需要花费几个小时来做​​出个人贡献。对我来说，它类似于以下内容：

• 修补程序（Hotfixes）。当世界即将爆炸时，需要修复一些东西。
• 在不编写测试的情况下为 pull request 提供概念证明。之后，请团队成员将其转变为生产级软件。
• 提交数据库或配置更改。
• 调查在开发环境中，难以复制的奇怪错误。
• 从度量/日志记录解决方案中，提取一些数据以验证实现的想法。

我认为 Tech Lead 应具备扎实的实践软件工程经验，以便能够制定和支持合理的决策。

在小型团队（最多 3 个直接报告者）上，我认为仍然可以做出一些好的个人贡献。

在撰写本文时，我还没有发展出足够的工程领导能力，能够为更大的团队做出可持续的个人贡献。

成为 Tech Lead 的优缺点

优点：

• 您将成为项目领域的主题专家（subject matter expert）。
• 您完全了解软件系统的工作原理，以及如何以最小的风险将更改应用于该系统。您现在可以将其复制到其他系统。
• 您成为一名优秀的沟通者，因为您有责任了解需求并解释技术解决方案。
• 在软件开发的各个领域，你达到了某种程度的能力（但并不总是很高）：
  • 系统设计 - 构建您的软件，并在早期阶段验证所有风险。
  • 操作 - 保持系统正常运行。
  • 工程质量 - 防止损失贵公司的声誉。
  • 工程管理 - 将实施委派给您的团队甚至其他团队。

缺点：

• 在工作日结束时，你往往没有成就感。 你已经为你的团队创造了一些新的工作，解决了一些阻碍者，但它并不像真正的工作。
• 大型团队编码不够。
• 你是团队的入口。 您应该能够接受来自多个来源的任务：
  • 你的队友
  • 你的管理层
  • 合作团队
  • 客户支持团队
  • 其他人听说过你的团队
• 有时它很紧张，因为它有很多责任 最终，你应该学会如何处理所有这些。

我认为这个位置值得尝试，我很高兴我有机会担任该职位多年。 我会再做一次。

Tech Lead 入门包

如果您对 Tech Lead 职位感兴趣并希望为此做好准备，那么以下便是我在路径的最开始时发现的有价值的技能列表：

• 从技术栈中，熟练掌握编程语言 —— 能够做出良好的技术选择，并进行代码审查。使项目正确启动至关重要，因此您的编码技能可以极大地帮助定义结构和基本组件。
• 与数据存储相关的良好技能水平 —— 我认为在大多数项目中，您处理从某个地方读取或存储的信息。此外，知识是系统设计能力的完美基础。
• 项目管理 - 用于在新的多任务环境中组织您的工作以及其他人的工作。
• 沟通技巧 - 这个职位是让其他人做技术工作。

我相信这 4 项技能已足够，其余的技能可以在项目期间建立。我希望这篇博文有助于提高软件团队的技术领导能力。

附： 在博客中，当我说“你做某事”意味着“你对某事负责。”作为 Tech Lead ，你可以将一些复杂的工程委托给团队中的专家，但能够验证、批准或纠正解决方案。此外，作为决策者并不等于成为独裁者而忽略了其他人的声音。

附附： 从我的角度来看，Team Lead 和 Tech Lead 之间的区别在于：

• Team Lead 负责人，而不是项目。
• Team Lead 负责人事管理。
• Team Lead 不应该做出个人贡献。

附附附： 另外，在我看来，架构师和 Tech Lead 之间的区别：

• 架构师有更实际和多样化的经验。
• 更广泛和更复杂的系统需要架构师。
• 架构师的立场更多的是做最费力的工作，而不是让团队的其他成员完成所有的工作。