Tech Lead (Техлид) — это относительно новая роль в иерархии организаций, занимающихся разработкой программного обеспечения. Когда я впервые услышал об ней, моей первой мыслью было следующее:

Это что, архитектор программного обеспечения + руководитель команды?

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

• возглавлял одну из команд для Atlassian Stride — комплексного решения для общения в команде. За почти 2 года команда выросла с 5 до 10 инженеров.

• возглавлял KPIdata — некоммерческую организацию, которая разрабатывала программное обеспечение для доступа к вопросам качества высшего образования в Киевском политехническом институте. Команда была расширена до 10 основных членов (всего 3 инженера-программиста, включая меня), и в конечном итоге 180+ индивидуальных участников помогли нам реализовать проект.

• Руководил командой из 4 инженеров (включая меня) в компании Video Internet Technologies Ltd по интеграции систем управления видео (CCTV).

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

Ознакомьтесь с этой статьей в блоге, чтобы узнать о том, как в действительности я полностью обеспечиваю работу программных систем. Здесь я подробно рассказываю о плюсах и минусах работы на позиции Tech Lead (техлида).

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

Быть полноправным владельцем

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

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

Что значит быть полноправным владельцем?

• Вы получаете задачи, привязанные к конкретным бизнес-целям. На самом деле, задачи — это проекты. Более того, требования могут быть определены частично. Следует идти вперед и выяснить до конца все требования и ограничения. Вам нужно максимально конкретизировать желаемый результат проекта, чтобы предотвратить изменение объема работ. Понимание и определение конечных целей — это самый первый шаг.

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

• Все успехи (и неудачи) программного обеспечения, созданного для достижения цели, связаны с вами. Если в вашей системе что-то сломалось или работает не так, как ожидалось — это ваша ответственность и вина. В случае, если цель достигнута — отличная работа! Не забывайте, однако, отдавать должное успехам своей команды. Люди заслуживают этого.

Простор для инженерного творчества

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

• Методология разработки программного обеспечения. Сильно зависит от целей проекта и сроков. Ответьте на вопросы, чтобы определить это:

  • Сколько дней в итерации?

  • Каков процесс планирования? Какие задачи должны быть оценены? Как оценивать задачи?

  • Должны ли мы допускать изменения в требованиях или нет между итерациями?

  • Каковы правила для задач разных типов/приоритетов? Пример: все баги для компонента Billing должны быть исправлены как можно скорее, независимо от степени серьезности.

  • Как донести это до остальных членов организации?

• Технический стек для проекта. Он может включать в себя языки программирования, фреймворки, хранилища данных, библиотеки, решения для мониторинга, но не ограничиваться ими. Иногда у вас есть какой-то заранее определенный набор, продиктованный политикой компании. Для нашего раздела стек был следующим:

• Python 3, asynchronous programming, asyncio

• MySQL, Elasticsearch, Redis

• AWS (EC2, RDS, ElastiCache, S3, SQS, CloudFormation, CloudWatch)

• DataDog, Elasticsearch/Logstash/Kibana, ElastAlert, Splunk

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

• Нефункциональные требования. Это определение границы между достаточно хорошим и идеальным программным обеспечением. Меня никогда не призывали создавать идеальное коммерческое решение. Обычно людям просто требуется стабильная разработка для решения их бизнес-задач. Решение должно быть достаточно гибким, чтобы позволить нам быстро вносить новые изменения. Для меня это означает создание обоснованных предпосылок для инженеров, чтобы сделать бизнес успешным. Примеры:

• Компонент должен быть устойчив к перезагрузкам базы данных...

• ...но если соединение не может быть установлено в течение 60 секунд — просьба сообщить об этом.

• Внутренние этапы. Вы можете установить приоритеты для команды на разных промежутках проекта, а также обозначить  ожидаемые результаты.

• Например, дорожная карта проекта может быть оптимизирована таким образом, чтобы как можно скорее получить версию системы в продакшене, создать пайплайн CI/CD, а также убедиться, что ваши идеи в принципе работают.

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

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

• Доступность. Можно ли пользоваться услугой?

• Количество обработанных заданий. Нужен ли нам еще этот сервис? Сколько полезной работы мы выполняем?

• Показатели успешности для основных компонентов. -Помогает нам увидеть проблемы на миддл-уровне.

• График развертывания. Он включает в себя то, как часто необходимо деплоить программное обеспечение в различных средах.

• Сразу после мерджинга пул-реквеста

• ИЛИ делать релизы раз в 4 месяца.

• Коммуникация. Как команда обменивается информацией о ежедневном прогрессе?

• 30-минутные видеозвонки два раза в день

• Текстовый стендап раз в неделю (возможно)

• Распределение работы. Как распределяются задачи в вашей Jira?

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

• Каждый может взять любую задачу, независимо от приоритета и зависимостей.

• Политика ревью кода. Кто должен одобрить пул-реквест, чтобы позволить создателю смёрджить его в master? Варианты:

• Консенсус — все вопросы решены, и все рецензенты по умолчанию одобрили изменения.

• Должно быть получено как минимум 2 одобрения от старших инженеров, чтобы продолжить работу.

• Я могу одобрить свой PR (pull request) и задеплоить его через 2 часа после последнего коммита.

• Ретроспективы. Как часто их проводить? Моя рекомендация — раз в 4 недели, но я знаю, что некоторые команды делают это раз в 2 недели. Кстати, а как часто вы их проводите?

Я упустил некоторые моменты, поэтому не стесняйтесь добавлять свои идеи в комментариях.

Насколько техничен технический лидер?

Моя задача заключалась в том, чтобы дать команде возможность реализовать правильное решение проблемы.

Вы не пишете много кода на ежедневной основе

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

Чтобы сделать свой проект успешным, прежде всего, следует многое изучить:

• Код

• Пул-реквесты, сделанные вашей командой.

• Решения, повторно используемые вашими системами.

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

• Техническая документация

• Описание сервисов, которые вы можете использовать для многократного применения (как собственных, так и сторонних).

• Детали имплементации решений.

• Известные проблемы для них (ничто не идеально) - для понимания рисков и планирования мер по их снижению.

После прочтения вы можете написать:

• Технические предложения — DACI, что является полезным фреймворком. Мне это нравится.

• После принятия решения относительно предложений — дизайн страниц.

• И в самом конце — тикеты на какую-то работу (моя команда работает на программном обеспечении Jira).

А после написания — обсудить это:

• Достигайте согласия с коллегами по команде в отношении нетривиальных задач.

• Проинформируйте своих напарников о том, если у вас неполная спецификация или вы не предоставили все источники данных.

• Заключайте контракты с другими командами.

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

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

• Хотфиксы. Нужно что-то исправить, пока не произошло катастрофы.

• Сделать пробный вариант концепции для пул-реквеста без написания тестов. После этого попросить кого-то из команды превратить его в продакшн-грейд программу.

• Зафиксировать изменения в базе данных или конфигурации.

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

• Получить некоторые данные из метрик/журналов для валидации идеи имплементации.

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

Я полагаю, что в небольших командах (до 3 непосредственных подчиненных), все еще возможно внести значительный личный вклад.

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

Плюсы и минусы работы в должности техлида

Плюсы:

• Вы приобретаете статус эксперта в области своего проекта.

• У вас есть полное понимание того, как работает система программного обеспечения и как вносить в нее изменения с минимальным риском. Теперь вы можете повторить это на других системах.

• Вы становитесь хорошим коммуникатором, поскольку отвечаете за понимание требований и объяснение технических решений.

• Вы достигаете определенного уровня компетентности (не всегда, правда, очень высокого) в различных областях разработки программного обеспечения:

• Проектирование системы — для создания архитектуры программного обеспечения и проверки всех рисков на ранних стадиях.

• Эксплуатация — для поддержания работоспособности ваших систем.

• Инженерия качества — для предотвращения потери репутации вашей компании.

• Инженерный менеджмент — чтобы делегировать имплементацию своей команде или даже другим командам.

Минусы:

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

• В больших командах недостаточно кодирования.

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

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

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

Стартовый набор TL (технического лидера)

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

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

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

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

• Коммуникативные навыки — должность предполагает предоставление возможности другим людям выполнять техническую работу.

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

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

P.P.S. С моей точки зрения, разница между Team Lead (руководителем команды, тимлидом) и Tech Lead (техническим лидером, техлидом) заключается в обязанностях:

• Team Lead отвечает за людей, а не за проект.

• Team Lead занимается управлением людьми.

• Team Lead не должен вносить индивидуальный вклад.

P.P.P.S. Также, на мой взгляд, разница между архитектором и техлидом:

• Архитектор имеет больше практического и разнообразного опыта.

• Архитектор нужен для более обширных и сложных систем.

• Должность архитектора — это скорее выполнение самой трудоемкой работы, а не предоставление возможности остальным членам команды сделать всю работу.

Материал подготовлен в преддверии старта курса «Highload Architect».