Привет, меня зовут Денис Лыков, я IT-директор в ЮMoney. Порассуждал про тимлида в ИТ — кто это, что он делает, какие использует инструменты и чем отличается от техлида. Разобрал задачи тимлида в финтехе и пофантазировал, есть ли кто-то выше по должности, чем он (оказалось, что да!). Статья будет полезна тем, кто работает тимлидом, хочет им стать или сделать тимлидом коллегу.
Почему разработчики боятся идти в тимлиды
Больше 10 лет назад, когда я работал старшим разработчиком в бэкенде, ко мне пришли с предложением стать тимлидом. И я ответил — нет. Боялся, что разучусь программировать, что буду менее полезен. И кому я тогда буду нужен? Но сейчас я считаю, что тогда мне стоило задать себе два вопроса:
Что значит быть тимлидом?
Если руководители такие бесполезные, почему они так много зарабатывают?
В чём разница между техлидом и тимлидом
Техлид — это неформальная роль. Когда инженер оказывается в команде самым опытным и инициативным, он начинает продвигать совершенствование инженерных практик. Этакий технический эксперт, проактивный и производительный локомотив команды, который задаёт направление движения в сфере технологий.
Тимлида можно сравнить c капитаном судна, который обеспечивает слаженную paбoтy экипажа и прокладывает общий маршрут к цeли. Он — связующее звено между специалистами разных команд, создаёт атмосферу эффективного взаимодействия, чтобы все быстрее достигали результатов.
Базовые качества тимлида такие:
Естественная высокая мотивация.
Инженерная культура.
Стремление к постоянному развитию.
Ответственность.
Если у вас этого нет, наверное, не стоит идти в тимлиды. А если есть, то в душе вы тимлид, который готов идти к результату и тащить за собой команду. И рано или поздно к вам придут с таким же предложением, с каким пришли ко мне. Осталось понять, нужно ли это вам.
Что такое пирамида тимлида
Тимлиды бывают разными. Это удобно показать в виде пирамиды. В её основе — те самые качества, о которых мы говорили выше. От них можно начинать идти вверх.
Инженер. Представим, что вы инженер: уверенно пишете код, понимаете систему, с которой работаете. Вам дают человека, который недавно пришел в компанию, возможно даже из института, без опыта. Вы делегируете ему часть своих задач и смотрите, как он их делает. Направляете, обучаете, помогаете. Вы — инженер-тимлид.
Руководитель группы. Постепенно вы растёте и становитесь руководителем группы. Вам выделяют пока не целый проект, а его часть, но она автономная, в ней вы всё понимаете. У вас, скажем, три бэкенд-разработчика, один фронтенд-разработчик и даже тестировщик. Вы руководите ими, распределяете задачи. И понимаете всю техническую подкапотную по своему куску проекта. Но, скорее всего, всю техническую задачу в целом и архитектуру всего решения вы со своего места не видите. Только тот кусочек, который к вам попал.
Руководитель отдела. Дальше можно вырасти до руководителя отдела, например бэкенд-разработки. Тут к ревью кода добавляется желание и необходимость понимать работу всех компонент и систем, которые производит ваш отдел. Может, вы пока не так хорошо знаете, что там на фронтенде, не знаете работу каждой внутренности отдельного компонента и тем более класса. Но общую логику, взаимосвязи, планы развития этих компонент вы уже понимаете.
Руководитель департамента. К бэкенду прибавился фронтенд, мобильная разработка, может, аналитика данных и тестирование. Вы всё ещё что-то помните про бэкенд, но уже чуть меньше понимаете в новых версиях Java. Зато у вас расширяется кругозор. Вы понимаете, куда двигаться всем направлениям — не только бэкенду. Разбираетесь во всех процессах и инструментах разработки — и, конечно, в бизнес-логике. Вы не просто знаете, что делают компоненты бэкенда и зачем, — но и как они связаны с компонентами фронтенда и даже с мобильной разработкой и мобильными приложениями.
Системный архитектор. Это ещё выше. Обычно у него нет подчиненных (или мало), но это один из самых уважаемых людей в IT. Этот специалист понимает — и уже не на уровне разработки, — как работает каждый компонент, для чего он нужен, когда и кого он вызывает и с какими параметрами. Системный архитектор знает про масштабирование и отказоустойчивость инфраструктуры, понимает всё про производительность системы. Он оперирует понятием программно-аппаратного комплекса.
СТО или CIO. Дальше можно дорасти до технического директора (СТО) или до ИТ-директора (CIO). Если компания не настолько большая, чтобы нужны были отдельные технические директора по направлениям, то хватает ИТ-директора. Но с масштабами, например, Сбера нужны технические директора. В любом случае на этой ступеньке вы уже всё понимаете и про разработку, и про бюджет, и про ресурсы, и про планирование. Но технический директор всё ещё не отвечает за общие части. За них отвечает ИТ-директор. А также за мониторинг, хелпдеск, саппорт, инфраструктуру. В общем, сложности возрастают — а вместе с ними и кругозор, ответственность и цена ошибки.
Почему простой инженер тоже может быть тимлидом
Считаю, что в этой пирамиде все специалисты в той или иной мере — тимлиды. Вот, например, трушный инженер, который пишет драйвера для видеокарт и компиляторы на ассемблере. Казалось бы, просто инженер. Вчера, может, так и было. А сегодня простые инженеры пользуются такими понятиями, как Jira, Kanban, Velocity, Story Point и прочими терминами из проектной деятельности. А это всё уже элементы управления.
По мере вашего продвижения вверх ваши тимлидские качества должны возрастать. С каждой ступенькой вы всё больше — про организацию команды, про планирование и достижение результата. И всё меньше — про узкие технические знания. Вы больше знаете вширь, но меньше — вглубь.
Так было и у меня. Я рос внутри одной компании, куда много лет назад пришёл старшим разработчиком. Сначала дали группу, потом отдел, потом ещё один и так далее.
А вот, например, эксперты будут бесконечно погружаться вглубь. Эксперты нужны в любой команде и в любой компании. И им не требуются лидерские качества, они не собираются управлять командой — они хотят знать в совершенстве какую-то отдельную техническую область.
Какие задачи решает тимлид
На каждом уровне у тимлида свой контекст и свои задачи. По мере движения вверх понимание контекста будет расширяться, а сложность задач и ответственность — возрастать.
Инженер и руководитель группы. На этом уровне вы занимаетесь проектированием, разработкой, тестированием. Делаете ревью технических решений и готового кода. Как правило, всё это на уровне объекта внутри сервиса или всего сервиса целиком. Или группы сервисов, если они работают в связке.
Пример: есть сервис нотификаций. На этом уровне не обязательно знать от и до, как он работает. Вы можете разбираться только в том, как работает, скажем, отправка пушей. Вам не надо задумываться, зачем мы написали этот сервис, как он деплоится, сколько у него копий на проде, как он масштабируется и какие сервисы — его клиенты.
Руководитель отдела или департамента. Ваши задачи — проектирование, разработка, тестирование, ревью технических решений и кода, но уже на уровне группы сервисов. Это могут быть либо все сервисы вашего отдела, либо сервисы какого-то домена, за который вы отвечаете.
Пример: нашему пользователю может быть доступен сервис регистрации, настроек, выпуска карт, чего-то ещё. Все эти сервисы взаимодействуют между собой и используют сервис нотификаций для получения кодов доступа и уведомлений. И вы уже понимаете всю эту связку.
Системный архитектор / технический директор / ИТ-директор. Тут времени на разработку у вас уже нет — по крайней мере, на работе. Если вы крутой директор, вы будете стараться следить за технологиями, изучать новые языки. А на работе надо будет заниматься проектированием, проводить ревью технических решений и кода на уровне всей системы и инфраструктуры. Тот самый программно-аппаратный комплекс. Вы должны понимать, как живёт и функционирует весь организм компании с технической точки зрения — в моём случае, организм ЮMoney.
Какие инструменты нужны тимлиду для разработки и сопровождения
Проектирование, разработка, тестирование, ревью технических решений и кода — всё это некие процессы. А для качественных процессов нужны подходящие инструменты.
Эффективные и универсальные процессы и инструменты разработки, тестирования и сопровождения — это зона ответственности тимлида.
Какие инструменты и процессы могут быть в распоряжении инженера или руководителя группы:
На уровне системного архитектора / технического директора / ИТ-директора, в принципе, инструменты будут те же самые. Но использоваться они будут в ограниченном количестве.
После разработки надо ещё как-то всё задеплоить и начать эксплуатировать. Для этого нужны инструменты и процессы сопровождения. Все инженеры разработки и эксплуатации так или иначе постоянно ими пользуются. А хороший тимлид, причём на любом уровне, участвует в обработке инцидентов.
Если вы директор департамента или архитектор, вы будете использовать те же самые инструменты, но, опять же, в ограниченном количестве.
Если же вы ИТ-директор, то со своей колокольни обозреваете и понимаете всю систему: связку ПО с инфраструктурой, бизнес-логику основных процессов и так далее. Поэтому вы можете направить, подсказать, простимулировать. У нас в ЮMoney тимлид должен придумать, как улучшить жизнь разработчиков и инженеров поддержки, эксплуатации. Должен пропилотировать изменения, внедрить их, зачастую через сопротивление. И потом бесконечно улучшать.
Управление на каждом уровне пирамиды
Теперь поговорим про управление.
Все — от инженера до ИТ-директора — решают управленческие задачи. От старшего разработчика до ИТ-директора. Просто у кого-то на подзадачи уходит час, у кого-то день, а у кого-то — квартал.
Пример классических/обязательных/стандартных задач, которые решает каждый тимлид:
Анализ постановки и выработка технического решения.
Оценка сроков или стоимости решения.
Декомпозиция на подзадачи.
Есть ли кто-то выше ИТ-директора в пирамиде тимлидов
По нашей пирамиде кажется, будто выше ИТ-директора никого уже нет. На самом деле есть.
Считаю, все эти люди — тоже тимлиды. Они знают всю подноготную своего дела, определяют техническое развитие своих компаний, а оно зачастую сильно влияет на успех бизнеса, выводит компанию на новые рынки, создаёт тренды.
Какие могут быть задачи у тимлида в финтехе
Скажем, вы захотели поменять версию базового фреймворка вашей фронтенд-платформы. У вас 50 сервисов на фронтенде, и все надо обновить. Для этого нужно выбрать наиболее безопасного кандидата, всё пропилотировать, выстроить план обновления остальных компонент. Но тут понятно, что и как делать, и нет влияния на бизнес-логику.
Задача посложнее — редизайн мобильного приложения. Тут уже придётся поработать со смежными подразделениями, спланировать коридорное тестирование и А/В-тесты. Подумать о том, как быстро пользователи переходят на новые версии на разных платформах и сколько надо поддерживать старые версии. И так далее. Вы уже выходите за рамки своей привычной зоны ответственности.
Задача ещё сложнее — эмиссия карт «Мир». Эта задача, хоть и несложная, займёт год, в лучшем случае полгода. Тут большая неопределённость. Встают вопросы каналов, сертификации, стоимости. Вам нужно организовать несколько команд и их параллельную работу. Тут уже и эксплуатация, и инженеры, и процессинг, и разработка. Но всё же это понятная задача. Есть документация, есть API, оборудование. Купи, интегрируй, пройди сертификацию — и всё, запускай эмиссию.
Но есть проекты с более высокой долей неопределённости. Например, связанные с международной экспансией бизнеса. Вы всё понимаете про систему и инфраструктуру своего бизнеса в России, но не знаете, сколько будет стоить выйти на рынок, например, Китая или Бразилии. Сколько это займет времени? Сколько надо людей? Непонятно. Надо как-то тиражировать вашу систему в Китай и Бразилию. А надо ли тиражировать тот же самый код? Или надо склонировать код и поддерживать разные версии для разных стран? И как получать данные обратно? Как собирать единую аналитику по компании в целом и с разделением на регионы? Масса вопросов.
Чем выше вы поднимаетесь, тем более сложные технические и продуктовые задачи вам нужно решать. Кругозор постоянно расширяется — за это я и люблю тимлидские позиции.
Что в голове у тимлида
Для меня лидер в ИТ — это человек, который помогает достигать целей с наилучшим результатом. А методы управления и уровень принятия решений зависит от позиции.
Если вы инженер, что для вас наилучший результат? Тут нужно думать не только о качестве отдельного кода, а о качестве всей архитектуры в целом — она должна быть гибкая, масштабируемая. Я думаю о технологиях и процессах — без них никуда. Необходима качественная инфраструктура — масштабируемая, отказоустойчивая и дешевая.
Каждый день тимлид сталкивается с множеством вопросов. И они всё время новые:
Что использовать — железо или облака?
Облако своё или готовое?
Если готовое, как не получить vendor lock — зависимость от конкретного поставщика?
Как найти баланс между безопасностью программно-аппаратного комплекса, скоростью поставки и качеством?
Вопросы выше можно отнести к развитию бизнеса, к продуктовым проектам. Но есть ещё большой внутренний мир ИТ и всей компании в целом, где регулярно возникают задачи цифровизации, автоматизации, техдолга и другие. А еще тимлиду, конечно, важно следить за трендами, пробовать что-то новое, думать о технологиях «завтрашнего дня».
Вывод
Тимлид — капитан судна: где-то он стоит у штурвала, где-то уже ничем не рулит, но у него есть рулевой — и ещё два отдыхают в каюте. Капитан знает, как доплыть из точки А в точку Б, чтобы при этом сохранить груз и чтобы пассажирам было комфортно. Он знает, как пройти антикоррозийную обработку корпуса корабля. Знает, какой у него тип двигателя, сколько ему нужно горючего и когда стоит переходить на новую версию — более производительную и менее затратную.
Если возвращаться к началу и к тому вопросу, который мне задали — хочу ли я в тимлиды, — оборачиваясь на весь пройденный путь, я бы однозначно ответил: да!
Если вы тоже тимлид или пока только на пути к этой роли, поделитесь своими впечатлениями от должности: согласны с мнением Дениса? Особенно нам интересно узнать мнения специалистов, которые не хотят в тимлиды и могут рассказать, почему. =)
