Топ-5 вещей, которые нужно знать, чтобы стать техлидом

Перевод статьи «Top Five Things You Need to Know Before Becoming a Tech Lead».

Возможно, вам предложили место техлида и вы обдумываете оффер, а может, просто задумались, каким должен быть ваш следующий шаг в карьере разработчика. Вы не хотите полностью переключаться на менеджмент проектов, потому что (будем откровенны) такое количество митингов никого не прельщает. Также вы не хотите разбираться с тикетами, пока не затошнит от них, потому что совершенно уверены: компания вполне может нанять джуниора и поручить ему большую часть этих «запросов на улучшения». А роль техлида кажется достаточно привлекательной, но как стать на этот путь?

Я часто шучу о том, как я впервые стал техлидом, но на самом деле этому предшествовало много подготовительной работы. Для начала, мне нужно было понять, вижу ли я себя в этой роли, а затем определиться, что мне нужно, чтобы все-таки сделать этот шаг. В этой статье я очень кратко опишу шаги, которые я предпринял на этом пути.

Знание технологии

Нельзя стать техлидом и не разбираться в технологиях.

Нужно ли вам быть тем самым «10-кратным» инженером (или как там сегодня принято называть этих сказочных разработчиков-единорогов?)? Нет. Вам даже не обязательно быть самым сильным программистом в команде. Я вот точно знаю, что я не самый сильный.

Но вам нужно хорошо знать ту область деятельности, в которой вы будете работать. Это означает, что в определенных вещах вы должны разбираться на более высоком уровне, чем это нужно «просто для работы». В таким вещам относятся следующие:

• Шаблоны проектирования
• Шаблоны интеграции корпоративных приложений
• Масштабирование и вещи, связанные с языком, на котором вы работаете. В моем случае это были фреймворк Spring, Activiti и Apache Camel.

Это, конечно, узко специализированные вещи, но мы создавали инструмент для управления рабочим процессом для довольно крупной торговой компании, а эта архитектура хорошо подходила.

Знал ли я все о Spring? Нет, даже и близко не все. Многие вопросы я делегировал другим людям. Один член моей команды взял на себя изучение Spring Security и к концу второго спринта стал экспертом по этой части. Это было очень кстати, потому что я один ни при каких условиях не смог бы охватить всю необходимую нам информацию.

Знание команды

Вы не можете быть лидером команды, если не знаете людей в этой команде.

По крайней мере, не сразу. Вот после нескольких успешных проектов — пожалуйста. Тогда вы сможете прийти в новую для себя команду и для своей успешной интеграции воспользоваться уже приобретенным опытом. Но для вашего «дебюта» вам нужна команда, с которой вы уже работали и члены которой вам доверяют.

Спустя некоторое время «знание людей» преобразуется в «знание их архетипов».

Вы должны уметь руководить разными типами людей:

• Людьми, с которыми вы ладите и людьми, с которыми не удалось поладить.
• Людьми, с которыми вы работаете бок о бок, и людьми, работающими удаленно.
• Людьми, говорящими с вами на одном языке, и людьми, совершенно не улавливающими сарказм.

Поэтому хорошенько познакомьтесь со своей теперешней командой, чтобы понять, что вы можете вынести полезного из всех сформированных в ней взаимоотношений.

Знание проекта

Вам нужно знать все входы и выходы самого проекта, над которым вы будете работать.

• Когда ожидается релиз?
• Что менеджер проекта ожидает увидеть еженедельно или каждые две недели?
• Каков пайплайн (конвейер) для следующей стадии проекта (ведь следующая стадия есть всегда?)
• Какой функционал клиент хотел получить, но так пока и не получил?

Вам также нужно знать людей, не входящих в вашу команду, но связанных с этим проектом, потому что в роли техлида вам придется взаимодействовать с ними гораздо чаще.

Знание окружения

В каждой компании своя рабочая атмосфера или климат. Может, у вас официально предполагается применение agile-методологии, но при этом требуются заранее подготовленные планы и четко прописанные результаты. Или, возможно, архитекторы не согласны с общим техническим подходом вашего технического директора. Может быть, привлечь внимание собственника продукта можно только поладив с кем-то нижестоящим.

Обо всех подобных вещах вы должны знать.

Причем никто не сможет составить для вас конкретный список того, что нужно знать. Это придется выяснять самостоятельно, ориентируясь на то, что вам нужно для эффективной работы.

Знание себя

Вам нужно знать, почему вы хотите этим заниматься. Я уже говорил, что я не самый сильный программист в команде. Может, в этих словах есть толика проявлений синдрома самозванца и большая доля скромности, но это только к лучшему.

Я знаю, что я куда лучше умею помогать людям, чем производить совершенный код. Поэтому позиция техлида мне очень подходит.

После завершения первых двух проектов я узнал о себе еще немного больше. Теперь я знаю, что:

• эффективность моей работы как лидера падает, если в команде появляется больше 4 разработчиков,
• после того как я в течение месяца поработал по 60 часов в неделю я больше не могу составлять предложения так же эффективно, как при нормальной нагрузке,
• мои ревью кода могут стать очень педантичными, если у меня сильно упадет уровень сахара в крови,
• не все люди, с которыми я работаю, хорошо понимают мою самоиронию.

Заключение

Без знаний технологий, с которыми вы работаете, команды, которую вы будете вести за собой, и проекта, которым вы будете заниматься, вы далеко не уйдете. А если вы не сумеете здраво оценить себя, свои способности и склонности, а также ваше рабочее окружение, вы даже за ворота не выйдете.

Лишь когда вы с уверенностью сможете сказать, что хорошо разбираетесь во всех этих пяти вещах, вы сумеете достичь успеха в роли техлида.

Это, конечно, не исчерпывающий список, это лишь пункты, которые я сам обдумывал, прежде чем согласиться занять предложенное мне место.

С моей командой я работал несколько лет. Также я примерно полгода работал с удаленной командой и чувствовал себя довольно уверенно. Что касается технологий, я регулярно помогал техлиду с сессиями проектирования. Менеджер проекта сидел через ряд от меня, а системный архитектор сидел сзади, так что я знал, в какое окружение попаду.

Когда я свыкся с мыслью, что могу принести больше пользы проекту, не занимаясь собственно разработкой, я был готов оставить свою работу и перейти на позицию техлида.