技术主管的五大职责

结论：

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

昨天你还是一位资深开发人员，愉快地完成分配给你的场景或用户故事。当你和你的经理坐下来谈话时，他/她邀请你担任技术主管这个新角色，你欣然接受，因为，何乐而不为呢……

原文发表于 TeachingTechLeads.com

你的日常生活中最近增加了哪些新的责任？

收集需求

每个项目都是从有人意识到自己有问题开始的。这个人会向其他人抱怨，迟早他们会意识到IT部门需要来解决所有问题。

你会与企业或客户会面，了解他们遇到的问题。你要认真倾听，提出问题，尽可能多地收集信息，然后再考虑提出解决方案。之后，你再提出你的方案。

“我们可以这样解决你的问题。”一旦他们同意，就可以开始工作了。

仅仅让他们同意整体方案是不够的，你还需要让他们同意其中的一些细节。你最不希望看到的就是他们看到一切都完成了，却仍然不满意。

小反馈回路至关重要。

设计解决方案

一旦获得批准，就该开始构建解决方案的运作方式了。此时，根据您所在组织/团队的规模，您可能需要独自工作，也可能需要与架构师合作。您将从抽象的层面转向更详细的分析，思考“我们如何才能让它正常运行？”

一旦你有了解决方案及其所有组成部分的粗略草图，你的内部团队流程就可以开始了。我的团队使用行为驱动开发（BDD）来实现规则，你可能使用测试驱动开发（TDD）来完成看板任务，或者使用 Scrum 来迭代用户故事；这取决于你。但是，正是在这个时候，你可以开始将工作单元分配给你的团队了。

与业务部门对接

团队在开发的时候，你很可能就无法参与了。我们会在以后的文章中详细讨论这个问题，但你现在已经不再是开发人员了。习惯就好。

你扮演的是一个接口的角色。客户会有疑问或担忧，他们会想了解某个功能的实现方式，或者想知道下一个版本发布周期何时到来。他们会尝试联系团队成员。

那个人就是你。不是别人。

你这样做是让你的团队腾出时间来工作。

守护代码

啊，对了，代码。你不用自己写代码，但肯定会读很多代码。

代码库需要维护。而你就是守护通往“主分支”、“主干分支”或特性分支……无论你采用何种分支策略的黑骑士。

每一次合并请求都应该被视为与被实现的功能和实现该功能的开发人员之间的一次对话。

他们是否满足了 Checkstyle 和 PMD 的要求？
他们是否提供了必要的代码覆盖率？
是否有验收测试来证明该功能按预期运行？
开发人员是否实现了你在设计阶段讨论过的模式？
他们是否遵循了代码库的整体风格指南？
代码审查本身就是一个值得单独撰写的文章，所以我们稍后会深入探讨。但可以肯定的是，你将阅读大量相关内容。

发布产品

一旦所有先前商定的需求都已完成，就可以发布了！接下来只需要编写发布说明、与质量保证团队沟通、通知运维人员、系统管理员或负责产品流水线推进的人员即可。

当这些人有疑问时，你是他们的联系人。他们需要从某个地方拉取 WAR 文件，还是需要将 Docker 镜像更新到新的版本标签？QA 团队是否需要一份详细的要求清单，以及如何测试每一项要求？

然后，一旦产品发布，当客户发现他们需要的改进功能或需要在下一个版本中修复的错误时，我们就会重新开始这个循环。

结论：

作为技术主管，您将负责：

• 找出问题所在
• 设计解决方案
• 解释该解决方案
• 委派任务并确保完成
• 将解决方案公之于众

这是一个非常简洁明了的软件开发生命周期清单，我知道这听起来可能有点不可思议。但是，当你担任项目技术负责人时，你将从头到尾亲力亲为。

但别担心，你不会孤军奋战。在后续的文章中，我们会讨论你的团队以及他们将如何帮助你。毕竟，如果技术主管实际上没有“领导”任何事情，那他们又算什么技术主管呢？