技术领导之路：如何从开发人员转变为团队负责人

如果软件开发只是你职业目标的一部分，那关于未来如何成为一名技术负责人也许是你应该认真思考和学习的事情。技术负责人可能意味着不同的事情：身兼团队负责人或技术经理的职责。譬如，研发项目经理是一个需要对其团队及项目负责的团队角色。这也就意味着他们还需对团队成员的工作情况、业务增长情况、可交付成果、项目截止日期、团队文化、代码标准、技术债务等等负责。

作为一名开发人员，你清楚如何从目前的职位晋升成为一名技术负责人吗？如果你的目标是尽快成为一名技术侧管理者，那么你首先需要问问自己为什么想要担任这个角色？成为一名技术管理人员不一定是真正符合你长期目标的一个选择。

以往我之所以从事软件开发，是因为与“电脑”合作比与人合作更让我感到自在。但是一段时间后，我发现自己能够在各方面越来越多地帮助到其他开发人员。同时我喜欢主导项目并追求更完美的代码水平。因此，就我个人而言，成为研发项目管理者是一个显而易见的最佳选择。

但对于多数软件工程师而言，成为一名独立贡献者（IC）可能是更为合适的道路。许多公司都会选择聘用一个杰出工程师或资深工程师等非常高级别的技术角色而非职业经理人来管理技术团队。

▲开发人员的刻板印象：吃披萨，仅在晚上工作等等▲

那么，你是想成为一名研发项目管理者还是其他类型的团队负责人呢？问题的关键在于诚实地了解驱动你的因素-究竟是编写代码还是软件架构设计？又或者你希望帮助其他开发人员取得更好的项目结果？与项目的相关者协商交付日期？以及说服你的业务团队在必要的时候进行代码重构？

对这些问题的回答将有助于你确定哪条道路更适合你。

如果你仍然确信成为一名技术负责人是你的选择，那么你还需要做一些前置准备工作：考虑与你的项目伙伴或导师合作，让他们在你不熟悉的领域为你提供帮助。

如果以上说的内容，你都已经确定并准备好。那么接下来的10点建议是我觉得你在成为技术团队负责人的道路上需要持续努力做到的事情：

一个真正的领导者无需职称或权威就可以领导他人。 任何具有花哨头衔和被组织赋予足够权力的人都可以下命令。但切记，站出来下命令不是领导能力的体现—而是你的工作。

因此，你应该从小处着手。在困难的项目中承担更多的责任。通过在项目过程中提供反馈来帮助你的伙伴。并且主动去介绍项目更新进度，提出对团队或产品工作流程的改进等方法来指导你的伙伴们。

一个项目中，其实是有很多值得你去主动帮忙的地方的。但一般人们要么不愿意帮忙，要么没有足够的专业知识或信心去承担责任。因此你需要确定你的同事正在苦苦挣扎什么，然后站出来帮助他们。

承担责任时，应对你所做的或没做的一切负责。 领导者要承担责任，避免将错误，错过截止日期或漏洞归咎于他人。

与其抱怨别人犯过的错误，不如帮助他们修复错误并解释将来如何避免它。既然找借口并不能帮助任何人，那么你应该要花时间践行你所承诺的。如有必要，请与你的经理协商一个更好的期限。然后像你运营自己的企业一样运行一个项目，并切身地关心它。

最近，我团队中的一位技术负责人扩展了一个我们的 master 分支。原因在于他早前发现单元测试的覆盖率大大下降。当下他没有抱怨，而是默默地增加了缺少的测试范围。然后介绍了如何正确检查覆盖率以及如何编写复杂功能的单元测试。可以看出他愿意在团队中提供帮助，而不是去责怪他人。团队所有人都对这个行为表示赞赏。

老是说，如果你不想与“人”打交道，那么在你想要成为领导者之前需要再认真考虑一下。

建立有意义的人际关系是技术研发管理者的职责之一，因为管理是使事情通过他人来实现。因此，从现在就开始与他人建立良好的合作关系，他们将是你未来的伙伴。

也许你可以尝试通过以下列举的几种方法来促进自己做到与他人建立良性合作关系：例如在技术沙龙中进行演讲、参加研讨会以及在团队之外指导开发人员。

一名研发技术管理者首先要是一名软件工程师。他们必须具有强大的软件工程背景和动手经验，必须是团队中最强大的工程师之一。无法编写代码或不了解技术细节的管理者是不能参与技术讨论的。同时也意味着成为管理者后，也应始终需要保持足够强的技能，以胜任更高层次的架构需求。

在团队中，没有团队合作精神的“优秀开发人员”的存在，其实都是弊大于利的。如果你在技术上很强，那么你应该帮助其他人达到自己的水平。结对编程、代码审阅、演示、开放源代码或内部源代码项目都是帮助他人很好的示例。

可能很少有人会主动来找你请教问题。但是，通过把自己称为“技术专家”并主动做上述事情，人们自然会开始向你寻求建议。通过帮助他人，你可以建立有意义的人际关系并赢得人们的尊重。你也要希望他们做同样的事情作为对你的回报——在有能力的情况下去帮助他人。

按时交付项目是管理者的核心职责之一。如果作为开发人员，你总是因为低估任务而错过了截止期限，那么其他人将如何信任你呢？当我们处理任务时，你必须保持井井有条。

众所周知，由于存在很多不确定性，因此估算软件项目的可交付时间是非常困难的。但是，通过正确的流程，多与你的项目经理或利益相关者不断交流项目的进度和期望,对项目进行有效把控并非不可能。

例如，我的团队正在做一个每周工作状态报告，这个小举动使得项目技术负责人有机会与我们交流进度，尽量减少当前的阻碍因素或有可能引起无法按时交付的问题。

清晰，简洁地沟通是所有领导者都需要拥有的重要特质。如果你无法清楚地说明团队的要求，那么你在成为领导者，甚至还没有开始任何工作之前就失败了。

沟通有多种形式，包括口头、书面甚至肢体语言。你需要一直努力提高每一种不同的沟通技能。

因为我未能及时清晰地传达需求，我的团队曾错过了一些截止日期。可见在一些情况下，缺乏沟通会令团队在应该做的事上造成混乱。我了解到，单单依靠项目经理或团队商务来解释项目详细信息是行不通的。作为研发负责人，本身必须了解相应的重点项目，然后对其进行解释并传达给团队。同时，激励团队人员去努力完成项目。

“管理”你的管理者（有时是其他团队的负责人）。这意味着要与他们不断沟通并管理期望。作为管理者无论好坏都很少喜欢“惊喜”。你要与你的管理者建立信任关系。成为重要的项目专家，并按时按预算地完成它们。然后进行更多项目，不断重复此过程。

无论你进行过多少次单元测试或集成测试，或多或少都还是会在这过程中出现问题。是的，你希望最大程度地减少项目中的错误。但更重要的是你是如何处理这些技术问题的。在他人的压力下开始恐慌的人立即会被取消领导资格。团队和其他负责人希望看到一个冷静的管理者，即使在最紧张的情况下，也可以控制一切。

举个例子，我曾经合作过的技术负责人在遇到问题的时候总是很冷静。没有任何冲突或压力可以使他慌乱，至少没有人看到他压力很大。当谈到凌晨3点还在处理技术问题时，他并不感到丢脸。在他的工作现中，这个问题像在几分钟之内就解决了一样。

反观另一位技术主管，因为最后期限的临近而倍感压力，他在我们准备发布一项重要功能的那天打电话请了病假。他太焦虑了，以至于周围的人都不愿意和他一起工作。

这是两个完全相反的案例，但大家不难看出哪一个管理者更有可能在未来取得成功。

对于技术负责人应负责的所有事情，都应该理解“为什么”。他们需负责确保其他人都知道他们为什么要做这个项目。领导者必须（经常或多次）解释为什么要进行这个或那个项目，为什么要由特定人员进行该项目以及该项目如何能适应“大局”。团队必须相信自己的所作所为，然后他们才能有效率地工作。

不要等待被许可，从现在开始就站出来。成为你所在领域的专家，当人们陷入困境时帮助他们。致力于提高你的沟通技巧。与你当前和潜在的未来同伴建立良好的职业关系。确保高效地管理时间，并且在每一个项目的交付期限之前完成任务。最后，不要忘记领导力与人有关，所以要真诚地帮助你的同伴成长并凡事尽力而为。

🔗原文链接：medium.com/free-code-c…