Tech Lead — новый вызов для аналитика

Октябрь 2023. Мне говорят: «Формируй команду с нуля — новое направление, конфигуратор персонализированных предложений». Несколько лет я рос на графовой платформе Mirion — от старшего аналитика до IT-лида, прошёл объединение команд прикладных сервисов Big Data. А теперь — чистый лист: ни людей, ни архитектуры, ни процессов. Первое, что я делаю — открываю рабочий мессенджер и пишу руководителю: «Принял. Начинаю нанимать». Второе — закрываю мессенджер и минут десять молча смотрю в монитор, осознавая, что весь мой аналитический опыт не подготовил меня к этому.

Я аналитик. Был аналитиком — с 2021 года рос в Иннотехе на графовой платформе, потом возглавил объединённую команду прикладных сервисов Big Data. А теперь мне надо собрать команду разработки нового продукта и возглавить её. На Analyst Days 2024 я рассказал эту историю — как аналитик стал IT-лидом, а потом руководителем кластера. Без прикрас.

Развилка, которую не видишь

Аналитик, который перерос уровень «напиши ТЗ» — что дальше? Я знаю минимум шесть направлений, и каждое ломает привычный образ мышления по-своему:

Направление	Фокус	Что качать
Product Manager	Рынок, метрики	Бизнес-стратегия, unit-экономика
Product Owner	Бэклог, приоритеты	Scrum, стейкхолдер-менеджмент
Tech Lead	Команда, архитектура	Код, CI/CD, people management
Архитектор	Системный дизайн	Интеграции, NFR, паттерны
Аккаунт-менеджер	Клиент, контракт	Переговоры, финансы
Консультант	Экспертиза, методология	Публичность, фреймворки

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

Почему именно Tech Lead

Мой путь был нелинейным. Я знал полный цикл разработки не из книжек, а из практики — сам автоматизировал, сам разворачивал, сам дебажил. Работал с данными в Nestlé, выстраивал data quality процессы в Kerama Marazzi, потом стал ведущим аналитиком в ВТБ. На каждом этапе залезал глубже, чем требовала должность: там, где аналитик обычно останавливается на диаграмме процесса, я шёл смотреть, что происходит в коде.

Аналитик видит продукт глазами бизнеса. Разработчик — глазами кода. Tech Lead должен видеть обоими одновременно. Если ты вырос из аналитики — бизнесовый глаз натренирован. Осталось прокачать технический. Это проще, чем разработчику учиться понимать бизнес, — я убедился на собственном опыте.

Строительство с нуля: пять месяцев боли

С октября по февраль — пять месяцев непрерывного найма. Десятки собеседований. Вот как это выглядело на практике.

Первые два кандидата — идеальные резюме. Senior-разработчики с опытом в enterprise. На собеседовании оба отвечали по учебнику. Я был в восторге, пока не задал один вопрос: «Расскажи про ситуацию, когда ты был не согласен с решением команды. Что делал?» Первый ответил: «Я делаю как скажут». Второй: «Я обычно работаю один, мне так продуктивнее». Оба были технически сильны. Обоим отказал.

Худшее собеседование — кандидат, который соврал про опыт с графовыми базами данных. Я это понял на третьей минуте технического вопроса, но провёл интервью до конца из вежливости. Потом час злился на себя за потраченное время. С тех пор ввёл правило: если за пять минут понимаю, что не подходит — честно говорю и заканчиваю. Уважение к чужому времени важнее социального комфорта.

Момент, когда команда «склеилась» — январь. К тому моменту собралось ядро из четырёх человек. Мы сели обсуждать архитектуру графовой платформы, и впервые за три месяца я почувствовал, что не вытягиваю процесс в одиночку. Люди спорили друг с другом, предлагали альтернативы, дополняли мысли. Не кивали, а думали. Это был тот момент, когда я понял: команда — есть.

Главный урок найма: собирать команду — не про «нанять лучших». Про «нанять тех, кто будут работать вместе». (Подробнее о паттернах, которые я научился видеть на собеседованиях — в red flags найма.) Звёздный разработчик, который не умеет коммуницировать, разрушит команду быстрее, чем создаст ценность.

Навыки, которых не было

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

CI/CD нюансы. Я знал, что pipeline существует, знал его этапы. Но когда разработчик приходит с вопросом, почему сборка падает на конкретном stage — нужно разбираться на уровне конфигурации. Не чинить самому, но понимать, что происходит — обязательно. Первый месяц я тратил вечера на изучение конфигов Jenkins и GitLab CI, чтобы на утренних стендапах не выглядеть идиотом.

Глубина code review. Просматривать pull request и реально ревьюить код — разные планеты. Первое время я пропускал архитектурные проблемы, замечая только стилистические — неправильные имена переменных, отсутствие комментариев. Серьёзные вещи — утечки абстракций, нарушения SOLID, неэффективные запросы — проходили мимо. Пришлось вырабатывать насмотренность: читать чужой код системно, задавать себе вопрос «а что будет, если нагрузка вырастет в десять раз?» на каждом merge request.

Оценка задач. Аналитик оценивает свою работу — одна переменная. Лидер оценивает работу команды — система уравнений. Зависимости, параллельность, риски, технический долг. Мои первые оценки были чудовищно неточными. На одну задачу я заложил неделю — заняла три. На другую — три дня, делали две недели. Со временем выработал подход:

1. Декомпозируй до задач не крупнее трёх дней — на этом уровне ошибка предсказуема
2. Добавь буфер 20-30% на интеграционные сюрпризы
3. Учти «невидимые» задачи: code review, деплой, согласования, больничные
4. Проверяй оценку с тем, кто будет делать — лидер всегда оценивает хуже исполнителя

Умение говорить «нет»

Это заслуживает отдельного раздела, потому что «нет» — самый недооценённый навык руководителя.

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

Заказчик, конечно, не обрадовался. Но когда я показал зависимости на доске — конкретные задачи, которые придётся подвинуть, конкретные риски — разговор перешёл в конструктивное русло. Отчёт ушёл в следующий спринт. Релиз вышел вовремя. А заказчик с тех пор приходил не с «надо к пятнице», а с «какие у вас ближайшие окна?»

Каждое «да» без оценки последствий — это долг, который копится. Команда сгорает, качество падает, технический долг растёт. Лидер, который не умеет говорить «нет» — не лидер, а буфер между бизнесом и командой. Причём буфер одноразовый.

Удержание: как не потерять тех, кого собирал пять месяцев

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

Первое, что сработало — матрица компетенций. Не формальная табличка для HR, а рабочий инструмент, который мы обсуждали на каждом one-on-one:

Компетенция        │ Текущий │ Целевой │ Как прокачать
───────────────────┼─────────┼─────────┼──────────────────
System Design      │  ██░░░  │  ████░  │ Архитектурные ревью
Kafka/Streaming    │  ███░░  │  ████░  │ Задача X в спринте
SQL оптимизация    │  ████░  │  ████░  │ Поддерживать
Менторинг          │  █░░░░  │  ███░░  │ Онбординг новичка

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

Второе — прозрачность. Я не скрывал от команды сложности проекта. Когда люди понимают контекст решений — они принимают трудности как часть работы, а не как произвол начальства. «Мы берём эту задачу, потому что без неё не пройдём аудит» звучит иначе, чем «берём, потому что я так решил».

Третье — ротация задач. Разработчик, который полгода пилил только ETL, получает задачу на API. Медленнее в моменте, но удерживает интерес и расширяет экспертизу. Человек, которому скучно — уже одной ногой на собеседовании в другой компании.

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

Карьерный парадокс

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

Разница — в масштабе:

Навык	Аналитик	Tech Lead
Декомпозиция	Требования и user stories	Стратегия и roadmap
Вопросы	Стейкхолдерам	Себе и команде
Системный взгляд	Продукт	Люди + процессы + технологии
Коммуникация	Бизнес ↔ Разработка	Команда ↔ Руководство ↔ Бизнес
Ответственность	За документ	За результат команды

Что бы я сделал иначе

Если бы я мог вернуться в тот октябрь и дать себе три совета:

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

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

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

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

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

Если ты сам на пути от аналитика к тех-лиду и хочешь ускорить рост — я провожу менторинг именно для таких переходов.

---

По мотивам несостоявшегося доклада на Analyst Days 2024 — заявка была принята, но выступление не случилось из-за отсутствия времени на подготовку. Материал написан по итогам того же опыта.

Ваш ДПУПП