Тимлид, архитектор или QA: куда расти разработчику, который не хочет в менеджеры

Считается, что после сеньора у разработчика остаётся один путь наверх: взять команду и руководить людьми вместо того, чтобы писать код. Управлять хочется далеко не всем, и из-за этого рост будто останавливается.

Почему стать тимлидом — это не повышение, а смена профессии

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

Но в реальности часто всё по-другому. У тимлида есть свой список обязанностей:

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

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

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

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

Трек 1. Тимлид — если всё-таки хочется к людям

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

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

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

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

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

Самый адекватный способ войти в роль выглядит так.

1. Сначала присмотритесь, чем на самом деле занят тимлид в вашей компании: возможно, вы представляете себе эту позицию неверно.
2. Затем скажите своему руководителю, что хотите попробовать.
3. Скорее всего, вам выдадут перечень базовых обязанностей, которые можно подхватить заранее, например починить давнюю процессную проблему команды.
4. Так вы примерите роль до формального назначения, и если через полгода станет ясно, что созвоны и координация вас выматывают сильнее любого легаси, откажетесь без потерь для карьеры.

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

Трек 2. Архитектор — рост в глубину без перформанс-ревью

Этот трек подходит тем, кому по-прежнему интересны технологии, но тесно в рамках одного сервиса. Архитектор проектирует системы целиком: как сервисы взаимодействуют между собой, выдерживают нагрузку, масштабируются и переживают изменения требований.

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

Внутри самой профессии есть свои виды архитекторов:

1. Софтверный архитектор решает технические задачи: как скомбинировать компоненты, как интегрировать системы между собой. Бизнес-контекст на этом уровне знать необязательно, схема с базой, кэшем и очередью может обслуживать что угодно.
2. Солюшен-архитектор добавляет к этому бизнес-фокус. Ему приносят проблему на языке заказчика, например «падает конверсия» или «выходим на рынок с другим регулированием», и он переводит её в структуру работ, понятную командам. На этом уровне приходит осознание, что иногда лучшим решением оказывается таблица с формулами на общем диске, а вовсе не система на год разработки.
3. Матёрый солюшен-архитектор учитывает ограничения: бюджет, сроки, зрелость инфраструктуры, скиллы команды. Отличная технология без инженеров, умеющих её эксплуатировать, превращается в обузу, поэтому одинаковая бизнес-задача в двух компаниях даёт два разных решения.
4. Уровень выше подразумевает масштаб в десяток команд и стратегический горизонт: решения должны оставаться валидными десять лет, а конфликты стейкхолдеров приходится разруливать самому, потому что эскалация наверх заканчивается ответом «разбирайтесь сами».

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

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

Трек 3. QA — горизонтальный манёвр, который недооценивают

У разработчиков к этому треку предвзятое отношение. QA многие держат в голове как стартовую площадку для входа в отрасль, поэтому движение туда после нескольких лет разработки выглядит понижением. Такое представление опирается на образ тестировщика, который вручную прокликивает формочки по чек-листу. Современное QA устроено сложнее: инженер по качеству проектирует стратегию тестирования, строит автоматизацию, встраивает проверки в CI/CD и влияет на процессы всей команды, включая то, в каком виде задачи вообще доезжают до разработки.

Бэкграунд разработчика конвертируется здесь напрямую, и лучше всего в автоматизации. Автотесты пишутся на тех же языках, на которых вы уже работаете: Java, Python, JavaScript, C#. По сути автоматизатор разрабатывает отдельный программный продукт, у которого есть своя архитектура, свои паттерны и своё легаси, если писать его небрежно. Умение проектировать код, разбираться в чужих API и настраивать пайплайны сразу выделит вас среди коллег, пришедших в QA с нуля.

Кроме автоматизации, инженерный опыт открывает для вас новые специализации:

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

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

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

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

Как выбрать трек и что делать

Выбор упрощается, если честно ответить себе на вопрос, от какой части работы вы получаете больше всего удовольствия. Попробуем сформулировать ориентиры:

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

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

Примерять треки удобнее всего там, где проектов много и они разные. В сервисных компаниях вроде Centicore Group, которая занимается заказной разработкой, контролем качества ПО, ИТ-консалтингом и модернизацией легаси-систем, в которой за 13 лет накопилось более 500 выполненных проектов, и на такой ротации можно попробовать роль автоматизатора, архитектора или тимлида без смены работодателя: закончился один проект, на следующем берете другую зону ответственности. Посмотреть, с какими задачами там работают, можно на сайте Centicore.

***

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

У всех направлений есть два главных правила:

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

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