Контрольный чек-лист для того, чтобы стать лидером команды разработчиков

Меня зовут Идан Кох, я работаю в сфере высоких технологий на различных должностях более 2 десятилетий. В течение этого периода я имел огромное удовольствие работать с замечательными людьми. На протяжении многих лет я принимал активное участие в процессе роста членов команды и наблюдал за тем, как талантливые разработчики переходили на разные должности. Наиболее распространенным вариантом, с которым я сталкивался, был переход разработчиков с ролей отдельных участников на роли руководителей группы. Обычно вопрос звучит так: «что мне нужно сделать, чтобы показать, что я готов?»

Данная статья переведена с английского с адаптациями в рамках Симулятор-курса Team Lead, руководитель команды.

При продвижении по карьерной лестнице иногда неясно, что нужно сделать, чтобы перейти на следующую должность, будь то технический руководитель, руководитель группы, менеджер или кто-то ещё. В компаниях не всегда есть чёткое руководство о том, чего нужно достичь, чтобы перейти из пункта А в пункт Б. Однако для перехода с должности IC на TL я на протяжении многих лет составлял простой чек-лист для любого разработчика, желающего совершить этот переход. Этот список основан на моём опыте, не все пункты являются обязательными, некоторые из них можно исключить в зависимости от предыдущего опыта или ожиданий компании от этой должности. Тем не менее, исходя из моего обширного опыта в этом вопросе, я могу сказать, что этот список довольно универсален.

1. Завоюйте свои владения

Чтобы стать TL, вам нужно будет представлять свою команду на различных технических и дизайнерских совещаниях, отвечать на вопросы как внутри команды, так и за её пределами, а также брать на себя ответственность или помогать в производственных инцидентах. Чтобы справиться с этой задачей, вам нужно будет делать следующее:

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

1.2. Станьте героем производства. Этот раздел зависит от описания вашей должности, некоторые разработчики не связаны с производством. Однако, если вам повезло и вы отвечаете за производство, то как технический руководитель вы либо будете на передовой, когда всё пойдёт наперекосяк, либо будете подменять своих коллег. Работа с производственными инцидентами поможет вам расти. Несколько ключевых моментов, касающихся управления производственными инцидентами:

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

Снижение стресса — есть разработчики, которые по умолчанию спокойны при любом производственном давлении, и это нормально, если вы не из их числа. Один из способов снизить производственное беспокойство — как можно чаще сталкиваться с ним. Единственный способ научиться — это погрузиться в процесс. Вы можете начать с «подглядывания» за дежурным и постепенно брать на себя управление инцидентами. Через какое-то время вы просто привыкнете к этому.

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

1.3. Оказание поддержки. Часто ваша команда получает запросы от других команд. Вопросы могут быть разными: от вопросов по API до вопросов о том, как работают потоки, о помощи в производстве и многом другом. Обычно это приводит к глубокому погружению в старый код и расспросам о том, почему всё устроено именно так. Ответы на вопросы помогут вам продемонстрировать свои знания в области, выходящей за рамки ваших повседневных задач. Кроме того, если вы будете отвечать на как можно большее количество вопросов, вы станете центром знаний.

2. Адаптация

Руководство другими людьми потребует от вас умения переключаться между своими задачами и помогать кому-то с его задачами, постоянно переключаясь между контекстами и зная, как с этим справляться. Например, новый член команды каждые 2 минуты обращается к вам с вопросом. Вы можете отвечать на каждый вопрос немедленно, но, возможно, ничего не успеете сделать. Альтернативой может быть фраза: «Давайте назначим часовую встречу после обеда. Я хочу внести последние штрихи в свой PR, чтобы сосредоточиться на ваших вопросах». Кроме того, вы научитесь тонкому искусству понимать, когда нужно позволить другим немного «побороться», чтобы они научились учиться, а когда нужно вмешаться и помочь. Так как же вы тренируете эти навыки, прежде чем стать TL?

Лично я считаю, что очень полезно, чтобы последний человек, присоединившийся к команде, был «наставником» для нового члена команды. Он помогает новичку освоиться, понять, к кому можно обратиться за помощью, какие процессы используются в компании/команде, помогает с написанием кода, ведёт его в «правильное» место, где можно пообедать… отвечает на все вопросы, большие и маленькие (обед — самый большой вопрос). Этот этап очень важен, так как он позволяет проверить ваши собственные знания. Лучший способ понять, что вы действительно знаете, о чём говорите, — это объяснить это кому-то другому. Вы обнаружите пробелы в информации, и это нормально, это даже здорово. Самое главное — это практический опыт руководства кем-то другим, который поможет вам понять, нравится вам это или нет.

3. Большие задачи

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

Требования — Соберите все требования и оставьте отзыв, задайте сложные вопросы (например, будет ли это этапом 2?). Понимаете ли вы текущие процессы, как и почему они реализованы именно так? Убедитесь, что вы знаете, как повлияет эта новая функция на жизнь наших пользователей?

Дизайн — Итак, вы собрали все требования, теперь вам нужно их выполнить. Вам нужен дизайн, который соответствует всем требованиям (обычно их несколько). Для получения обратной связи и создания списка действий, которые нужно выполнить, необходимы обсуждения дизайна со всеми техническими сторонами. Этот процесс может включать несколько итераций, иногда даже с возвращением к этапу сбора требований. Ваша задача — сделать эти итерации как можно короче. Вы найдёте «ярлыки», такие как получение обратной связи от конкретных технических специалистов до начала проверки, чтобы быстрее выявить проблемы, или даже просто создание канала Slack, посвящённого функции, что позволит вам делиться информацией и вопросами с более широкой аудиторией.

Зависимости — даже несмотря на то, что это часть дизайна, она заслуживает отдельного раздела. Чаще всего вы зависите от других команд. Вам нужно в какой-то степени понимать их область деятельности. Вам нужно понимать их проблемы, возможно ли то, о чём вы их просите, с их текущей системой. Вам нужно понимать, сколько времени им потребуется, чтобы выполнить свою часть работы. Наконец, вам нужно понимать, что для них важнее всего. Могут ли они встретиться с вами в точках интеграции? Нужно ли вам поднимать тревогу, если есть риск, что другие команды не выполнят свои обязательства? Знайте, к кому обращаться за помощью, чтобы получить приоритет от других команд. При необходимости можно внести свой вклад в виде кода.

Составьте план — разбейте всё на мелкие задачи. Отметьте зависимости между задачами, которые блокируют другие задачи. Отметьте задачи, которые можно выполнять параллельно (на случай, если вам помогут). Установите точные сроки (насколько это возможно) для выполнения и интеграции.

Оценка времени — это всегда непросто, процесс оценки времени иногда учит вас не быть слишком оптимистичным. Звучит удручающе, но на самом деле это ключ к тому, чтобы избавить себя от стресса в будущем. Вам нужно будет помнить, когда вы на дежурстве, когда у вас встреча с коллегами, когда у вашего ребёнка футбольный матч, праздники или любые другие обязательства, которые могут повлиять на сроки выполнения. По возможности оставляйте немного времени на отдых, большие задачи — это марафоны. По ходу работы будут происходить непредвиденные события, будут случаться переключения контекста. Мой эмпирический принцип: если вы не знаете, как оценить неизвестное, убедитесь, что у вас есть дополнительные 20% времени. Обычно дополнительное время требуется для интеграции, производственного тестирования, исправления ошибок или в те замечательные дни, когда сборка не работает и вам нужно потратить день на выяснение причины. Например, если выполнение задачи занимает месяц, то, скорее всего, вам понадобится дополнительная неделя.

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

4. Большие задачи — вы сами по себе

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

5. Большие задачи — ведите за собой других

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

6. Встречи 

Большая часть работы технического директора заключается в участии в совещаниях. Рецензирование дизайна, технические консультации, мозговые штурмы, анализ рабочих процессов. Даже если вы не выступаете с лекциями на большой конференции, вы будете стоять перед другими менеджерами и руководителями вашей компании, объясняя технические вопросы, проблемы с дизайном, ведя обсуждения и отвечая на отзывы. Вам нужно будет чётко формулировать свои мысли, чтобы правильно донести свою мысль. Ваши руководители будут больше доверять вам, когда увидят вас в такой обстановке. Я признаю, что этот шаг немного более рискованный, он не всегда обязателен и иногда может быть частью обучения на рабочем месте. Однако, если у вас будет возможность попробовать, это поможет вам развиваться и расти. Кроме того, если вы увидите, как кто-то другой проводит сложную встречу и прокладывает путь через море проблем и эгоизма к обещанной земле с конкретными задачами, — спросите себя, как он этого добился? Какая подготовка была необходима? Если вы видите кого-то, кого хотите «смоделировать» или перенять «аспекты» его профессиональных навыков и адаптировать их, задайте ему вопросы. Возможно, вам повезёт, и он станет вашим наставником. Наставничество — это отличный способ продвинуться в своём деле, когда кто-то со стороны следит за вашими достижениями, даёт советы и беспристрастную обратную связь.

Подводя итог:

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

1. Будьте в курсе всех производственных вопросов и вопросов поддержки.

2. Сначала выполняйте большие задачи вместе со своим руководителем, а затем действуйте самостоятельно.

3. Если возможно, проводите «важные» встречи.

Данная статья переведена с английского с адаптациями в рамках Симулятор-курса Team Lead, руководитель команды.