Работа техлида требует развитых навыков и в технической сфере, и в управлении командой, и в общении с людьми. Дмитрий Макаров, техлид Яндекса, руководил несколькими крупными проектами — например, внедрением ленты рекомендаций в приложениях. Дмитрий рассказал, какие ключевые задачи он выполнял в этой роли, как добивался синергии между бизнесом и разработкой, а также дал советы начинающим руководителям.
Дмитрий, вы работаете на крупных проектах Яндекса, где миллионы пользователей зависят от решений вашей команды. Расскажите, как выглядит ваша роль в таких условиях, и какие ключевые задачи вы решаете как техлид?
Главная задача техлида — это реализовывать задачи бизнеса с помощью управления IT-командами и ресурсами. Техлид одновременно должен быть и продвинутым разработчиком, и продакт-менеджером, и тестировщиком, и стейкхолдером, который определяет конкретные метрики. Кроме того, важно уметь аргументированно защищать свою точку зрения и перед командой, и перед остальными стейкхолдерами. Таким образом, это комплексная роль, которая включает в себя глубокую техническую экспертизу и развитые софт скиллы.
В качестве техлида я занимаюсь широким спектром задач: планирую этапы работ и ежедневно мониторю статусы, согласовываю и выделяю ресурсы, принимаю продуктовые и технологические решения, коммуницирую с менеджерами и дизайнерами, провожу встречи 1:1 с разработчиками и мотивирую команду. То есть я играю роль связующего звена между бизнесом и разработчиками, и от моих решений зависит успех того или иного проекта в Яндексе.
Я знаю, что вы выделили ленту рекомендаций в отдельный компонент, который затем интегрировался в другие части Яндекс.Маркета и приложения вроде Яндекс.Go. Как вы обеспечивали совместимость, согласованность архитектуры и переиспользуемость этого компонента между командами?
Да, задачей нашей команды было выделить код ленты в мобильном бэкенде Яндекс.Маркета, чтобы сделать его переиспользуемым и совместимым с другими продуктами Яндекса. Работы велись через фреймворк Flex, который умеет отрисовывать интерфейсы по верстке MAPI, присылаемой сервисами. Так как функционала Flex не хватало, мы добавили туда часть нативного кода, отвечавшего за рендеринг ленты и отдельных сниппетов.
Чтобы другие приложения могли использовать только ленту без всего фреймворка, мы раздробили Flex на модули и выделили Feed SDK модуль, который включал процессы по работе с MAPI и нативный код ленты. Для каждого приложения Яндекса мы написали отдельный сервис, который преобразовывал данные из их источников в формат ленты.
Все это позволило снизить нагрузку на приложения, обеспечив при этом совместимость и согласованность ленты. В итоге, мой подход заключается в модульности, изоляции и инъекции только необходимых частей, что позволяет создать гибкий и масштабируемый компонент, который используют несколько команд в разных продуктах.
О роли техлида часто говорят, что нужно меньше кодить и больше управлять, но вы, насколько я понимаю, стараетесь сохранять обе функции. Почему для вас важно оставаться в коде, даже когда вы руководите командой?
По моему мнению, инженерные практики сохраняются на любом уровне ответственности. Я все равно программирую — только не кодом, а текстом или процессами. Меняется только зона ответственности и цена принятия решений. То есть, если разработчик на 15 минут вывел из строя сервер, то цена его ошибки будет пара миллионов. А если СТО привел к кризису целое направление, то компании это будет стоить миллиарды.
Разница между простым разработчиком и техлидом только в том, что во втором случае ты не поддерживаешь актуальность знаний своей кодовой базы. Но это уже становится ответственностью команды, которую ты строишь вокруг себя. Соответственно, на любой внутрикомандной встрече можно задать вопрос о коде своим разработчикам. Как раз умение задавать вопросы и быть дотошным остается со мной всегда — потому что это фундаментальный навык инженера.
Учитывая, что вы работаете на проектах, где взаимодействуют мобильная, бэкенд и смежные команды, какие принципы помогают вам эффективно координировать работу разных команд?
Универсальный принцип — это дисциплина. Важно регулярно проверять статусы задач и обновлять информацию у всех участников процесса. Для своей команды я устраиваю ежедневные созвоны — для нас это не только сообщения о статусах работы, но и общение. Команда знает, кто чем занимается, у кого какие проблемы, кому нужна подсказка — и это позволяет быстро решать все вопросы.
Также я устраиваю часовые командные встречи, где собираются продакт-менеджеры, дизайнеры, тестировщики, бэкендеры, аналитики и другие задействованные лица. Там мы обсуждаем абсолютно все вопросы и решаем, какие наши действия сделают проект максимально полезным для бизнеса.
Вы активно обучаете и менторите коллег. Какие подходы к развитию команды работают для вас лучше всего?
Я вкладываюсь в тех, кто сам хочет развиваться. Когда я вижу у сотрудника потенциал, то предлагаю ему свою помощь — если он согласен, то прошу его пройти тест, который показывает сильные и слабые стороны. Обычно мы вместе выделяем два хард скилла и один софт скилл, над которыми необходимо поработать, и составляем план на полгода-год.
По моему мнению, лучше делать акцент на сильных сторонах — развивать навыки, которые нравятся, и в которых сотрудник чувствует потенциал. Идеально, когда пожелания сотрудника совпадают с его возможностями и с планами компании. Кстати, такой принцип я советую использовать не только в работе, но и в жизни.
Обучаю я через практику — например, написать какой-либо код, собрать и провести встречу, договориться о чем-либо с другой командой. Бывают и теоретические задания — например, изучить фреймворк. Но я стараюсь, чтобы эти знания сразу применялись на практике. Иногда я могу передать сотруднику и часть проекта, консультируя его по ходу работы. Это позволяет ему не только почувствовать себя увереннее, но и заявить о себе продакт-менеджерам и другим стейкхолдерам.
Я уделяю большое внимание дисциплине, поэтому раз в неделю устраиваю встречи 1:1, где мы общаемся о проектах, рабочем настрое и общем эмоциональном фоне сотрудника. На встречах я стараюсь мотивировать своего подопечного и обсуждать с ним интересные вдохновляющие идеи. А
Техлид часто оказывается между амбициями бизнеса и ограничениями команды. Как вы находите баланс между этими двумя сторонами?
Опять же, главное здесь — это дисциплина и последовательность. Перед встречей по планированию проекта мы с командой заранее оцениваем сложность и стоимость задач, поэтому к менеджерам я прихожу уже с готовыми расчетами. И на встрече мы сразу можем решить, какие сроки и ресурсы понадобятся нам для проекта.
Находить баланс помогают регулярные встречи с другими командами и стейкхолдерами — так бизнес в курсе, чем мы заняты, и на каком этапе находится проект. Бизнес тоже предоставляет нам планы, чтобы мы заранее прогнозировали свою занятость. Поэтому авралы и горящие дедлайны бывают редко.
Более важную задачу я вижу в том, чтобы не допустить выгорания команды — ведь выгоревший сотрудник не сможет работать эффективно. Поэтому я занимаюсь принятием hr-решений, которые помогают команде продуктивно выполнять проект и получать удовлетворение от своей работы.
Какие неожиданные или сложные уроки техлидства вы вынесли, и что из этого могут взять на вооружение начинающие лидеры?
Поначалу кажется, что техлидство и работа с людьми — это всегда разнообразие. Придется работать с различными задачами, общаться с десятками сотрудников — и к каждому предстоит найти подход. Это может показаться очень сложным.
Но на самом деле, с опытом можно выявить для себя повторяющиеся паттерны — и в задачах, и в общении с людьми. Если следовать определенным алгоритмам, сохранять регулярность встреч и не отклоняться от выбранных стратегий, то неверные решения будут сведены к минимуму.
Поэтому я бы посоветовал начинающим техлидам не бояться ответственности, а постараться выработать закономерности ведения встреч и проектов — тогда любая задача будет выглядеть проще.
