技术主管技术主管是做什么的？

原文发表于我的博客： All You Need Is Backend。

技术主管是软件开发组织架构中一个相对较新的角色。当我第一次听说这个角色时，我的第一反应是……

那位是软件架构师兼团队负责人吗？

我认为这个定义并不完全正确，但它提供了一种很好的思考方式。在这篇文章中，我回顾了过去三年半担任该职位的工作经验，其中包括：

• 领导Atlassian Stride （一套完整的团队沟通解决方案）的一个团队。在不到两年的时间里，团队规模从 5 人增长到 10 人。
• 我领导着KPIdata，这是一个非营利组织，开发了用于评估基辅理工学院高等教育质量的软件。团队最初由10名核心成员组成（包括我在内的只有3名软件工程师），最终，超过180名个人贡献者帮助我们完成了项目。
• 在Video Internet Technologies Ltd领导一个由 4 名工程师（包括我自己）组成的团队，负责视频管理系统（CCTV）的集成。

请注意，同一职位在不同公司可能承担不同的职责。

请阅读这篇博文，了解我作为全职软件系统负责人的真实经历。我详细阐述了担任技术主管这一职位的利弊。

从实际角度来看——该职位所需的最关键技能清单在博客的最后部分提供。

成为全职业主

我上任后发现的第一件事就是，我现在要全权负责一个工程团队的某个分支。好处是，这个新分支当时还没有任何上线产品。所以，我不需要维护和扩展之前维护人员留下的任何遗留代码。这很不错。

然而，这并非绝对，每家公司的情况都不尽相同。我认为，更多时候，你有机会改进现有的软件系统，而不是从零开始创建。因此，你要做好准备，承担那些并非由你的团队发起和设计的项目。

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

• 你收到的任务都与特定的业务目标挂钩。实际上，这些任务就是项目。此外，需求可能只定义了一部分。你需要进一步明确所有需求和约束条件。为了防止范围蔓延，你需要尽可能详细地定义项目的预期成果。理解并定义最终目标是至关重要的第一步。
• 在时间和预算允许的范围内，您可以采取任何合理的方式来实现目标。我们将在下一节中详细探讨这一点。
• 所有为实现目标而开发的软件的成功（和失败）都与你息息相关。如果你的系统出现故障或运行不符合预期，那就是你的责任和过错。如果目标超额完成——干得漂亮！但别忘了把功劳归于你的团队。他们值得这份荣誉。

工程创造力的空间

是的，为了实现工程目标，你可以做任何事。以下是我能够更改或实施的一些事项。请注意，你需要获得团队的认可才能使这些更改长期有效。软件是由人创造的。快乐的团队才能创造出可用的软件。

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

我省略了一些内容，欢迎在评论区补充您的想法。

技术主管的技术能力如何？

我的任务是帮助团队找到解决问题的正确方案。

你每天编写的代码并不多。

在加入新团队担任技术主管之前，我曾在同一领域、同一团队担任中高级软件工程师超过一年半的时间。对我来说，积累异步编程、关系型和非关系型数据库、即时通讯以及高负载系统方面的实践经验至关重要。

为了确保项目成功，首先你应该阅读大量资料：

• 代码
  • 您的团队提交的拉取请求。
  • 系统可重复使用的解决方案。
  • 您需要与之合作的其他团队维护的第三方服务的代码。
• 技术文档
  • 您可以重复使用的服务（包括内部服务和第三方服务）的描述。
  • 解决方案的实施细节。
  • 已知问题（没有什么是完美的）——了解风险并制定缓解措施。

读了很多书之后，你写了一点：

• 工程方案——DACI是一个很有用的框架。我非常喜欢它。
• 方案确定后——设计页面。
• 最后——还有一些工作需要提交工单（我的团队正在运行）。 咖啡因Jira 软件）。

写完之后——你们要讨论：

• 与队友就重要的任务达成一致。
• 如果你的规范不完整或没有提供所有数据来源，请向你的团队成员进行解释。
• 与其他球队协商合同。
• 展示你的工作成果，并在公司内部推广你的解决方案。

一天结束时，你可能还有几个小时的时间来完成个人贡献。对我来说，大概是这样的：

• 热修复补丁。世界即将崩溃的时候，需要修复一些问题。
• 先做一个概念验证，无需编写测试，然后请团队成员将其转化为生产级软件。
• 提交数据库或配置更改。
• 调查一个在开发环境中很难重现的奇怪漏洞。
• 从指标/日志解决方案中提取一些数据，以验证实施方案的想法。

我认为技术主管应该具备扎实的软件工程实践经验，才能做出并支持合理的决策。

我认为，在小型团队（最多 3 名直接下属）中，仍然有可能做出相当可观的个人贡献。

截至撰写本文时，我的工程领导能力尚未发展到足以在大团队中做出可持续的个人贡献的程度。

担任技术主管的利弊

优点：

• 你会成为项目领域的专家。
• 您已完全了解软件系统的工作原理，以及如何以最小的风险对其进行更改。现在您可以将此方法复制到其他系统。
• 因为你负责理解需求和解释技术解决方案，所以你会成为一名优秀的沟通者。
• 你在软件开发的各个领域都达到了一定的熟练程度（虽然不一定很高）：
  • 系统设计——构建软件架构并在早期阶段验证所有风险。
  • 运维——确保您的系统正常运行。
  • 质量工程——防止公司声誉受损。
  • 工程管理——将实施工作委托给你的团队甚至其他团队。

缺点：

• 一天工作结束后，你往往没有成就感。你为团队创造了一些新工作，解决了一些障碍，但感觉并不像是真正的工作。
• 大型团队的编码工作量不足。
• 你是团队的入口点。你应该能够接受来自多个来源的任务：
  • 你的队友
  • 您的管理
  • 合作伙伴团队
  • 客户支持团队
  • 其他听说过你们团队的人
• 有时候压力很大，因为责任很重。但最终，你应该学会如何应对这一切。

我认为这个职位值得一试，我很庆幸有机会担任这个职位多年。如果再来一次，我还会选择这个职位。

TL入门包

如果你对技术主管职位感兴趣，并想为此做好准备，以下是我在职业生涯初期发现的一些最有价值的技能：

• 熟练掌握你所用技术栈的编程语言，才能做出合理的技术选择并进行代码审查。项目的正确启动至关重要，而你的编码技能将极大地帮助你定义项目结构和基本组件。
• 具备良好的数据存储相关技能——我认为在大多数项目中，你都会处理从某个地方读取或存储的信息。此外，这些知识也是系统设计能力的坚实基础。
• 项目管理——在新多任务环境下组织你自己的工作以及其他人的工作。
• 沟通技巧——该职位旨在帮助其他人完成技术工作。

我认为这四项技能就足够了，其余技能可以在项目进行过程中在此基础上逐步培养。我希望这篇博文能够帮助提升软件团队的技术领导力。

PS：在博客中，我说“你做某事”指的是“你负责某事”。作为技术主管，你可以将一些复杂的工程任务委派给团队中的专家，但同时也要能够验证、批准或纠正这些解决方案。此外，决策权并不等同于独裁，也不等同于忽视他人的意见。

附注：在我看来，团队负责人和技术负责人之间的区别在于职责：

• 团队负责人负责的是人员，而不是项目。
• 团队负责人负责人员管理。
• 团队负责人不应该做出个人贡献。

另外，在我看来，架构师和技术主管之间的区别是：

• 建筑师拥有更丰富的实践经验和多元化的经验。
• 对于更广泛、更复杂的系统，需要架构师。
• 架构师的职责更多在于承担最繁重的工作，而不是让团队其他成员完成所有工作。