Во многих IT-командах карьерная система заканчивается знакомой системой: джун, мидл, сеньор, лид. Иногда между ними добавляют промежуточные варианты middle+ и middle−, но понимания происходящего от этого обычно не добавляется. Ответ на главный вопрос все еще приходится вытягивать из руководителя: что конкретно нужно сделать, чтобы перейти дальше?

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

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

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

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

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

Критерий должен описывать конкретное действие. Например: «Самостоятельно проводит сложные встречи с заказчиком и фиксирует договоренности». Вы сразу понимаете, что от вас ждут, и на какой задаче можно показать этот навык.

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

Почему сеньор не должен становиться тимлидом

Линейный путь «джун → мидл → сеньор → тимлид» подходит не всем. Если вам нравится разбираться в архитектуре и писать код, повышение до руководителя окажется сменой профессии: вместо технических задач появятся управление командой, встречи и контроль процессов.

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

На чем держится рабочий карьерный трек

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

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

Что получает компания

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

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

Итого

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

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

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

Сначала формулируют задачу бизнеса

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

На старте заказчик и подрядчик договариваются:

• какую часть продукта забирает внешняя команда;
• какого результата от неё ждут;
• какие изменения планируются дальше;
• где заканчивается её зона ответственности.

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

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

Настроить порядок работы с изменениями

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

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

1. Внутренняя команда заказчика описывает, что изменилось и зачем это нужно продукту.
2. Внешняя команда оценивает, какие задачи придётся сдвинуть и как запрос повлияет на загрузку, технический долг и сроки.
3. Менеджер подрядчика собирает варианты действий и показывает последствия каждого.
4. Владелец продукта со стороны заказчика выбирает вариант и утверждает приоритет.
5. После этого задача попадает в бэклог или в текущий спринт.

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

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

Включить внешнюю команду в процессы проекта

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

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

Подготовить проект к ротации специалистов

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

1. найти специалиста под требования заказчика;
2. передать ему текущие задачи и контекст проекта;
3. подключить к встречам и рабочим каналам;
4. оформить доступы и нужные документы.

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

Сообщать о рисках вместе с решением

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

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

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

Понять, когда исполнитель стал партнёром

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

Обычно заказчик:

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

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

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

По такому принципу в Centicore Group выстраивается работа выделенных команд: погружение специалистов в контекст проекта, подключение их к процессам заказчика и предварительное согласование порядка взаимодействия. Подробнее о компании и проектах можно узнать на centicore.ru.

Что в итоге

Работа с выделенной командой держится на предсказуемом процессе. Заказчик должен понимать, что произойдёт при смене приоритетов, появлении риска или ротации специалиста. Подрядчик должен быстро оценить последствия, предложить варианты и обновить план.

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

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

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

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

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

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

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

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

Трек 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. каждое из решений обратимо, дорога назад в разработку отработана, поэтому цена эксперимента ограничивается несколькими месяцами адаптации.

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

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

Зачем вообще нужны метрики и причем тут команда разработки

Бизнес, как правило, всегда хочет одного: чтобы мы делали гораздо больше, чем физически позволяет размер команды. Желание «впихнуть невпихуемое» — это классика.

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

• Метрики помогают увидеть реальный поток задач, а не ощущение «мы же целый день заняты».
• Они позволяют говорить с бизнесом на языке скорости и рисков, а не «нам ещё немного пооптимизировать» .

Еще раз скажу: разработка — это «поток», а не магия.

Как мы искали идеальную метрику (и почему из семи оставили только одну)

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

1. Отработанные часы в Jira (с точностью до 15 минут — чтобы видеть, куда уходит время).
2. Индивидуальная Velocity (сжигание Story Points на конкретного разработчика).
3. Time to Market (считали от первой идеи бизнес-заказчика до продакшена).
4. Throughput (пропускная способность — сколько карточек мы закрываем).
5. WIP (лимиты на количество задач в работе).
6. DORA (метрики частоты деплоев и стабильности).
7. Cycle Time (время выполнения задачи от «In Progress» до «Done»).

Что произошло дальше? Классическое «KPI-караоке» методом перебора

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

Сначала мы попробовали трекать часы в Jira. Хотели кристальной прозрачности, но в итоге товарищи разработчки тратили по полчаса в день просто на то, чтобы вспомнить и аккуратно раскидать свои 8 часов по таскам. Мы быстро поняли, что это бессмысленная рутина, и отказались от нее.

Следующей гипотезой стала Индивидуальная Velocity. И тут сработала психология: люди (сами того не замечая) перестали брать сложные задачи или очень сильно дробили их. Зачем рисковать закопаться и испортить свою красивую статистику спринта? Вместо этого разработчики начали наперегонки разбирать легкие минорные баги. Увидев, что командная работа превращается в соревнование, мы свернули и этот эксперимент.

Дальше мы взялись за Time to Market. Ситуация стала еще абсурднее. Задача могла месяцами лежать в бэклоге, пока бизнес писал аналитику, а итоговый график TtM показывал «медленную команду». И хотя санкций не следовало, ребят это дико демотивировало — цифры выглядели так, будто мы плохо работаем. Мы осознали, что оценивать инженерию метрикой, на которую она влияет лишь частично, бессмысленно.

Пытаясь найти рабочую альтернативу, мы поочередно пробовали опираться на Throughput, WIP и DORA. Но без уже выстроенной культуры это тоже давало сбои: Throughput за счет искусственного дробления задач на микроскопические части, а попытка деплоить чаще (ради красивых метрик DORA) приводила к нестабильности тестовых стендов.

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

Мы остановились только на Cycle Time. Почему? Потому что это единственная метрика из списка, которая честно оценивает работу всей системы (процесса), а не утилизацию конкретного человека. Она показала нам, где лежат реальные проблемы в разработке, не заставляя инженеров подстраиваться под графики.

Свой путь: почему метрики нельзя просто «скопировать»

Значит ли наш опыт, что Throughput, WIP или DORA — это плохие метрики? Абсолютно нет. Главный вывод, который мы сделали на своих ошибках: не все метрики подходят друг другу, и не все можно безболезненно внедрять в любой момент.

У каждой команды должен быть свой эволюционный путь. Нашим ключом к выздоровлению стал Cycle Time — именно с него мы начали распутывать процессный клубок. Другой команде, возможно, жизненно необходимо прямо сейчас ввести жесткие лимиты WIP, чтобы перестать тонуть в незавершенке. Третьей — посмотреть на DORA, чтобы перестать ронять прод каждую пятницу.

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

Базовый минимум по цифрам, которые объясняют, «Почему мы не успеваем»

Cycle Time: сколько задача живёт «в работе» на самом деле

Что это такое

Cycle Time — это время от момента, когда команда действительно начала работать над задачей, до момента, когда результат можно считать завершённым (обычно — до состояния «в проде» или хотя бы Done, если релизы батчевые). В классическом определении это от входа в «In Progress» до попадания в «Done».

Когда начинается и когда заканчивается

Чтобы Cycle Time не превратился в хаос, в команде нужны чёткие правила:

· Старт цикла: задача переведена из To Do в первый «рабочий» статус — например, In Progress или «В разработке».

· Конец цикла: задача в статусе Done или «В продакшене» — главное, договориться, учитываете ли вы время релиза внутрь Cycle Time.

Важный момент: ожидание в бэклоге — это не Cycle Time, это lead time и вопросы приоритизации, поэтому «лежит в backlog две недели» не должно портить вам картину по скорости выполнения.

В чём измерять

· В большинстве продуктовых команд имеет смысл мерить Cycle Time в рабочих днях; для инцидентов и срочных багов — в часах.

· Для анализа удобно смотреть не только среднее, но и медиану и, например, 85‑й перцентиль: «половина задач закрывается за 2 дня, 85% — не дольше чем за 5 дней».

Как читать Cycle Time

Cycle Time — это не просто «2,7 дня», это ответ на вопрос: сколько времени задача проводит внутри системы разработки. Если вы видите рост Cycle Time, значит:

· где‑то появилось узкое место (ревью, тесты, деплой);

· или раздут WIP, и задачи просто толкутся в очереди.

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

К примеру, в одной из моих команд бизнес постоянно жаловался: «Разработчики делают интеграцию с новым шлюзом уже три недели, почему так долго?!». Разработчики же клялись, что код написан за пару дней. Мы включили трекинг Cycle Time с разбивкой по статусам и увидели шокирующую картину: медианное время в статусе «In Progress» (написание кода) составляло 2,5 дня.

А вот время в статусах «Code Review» и «Ожидание AppSec» (проверка безопасниками) составляло суммарно 14 дней! Задача просто лежала и ждала, пока у смежного отдела появится окно. Метрика Cycle Time спасла команду от выгорания: мы перестали давить на разработку и пошли договариваться с отделом ИБ о том, что наши фичи не такие страшные как платежи или кредиты и можно проявить немного спокойствия и лояльности(менеджерские хитрости). Скорость доставки выросла кратно.

Как внедрить Cycle Time у себя

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

2. Включите отчёт по времени в статусах в Jira/YouTrack или используйте плагины «time in status» — большинство трекеров это умеют.

3. Зафиксируйте целевой ориентир: например, «85% задач среднего размера должны укладываться в 3 рабочих дня».

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

Throughput: сколько готовых задач вы реально выдаете

Что это такое

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

Как измерять

· Самый простой вариант: посчитать задачи, переведённые в Done за спринт или неделю.

· Лучше разделять типы задач: фичи, баги, техдолг — иначе есть соблазн «набить Throughput» мелкими фиксками.

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

Как читать Throughput

Throughput отвечает на вопрос «сколько мы реально успеваем», а не «сколько хотим успеть». Его удобно использовать так:

· для планирования спринтов: ориентироваться на прошлый Throughput вместо «оптимистичных хотелок»;

· для отслеживания тренда: если состав команды не менялся, а Throughput падает — где‑то ухудшился процесс или накопился техдолг.

Сравнивать Throughput разных команд «в лоб» почти бессмысленно: у каждой свой контекст, размер задач и доля поддержки против фич.

WIP: сколько «незавершёнки» висит в системе

Что это такое

WIP (Work in Progress) — количество задач, которые уже начаты, но ещё не завершены в текущий момент. В канбан‑терминах это всё, что находится между колонками In Progress и Done.

Как измерять

Чтобы посчитать WIP, достаточно:

· определить, какие статусы считаются «в работе» — обычно это разработка, ревью, тесты, готово к релизу;

· подсчитать количество карточек в этих колонках; можно делать это ежедневно или раз в несколько часов, если хотите строить графики.

Некоторые команды дополнительно смотрят WIP в сторипоинтах — так видно не только количество задач, но и их суммарный «вес».

Как читать WIP

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

Высокий WIP = много переключений внимания, очереди перед узкими местами и затянувшийся Cycle Time. Если WIP растёт, а Throughput и число задач в Done не растут, система перегружена.

Как внедрить управление WIP

1. Явно установите WIP‑лимиты на ключевых стадиях: например, не больше 2 задач на разработчика в In Progress и не больше 5 задач в Testing.

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

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

Узкие места: где «бутылочное горлышко» съедает релизы

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

Типичный симптом: в одной колонке доски скапливаются карточки, а время ожидания там непропорционально большое (например, разработка 1 день, ревью 3 дня).​

Чтобы искать такие места не на глаз, используют разбор времени по статусам (это часто умеют трекеры задач) и визуализации потока вроде value stream mapping и cumulative flow diagram (CFD).​

А есть еще что-нибудь из метрик?

Можно ли брать на вооружение другие метрики, которые не указаны в статье? Но тут как говорили классики. “Можно, а зачем?”

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

Мини‑шпаргалка (что мерить и зачем)

Как внедрять метрики и не устроить “KPI-казнь”

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

План на месяц (лёгкий, но действенный):

• Неделя 1: договориться о дефинициях (что такое “начали”, что такое “done”, включаем ли релиз).

• Неделя 2: включить сбор Cycle Time/Throughput/WIP из трекера и посмотреть, где накапливаются очереди.

• Неделя 3-4: выбрать одно узкое место и провести маленький эксперимент.

• Неделя 4: добавить DORA‑метрики из CI/CD/инцидентов и проверить баланс «скорость vs надежность».

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

• Трекеры задач (Jira, YouTrack и др.) дают доски, лимиты WIP, контроль времени в статусах и отчёты по циклу задач, если команда честно обновляет статусы.
• CI/CD‑системы (GitLab CI/CD, GitHub Actions и т.п.) автоматизируют сборку, тестирование и деплой, убирая ручные узкие места и зависимость от «того самого человека, который умеет катить релизы».
• Мониторинг и observability‑платформы помогают быстро находить проблемы в продакшене и снижать MTTR, чтобы команда меньше жила в режиме бесконечных пожаротушений.

Инструмент как часть личности

Возьмем типичную ситуацию: переход на новый стек или поддержка старой базы. Допустим, команда третью неделю (а иногда и третий месяц!) обсуждает, оставить Scala или перейти на Kotlin. Аргументы обеих сторон озвучиваются на первой же встрече, а затем просто повторяются от созвона к созвону. Кто-то говорит об экосистеме, кто-то — о кривой обучения. Внешне это выглядит как техническая дискуссия, но решение не принимается.

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

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

Ловушка единомышленников

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

Однако со временем команда перестает замечать собственные слепые пятна. Любой «человек со стороны» с его новым взглядом воспринимается как дилетант, пытающийся найти изъяны в идеальной системе. Холивары в таких коллективах особенно вязкие: все одинаково уверены, что «очевидное очевидно», а любое альтернативное мнение априори ошибочно или упоминается лишь в контексте «идея хорошая, но делать ее мы не будем».

Скульптура против Lego: конфликт ценностей

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

Хорошая аналогия — скульптура из мрамора против фигурки из Lego. Когда мы видим работы Страцца и Бернини, которые смогли передать в камне эффект тончайшей вуали, мы застываем в восхищении посреди музея. Но создание таких статуй требовало времени, а внести “правки от заказчика” означало бы подвергнуть риску всю работу: попробуйте исправить скол на мраморной статуе, которую ваяли сильно дольше, чем планировалось. В случае с конструкцией из Lego все намного проще: вынул блок, вставил другой, и вот из фигурки кошки уже получился «Тысячелетний сокол».

Чем сложнее язык или технология, тем глубже оказываются ошибки и тем труднее их потом найти. Причем платит за это не только тот, кто писал. Автор ошибки как раз легко может к этому моменту уже уйти на повышение. Но каждый следующий человек, который начнет взаимодействовать с этим кодом, заплатит ту же цену. Технический долг в командах почти всегда описывают одинаково: «это то, что написали до меня». Мы сильно реже склонны упоминать его, имея в виду собственный код и свои планы. Сложные решения, выбранные ради красоты концепции, — один из самых надежных способов создать именно такой долг.

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

Конфликт как трудности перевода

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

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

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

Молчание как последствие конфликтофобии

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

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

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

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

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

Эксперты Centicore Group собрали чек-лист из 12 пунктов, которые реально работают при выборе интегратора, а когда у вас станет вопрос подрядчика – вы можете воспользоваться этим списком.

1. Опыт в вашей индустрии

Системный интегратор, который делал проекты для e-commerce, не обязательно справится с финтехом. У каждой индустрии свои особенности: требования к безопасности, специфика бизнес-процессов, регуляторные ограничения.

Что проверять:

1. Портфолио с проектами в вашей сфере. Нужны конкретные кейсы: что делали, какой стек, какие результаты.
2. Понимание специфики. Если интегратор сразу задаёт правильные вопросы про ваши бизнес-процессы — хороший знак. Если предлагает типовое решение без погружения в специфику — советуем искать дальше.
3. Измеримые результаты. Везде понятные показатели: на сколько сократили время обработки заявок, сколько проект занял по времени, какая команда специалистов и к чему в итоге пришли.

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

2. Что по техстеку и обновлениям

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

На что смотреть:

1. Соответствие вашему контуру. Если у вас закрытый on-premise, а подрядчик умеет деплоить только в публичные облака — вам не по пути.

2. Релевантные сертификаты и лицензии. Если делаете финтех — нужен опыт прохождения PCI DSS. Если работаете с госсектором или персональными данными — ищите подрядчика с лицензиями ФСТЭК и ФСБ.

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

4. Геополитические и санкционные риски. В 2026 году для российского рынка это один из ключевых рисков. Что здесь нужно проверять:

• Зависимость от иностранных облаков и компонентов.
• Отдельно open-source библиотек и фреймворков с высокой санкционной уязвимостью.
• Наличие у подрядчика плана «Б» на случай новых ограничений (альтернативные поставщики, российские облака, on-premise).
• Опыт работы с проектами, которые уже проходили через санкционные ограничения.

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

5. Отношение к ИИ-инструментам и low-code решениям. В 2026 году почти все интеграторы так или иначе используют ИИ (Cursor, GitHub Copilot, Claude, внутренние агенты). Важно понимать политику компании. Что проверять:

• Есть ли у подрядчика регламент использования ИИ-инструментов (что разрешено, что запрещено, как проверяется код, сгенерированный ИИ).
• Насколько активно они применяют low-code/no-code платформы и как это влияет на качество и поддержку решения.
• Готовы ли они комбинировать ИИ + ручную разработку или полностью полагаются на «ИИ всё сделает».
• Есть ли у них экспертиза по prompt engineering и проверке качества ИИ-генерируемого кода.

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

3. Насколько гибкие в разработке

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

Что важно:

1. Подход к кастомизации показывает философию компании. Если подрядчик сразу говорит о готовом решении и предлагает подстроить бизнес-процессы под него — это провал для специфичных задач. Подбор решения под клиента, а не наоборот — признак зрелого подхода.
2. Работа с изменениями — реальность любого проекта. Требования меняются в процессе, это нормально. Agile не на словах, а на деле означает готовность пересмотреть приоритеты, адаптировать бэклог, обсуждать изменения.
3. Понимание бизнес-задачи отличает хорошего интегратора от посредственного. Технари часто зацикливаются на том, как реализовать, забывая спросить, зачем это нужно. Вопрос о том, какую проблему решает функция, должен звучать чаще, чем обсуждение технологии.

Спросите, как подрядчик работает с меняющимися требованиями в середине спринта. Если ответ сводится к пунктам контракта и доп.оплате — это может быть, но для начала лучше обсудить приоритеты и найти компромисс.

4. Прозрачность процессов

Вы должны понимать, что происходит на проекте в любой момент.

Как оценить прозрачность:

1. Структура коммуникации определяет скорость решения вопросов. Кто ваш контакт — менеджер без технической экспертизы или техлид команды? Как быстро получаете ответы? Есть ли прямой доступ к разработчикам для обсуждения технических деталей?
2. Регулярная отчётность — это не бюрократия, а инструмент контроля. Демо каждый спринт, доступ к таск-трекеру вроде Jira, понимание прогресса в реальном времени. Компании с 24/7 поддержкой обычно имеют настроенные процессы коммуникации и реагирования.
3. Документация показывает зрелость процессов. Если подрядчик не может показать примеры технической документации, процессов разработки, архитектурных решений — это тревожный звонок.
4. Совпадение ценностей и корпоративной культуры. Технические навыки важны, но если ценности не совпадают — проект будет постоянным источником конфликтов. Попросите пообщаться не только с техлидом, но и с 1–2 разработчиками, которые будут работать над проектом. Задайте вопросы про их реальный опыт работы в компании. Что проверять:

• Отношение к удалённой работе и овертаймам (есть ли культура «гореть на проекте» или уважают work-life balance).
• Прозрачность внутри компании (как принимаются решения, насколько открыто руководство общается с командой).
• Отношение к качеству vs скорость (готовы ли отказываться от «быстрых костылей» ради долгосрочного результата).
• Корпоративные ценности: как компания относится к клиентам, к сотрудникам, к этике в разработке.

Красные флаги:

1. Вам говорят, что всё хорошо, но конкретики нет. Нет демо, доступа к репозиторию, промежуточных результатов. А потом в день дедлайна выясняется, что половины функционала нет. Нормальная практика — давать клиенту видимость работы: задачи, коммиты, тесты.
2. Проводите демо результатов каждые 1-2 недели. Так будете видеть рабочий код, сможете проверить функционал, задать вопросы напрямую техлиду. Ошибки дешевле исправлять на ранних этапах, чем в продакшене.
3. Команда говорит одно на собеседовании, а на деле — жёсткий overtime, токсичная культура и «мы просто кодим, а менеджеры решают».

5. Команда и культура разработки

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

Что проверять:

1. Квалификация разработчиков определяет скорость и качество работы. Соотношение мидлов и сеньоров в команде показывает, кто будет делать архитектурные решения, а кто — рутинные задачи. Если в команде только джуны под управлением одного сеньора — это риск.
2. Текучка кадров — критический показатель стабильности. Высокая текучка означает проблемы: либо с зарплатами, либо с управлением, либо с атмосферой. Всё это отразится на вашем проекте.
3. Практики разработки видны в деталях. Code review, автоматизированное тестирование, CI/CD — это страховка от багов в продакшене. Спросите, как организован процесс: делают ли ревью кода, какое покрытие тестами, как часто деплоят.

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

6. Пост-интеграционная поддержка

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

На что смотреть:

1. Гарантии и доработки. Что будет, когда система упадет из-за архитектурной ошибки вендора? Условия фикса багов и доработок после релиза должны быть зафиксированы в контракте.
2. Контроль ответственности. Должно быть четко расписано, где заканчивается зона ответственности интегратора и начинается зона ваших админов, девопсов или первой линии поддержки.
3. Документация и передача знаний. Подрядчик обязан выгрузить не только исходники, но и актуальную документацию: ADR (архитектурные решения), схемы инфраструктуры, регламенты развертывания.

Юридическая и договорная часть. Условия расторжения договора и стратегия. Кто владеет кодом и данными после завершения проекта. Штрафы за срыв сроков и SLA. Право на аудит кода и инфраструктуры.

7. Безопасность и комплаенс

1. Проверяйте сертификаты и стандарты: ISO 27001 по информационной безопасности, соответствие ФЗ-152 о персональных данных, отраслевые стандарты вроде PCI DSS для платёжных систем.
2. Пентесты, аудит кода на уязвимости, шифрование данных, управление доступами — всё это должно быть в процессе по умолчанию.
3. Убедитесь, что контракт чётко прописывает, кому принадлежит код, как защищаются ваши данные, какие санкции за утечку.

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

8. Реальные кейсы и рекомендации

Самый очевидный и простой способ проверить подрядчика — поискать в открытом доступе упоминания и кейсы в медиа или на специальных площадках. Вот на что смотреть:

1. Соблюдение сроков — классический больной вопрос IT-проектов. Уложились ли в первоначальные оценки? Если были задержки — как объясняли и решали?
2. Работа с изменениями — насколько гибко подрядчик реагировал на новые требования? Были ли конфликты по поводу доп.функционала?
3. Качество коммуникации — как быстро отвечали, насколько понятно объясняли технические вещи, был ли прямой контакт с командой?
4. Пост-поддержка — что происходило после запуска? Быстро ли реагировали на проблемы? Помогли ли с развитием продукта дальше?

9. Финансовая прозрачность

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

На что смотреть:

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

Красные флаги:

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

10. Масштабируемость решения

Интегратор не сдает вам в аренду серверы, поэтому он должен спроектировать систему так, чтобы при х10 росте нагрузки вам не пришлось переписывать ядро, менять СУБД или сносить весь проект.

1. Проектирование под рост бизнеса отличает стратегическое мышление от тактического. Хороший интегратор спросит о ваших планах: сколько пользователей сейчас, сколько планируется через год, через три года. И заложит архитектуру с запасом.
2. Постепенное расширение функционала дешевле полной переделки. Модульная архитектура, микросервисы, API-first подход — всё это позволяет добавлять новые возможности без переписывания существующего кода.
3. Управление техническим долгом. Любая разработка накапливает технический долг: быстрые решения, костыли, устаревшие зависимости. Профессионалы планируют рефакторинг, выделяют время на улучшение кода, следят за обновлениями библиотек.
4. Vendor lock-in и технологическая независимость. Хороший интегратор не строит систему так, чтобы вы навсегда зависели от его экспертизы, конкретного облака или проприетарного инструмента. Проверяйте: на каких лицензиях работает стек, можно ли сменить подрядчика без переписывания системы, кто владеет кодом и есть ли возможность развивать продукт силами инхаус-команды.

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

11. Скорость и качество коммуникации

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

1. Время отклика на первый запрос — если на ваше обращение отвечают через неделю — представьте, как будет идти коммуникация в процессе проекта.
2. Интегратор должен задавать вопросы не только про технические требования, но и про то, какую проблему бизнеса решает система. Это показывает стратегическое мышление.
3. Хороший подрядчик не просто делает, что сказали, а предлагает улучшения: как сделать эффективнее, дешевле, быстрее. Это требует глубокого понимания вашего бизнеса.

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

12. Репутация на рынке и стабильность

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

Что оценивать:

1. Время на рынке — один из положительных сигналов, но не гарантия. Компании с опытом 8+ лет, как правило, пережили кризисы, накопили экспертизу и выстроили процессы. Но возраст сам по себе не означает качество: проверяйте кейсы, репутацию и стабильность команды, а не только дату основания. Стартапы могут быть инновационными — просто риски у них другие.
2. Финансовая устойчивость проверяется косвенно: по масштабу проектов, количеству офисов, размеру команды.
3. Участие в профессиональных мероприятиях показывает открытость. Компании, которые выступают на конференциях, пишут статьи, делятся опытом, обычно уверены в своей экспертизе. Это также помогает проверить репутацию через знакомых в индустрии.
4. Партнёрские отношения с крупными вендорами — ещё один индикатор.

Проверка на негатив:

• Поищите упоминания компании в негативном контексте: судебные споры, публичные конфликты с клиентами, жалобы сотрудников. Одна претензия — не приговор, но если их много — стоит задуматься.
• Отсутствие следов в интернете тоже настораживает. Нормальная IT-компания в 2026 году должна быть видна: сайт, соцсети, публикации, упоминания в медиа.

Как использовать чек-лист

1. Первичный скрининг отсекает неподходящих кандидатов. Пройдитесь по критичным пунктам: опыт в индустрии, технологический стек, безопасность, репутация. Если есть красные флаги — не тратьте время на глубокую оценку.
2. Глубокое интервью для финалистов. Возьмите 2-3 компании, которые прошли скрининг, и проверьте остальные пункты детально. Встречи с командой, разбор кейсов, общение с референсами, обсуждение процессов.
3. Пилотный проект снижает риски. Перед большим контрактом протестируйте подрядчика на небольшой задаче. Это покажет реальное качество работы, скорость коммуникации, соблюдение договорённостей. Дешевле потратить месяц на пилот, чем год на исправление ошибок.

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

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

Ошибка 1. Агрессия и хамство

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

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

Анна Жаркова, руководитель мобильной практики ГК Юзтех, подтверждает, что хамство встречается редко, но перечёркивает всё:

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

Евгений Антонов, тимлид в Yandex Infrastructure и IT-консультант, подчёркивает важность профессионализма в вопросе общения с кандидатами:

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

Саша Шинкевич, руководитель разработки продуктов Яндекс Контест, резюмирует:

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

Совет: общайтесь вежливо и дружелюбно, настройтесь на сотрудничество. Если что-то непонятно — спросите, а не защищайтесь.

Ошибка 2. Попытки обмануть или приукрасить

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

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

Порой кандидаты прибегают к откровенным уловкам, например, используют подсказки друзей во время онлайн-интервью. Александр Коротаев вспоминает курьёз:

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

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

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

Евгений Антонов считает, что использование шпаргалок допустимо, если кандидат знает, что искать:

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

Глеб Михеев, руководитель программного комитета FrontendConf, автор телеграм-канала Уставший техдир, ведущий подкаста «Фичи катятся», ментор и консультант, считает, что ненадёжные кандидаты читаются сразу:

Фейк-эксперты палятся моментально — по уверенности, по словам, по дыханию.

Совет: если чего-то не знаете — скажите честно. Тимлиды уважают честность больше, чем идеальное резюме.

Ошибка 3. Неуважение ко времени

Опоздание без предупреждения — это редфлаг. Кандидат автоматически провалил интервью, если подключился спустя 15 минут или позже. Даже сильное резюме не спасает, когда человек не может организовать себя.

Если кандидат опаздывает и не предупреждает, мы ждём максимум 15 минут и закрываем интервью. Это тоже результат — просто отрицательный.

Анна Жаркова добавляет, что опоздания из-за технических сбоев можно понять, но уведомить HR-а нужно обязательно:

Люди могут опаздывать чисто по техническим причинам. Тут будет правильнее предупредить интервьюера через HR.

Совет: проверьте и настройте свою технику заранее. Если опаздываете — предупредите.

Ошибка 4. Неподготовленность и отсутствие мотивации

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

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

Отсутствие подготовки не только затрудняет оценку кандидата, но и заставляет тимлидов сомневаться в его заинтересованности. Александр Коротаев подчёркивает:

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

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

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

Ошибка 5. ЧСВ и снисходительный тон

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

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

Такое поведение создаёт барьер, ведь тимлиды ищут тех, с кем комфортно работать в команде:

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

Высокомерие часто воспринимается как попытка компенсировать нехватку реального опыта, что снижает шансы на успех.

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

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

Ошибка 6. Болтовня и нерелевантные ответы

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

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

В другом случае он отмечает:

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

Анна Жаркова подчёркивает:

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

Совет: лучше честно скажите, что не знаете ответа. Затем объясните, как бы вы подошли к задаче. Так вы покажете, как именно мыслите.

Ошибка 7. Отсутствие диалога

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

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

Александр Коротаев уточняет:

Вопросы нужны, но это не связано с моим желанием, чтобы всё было "по шаблону". Хочется знать, что мы оба понимаем друг друга правильно. Что в работе он тоже не уйдет в самостоятельное плаванье без фидбека, когда время будет потеряно, а человек не пойми зачем ушел в дебри, которые и не были нужны.

Совет: подготовьте вопросы о команде и процессах. Например, как проходит код-ревью или как в компании дают фидбэк.

Вывод

Тимлиды не ждут идеальных ответов. Забытый термин, пауза для размышлений или небольшая растерянность — это нормально и не повод для отказа. Однако ложь, хамство и равнодушие моментально портят впечатление. Александр Коротаев считает, что важен баланс:

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

Эксперт также рекомендует заранее изучить компанию:

Найдите коллег в чатах, узнайте, что спрашивают, и попросите рефералку, чтобы обойти HR-фильтр.

Советы тем, кто готовится к собеседованию:

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

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

Читайте также:

• Техническое собеседование: как пройти и подготовиться к нему
• Оффер во фронтенде в 2025 году: как получить и не облажаться
• Скрутка и накрутка опыта: работает ли это в айтишке
• Поливоркинг в IT: полезная стратегия для карьеры или путь к выгоранию?

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

1. Minerva Knowledge — система управления знаниями полного цикла

Идея Minerva Knowledge не просто в организации вики-подобной базы, а в настройке всего процесса: от совместного создания документации и её актуализации до доставки нужной информации сотруднику прямо в его рабочее окружение с помощью ИИ-ассистента.

Продукт включён в реестр российского ПО и работает с отечественными ОС, а поддержка осуществляется на русском языке. Для развёртывания есть два варианта: безопасное облако на выделенном сервере компании или on-premise установка на собственном оборудовании, чтобы вписаться в стандарты безопасности.

Как это выглядит на практике для разных ролей

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

• Для разработчика это, в первую очередь, среда для ведения технической документации, фиксации опыта и багов. Встроенные шаблоны помогают стандартизировать описание задач, а ИИ-помощник, который можно встроить в IDE или таск-трекер, ускоряет поиск ответов.
• QA-инженер использует систему для создания и хранения тест-планов, чек-листов и ведения отчётности. Важный момент — возможность сопоставлять дефекты с требованиями и документацией в одном месте.
• PM или тимлид получает инструменты для управления требованиями, визуализации прогресса через дашборды и планирования спринтов.
• Аналитик или дизайнер может хранить в системе результаты исследований, макеты, пользовательские сценарии и гайды по UX/UI.
• Сотрудник поддержки использует Minerva Knowledge для быстрого доступа к FAQ, инструкциям и шаблонам, а также для создания новых статей по итогам решения обращений.

Что интересного в Minerva Knowledge

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

Фокус на ИИ и доставке знаний

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

• Minerva Copilot: Это GenAI-ассистент, который встраивается в виде виджета в любую рабочую систему (CRM, Service Desk, таск-трекер, IDE). Он даёт рекомендации и генерирует ответы на основе корпоративной базы знаний.

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

Знания + Обучение (LXP)

В продукт встроена собственная LXP-платформа Minerva Learn, в которой можно собирать полноценные учебные курсы из статей в базе знаний. Система поддерживает SCORM/Tin Can пакеты, в ней есть тестирование, геймификация (рейтинги, баллы, сертификаты) и детальная аналитика для контроля результатов. Удобно для онбординга и проверки знаний команды.

Minerva Learn также даёт возможность настраивать мини-тесты для конкретных групп пользователей в момент публикации контента в Minerva Knowledge. Сотрудник получает уведомление об изменениях в статье и может сразу закрепить новые знания с помощью опроса, не переключаясь между окнами.

Портал самообслуживания Minerva Portal

Полностью защищённый портал с документацией, основанный на знаниях сотрудников. Адаптируется под требования брендбука, находит информацию с помощью поисковой строки и GenAI-помощника.

Совместная работа и миграция

Совместный редактор поддерживает одновременную работу нескольких пользователей, комментирование и использование макросов для встраивания графиков, диаграмм Draw.io и PlantUML и контента из Figma, Miro или Google Docs.

Кроме того, компания делает особый упор на удобство переезда с западных систем. Minerva Knowledge позволяет автоматически переносить контент из Confluence, SharePoint, Notion и других сервисов, сохраняя структуру, вложенность и даже графику. В системе реализованы все востребованные макросы, есть собственная система управления требованиями.

Авторская методология Minerva Result

Компания помогает запустить процессы и культуру менеджмента знаний для повышения качества и актуальности статей. В итоге единый источник правды появляется не только у сотрудников, но и у GenAI-агентов, которые начинают выдавать корректные ответы в среднем в 94% случаев.

Технические детали и возможности

Что касается технических момент, Minerva Knowledge предлагает гибкость как в доступе, так и в развёртывании. Работать с системой можно через веб-интерфейс, десктопные и мобильные приложения. Для интеграции в текущие рабочие процессы можно интегрировать API и SDK, а также встраиваемый виджет Minerva Copilot.

Модель тарификации включает подписку, покупку лицензий и корпоративные тарифы. Поддержка пользователей происходит в нескольких каналах: через чат, e-mail, Telegram, а для крупных клиентов предусмотрен выделенный менеджер и SLA.

2. ПланФикс — сценарии на все случаи ИТ-команд

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

Система размещена на российских серверах, работает без VPN и интегрирована с локальными платёжными системами, телефонией и сервисами вроде 1С.

Как это выглядит на практике для разных ролей

• Для разработчика это пространство для работы с задачами, фиксации багов и тайм-трекинга. Вся коммуникация с коллегами или заказчиком сохраняется в контексте конкретной задачи, а документация по проекту хранится здесь же.
• QA-специалист может вести тест-кейсы и чек-листы, напрямую общаться с разработчиком или продактом и настраивать свои процессы тестирования.
• PM или тимлид использует ПланФикс для планирования. Можно начать с общей схемы продукта на «Диаграмме связей», декомпозировать её до конкретных задач и отслеживать прогресс через канбан-доски, календари загрузки и отчёты по затратам в разных разрезах.
• Для дизайнеров и аналитиков это место для версионного хранения макетов, обсуждения исследований и коммуникации с командой на нужных этапах.
• Бизнес и HR могут вести внутренние проекты (в том числе скрытые, с финансовой информацией), создавать базу знаний, вести учёт сотрудников и даже рассчитывать зарплаты на основе данных из тайм-трекинга.

Что понравилось в ПланФикс

Главная особенность — гибкость. Вместо того чтобы подстраивать свои процессы под инструмент, можно настроить инструмент под себя.

За время тестирование нашли самые интересные фичи:

Продвинутые автоматические сценарии

Это, по сути, no-code инструмент, который позволяет настроить практически любую логику: при изменении статуса задачи отправить уведомление, при наступлении дедлайна создать новую задачу, при получении письма от клиента запустить определённый процесс. Для связи с внешними системами есть вебхуки.

Аналитика

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

Диаграмма связей

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

Настраиваемые планировщики

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

Ограничения и система тарификации доступны по ссылке. Для интеграций есть REST и XML API. Сервис доступен в вебе и через мобильные приложения. Поддержка отвечает в чате из самого ПланФикса, МП, по email, в Telegram и VK. Также у сервиса есть активное сообщество на форуме и в Telegram, обширная база знаний и видеоуроки.

3. Kaiten — все рабочие процессы на одном экране

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

Сервис размещён на российских серверах (Tier 3), соответствует ФЗ-152 и входит в реестр отечественного ПО. Для компаний с жёсткой политикой безопасности есть on-premise версия. Оплата в рублях, работает без VPN.

Как это выглядит на практике для разных ролей

• Для разработчиков Kaiten — это удобный трекер с WIP-лимитами, прогнозированием сроков по Lead/Cycle Time и сквозной связкой с репозиториями, PR и CI/CD без необходимости дублировать статусы вручную.
• QA-специалист получает стандартизированную приёмку по чек-листам и критериям готовности (DoR/DoD), управляет дефектами в едином потоке с задачами разработки и отслеживает SLA на исправление багов.
• PM или тимлид использует Kaiten для поддержания ритма поставки без ручного администрирования. Автоматические правила не дают пропустить важный этап, а готовые Agile-отчёты помогают находить узкие места и планировать ресурсы с помощью диаграммы Ганта.
• Продакт-менеджер выстраивает сквозную трассировку от стратегии до бэклога и реализации. Встроенный User Story Mapping позволяет создавать дорожные карты, а система сама собирает метрики по срокам и статусам для принятия продуктовых решений на основе данных.
• Бизнес-лидеры (CEO/CTO) получают единую панель управления компанией, которая даёт прозрачность по всему портфелю проектов без лишнего микроменеджмента.

Что понравилось в Kaiten

Главная особенность — фокус на Agile-практиках из коробки, без необходимости долгой настройки и установки плагинов.

За время знакомства с системой выделили несколько интересных моментов:

Визуализация связанных процессов

Есть возможность видеть на одном экране несколько досок (например, дизайн, разработка, маркетинг) и отслеживать, как задачи перетекают между командами. При этом система позволяет создавать неограниченное количество рабочих пространств и досок внутри них.

Проработанная диаграмма Ганта

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

Agile-метрики без костылей

Система сама строит контрольные графики, CFD (Cumulative Flow Diagram) и рассчитывает Lead/Cycle time.

Документы и База знаний

Можно создать собственную базу знаний, где команда будет хранить и редактировать документы, не выходя из Kaiten.

Бесшовная миграция

Для команд, которые переезжают с Jira, Trello, Notion или Asana, есть автоматический импорт задач и истории.

Интеграции

В Kaiten доступны открытый API, SDK и широкий набор интеграций — это позволяет настраивать систему под конкретные рабочие процессы и автоматизировать рутину. Можно разработать свои дополнения, а из готового набора сразу доступны связки с GitHub, GitLab, Telegram, Slack, календарями и более чем 50 приложениями через Zapier.

Тарифы и стоимость

Тарифная система устроена по принципу «тариф + набор модулей».

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

• Платные тарифы («Старт», «Стандарт», «Бизнес», «Корпорация») стартуют от 185 рублей и различаются количеством доступных модулей и числом пользователей: «Стандарт» включает 2 модуля, «Бизнес» — 6 модулей. «Корпорация» — полный набор модулей. Количество пользователей ограничено купленными лицензиями, но ограничений по объёму хранимых данных нет ни на одном из тарифов.

Для компаний со сложными требованиями к инфраструктуре и безопасности есть on-premise версия на тарифе «Корпорация» с возможностью бессрочной покупки лицензии.

Поддержка и обучение

Kaiten доступен через веб и мобильные приложения, для enterprise — on-premise версия на Docker.

Поддержка включает базу знаний, техподдержку и команду customer success для сопровождения клиентов. Для on-premise версии — выделенная поддержка и внедрение под ключ.

Для обучения есть онлайн-курс по Kaiten, разборы кейсов, консалтинг и корпоративное обучение команд. Планируется запуск AI-ассистента для автоматизации сопровождения.

Что в итоге

Все три сервиса работают без VPN, размещены в России и могут заменить западные инструменты — но решают разные задачи.

Minerva Knowledge сфокусирована на управлении корпоративными знаниями с упором на ИИ-ассистентов и обучение. Плюс встроенная LXP для онбординга и автоматическая миграция из Confluence.

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

Kaiten — про визуализацию и Agile из коробки. Если вам нужны связанные доски команд на одном экране, встроенные метрики и быстрый старт без долгих конфигураций.

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

Тектонический кадровый сдвиг: миллениалы и зумеры

Поколенческие разломы в IT-сфере становятся всё очевиднее. Миллениалы (Y) видят в карьере долгосрочный проект с целью роста до руководителя. Зумеры (Z) ищут интересные задачи, технологии и возможность проявить экспертность, легко меняя место работы, если их интересы не учитывают.

Управляющий партнёр агентства «Люди Дела» Елена Алеева чётко формулирует разницу: «Поколение Y ориентировано на вертикальный карьерный трек. Их мотиваторы: финансовая стабильность, статусная принадлежность, соцпакет и понятная карьерная траектория. Для зумеров на первом месте — интересные задачи, разнообразие проектов, гибридные форматы работы, возможность выбора. У них нет страха.

Ключевое изменение: запрос сместился с денег и статуса на смысл и влияние. Y стремились стать руководителями, Z хотят быть влиятельными экспертами в узкой области, сохраняя автономию. Чтобы привлекать Z, компаниям нужно прокачивать человекоцентричность».

Преподаватель MBA-дисциплин по управлению персоналом Анна Кутко видит корни этого различия в историческом контексте: «Игреку нужна стабильность, прозрачные перспективы, потому что это поколение росло, когда мир активно менялся, проходил кризисы. Поэтому они стремятся строить карьеру системно. Z родились в эпоху цифровизации, и у них сформировалось клиповое мышление, им сложно потреблять информацию сразу большими объемами. По моим наблюдениям, зетам нужно всё здесь и сейчас. Чтобы их заинтересовать, важно учитывать, что им комфортно общение онлайн — должны быть специальные платформы, на которых они будут видеть свои обязанности и их стоимость. Например, есть хороший опыт у Ozon и "Самоката" — в их приложениях сотрудникам видны задачи, размер и дата оплаты».

Но как эта разница в мировоззрении проявляется в конкретных карьерных стратегиях именно в IT и в требованиях к работодателям?

От карьерной лестницы к экспериментам

Траектория карьеры претерпела, пожалуй, самые радикальные изменения. Модель «джуниор-миддл-сеньор-тимлид» перестала быть единственной.

Директор кадрового агентства Anti-HR и собственной HR-школы Татьяна Филатова констатирует:

«Примерно десять лет разделяет поколения Y и Z, но их карьерные ориентиры и ожидания различаются существенно. Миллениалы, заставшие рождение интернета и цифровой бум, видели в IT в первую очередь стабильность и возможность построить успешную карьеру. Их идеалами были специалисты из крупных компаний вроде Microsoft, Google или Яндекс. Карьера представлялась, как лестница.

Для поколения Z карьера — устаревшее понятие в принципе, для них это серия интересных экспериментов. Их ролевые модели — IT-фрилансеры, создатели стартапов, блогеры и разработчики в сфере Web3 и AI. Они не боятся менять компании каждые 1-2 года, работать одновременно в нескольких проектах или создавать свой. Горизонтальный рост для них часто важнее вертикального: интереснее освоить новый стек технологий, чем стать менеджером.

Зумеры хотят чувствовать смысл в том, что они делают. Им важна забота о ментальном здоровье: доступ к психологу, программы против выгорания, открытая корпоративная культура без токсичности. Нужна прозрачность и быстрая обратная связь. Работа, по их мнению, должна вдохновлять, приносить пользу и встраиваться в образ жизни, а не наоборот. Тогда как Y готовы хорошо и много работать в обмен на благополучие, возможности личностного и профессионального развития. Их запрос сейчас, в отличие от поколения Z, абсолютно понятен работодателю».

Это подтверждает и управляющий партнер «Агентства Маркетинговых стратегий Макс» Ульяна Павлова. Она приводит конкретные данные: «Миллениалы строили карьеру внутри компаний, а затем массово уходили в самозанятость/аутсорс — именно Y стали драйвером роста самозанятых в 2025 г.

По данным исследования ВТБ, зумеры заходят в компании очень активно — много стажировок, быстрые переходы между должностями, при этом высокая активность в смене места работы. Хотя есть новые исследования, где видно, что Z, как и предыдущее поколение, ищет стабильности: они охотно меняют места в начале карьеры, но готовы оставаться пять и более лет там, где условия прозрачны и развитие реально».

Руководитель по ресурсному обеспечению IT Smart Finance Артем Кириллов резюмирует это чёткой формулой: «Если для Y характерна "долгая дорога" — постепенный рост до роли архитектора или тимлида, ставка на стабильность, грейды, соцпакет и экспертность, то для Z важнее серии коротких спринтов, быстрая смена ролей и проектность. Лояльность тоже изменилась: у Y она к команде и продукту, а у Z — к возможностям роста и развитию личного бренда».

Деньги, смыслы и ментальное здоровье: новая мотивация

Фокус сместился с внешних атрибутов успеха на смыслы и благополучие.

Руководитель внешних коммуникаций hh.ru Мария Бузунова, ссылаясь на исследования сервиса, указывает ключевые тренды:

— Смена фокуса с процесса на результат. Для миллениалов важен был сам процесс построения карьеры и долгосрочные достижения. Например, в рамках опроса hh.ru, на вопрос «Что для вас — работа мечты?» респонденты в возрасте от 25 до 34 лет отвечали, что важные факторы — это своевременная зарплата (51%), возможность карьерного роста и профессионального развития (38%), польза обществу от работы (20%). Зумерам скорее важны быстрый измеримый результат и эмоции. Чаще всего респонденты 18-24 лет, при описании работы мечты, указывают возможность баланса жизни и работы (67%) — это самый высокий показатель среди остальных возрастных когорт. Значимо чаще, чем миллениалы, зумеры указывают отсутствие переработок (35%) и то, что работа должна вписываться в образ жизни (25%). При этом для обоих поколений наиболее важен баланс личной жизни и работы. А респонденты 55 лет и старше реже указывают этот фактор (34%).

— Смысл против стремления к стабильности. «Миллениалы выросли в нестабильное время, что сформировало их запрос на надежность, понятность процессов и накопления. Зумеры ищут в работе не просто доход (хотя их стартовые запросы существенно выше, чем были у миллениалов), а цель. Им важно, чтобы задачи были интересными, а миссия компании совпадала с их ценностями. Они могут отказаться от задачи, если не видят её смысла», — отметила Мария Бузунова.

Взгляд изнутри от практика добавляет нюансов. Фронтенд-разработчица, тимлид Яндекса Саша Шинкевич наблюдает такую картину: «Для поколения Y работа рассматривается скорее как долгосрочное партнёрство, стабильная зарплата, горизонт на годы вперед, рост, пусть не всегда быстрый, но предсказуемый. Для многих игреков быть айтишником — часть самоидентичности. Для молодого поколения работа может быть менее приоритетной стороной жизни. Это лишь способ получить опыт и доход. И если работодатель "не заходит", смена места или проекта воспринимается спокойно. Как ни удивительно, я иногда вижу больше осознанности в вопросе "действительно ли мне нравится этим заниматься» именно у ребят помладше"».

При этом, как подчеркивает Ульяна Павлова, одной зарплатой зумеров не удержать: «В 2025 г. растёт значимость ДМС и дополнительных отпусков; интерес к обучениям/конференциям падает, зеты интересуются психологическим портретом начальства и комфортом». Для них важна забота о ментальном здоровье и «поглаживание по голове». Это отмечает и преподаватель MBA-дисциплин по управлению персоналом Анна Кутко: «Для зетов важно межличностное общение, позитивная обратная связь от руководителя, потому что это дети, которые выросли у поколений X и Y, а те не всегда охотно дают хороший фидбэк».

Условие прозрачности и технологии

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

Во-первых, это требование к ясным условиям. Управляющий партнер «Агентства Маркетинговых стратегий Макс» Ульяна Павлова приводит яркий пример: «8 из 10 представителей Z, в отличие от Y, не откликаются на вакансию с припиской "зарплата по договорённости". Требуют конкретные вилки, KPI, понятные правила бонусов».

Во-вторых, технологические ожидания. Ульяна Павлова указывает, что генеративный AI по умолчанию требуется в работе для Z: «Они приходят готовыми работать с ИИ или очень быстро учатся ИИ-грамотности. Российские компании уже масштабно внедряют GenAI; в ИТ это норма 2024-2025 гг.».

Руководитель по ресурсному обеспечению IT Smart Finance Артем Кириллов добавляет: «В обучении Y традиционно выбирали длинные курсы и сертификации, тогда как Z предпочитают микрообучение, пет-проекты, менторство и использование ИИ-ассистентов».

Что в итоге? Вызов для работодателя

Карьерные ожидания трансформировались от стабильности к свободе. Директор кадрового агентства Anti-HR и собственной HR-школы Татьяна Филатова заключает: «Если Y ценили надежность одного работодателя, то Z ценят свободу выбора и мобильность. Потребность в линейном росте сменилась многовариантностью. Печеньки и корпоративы перестали быть решающим аргументом. На первый план вышли гибкость, миссия компании и забота о благополучии сотрудника».

Разрыв, о котором говорит Ульяна Павлова, — главный вызов для HR и работодателей: «Мы наблюдаем, как HRам, которые привыкли работать с миллениалами, приходится меняться под требования ценностей молодых и сильных IT-специалистов».

Нестандартный взгляд на проблему предлагает Product Owner в Skillaz и автор телеграм-канала «Серёжа печатает» Сергей Попов: «Я не делю людей на поколения, для меня есть три группы: ребята до 25 лет — молодёжь; 25-35 лет — "переходное" поколение; 35 плюс — "олды".

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

У молодёжи другой подход — она не воспринимает работу как средство достижения успеха, это инструмент заработка. Если раньше люди становились айтишниками, потому что им нравилась эта роль, то сейчас среднестатистический молодой разработчик скажет, что пошёл в IT потому, что это приносит бабки. Они хорошо знают свои границы, понимают про work-life-balance, умеют чувствовать свою стоимость на рынке труда, не делают ничего бесплатно. В этом смысле они относятся к себе гораздо лучше, чем "олды", и это правильно. Вопрос в том, насколько этот подход хорош для IT, ведь много крутых продуктов создано как раз, когда люди пахали ночами и горели идеей.

Если все будут работать с 10:00 до 19:00, вряд ли IT сможет развиваться так же мощно, как раньше. Если работодателю нужен огромный успех и быстрый результат — это к "олдам". Молодёжь редко относится к работодателям хорошо, считая, что это люди, которые используют их ресурс для своего успеха. Выстраивая работу с молодёжью, нужно фиксировать все договорённости».

Чтобы привлекать и удерживать таланты поколения Z, компаниям приходится всерьёз прокачивать человекоцентричность, гибкость и готовность предлагать не просто работу, а осмысленную, технологичную и прозрачную коллаборацию, где уважают личные границы и дают возможность быстрого роста. Как верно замечает Сергей Попов, портреты поколений не абсолютны, и исключения есть везде, но понимание трендов — это половина успеха в построении диалога между поколениями IT-специалистов: «Работа с молодым поколением — это вызов для работодателя. Но все-таки я бы не делил всех на чёрное и белое, потому что очевидно, что в каждом поколении есть исключения. Просто существуют общие поколенческие черты, которые стоит учитывать».

Под «оптимизацию» попали разработчики, аналитики, тестировщики и инженеры — от новичков до тимлидов. По данным источников CNews и профсоюза работников IT, под сокращение может попасть до 25% IT-команды, то есть более 5000 человек.

Официально увольнения объясняют внедрением искусственного интеллекта и автоматизацией процессов:

Топ-менеджеры называют это оптимизацией, а не сокращением.

При этом, по словам работников, реального эффекта от внедрения ИИ нет:

На деле — гонка ради отчетности, а не улучшений.

Три волны и «мягкие» увольнения

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

Некоторым сотрудникам предлагают уйти «по соглашению сторон» с выплатой двух-трех окладов и сохранением годовой премии.

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

Позиция банка

В Сбербанке отрицают наличие массовых увольнений. «Мы не сокращаем команду, а пересматриваем функции и автоматизируем процессы», — заявили в пресс-службе.

По данным банка, сейчас открыто около 4000 вакансий, преимущественно в сфере ИИ и автоматизации.

Последствия для рынка

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

По словам аналитиков, крупные корпорации переходят от найма «на вырост» к осознанной автоматизации. Однако спрос на специалистов по ИИ, Big Data и кибербезопасности при этом продолжает расти.

Дмитрий Борцов — руководитель разработки клиентских интерфейсов в PREMIER.ONE. В его подчинении более 60 инженеров, распределённых между вебом, Android, iOS и SmartTV. В индустрии он уже 15 лет: прошёл путь от фриланса и собственной студии до руководства крупными командами. Такой опыт, как он сам говорит, позволяет видеть рынок «с двух сторон» — понимать, что нужно бизнесу и какие компетенции позволяют разработчику стоить дороже. Сегодня Дмитрий совмещает управленческую роль с менторством: вместе с техлидом PREMIER.ONE Андреем Автушенко он развивает платформу Frontend Alliance, где в формате парного наставничества помогает фронтендерам — от джунов до тимлидов — прокачивать хард и софт скиллы, готовиться к собеседованиям и строить карьеру с опорой на реальную практику.

Фронтенд под давлением: рынок стал жёстче, но не умер

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

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

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

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

Что должен уметь фронтендер в 2025 году и как попасть в «5% из 95»

Уровень middle и senior во фронтенде больше не определяется знанием пары фреймворков. Базовый «джентльменский набор» очевиден: HTML, CSS, JavaScript и хотя бы один современный фреймворк — React, Vue, Angular или Svelte. Сегодня к нему де-факто добавился TypeScript: без него в резюме вы рискуете выглядеть устаревшими, даже если на проекте TS практически не используется. Работодатели хотят видеть уверенную работу с ним, потому что это напрямую ассоциируется со стабильностью и предсказуемостью кода.

Дальше идут надстройки, которые начинают выделять кандидата. Это метафреймворки вроде Next.js или альтернативы с упором на SSR и SSG, понимание разных паттернов рендера и умение применять их под конкретный продукт. Сюда же — юнит-тесты. Никто не будет устраивать экзамен на знание Jest, но сам факт владения тестированием сразу повышает ценность инженера.

Самый заметный маркер — архитектурные практики. Фронтендер, который мыслит архитектурно, понимает FSD, может объяснить, зачем нужны микрофронты (и когда они не нужны), сразу выделяется на фоне тех, кто «просто собирает фичи». Настроить приложение так, чтобы через два года его не пришлось переписывать, — это компетенция, которая превращает разработчика в дорогого специалиста.

При этом стек сам по себе не делает из мидла сеньора. Настоящее отличие — в мышлении. Сеньор умеет общаться с соседними командами, отстаивать нужные изменения в API или инфраструктуре, учитывать долгосрочные риски продукта. Это опыт, который не заменят ни курсы, ни туториалы. И именно он отличает того, кто «пишет код», от того, кто создаёт систему.

Найм и подготовка кандидата: где спотыкаются фронтендеры

Первое, что бросается в глаза при просмотре резюме фронтендеров, — это ошибки самопрезентации. Человек может написать «переписал приложение на новый фреймворк» и не уточнить, что это сократило время загрузки на 30% или сняло половину багов в проде. Для HR выглядит как рядовая строчка, хотя на деле это серьёзное достижение. Добавим сюда непонимание того, как работает HeadHunter: большинство кандидатов просто игнорируют логику поиска и фильтров, и их резюме тонет в выдаче. В итоге, 85% проблем — это не недостаток скиллов, а то, как они упакованы.

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

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

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

Кейс «Кода найма»: как Ярослав Грачёв выбил оффер в 380К

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

Первое, что пришлось менять, — резюме. Вместо сухого «работал три года» появилось описание проектов и секция «Обо мне». Ярослав даже перефотографировался, чтобы профиль выглядел живым. Параллельно он учился работать с алгоритмами HeadHunter и GPT: HH поднимал резюме в выдаче, а бот имитировал собеседования. Через две недели у кандидата уже был первый оффер.

Ситуация была интересной: предложение на 300 тысяч выглядело заманчиво, но ментор настоял не торопиться. Аргументы были простыми: поток откликов и приглашений уже пошёл, значит, офферы будут и дальше. Они вместе придумали безопасную отговорку для HR и договорились ждать неделю. Ставка сыграла — скоро пришёл новый оффер на 360 тысяч.

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

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

А дальше начинается игра на рынке: один оффер на 250 можно держать как «аварийный», второй на 300 использовать для торга, третий — поднять до 350. Главное — не зажиматься на звонках с HR: «их мотивация — провести тебя дальше, деньги они получают за закрытых кандидатов», — напоминает Дмитрий. Поэтому правило простое: дружелюбие, открытость и готовность разговаривать.

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

Советы начинающим фронтендерам

Дмитрий выделяет несколько аспектов, которым стоит уделять внимание в вопросе оффера мечты:

Не рассчитывайте только на ментора

Ментор может сильно ускорить путь: кто-то готовит к собесам, кто-то учит реально работать. Но это не панацея. Без самостоятельного копания в YouTube, статьях и пет-проектах вы просто застрянете. При этом нужно быть готовым к тому, что половина выученного окажется невостребованной, а рынок попросит ещё десяток дополнительных технологий.

Начинайте с основы, а не с фреймворка

Ключевой навык фронтендера — JavaScript. «Все есть JavaScript», — как сказал Илья Климов. React, Vue, Angular, Svelte — это лишь надстройки. Если понимаете сам язык и то, как он работает под капотом, вы сможете писать на чем угодно, хоть в фронте, хоть на Node.js в бэке.

Не ведитесь на быстрые рецепты успеха

Онлайн-школы и ютуберы любят обещать: «выучишь React — и всё в шоколаде». Но без знания JS никакой React не спасёт. На собеседованиях почти всегда спрашивают именно JavaScript, а не то, как вы намагичили интерфейс на очередном фреймворке.

Думайте о том, зачем работает код

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

История Дмитрия Борцова и Ярослава Грачёва — это иллюстрация того, что даже в перегретом и избирательном рынке фронтенда можно найти своё место. Ключ к успеху — не только в технической базе, но и в умении правильно упаковать опыт, показать насмотренность и держать фокус на том, что важно работодателю. Для джунов это часто означает вложиться в JavaScript, а не в очередной модный фреймворк. Для мидлов и выше — развивать софты и стратегически подходить к собеседованиям. А для всех уровней — не замыкаться в одиночном обучении, а искать наставников и сообщество, которые помогают расти быстрее.

Фронтенд в 2025-м всё ещё щедр, но не прощает случайности. И чем раньше разработчик перестанет полагаться на удачу и начнёт работать над собой системно, тем выше шансы получить оффер, который изменит карьеру.

Уже 24 сентября Наталия совместно с ведущим специалистом в области конфликтологии Андреем Кёнигом проведут воркшоп с разбором типичных и нестандартных конфликтов в работе DevRel-менеджеров, включая истории самих участников.

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

— Наталия, расскажи пару слов о себе.

— В настоящий момент я консультирую компании по стратегии DevRel и специалистов по карьерным вопросам. Ещё преподаю на курсе OTUS и помогаю стартапам, чьи продукты ориентированы на разработчиков. Когда узнала про новый сезон конференции Онтико, предложила тему, и программный комитет принял мой воркшоп в программу.

— Расскажи, о чём будет твой доклад. Что вообще ждёшь от конференции?

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

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

— То есть речь идёт именно о конфликтах со смежными подразделениями в нескольких компаниях?

— Не совсем так. Например, DevRel-менеджер часто выступает в роли проектного менеджера по коммуникациям. Для организации любого проекта или мероприятия ему приходится взаимодействовать с большим числом смежных подразделений. Это могут быть разработчики, тимлиды, дизайнеры, юристы, финансисты, hr-ры, маркетологи — в зависимости от структуры компании.

— И именно на стыке этих взаимодействий возникают трудности?

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

— Приведешь примеры наиболее типичных конфликтов?

— Например, спор с PR, чей Хабр :)

Это один из главных инструментов DevRel. Пиар-служба тоже понимает, что это важный канал коммуникации, и считает, что он должен быть под их контролем. Но у них есть своё видение — исходят из логики массовых коммуникаций, работы с журналистами, внешнего имиджа компании. А мы в DevRel-направлении настаиваем, что для аудитории разработчиков важно быть максимально открытыми. Надо публиковать не только статьи, которые соберут десятки тысяч просмотров, но и узко-специализированные полезные профессиональные материалы от наших коллег. Важно говорить не только о позитивных сторонах, но и прорабатывать негативные стереотипы или признавать ошибки. Мы этого не боимся, а вот PR боится. Именно на этой границе часто возникает конфликт.

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

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

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

— А бывают ли подобные ситуации и с другими подразделениями?

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

Наша задача — мотивировать и поддерживать разработчиков, которые сами хотят писать статьи. Но бывает, что тимлид против. Ситуация может оказаться и более острой, когда тимлид чувствует угрозу бизнес-процессу, где конфликт заложен системой KPI, когда у тимлидов и DevRel-менеджера совершенно разные и взаимоисключающие цели. Появляется угроза авторитету, если руководителю кажется, что его сотрудник станет “звездой” и “подсидит его” или уйдет. Или есть уже недоверие к работе DevRel, так как в прошлый раз не было быстрого результата и пр.

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

— А как вообще объяснять разработчикам и их лидам, что оно того стоит — выступать, писать статьи? Как аргументировать, на какой профит делать акцент?

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

В таком случае важно правильно описать задачу и объяснить, зачем всё это делается. Мы можем исходить из того, что это пиар компании. А дальше включаются разные мотивационные «ключи». Например, если руководителю нужно нанимать людей, то наши аргументы к его мотивации: публичные выступления команды помогают привлечь кандидатов и сделать задачи команды более заметными. Если же у лида найм не стоит на повестке, ищем другие аргументы. Главное — подобрать тот мотив, который для человека будет значимым.

— А какая мотивация выступать или писать статьи может быть у разработчиков?

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

— Но ведь многим сложно начать, особенно если это первый опыт.

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

— А что делать, если разработчик вроде бы не против написать статью или подготовить доклад, но сам не знает, о чём?

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

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

— У тебя есть какой то пайплайн, как готовить спикера, который ещё не выступал на конференции?

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

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

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

— А если вернуться к конфликтам: часто ведь руководство не хочет отпускать людей на конференции. Это же командировка, выпадают несколько дней, плюс время на подготовку. Как с этим быть?

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

Сначала руководители могут сопротивляться, но постепенно меняют мнение. Когда они видят, что коллеги разрешают выступления, их сотрудники становятся более мотивированными и довольными, а сами команды — более заметными и привлекательными, то понимают, что это работает на результат. Тогда у CTO или команды постепенно начинает меняться мышление в эту сторону. Это не всегда происходит быстро — иногда требуется время, но результат заметен.

— А если посмотреть шире — какие компании более открыты к таким практикам, а какие менее? Есть разница между стартапами и крупными корпорациями?

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

С крупными компаниями, особенно из реального сектора, которые пришли к цифровой трансформации относительно недавно, ситуация сложнее. Некоторым компаниям может потребоваться несколько лет, чтобы наладить процесс. Сначала придется преодолевать сопротивление со стороны служб безопасности и PR, которые категорически не готовы пускать простых разработчиков к публичным коммуникациям. Но постепенно накапливается пул собственных успешных кейсов, приходит понимание, что пользы больше чем опасности, присматриваются к успешным референсам с рынка и конкурентов и … закрытая вчера корпорация приносит 10-15 докладов на конференцию для разработчиков.

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

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

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

Если ты понимаешь, что твою работу и запрос поддерживает авторитетный заказчик или топ-менеджер, то сопротивление PR или бренда снижается. Можно прямо сказать: «Это нужно не только мне, это нужно вот этому человеку». И тогда вопрос решается быстрее. Бывают ситуации, когда после слова ключевого руководителя все тут же меняют позицию и делают то, что до этого категорически отвергали.

Мы можем закладывать бюджет в разные «кубышки» — бюджеты разных направлений, тех, кто заинтересован в DevRel. Но в любом случае, когда работаешь со смежниками, нужно быть готовым к компромиссам и к аргументации.

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

— А как быть, если один топ-менеджер полностью тебя поддерживает, а другой — равного уровня — наоборот, против? И начинается конфликт уже между ними?

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

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

— Звучит логично. А можешь посоветовать какие-то книги или ресурсы для тех, кто только начинает работать? Может, что-то по конфликтам или коммуникациям? Какие навыки вообще нужно прокачивать?

Начнем с последнего вопроса. Нужно быть:

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

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

– маркетологами и пиарщиками, потому что надо использовать маркетинговые инструменты, каналы, форматы, приемы и аналитику.

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

— А как прокачивать коммуникации, особенно в части договорённостей и конфликтов?

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

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

— А в каких случаях всё-таки стоит идти в конфликт? Ты говорила, что иногда конфликты бывают полезны.

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

— Вот для меня DevRel — это когда ты всегда на стороне разработчиков, отстаиваешь их интересы в любом случае?

— Абсолютно. Те, кто работает с инженерами, должны отстаивать их интересы, иначе принцип взаимодействия ломается. И ещё важнее, чтобы людям было комфортно с тобой работать.

Возьмём конфликт с дизайном. Дизайнеры требуют, чтобы презентация была готова минимум за две недели до конференции. Но чаще всего разработчик готовит и отдает презентацию за три дня до конференции (многие деврелы со мной согласятся). В итоге: дизайнер относится с пониманием, входит в положение, открыто не выражает негатива, быстро всё доделывает, вроде бы все довольны, мы его от всего сердца поблагодарили. Но потом на ревью появляется негативный отзыв: дескать, менеджер плохо организовал процесс. Вот и дилемма. Мы, как деврелы, должны стремиться к идеальному процессу, но реальность такова, что приходится лавировать между интересами команд.

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

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

— Насколько, на твой взгляд, DevRel-специалисту важно выстраивать личные хорошие отношения со всеми контрагентами, с которыми работаешь?

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

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

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

— Получается, хорошие отношения всё же важны?

— Безусловно. Человек не должен быть токсичным, он должен обладать позитивной энергией и харизмой, уметь благодарить. В нашей работе это особенно важно: даже если разработчик просто сделал свою работу, всё равно нужно сказать «спасибо». Это элементарно, но многие забывают или не находят на это времени. Хорошие отношения важны, но степень их глубины зависит от стиля самого человека.

— Мне казалось, что в профессиях с Rel в названии, отношения — это ключ.

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

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

Если хотите глубже разобраться в работе DevRel, научиться выстраивать взаимоотношения с техническими специалистами и зажечь в них жажду выступать и появляться в сообществе — приходите на DevRelConf #9.Там будем разбираться со всеми аспектами работы DevRel, чтобы приносить пользу инженерам и классно делать свою работу!

Почему пет-проекты остаются самым понятным способом войти в IT

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

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

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

Для опытных специалистов пет-проекты остаются способом выйти за рамки своей узкой специализации. Они помогают увидеть полный цикл: от взаимодействия с оборудованием и выбора форматов данных до интеграции в интерфейс и настройки мониторинга.

Как работают петы для разных грейдов:

• Для начинающих и мидлов пет-проекты — понятный маркер потенциала. Публичный репозиторий с живой историей коммитов показывает процесс мышления. Это сигнал инициативности и самостоятельности.
• Для middle-разработчиков активный проект говорит о зрелости и желании расти, а также о способности мыслить архитектурно и предлагать решения с нуля. Часто именно такие проекты помогают вырасти до роли тимлида.
• Для senior-уровня личные проекты могут быть признаком глубокой вовлечённости и лидерских качеств. Однако в некоторых компаниях это может вызвать вопросы о приоритетах и рисках отвлечения от основных задач — здесь всё зависит от контекста.

В итоге, пет-проект остаётся инструментом, который одинаково полезен и для старта в профессии, и для расширения горизонтов опытного разработчика.

Как выбрать идею пет-проекта

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

Признаки «живой» идеи

Главный критерий — личная вовлечённость. Если проект решает вашу собственную проблему, у вас будет и чёткое понимание, каким должно быть решение. Сможете тестировать продукт в реальных условиях и быстро видеть, что стоит улучшить.

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

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

Где искать идеи

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

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

Работа в команде даёт дополнительный ресурс — внутренние боли, на которые не хватает рук. Даже простой internal tool с внятным UX может стать ценным проектом.

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

Форматы пет-проектов, которые реально прокачивают

«Витринные» проекты против реальных

Так называемые «витринные» пет-проекты — это работы для портфолио, обычно размещённые на GitHub или другой публичной платформе. Их цель — показать навыки и интерес к определённым технологиям. Как правило, это одноразовые демонстрации, которые не получают развития.

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

Типы проектов, которые чаще приводят к офферам

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

Тип проекта — бот, API, open-source-библиотека или мини-продукт — не так важен. Ключевые критерии:

• связь с реальной задачей;
• рабочее состояние проекта;
• минимальная упаковка для использования.

Такие проекты легко оценить и привести как аргумент на собеседовании.

Форматы, которые развивают

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

Иногда такие проекты перерастают в полноценный продукт — с регистрацией прав, подачей в акселератор, созданием команды. Даже если этого не произойдёт, сам процесс — ценный опыт.

Что убивает пет-проекты

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

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

Привычные ошибки, которые мешают доводить до результата

• Гипер сложность на старте. Вместо того чтобы упростить задачу и разбить её на этапы, многие бросают проект, когда понимают, что не тянут.
• Уход во второстепенные фичи. Неделями можно оттачивать анимации или кастомные библиотеки, забывая, что основной функционал ещё не работает.
• Неправильные приоритеты. Вместо итерационного подхода («сначала сделать главное, потом расширять») ресурсы тратятся не туда.
• Отсутствие финальной точки. Если нет чётко определённого результата, к которому можно прийти, нет и ощущения успеха — а значит, пропадает энергия двигаться дальше.

Как правильно выстроить пет-проект

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

С чего начать — минимальная версия

Первая цель — очевидно работающий MVP. Пусть он будет глючным, неполным, без красивого дизайна, но выполняющим главную задачу.

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

Приоритеты: фичи, архитектура, документация

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

• Сложность реализации (1–3 балла)
• Ценность/интересность (для вас или проекта в целом)

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

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

Тестирование и фидбэк на ранних этапах

Ранняя обратная связь спасает от лишней работы и блуждания в идеях.

• Если проект понятный и бытовой — тестируйте на друзьях и родственниках. Подготовьте набор вопросов: что удобно? что запутало? чего не хватает?
• Если проект технический (например, API), ищите тестировщиков в профильных чатах, вузовских группах, на тематических форумах. Можно предложить бесплатный доступ в обмен на комментарии.

Не бойтесь показывать «сырой» продукт — просто объясните, что это черновик, и вам нужен честный фидбек. Чем раньше получите фидбэк, тем меньше сил уйдёт в пустоту.

Как масштабировать своего «питомца»

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

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

Далее — смысловая упаковка: чётко описать, что проект делает, для кого он, какие задачи решает и какие ограничения имеет. Это полезно и пользователям, и автору, чтобы видеть границы и приоритеты.

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

Советы по масштабированию

1. Вести осмысленные разговоры с потенциальными пользователями, экспертами и теми, кто решал похожие задачи — это поможет понять, что действительно ценно, а что мешает.
2. Оценить масштабируемость: проект может быть полезным на малом масштабе, но рушиться при росте.
3. Определить вектор: B2B или B2C, чёткий портрет потребителя. Без этого презентация будет размыта.
4. При планах на инвестиции — предварительная оценка рынка, прогноз доли и гипотеза роста.
5. После подготовки — выход «в поле»: участие в отраслевых событиях, акселераторах и деловые знакомства.

Упаковка — это проверка зрелости проекта. Если его можно показать и объяснить, значит, он готов к следующему этапу.

Что дальше: превращаем проект в карьеру

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

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

Когда стоит показывать проект миру

1. Если он открыт на GitHub, уже доступен. Активно рассказывать о нём лучше после минимальной упаковки: README, описание, структура, работающая ключевая функция.
2. Для продвижения себя как продуктового специалиста, поиска команды или инвестиций нужно полноценное оформление: описание, демо, фидбэк, проработанная аудитория и сценарии применения.
3. Для портфолио или аргумента на собеседовании достаточно, чтобы проект был рабочим, логичным и понятным.

Удачи в петах!

Шаг 1: Оцените текущую ситуацию

Прежде чем увольняться, трезво оцените свое решение и текущие реалии рынка. В 2025 году рынок IT стал рынком работодателя (раз, два) — конкуренция за вакансии сильно выросла. Массовые сокращения в крупном ИТ-секторе за последние пару лет привели к перенасыщению рынка опытными кадрами и осложнили поиск работы, особенно для джунов и миддлов. Многие, кто сейчас выходит на рынок, сталкиваются с тем, что рекрутеры больше не пишут им первыми.

Работодатели меняют фокус на найм по рекомендациям (раз, два, три), в то время как открытый рекрутинг и холодный поиск отходят на второй план. Число открытых вакансий снизилось, потому что на публичные позиции с популярных job-сайтов сыпется слишком много откликов — в том числе от ботов и всевозможных карьерных консультантов. Чтобы не захлебнуться в потоке нерелевантных заявок, компании избегают размещать вакансии в открытом доступе, предпочитая искать через знакомых по внутренним рекомендациям (раз, два, три). В таких условиях одного резюме, выложенного на сайте, недостаточно, чтобы дождаться приглашения на собеседование. Нужно вести активный поиск, и он может занять больше времени, чем раньше.

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

Шаг 2: Обновите резюме

Для подготовки первоначального резюме можно воспользоваться специальными сайтами-конструкторами (например resumeworded.com), но использовать их стоит осторожно и только для вдохновения. Можно взять готовый шаблон резюме. Оптимальный объём резюме должен быть 1–2 страницы, а содержать оно должно ваши достижения в каждой должности. Убедитесь, что резюме правильно структурировано и содержит все ключевые слова по вашей специализации. Структура должна легко считываться не только человеком, но и автоматическими системами, так как ATS-системы отфильтровывают резюме, в которых нет структуры или терминов из описания вакансии.

Готовый вариант резюме желательно дать на проверку знакомому рекрутеру или выложить в группы Telegram по вашему профилю, для обратной связи. Свежий взгляд со стороны поможет выловить ошибки и слабые места. Есть специализированные группы (например, @resume_review), где вам субъективно оценят резюме: прислушаться стоит, но решения о правках принимайте исходя из здравого смысла.

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

Шаг 3: Прокачайте онлайн-профили

Убедитесь, что вы представлены в основных профессиональных сетях, например, на Хабр Карьера и LinkedIn. Зарегистрируйтесь (если почему-то до сих пор этого не сделали) и добавьте в контакты всех, с кем вы лично знакомы и работали: бывших коллег, одногруппников, клиентов. Когда придёт время объявить о поиске работы, их активность (лайки, комментарии, рекомендации) поможет продвинуть ваш пост.

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

• Хабр Карьера — на этой платформе сейчас меньше соискателей, чем на HH, поэтому у вас больше вероятность быть замеченным, а значит, ненулевой шанс получить ответ от работодателя.
• LinkedIn — несмотря на блокировку, там по-прежнему активное русскоязычное IT-сообщество, и многие HR ищут разработчиков через LinkedIn. Особенно полезно, если вы рассматриваете работу за рубежом.
• Сервисы типа Geekjob и Getmatch — сервисы и сайты-агрегаторы вакансий, популярные в стартап-тусовке. Пока проект небольшой, удобнее опубликовать вакансию в таком сервисе.
• Telegram-каналы и чаты с вакансиями — вступайте в сообщества, соответствующие вашему стеку или специализации, и следите за публикуемыми там предложениями. В интернете можно найти множество подборок таких каналов, по каждому направлению. (вот наиболее актуальный список каналов и чатов с вакансиями в ИТ).
• Сайты компаний — банально можно написать прям через карьерные страницы интересующих вас компаний. Вакансии там могут появляться раньше, и отклик попадает сразу в систему к рекрутеру.

Кроме того, обратите внимание на ваши проекты и код в открытом доступе. Если у вас репозитории с проектами, которыми вы гордитесь, сделайте их публичными и закрепите в своём профиле. Добавьте понятные README-файлы, описывающие проект. По возможности прикрепите ссылки на работающие демо или публикации. На пустой же GitHub ссылку лучше не давать.

Шаг 4: Сохраните и расширьте деловые контакты

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

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

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

И наконец, прямо заявите о своём статусе. Поставьте везде отметку Open to Work. В идеале — публично объявите в личных соцсетях, что вы в поиске новой позиции. Небольшой пост с благодарностью прошлой компании и упоминанием, что открыты для предложений. Информация быстро разлетается по сети, и нередко именно через знакомых приходят интересные предложения.

Шаг 5: Подготовьте шаблон отклика (сопроводительное письмо)

Составьте динамический шаблон отклика, который будете подстраивать под каждую вакансию. На крупных сайтах вроде HH рекрутеры сейчас получают сотни заявок, и сделать выбор становится всё сложнее. Ваша задача — выделиться из массы. Поэтому важно уже в первых строчках сопроводительного письма показать, что вы идеально подходите под требования вакансии. Укажите 2–3 ключевых навыка или достижения, наиболее релевантных описанию позиции.

Чтобы повысить шанс на отклик, под каждую вакансию пишем индивидуальное письмо. Для экономии времени можно воспользоваться нейросетью, чтобы она помогла быстро проанализировать описание вакансии и выделить основные требования. На основе полученного списка убедитесь, что в отклике и резюме упомянуты все ключевые навыки, которыми вы владеете и которые требуются работодателю, а лишние детали — удалены. Это нужно для того чтобы ваш отклик прошёл авто-скрининг (раз, два, три): если резюме не содержит определённых слов, его может даже не увидеть живой рекрутер. Чтобы не быть отсеянным бездушной машиной, сопроводительное письмо и резюме должны на 100% подходить под вакансию. Если же в вакансии указана технология, с которой вы мало работали, но в целом знакомы — всё равно упомяните её, честно указав уровень владения. Пусть лучше ATS пропустит вашу кандидатуру, а решение уже будет принимать человек.

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

Шаг 6: Грамотно работайте с откликами

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

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

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

Но настоящий интервьюер в 2025 не станет задавать «100 вопросов разработчику», а скорее всего предложит решить прикладную задачу или обсудить реальный кейс из практики. Полезно также поискать и посмотреть видео с реальными собеседованиями в похожих компаниях или на аналогичные позиции. Это не даст готовых ответов, но поможет понять общую структуру интервью, зная, чего примерно ждать.

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

Заключение

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

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

Полезные ссылки:

• Мой блог, в котором есть и другие статьи по теме
• Мой Telegram-канал
• Шаблон АТС-френдли резюме
• Каналы и группы с вакансиями

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

Здесь и появляются новые роли — Technical Owner и Unit-лид. Их задача — взять на себя куски ответственности, которые раньше выпадали из поля зрения команды.

В российских компаниях эти роли пока не получили широкого распространения, особенно в небольших и средних организациях, где функции часто распределены между тимлидами, продакт-оунерами и проектными менеджерами. Однако в крупных IT-компаниях и продуктовых командах, таких как Avito и другие, Unit-лид и Technical Owner становятся всё более востребованными, поскольку помогают разграничить ответственность и повысить прозрачность управления сложными продуктами и командами.

Technical Owner: кто это и зачем нужен

Представим ситуацию: компания разрабатывает маркетплейс на Python и React, всё вроде идёт по плану, пока менеджеры не просят срочно добавить новую систему оплаты. Они не вникают, что для этого придётся переделать схему платежей, разнести микросервисы, рискуя уронить старые заказы. Разработчики объясняют, что быстро не выйдет, но их не слышат — и в итоге проект зависает между требованиями бизнеса и возможностями команды. Именно в таких случаях нужен Technical Owner.

Кто это такой

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

Какие у него обязанности

Вот примерный список того, что делает ТО:

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

Это неполный список, и обязанности отличаются в разных компаниях, всё зависит от специфики продукта и процессов.

Чем отличается от продуктового менеджера, техлида и архитектора

Чем ТО отличается от продуктового менеджера

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

Чем отличается от тимлида, техлида и архитектора

Тимлид, техлид — это руководители команды, которые отвечают только за её задачи. TO, хоть и глубоко понимает техническую сторону, но его роль шире — он связывает технику с бизнесом и даже консультирует клиентов. Technical Owner отвечает за общее техническое и архитектурное видение продукта. Масштаб его ответственности больше.

В отличие от архитектора, технический владелец не только принимает участие в проектировании, но и доносит эти решения до клиентов и руководства.

Technical Owner (Технический владелец) ответственен за долгосрочное здоровье и развитие конкретного компонента/системы/продукта. Фокус на технической стратегии, архитектуре, надёжности и поддержке в течение всего жизненного цикла.

Техлид руководит командой, отвечающей за разработку. Фокус на распределении задач, наставничестве и решении технических проблем.

Архитектор решений определяет технологический стек и взаимодействие компонентов. Фокус на общей структуре и дизайне решения.

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

Сколько зарабатывает и какие нужны навыки, чтобы стать ТО

Если мы сейчас пойдём на hh.ru и введём в поиск Technical Owner, то, в лучшем случае, найдём только пару вакансий. Technical Owner нужен для больших продуктов в крупных компаниях, поэтому должность встречается на рыке редко и пробиться туда сложно.

Зарплата и навыки зависят от конкретной компании, её процессов и задач. Обычно это что-то на уровне топ-менеджмента. Вот пример заработной платы в одной из вакансий от Яндекс 360:

А вот так выглядят обязанности и необходимые навыки:

Вот пример ещё одной такой вакансии от компании Itransition:

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

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

Кто такой Unit-лид, зачем он нужен

Кто это такой

Юнит-лид — это руководитель, который возглавляет «юнит» – объединение нескольких команд (обычно 3-5), работающих над частью общего продукта или бизнес-направления. Он отвечает за стратегию и бизнес-результаты своего юнита.

В последние полгода в нашей компании появилась новая управленческая роль — Unit Lead. Это ответственный руководитель,который координирует работу всего юнита: от стратегии до найма и развития сотрудников. Мы внедрили эту модель не просто ради структуры — она стала ответом на быстрый рост бизнеса и усложнение внутренних процессов.

Что такое юнит? Это самостоятельный бизнес-модуль, включающий несколько стримов (направлений). Каждый стрим, в свою очередь, состоит из команд по 5-10 человек. Таким образом, один юнит может объединять от 5 до 12 команд, представляющих разные IT-направления: фронтенд, бэкенд, мобайл и др.

Какие у него обязанности

Обязанности юнит-лида очень обширны и зависят от типа юнита:

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

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

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

Ответственность за результаты: вся ответственность за вектор развития и конечный результат юнита лежит на юнит-лиде. Иногда на нём висит даже отчётность по финансовым результатам.

Разработка и развитие продуктов/инструментов: юнит-лиды могут адаптировать существующие инструменты, разрабатывать новые под потребности команд, а также создавать внутренние платформы и технически сложные продукты.

Чем отличается от продуктового менеджера и тимлида

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

Что делает продуктовый менеджер

Продуктовый менеджер (PM или Product Owner) отвечает за конкретный продукт или его отдельные части. Его главная задача — понять, что нужно пользователям и бизнесу, сформировать требования и приоритеты, а затем воплотить эти требования в жизнь. PM постоянно держит руку на пульсе метрик, проводит A/B-тесты и собирает обратную связь.

Что делает тимлид

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

Чем занимается юнит-лид

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

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

Две другие команды отдают цены в другие сервисы, организуют скидки, интегрируют новые категории товаров и услуг в систему.

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

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

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

Сколько зарабатывает unit-лид, какие нужны навыки и как им стать

Наткнуться на вакансию юнит-лида на просторах hh.ru тоже непросто. Это новая роль, которая нужна только для сложных продуктов в крупных IT-компаниях.

С зарплатой и обязанностями всё индивидуально, зависит от компании. Вот пример одной из вакансий от Купера:

Зарплата вполне на уровне топ-менеджмента. А вот обязанности и ожидания:

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

А вот ещё один пример обязанностей и ожиданий в другой вакансии, на этот раз от Яндекса:

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

Где и когда эти роли реально нужны (а где — нет)

Какие компании и проекты выигрывают от появления таких ролей

Technical Owner и Unit-лид подходят не всем. В стартапах и небольших командах, где каждый знает свои задачи и зоны ответственности, эти позиции будут избыточными и просто усложнят работу.

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

Сигналы, что команде пора подумать о Technical Owner или Unit-лиде

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

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

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

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

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

Что злит инженеров

1. Постоянные «синки», которые мешают работе

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

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

2. Пренебрежение реальностью

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

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

3. Присвоение заслуг

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

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

4. Бессмысленные митинги

Многие менеджеры заменяют простое сообщение в мессенджере регулярными встречами. Расписание команды заполняется планированиями, синками, ретроспективами и демо. На саму работу времени почти не остаётся.

5. Поверхностный фидбек

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

Что чувствуют сами менеджеры

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

Руководители тоже испытывают давление — со стороны бизнеса, клиентов и команды. Многие из них не «плохие по натуре» — просто не справляются с системой, в которой находятся. Они вынуждены действовать в условиях нехватки информации, ресурсов и времени.

В целом, это скорее не оправдание, а объяснение позиции человека «с той стороны».

Как выглядит хороший менеджмент

Лучшие руководители, с которыми автор работал, выделяются несколькими подходами:

• Уважают «фокусное время» инженеров и не мешают по мелочам.
• Поддерживают техническую насмотренность и слушают команду.
• Делятся заслугами команды и берут ответственность на себя.
• Дают своевременную и конкретную обратную связь.
• Активно продвигают своих сотрудников внутри компании.

Почему «тормоза» — это не всегда про код

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

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

Вот что тормозит, когда код ни при чём:

Архитектура

• Цепочки вызовов: каждый хоп — +latency.
• Синхронные зависимости: завис один сервис — тормозят все.
• Общие ресурсы: shared state, глобальные очереди, блокировки.

Базы данных

• Нет индексов или плохой план запроса.
• N+1-запросы — особенно при неосторожной ORM.
• Частый доступ к одним таблицам — гонка за IO и блоки.
• Нет шардинга или репликации в масштабируемой нагрузке.

Сеть

• Высокая задержка между регионами (особенно multi-cloud).
• Потери пакетов, DNS-проблемы, нестабильность.
• Отсутствие connection reuse: TLS-handshake на каждый вызов.

Очереди и брокеры

• Один медленный потребитель тормозит всех.
• Нет защиты от от backpressure или дедупликации.
• Неправильные batch- и ack-настройки.

Аллокаторы и GC

• Фрагментация памяти, нагрузка на GC.
• Финалайзеры, слабые ссылки, плохо настроенный heap.

Конфигурации

• Маленький пул соединений — пул заканчивается, запросы ждут.
• Агрессивные retry-политики — система перегружается.
• CPU throttling в Kubernetes — контейнеру не хватает ресурсов.

Сериализация и форматы

• Перегруженные JSON/Protobuf.
• Вложенные base64 + gzip + JSON — боли сериализации.

Почему bottlenecks остаются невидимыми до продакшена

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

• мало данных,
• нет конкуренции за ресурсы,
• нет распределённой нагрузки.

В проде начинается хаос. Рассмотрим на конкретных примерах:

• На деве — 2 запроса в секунду, в проде — миллион. Кто-то запустил маркетинговую рассылку, аналитик тащит big report, а клиент ретраит ошибки.
• Архитектура «в лоб»: всё синхронно, каждый сервис вызывает по цепочке десяток других. Пока нагрузка мала — все живет. Как только одно звено не выдерживает — перестает жить.
• Иллюзия масштабируемости: до 100 пользователей — всё окей, на 1000 — каскадная деградация.
• «Невидимая боль» между сервисами: каждый по отдельности быстрый, но блокирует друг друга на базе.

Слои архитектуры и где в них зарыты проблемы

Когда приложение тормозит, мы часто копаемся в отдельных компонентах — фронте, бэке, базе. Но bottleneck может быть не внутри компонента, а между ними: в конфигурации, связях, сетевых задержках, очередях вызовов.

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

На уровне клиента

• Тяжёлые бандлы. Огромный JS, куча аналитики, трекеры — и вот страница загружается 8 секунд на старом телефоне.

• Чрезмерные запросы. После загрузки — 10 fetch в секунду. API захлёбывается, браузер — тоже.

• Нет кеша. Даже статичные справочники каждый раз грузятся заново.

• Лаги рендеринга. Бэкенд дал ответ за 100ms, но интерфейс лагает — сложные таблицы, графики, reflow.

На уровне API Gateway / BFF

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

На уровне Backend / бизнес-логики

• Цепочки вызовов. Один сервис вызывает другой, тот — ещё один… И так далее.
• Ограниченный пул соединений — сервис готов работать, но все worker-ы ждут ресурсы.
• Логика в цикле по данным — N+1-запросы, сериализация, дублирование работы.

На уровне базы данных / кэша

• Full table scan. Работает быстро на 1000 строках. Умирает на 10 миллионах.

• Локи и гонка за ресурсы. Один UPDATE лочит строку, остальные ждут.

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

На уровне внешних сервисов (API, брокеры, платёжки)

• Без timeout и fallback. Внешний API залип — вы вместе с ним.
• QPS-лимиты. Вы не знали, а вас уже зарейт-лимитили.
• Нестабильная сеть. DNS тормозит, соединения рвутся, задержки скачут между регионами.

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

Есть архитектурные паттерны риска, которые часто приводят к тормозам через полгода. Во-первых, общий ресурс на всех: один Redis, один Kafka-топик, одна таблица. Пока нагрузка маленькая — ок. Потом начинается бойня за доступ. Во-вторых, микросервисный монолит: формально разделены, но живут как один. Масштабировать невозможно. В-третьих, цепочки вызовов: 5–6 сервисов на путь одного запроса. Один подвис — и вся цепочка тормозит.

Базы данных: когда даже SELECT тормозит всё

В бэкенде одна из самых коварных фраз — «ну это же просто SELECT, что с ним будет». Ответ — сначала ничего. Но со временем появляется 10 миллионов строк, и ваш innocuous SELECT превращается в full scan, который лочит диск, ест CPU и тормозит всё, что движется.

Типичная ситуация: в таблицу пишут JSONB без нормализации и индексов. Пока строк мало — жить можно. Но при росте объёмов каждый запрос превращается в медленное последовательное чтение. Это не просто «долго», а начинает мешать соседним транзакциям: подгружаются stale данные, вытесняется кэш, система начинает проседать вся — вплоть до API.

Отдельная ловушка — смешение OLTP и OLAP нагрузки. Днём — INSERT и UPDATE от клиентов, ночью — фоновая аналитика, высчитывающая отчёт за год с десятком JOIN и чтением всей таблицы. Если все запросы идут в один инстанс, происходит конкуренция за ресурсы: аналитика сбивает кеш, вызывает блокировки, а продакшн-метрики начинают сыпаться.

Как понять, что тормоза идут из базы, а не из бэкенда?

Вот несколько типичных признаков:

• Бэкенд «висит» на запросах к базе — в логах видно, что приложение ждёт результат запроса (долгий await, query(), findMany() и т. д.).

• Latency растёт, а CPU и память в норме — сервис сам по себе не перегружен, но ответ приходит медленно.

• В базе фиксируются медленные запросы — например, SELECT или JOIN занимают секунды, хотя раньше проходили за миллисекунды.

Чтобы подтвердить гипотезу, можно:

• Включить логирование SQL-запросов с таймингом;
• Посмотреть трейс: если шаг DB заметно длиннее остальных — это тревожный сигнал;
• Запустить EXPLAIN ANALYZE на типовые запросы и проверить, где зарыта сложность.

Архитектура доступа к данным: как закладываются тормоза

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

На что здесь стоит обратить внимание:

• Количество и характер обращений. Один пользовательский запрос не должен порождать десятки обращений к базе. Планирование кэшей, агрегаций, prefetch, нормализация — всё это часть архитектуры.
• Уровень абстракции над данными. ORM может быть удобным, но часто скрывает десятки неэффективных SELECT’ов. Нужно понимать, какие запросы реально идут в базу, и не превращать каждый use case в потенциальный bottleneck.
• Стратегия хранения и агрегаций. Если вы пытаетесь на лету агрегировать 100 миллионов строк без шардинга и партиционирования — тормоза неизбежны. Архитектура должна учитывать нагрузку, частоту агрегаций, структуру данных.

Очереди и событийные системы: скрытые замедления

Событийные архитектуры и очереди вроде Kafka или RabbitMQ часто воспринимаются как универсальное средство от всех проблем: «Сделаем асинхронно — и всё полетит». Но это не серебряная пуля. Очередь не решает проблему — она её откладывает. А иногда сама становится bottleneck’ом.

Типовые ситуации, когда очередь тормозит систему:

• Медленные консьюмеры. Очередь принимает сообщения с высокой скоростью, но обработчики не успевают, и начинается накопление беклога. В результате задержки накапливаются, SLA летит, а вы только недоумеваете, почему всё так тормозит.
• Неправильный размер batch’ей. В Kafka и аналогах размер и частота batch'ей критичны. Слишком большие — ждём, пока соберётся партия. Слишком маленькие — тратим ресурсы на лишнюю загрузку и пересылку. В итоге получаем либо высокую задержку, либо низкую производительность.
• Неравномерное партиционирование. Если сообщения распределяются по партициям неравномерно, то часть узлов будет простаивать, а часть захлёбываться под нагрузкой. Одна горячая партиция может стать bottleneck’ом всей системы.
• Проблемы с retry. Если нет чёткой стратегии повторных попыток, логирования и DLQ (dead-letter queue), битое событие может крутиться в системе бесконечно, тормозя всё остальное. Также если что-то пошло не так и включились retry-механизмы, задержка может вырасти в разы. Особенно если есть backoff или дедлоки.

Почему «асинхронно» ≠ «мгновенно»

Асинхронность — это не про скорость, а про отложенность. Событие отправлено — но когда оно будет обработано, никто не знает. Через секунду, через минуту, через час?

Типичные причины задержек в асинхронной обработке:

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

Что происходит, когда очередь переполнена — и почему это тяжело заметить

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

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

Для защиты от переполнения очереди нужно мониторить несколько важных показателей:

• Глубина очереди (в Kafka — consumer lag, в RabbitMQ — queue.messages_ready или queue.messages): показывает, сколько сообщений накопилось и ждёт обработки.
• Publish rate: сколько сообщений в секунду публикуется.
• Processing rate: сколько сообщений в секунду обрабатывается.
• Утилизация ресурсов воркеров (CPU, memory, I/O).
• End-to-end latency: сколько времени проходит от публикации события до его обработки.

Есть самые частые причины накопления сообщений:

1) Медленные потребители, которые не успевают обработать весь поток сообщений.
2) Шумная архитектура: 10 сообщений там, где можно было обойтись и одним.
3) Неправильное масштабирование брокера (например, неправильно выбранный ключ партиционирования в Kafka).

API и микросервисы: где тормозит взаимодействие

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

Что тормозит в микросервисах?

Много лишних вызовов

Один пользовательский запрос вызывает лавину внутренних HTTP/gRPC-запросов. Каждый из них — это:

• сетевые задержки (latency),
• сериализация/десериализация данных,
• ретраи при сбоях,
• риск таймаутов и обрывов.

Если таких вызовов много, задержка накапливается каскадом.

Цепочка зависимостей

Классика жанра: заказ зависит от оплаты, оплата — от биллинга, биллинг — ещё от трёх микросервисов.

Если тормозит хотя бы один, сыплется всё. Получается эффект домино и каскадные отказы, где неполадка в одном звене рвёт всю цепочку.

Нет fallback'а и таймаутов

Если вызов к нужному сервису не отвечает, а у вас нет fallback'а или таймаута — всё встаёт. Особенно плохо, если вызов синхронный и блокирует поток.

Наносервисы

Иногда архитекторы увлекаются и дробят сервисы до абсурда. Начинается с «давайте переиспользуем», а заканчивается 10 API-вызовами ради одного действия.

Вместо бизнес-логики система начинает заниматься оркестрацией — координирует сама себя.

Кэш и CDN: почему «ускорители» тоже могут тормозить

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

Вот несколько типичных ошибок, которые приводят к деградации производительности:

Невалидные или слишком агрессивные стратегии

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

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

Перегрузка кэша

Когда кэш настолько загружен, что сам по себе начинает тормозить — это уже не помощь, а вред. Такое часто случается с Redis, Memcached или in-memory решениями, особенно если они:

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

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

Кэш-миссы и лавины запросов

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

Вместо одного запроса вы получаете 10 000, и тормозит всё. Особенно критично это для систем с CDN, где внезапное истечение кэша популярных страниц может вызвать DDoS-подобную нагрузку.

Несогласованность кэшей

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

Вычисления и память: что не так с аллокацией

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

Частые и крупные аллокации

Каждый раз, когда создаётся новый объект, память выделяется из кучи. При интенсивной работе (например, при парсинге JSON или обработке больших структур) это может происходить слишком часто, и тогда запускается сборщик мусора (GC).

Сборка мусора — это не бесплатная операция: она останавливает выполнение программы. Частые GC-паузы создают «плавающую» производительность, когда всё работает быстро, но время от времени подвисает даже на секунду.

GC-паузы

Автоматическое управление памятью — благо, но оно же и ловушка. В языках вроде Go, Java или Python невозможно точно контролировать, когда сработает сборщик. Даже задержка в 50 миллисекунд может ощутимо ударить по RPS или нарушить real-time обработку.

Некоторые компании придумывают обходные пути. Так, в Twitch использовали технику memory ballast для Go-приложений, чтобы стабилизировать поведение GC и избежать всплесков пауз.

Синхронные и блокирующие операции

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

Классический пример — однопоточный web-сервер, который просто ждёт ответ от другой системы. Или библиотека, использующая mutex.Lock() в горячем участке, из-за чего десятки горутин встают в очередь.

Ограниченные ресурсы и очереди

Даже в многопоточном приложении можно легко создать узкое место. Например:

• доступ к объекту синхронизирован через mutex или RW-lock;

• пул соединений имеет жёсткий лимит;

• очередь задач не может масштабироваться под нагрузку.

В таких случаях нагрузка растёт, а пропускная способность — нет. Всё упирается в искусственное ограничение, введённое «на всякий случай».

Однопоточные горячие участки

Даже в многопоточной архитектуре может оказаться, что 80% времени тратится в одном месте, которое не масштабируется — например, в процессе сериализации, расчёта или шифрования. Иногда этот участок реализован однопоточно (особенно в Node.js, Python или старом Go-коде) и становится главным тормозом системы. Под высокой нагрузкой это становится особенно заметно.

Что делать: подход к поиску и устранению bottlenecks

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

Шаг 1. Зафиксировать симптомы и контекст

Важно понять, что именно «тормозит» и в каких условиях. Типовые вопросы:

• Когда проявляется проблема: под нагрузкой, в пиковые часы, у конкретных пользователей?
• Что именно работает медленно: API, отчёты, фоновая обработка?
• Как это влияет на систему: задержки, таймауты, ошибки?

Пример: пользователи жалуются, что отчёты стали строиться дольше. Вчера — 5 секунд, сегодня — 20.

Шаг 2. Проверить очевидные метрики

Начинаем с того, что уже доступно в мониторинге:

• латентность API (p50, p95, p99);
• загрузка CPU, использование памяти и диска;
• глубина очередей и backlog;
• паузы GC;
• кэш hit/miss ratio.

Если латентность растёт, а CPU загружен на 20%, это может указывать на проблемы в синхронных вызовах, аллокации или неэффективной работе кэша.

Шаг 3. Сузить область через трейсинг и логирование

Чтобы выяснить, не «тормозит» ли другой сервис, используйте распределённый трейсинг (Jaeger, OpenTelemetry, Sentry Performance) или логирование таймингов внутри запроса.

Пример (Go, обёртка для http.RoundTripper):

Так можно увидеть, что, например, сторонний сервис отвечает 3 секунды, или Redis стал отдавать ответ за 300 мс вместо обычных 3 мс.

Шаг 4. Воспроизвести нагрузку

Если проблема зависит от объёма данных, воспроизведите реальный сценарий или нагрузку:

• используйте инструменты вроде k6, Locust, Artillery;
• проверьте реальные условия (например, отчёт за 30 дней, а не за 3).

Если латентность растёт нелинейно, это может быть признаком N+1-запросов, неоптимального SQL или проблем с аллокацией.

Шаг 5. Подтвердить проблему профилированием

Если есть подозрение на перегрузку CPU или утечку памяти, используйте профилировщики:

• Go — pprof;

• Java — JFR, VisualVM;

• Node.js — clinic.js, chrome://inspect.

Пример (Go, локальный pprof):

Профиль покажет, где тратится CPU, как распределяются аллокации, как часто запускается GC и в каком коде.

Шаг 6. Оптимизировать, перепроверить и зафиксировать

После подтверждения проблемы можно переходить к исправлениям:

• кэшировать внешний вызов;

• заменить тяжёлую сериализацию (например, на easyjson в Go);

• убрать блокирующую операцию;

• перейти на batch-обработку.

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

Итоги: как не попасть в архитектурную ловушку

Bottleneck’и возникают даже в самых технологичных проектах. Это не всегда следствие «плохого кода» — куда чаще они появляются из-за архитектурных просчётов: недооценили нагрузку, не предусмотрели масштабирование, сделали ставку на неправильное решение.

Главная проблема в том, что узкие места проявляются не сразу, а под нагрузкой. В разработке и тестах всё летает, потому что ресурсов хватает. А вот в проде — особенно при росте аудитории — на поверхность всплывает всё, что не выдерживает реального объёма данных или конкуренции за ресурсы.

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

Думайте об объёмах и росте

Архитектура должна выдерживать не только текущую нагрузку, но и разумный рост. Строить систему на «миллиард пользователей» с первого дня — избыточно. Но если вы рассчитываете, что пользователей станет в 5 раз больше через год — закладывайте это сейчас. Узкие места не любят сюрпризов.

Настраивайте метрики с первого дня

Без данных вы работаете вслепую. Любой анализ будет превращаться в гадание: виноват код или Redis, где тормозит — непонятно. С самого начала следите за ключевыми метриками: latency, очереди, GC, hit/miss в кэше, ошибки. Это не «доработка потом», а часть живой системы.

Проектируйте с учётом деградации

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

Не усложняйте архитектуру без повода

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

Bottleneck’и — это не баг, а симптом. И хороший архитектор — это не тот, кто устраняет тормоза, а тот, кто их не допускает.

Больше боли коддеров — тут.

Почему код-ревью — не про власть, а про заботу

Код-ревью — процесс, который помогает проекту и команде расти. И подходить к нему стоит не с позиции «сейчас найду ошибку», а с установки «сделать вместе с разработчиком лучше». На зачем он вообще нужен?

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

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

Что на самом деле проверяется

В код-ревью обычно проверяется:

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

Задача здесь — дать взгляд со стороны, нащупать правильные вопросы, увидеть то, что автор кода мог не заметить. Но как это сделать правильно?

Чек-лист для ревьюера: что смотреть в коде, чтобы все прошло гладко

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

Логика: всё ли понятно и предсказуемо?

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

Код решает задачу или обходит её?

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

• «А зачем тут это условие?»
• «Можно ли решить задачу проще?»
• «Это бизнес-логика или побочный эффект бага?»

Всё ли предсказуемо?

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

Нужно проверить:

• Есть ли неожиданные побочные эффекты?
• Не делает ли функция всё подряд?
• Можно ли использовать этот код повторно?

Учитываются ли граничные случаи?

Тестировать happy path — это приятно. Но ревью — момент, когда нужно быть немного параноиком и задавать себе вопросы:

• «А что, если в массиве будет null?»
• «Что вернётся, если база пустая?»
• «Что произойдёт, если API не ответит?»

Если логика ломается при первой же нестандартной ситуации — это нерабочая логика.

Видна ли связь между частями?

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

Архитектура: насколько код ложится в общую картину?

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

Живёт ли код в вакууме

Каждый новый модуль, компонент или класс должен:

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

Следует ли код соглашениям команды

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

Нужно проверить:

• используются ли принятые в команде подходы;
• поддерживаются ли слои;
• повторяет ли структура проекта предыдущие решения.

Безопасность: нет ли уязвимосей?

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

Пользовательский ввод

Всё, что приходит от пользователя (формы, параметры URL, тело запроса), требует внимания. Здесь могут возникнуть SQL-инъекции, XSS и т.д. Поэтому стоит проверить:

• Есть ли валидация данных на стороне сервера?
• Используются ли подготовленные запросы или ORM?
• Обрабатываются ли потенциально опасные символы?
• Предусмотрена ли защита от исполнения произвольного кода?

Доступ к данным и авторизация

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

• Есть ли проверка прав пользователя перед выполнением запроса?
• Реализована ли проверка не только на фронте, но и на сервере?
• Используются ли идентификаторы, которые нельзя легко перебрать?

Тесты: можно ли быть уверенным, что всё работает?

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

Есть ли вообще тесты?

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

Проверяем:

• Есть ли новые юнит- или интеграционные тесты?
• Актуальны ли существующие — не остались ли висящими после изменений?
• Упали ли какие-нибудь тесты в CI — и если да, то почему?

Тестируется ли то, что нужно?

Иногда тесты есть, но проверяют слишком очевидное или не покрывают рисковые места. На что обратить внимание:

• Проверяются ли граничные случаи (например, пустой ввод, null, некорректные данные)?
• Есть ли тесты на негативные сценарии — когда функция должна вернуть ошибку?
• Покрыта ли новая логика?

Понятны ли сами тесты?

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

• Говорят ли названия тестов, что именно они проверяют?
• Можно ли по коду теста быстро понять, зачем он нужен?
• Нет ли странных чисел или непонятных моков?

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

Как давать комментарии и не звучать резко

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

Начните с положительного: что в этом коде уже хорошо

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

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

Что можно хвалить:

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

Примеры фраз:

• «Здорово, что ты вынес логику в отдельный хелпер — теперь это читается в разы легче».
• «Классная идея использовать (вставьте код),а не (вставьте код)— так гораздо понятнее».
• «Круто, что добавил тест на этот кейс — про него часто забывают».

Замечания: только по делу и с предложением, как исправить

Чтобы код-ревью было конструктивным, нужно не просто указывать на проблему, а помогать найти решение. Комментарии без объяснения или контекста могут звучать как придирки, особенно если ревью получает менее опытный разработчик. А вот если вы объясняете, почему что-то не так, и что можно сделать по-другому — это уже наставничество, а не критика.

Так НЕ надо:

• «Плохо читается».
• «Переделай»
• «Зачем???»

Так лучше:

• «Можно упростить, если разделить условие на два блока — сейчас выглядит довольно сложно».
• «Тут, кажется, можно обойтись без цикла: достаточно метода (вставьте метод)— он короче и лучше читается»..
• «В этом месте можно потенциально получить undefined. Может, стоит добавить проверку?»

Говорите прямо, без намёков и иронии

Код-ревью — не место для недосказанностей и полутонов. Комментарии вроде «Ну, если так РЕАЛЬНО работает — ок» звучат пассивно-агрессивно и только создают напряжение. Получивший такое замечание будет гадать: это одобрение, сарказм или тонкий намёк, что я всё сделал не так?

Вместо этого — формулируйте замечания ясно и по существу:

• «В этом месте поведение функции может быть неочевидным — можешь уточнить название или добавить комментарий?»
• «Пока непонятно, почему именно такое условие — можешь пояснить, пожалуйста?»
• «Похоже, тут можно упростить: если заменить на (вставьте код) логика станет короче».

Если вы не уверены, как ваша реплика будет воспринята — переформулируйте. В ревью лучше не пошутить, чем задеть человека, особенно если вы не на 100% уверены в уровне вашей взаимной иронии.

Делайте фокус на код, а не на человека

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

Так НЕ надо:

• «Ты опять забыл обработать ошибку».
• «Почему ты так сделал?!»
• «Это неправильно».

Лучше так:

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

Когда мы говорим о коде, а не о человеке, снижается напряжение. Человек не чувствует, что его «проверяют», он чувствует, что с ним вместе улучшают результат.

Как сделать код-ревью полезным и для себя

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

Учитесь новому: чужой код — тоже учебник

Читая чужие решения, можно заметить многое: библиотеку или инструмент, который вы раньше не использовали; необычную структуру функции или способ организации логики; паттерн, который вы обычно не применяете, но он к месту и т.д. Это особенно полезно, если вы работаете в мультистековой команде. Кто-то пишет на Python, вы — на C++, но идеи и архитектурные подходы легко переносятся между языками. Подмечайте, как другие подходят к задачам, даже если в целом всё вам понятно — детали часто дают самые интересные инсайты.

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

Задавайте вопросы, даже если всё понятно

Иногда вы смотрите код — и вроде всё чисто, логично. Но это как раз повод не просто молча одобрить, а пообщаться с проггером. Почему? Потому что вопросы — не всегда сигнал о проблеме: иногда это инструмент обучения.

Например:

• «А почему решили использовать именно этот метод?»
• «Это кастомное решение или такой подход у нас принят в проекте?»
• «Я раньше делал по-другому — есть ли причины, почему здесь выбрали такой путь?»

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

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

Прокачивайте навык объяснять

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

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

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

Почему это работает:

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

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

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

Мы задали одни и те же вопросы тимлидам и менторам Solvery —Михаилу Черемухину-Рербергу, frontend team lead в Uchi.ru, и Камилю Закиеву, backend team lead в Контуре, — и узнали, чем же на самом деле отличаются миддлы и сеньоры.

Решать задачу или решать проблему

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

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

Разница в подходе к решению бага — это не просто про технику, а про системное мышление. Senior мыслит процессами, связями и классами проблем. Он знает: устранение конкретного бага не спасёт систему от будущих сбоев, если не изменить подход к разработке.

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

К слову о вопросах. Вот шутка от Миши:

Миддл: Почему код этого приложения так плохо написан? Можно же было взять технологию Х, она бы упростила все раз в 10!
Сеньор: так исторически сложилось.

Та самая ответственность

Один из главных признаков senior-разработчика — уровень ответственности, который он берёт на себя. Это видно буквально с первых дней работы над задачей. Миддл — уточняет, просит помощи, ждет ревью, не всегда понимает продуктовый контекст. Senior сам идёт выяснять, кто заказчик задачи, уточняет требования, предлагает компромиссы, инициирует обсуждение с командой.

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

Миша, например, не доверил бы миддлу такие задачи:

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

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

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

Сеньор — это далеко не про знание

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

Вот главные навыки, которые отличают сеньора от миддла по мнению Миши:

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

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

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

От сеньора я ожидаю, что он задаст любое количество вопросов, которое ему понадобится, чтобы картина сложилась целиком. Как правило, разработчики рангом ниже стесняются задавать вопросы, ибо боятся показаться глупыми. Сеньор же понимает, что лучше спросить сейчас, чем больше работать потом, либо доделывать работу в нервяках. Также ожидаю, что в лорда можно кинуть задачу (контекст), ограничения (как временные, так и ресурсные), а он в свою очередь возьмет техническую часть реализации. Уйдет и вернется с решением. В идеале, еще и будет держать в курсе по промежуточным статусам.

Про влияние на команду

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

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

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

Ты готов, мой мальчик (или нет)

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

Когда человек берёт больше ответственности, берёт задачи с большой долей неизвестности, отвечает за результат — тогда он становится сеньором.

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

Все сводится к одной простой мысли: senior — это не роль, а способ действовать. Это уровень ответственности, зрелости, влияния и подхода. Миддл решает задачи, а сеньор — проблемы. Миддл спрашивает, как делать, а сеньор — зачем делать.

Если вы миддл и хотите вырасти — начните брать на себя чуть больше, чем просили. Задавайте больше вопросов, особенно про смысл и цели. Учитесь не просто кодить, а проектировать, объяснять и влиять на то, какие задачи появляются.

И тогда — грейд догонит вас сам.

Более 400 профессионалов приняли участие — разработчики, инженеры и тимлиды из ведущих компаний, таких как Сбер, Т-Банк, Яндекс, VK, Авито и другие. Посетители могли погрузиться в атмосферу работы в банке, послушав доклады на Hard- и Soft-треках, а также приняв участие в активностях в экспозоне с 16 ИТ-направлениями.

Особенно приятно нам было получить много позитивных отзывов. Рассказываем, что интересного было на технологической конференции Газпромбанка.

Как мы перестроили разработку

Первый Вице-Президент Газпромбанка Алексей Ульенков открыл конференцию и рассказал про инженерную трансформацию банка за последние несколько лет.

В 2021 году в банк пришла новая управленческая команда. Ее целью стала трансформация разработки для розничного бизнеса до уровня лучших российских банков и финтех организаций. За три года трансформации удалось достигнуть среднего срока вывода новых продуктов в 2 месяца, доля собственной разработки по ключевым системам близка к 100%, а доля клиентских жалоб на цифровые сервисы находится на историческом минимуме.

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

• Все производство покрыто метриками эффективности (DORA-метрик);
• Переход на собственную разработку;
• Участие всех инженеров в написании кода;
• Переход к парадигме тестирования в разработке (shift left) для раннего получения обратной связи о качестве;
• Ориентация на бизнес-результат.

Время вывода нового продукта в Газпромбанке сейчас занимает 2 месяца, для сравнения — в других банках это 3-4 месяца. Доля инхаус-разработки для ключевых систем — 95%.

Цели команды на 2025 год:

• Внедрение помощников на баз LLM для разработчиков, автоматизаторов тестирования;
• Замена OpenShift на k8s;
• Полная миграция в новое рабочее окружение;
• Основные работы по выносу бизнес-логики из АБС и импортозамещению;
• Масштабирование практик SRE;
• Тиражирование стандарта разработки.

API-First: когда контракт важнее кода

На нашем мероприятии мы уделили отдельное внимание одному из самых актуальных подходов в разработке. Об особенностях перехода на API-First рассказал Максим Морозов. Суть подхода в том, что сначала создается четкий контракт (API), который становится основой для параллельной работы команд, и только потом пишется код. Это противоположность традиционному Code-First, где сначала создаются программные компоненты, а затем решаются проблемы их интеграции.

В масштабе крупной организации, где работают сотни команд, API-First становится не просто полезной практикой, а необходимым условием эффективной работы. Когда 200 команд и 2000 инженеров должны взаимодействовать без задержек, четкие контракты между системами критически важны для сокращения Time-to-Market.

Виктор Цветков и Юлия Григорьева поделились опытом внедрения API-First. Их доклад был не столько о технических аспектах, сколько о том, как преодолевать организационное сопротивление.

Кто-то из разработчиков видел в API-First лишнюю работу, кто-то боялся, что это замедлит разработку, а бизнес опасался дополнительных затрат и задержек в выпуске продуктов. В итоге команде удалось найти золотую середину: с одной стороны, четкий мандат руководства (без этого никуда), с другой — активное вовлечение команд через API-сообщества и рабочие группы, где разработчики сами участвовали в создании стандартов.

Результат: в розничном блоке и МСБ уже более 50 команд перешли на API-First, 127 сервисов подключены к генератору кода, а из общего количества 1033 сервисов уже 450 имеют спецификацию.

Trunk-Based Development: как выжить, когда все коммитят в одну ветку

Вадим Ваганов рассказал о Trunk-Based Development (TBD) — подходе, который многим сначала кажется безумием: одна интеграционная ветка (trunk/main), куда все разработчики напрямую вносят изменения. Вадим поделился проблемами, с которыми столкнулись при внедрении, и тем, как их решали.

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

Еще одно важное правило — «Общий только trunk!». Ветки создаются только для конкретных задач, ветвятся только от trunk и живут максимум несколько дней. Следующая важная мысль: «Деплой не равен релизу». Благодаря Feature Toggles можно часто деплоить в продакшн, но включать новую функциональность лишь тогда, когда это нужно бизнесу.

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

Инженерный рост, ускорение тестирования и мониторинг

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

Никакой воды и абстрактных рассуждений. Роман дал конкретные советы: как готовиться к собеседованиям (спойлер: это просто навык, который можно прокачать), как строить индивидуальный план развития и почему регулярные 1-на-1 встречи с руководителем — это не просто галочка в HR-процессах. Кстати, у него даже есть рецепт идеальной 1-на-1 встречи: 10% времени — про жизнь, 45% — про проект, остальное — про развитие. А еще мы как бы между делом рассказали про наш внутренний профиль инженера. Прокачал нужные навыки — получил «ачивку». Геймификация в действии!

На другой стороне спектра — практический доклад Кристины Клигер о том, как перестать работать ночами и начать выкатывать фичи в прод по нескольку раз в день. Ее рецепт — правильно выстроенное тестирование, особенно компонентное и API.

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

Валентин Лебедев рассказал, как в банке применяют MaaS (мониторинг как сервис) — подход, когда мониторинг превращается из головной боли в удобный инструмент самообслуживания. Суть простая: видеть проблемы раньше, чем клиенты успеют пожаловаться. Классическая проблема — мониторинг нужен всем, но настраивать его сложно, а разбираться в PromQL хочется далеко не каждому. Поэтому команда создала набор инструментов, где можно просто включить нужные функции анализа. Например, написали собственный плагин для VictoriaMetrics, чтобы инженерам не пришлось становиться экспертами по всему стеку мониторинговых решений.

Что было в экспозоне

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

На стенде тестирования мы запустили Mission: QApossible — квест, где участникам предстояло стать QA-спецагентами, собрать идеальный набор инструментов и спасти мир от багов. Ну, или хотя бы спасти релиз от откатов.

У мобильных разработчиков играли в Mobile Jenga: нужно было собрать приложение для iOS и Android, убрав лишние блоки, но так, чтобы вся конструкция не рухнула. Метафора понятна, да?

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

Интересно было и у бэкендеров. Они подготовили несколько хитрых задач на логику, которые заставляли участников как следует поразмыслить. А фронтендеры организовали две активности: «КОДетектив», где нужно было угадать язык программирования по фрагменту кода, и Bug Hunting с заданием найти в коде уязвимость. К стендам выстроились очереди из желающих проверить свои навыки.

Квартирник: как быть с токсиками в команде

Одним из самых увлекательных событий конференции стал квартирник на тему «Что делать с профессионалом, который демотивирует и ведет себя как токсик в команде» или, если совсем просто — «гений, но токсик: уволить или терпеть?». Формат квартирника был выбран не случайно: хотелось создать атмосферу, где можно говорить максимально открыто, без клише и обтекаемых формулировок.

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

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

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

Обсуждали и практические инструменты. Например, как объективно измерить токсичность (один из вариантов — оценка 360 градусов)? А также способы снижения уровня токсичности: регулярная похвала за успехи, материальное стимулирование и «радикальная прямота» — умение честно говорить о проблемах, не переходя на личности.

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

Было круто, будет еще круче

За один день конференции мы провели десятки активностей: от технических воркшопов до игр в Mobile Jenga и UX-квестов. Мы получили множество позитивных отзывов, что особенно ценно для нашего опыта проведения конференции.

Мы хотели показать, что Газпромбанк — это не просто финансовая организация, а технологичная и инновационная ИТ-компания, которая создает действительно удобные и надежные продукты. Первая GPB Conf точно не последняя. В будущем мы расширим программу, добавим еще больше активностей и устроим полноценный хакатон для участников. Так что ждем всех в следующем году.

А пока собираем отзывы, анализируем опыт и готовим новые идеи, чтобы следующая конференция стала еще интереснее. Если у вас есть предложения или вы хотите выступить на следующей GPB Conf — пишите нам. Лучшие идеи обязательно воплотим в жизнь!

Узнать больше о нас и наших проектах можно в телеграм-канале и на сайте Газпромбанк.Тех.

Зачем тимлиду вообще оценивать себя и команду

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

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

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

В чём разница между рефлексией тимлида и ретроспективой команды?

Важно разделять две зоны ответственности:

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

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

Самооценка тимлида: навыки, зоны роста, влияние

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

Какие навыки важны тимлиду в 2025 году?

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

Чтобы оценить свою эффективность, нужно опираться не только на ощущения. Помогают конкретные маркеры:

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

Важно задавать себе прямые вопросы: где я сработал хорошо? Что пошло не так? Что можно сделать по-другому в следующий раз?

Но что делать, если даже при хороших результатах чувствуешь синдром самозванца? В такой ситуации стоит сравнивать себя не с «идеальным» тимлидом или чужими успехами, а с собой в прошлом. Если за последние месяцы есть прогресс — ты движешься в правильном направлении. Это помогает вернуть фокус на реальное развитие, а не на внутреннюю тревожность.

Оценка команды: не про «кто слабый», а про развитие

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

Какие метрики командной эффективности реально работают?

Есть простые, но показательные ориентиры:

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

Как распознать рост или стагнацию участника команды

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

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

Как отличить выгорание от потери интереса

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

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

Подходы и инструменты для оценки команды

Необязательно устраивать месячник самопознания с табличками и ритуалами. Но если нужно видеть, как развивается команда (и самому при этом не буксовать), придётся систематизировать подход. Без данных всё будет держаться на ощущениях — и чаще всего, ложных.

Что использовать для оценки команды

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

• 1:1 — регулярные личные встречи раз в две недели или раз в месяц. Здесь можно выстроить доверие и быстро решать проблемы до того, как они всплывут на митапах.
• Опросы — раз в квартал, чтобы понять общее настроение, уровень удовлетворённости, зоны риска.
• 360-фидбек — раз в полгода или год, если хочется посмотреть на человека глазами коллег, а не только руководителя.

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

Типичные ошибки в оценке команды — и как их избежать

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

Фокус на «проблемных людях»

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

Фиксация на «слабом звене» только усугубляет ситуацию: остальные теряют мотивацию, настоящие проблемы не решаются, атмосфера становится токсичной.

Псевдо-ретро

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

Путаница между личным и рабочим

Личное отношение легко затуманивает взгляд. Особенно если кто-то «приятный в общении», но стабильно опаздывает с задачами — и наоборот. Чтобы оценка оставалась честной, нужны факты: как человек справляется с задачами, как влияет на процессы, насколько вносит вклад в общее дело.

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

Что делать с результатами оценки команды

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

Корректно даем фидбек по итогам само- и командной оценки

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

Строим индивидуальные планы развития по результатам

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

Вовлекаем команду в изменения, не вызывая сопротивления

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

Итоги: чек-лист для оценки себя и команды

В конце предлагаем универсальный чек-лист, который поможет тимлиду в оценке команды.

На что обратить внимание при самооценке?

• Достигаю ли я цели, которые ставлю перед собой и командой?
• Поддерживаю ли рост и развитие каждого члена команды?
• Регулярно ли даю понятную и полезную обратную связь?
• Умею ли я решать конфликты спокойно и конструктивно?
• Развиваю ли процессы, а не просто работаю в режиме пожаров?

Какие сигналы говорят, что в команде что-то не так?

• Появляются частые недопонимания и скрытые конфликты.
• Сильно падает мотивация и вовлечённость в задачи.
• Заметны регулярные срывы сроков без очевидных причин.
• Люди сопротивляются изменениям или делают их для вида.
• Пропадает инициатива и стремление предлагать улучшения.

Что проверить, прежде чем делать оргвыводы?

• Не перегружена ли команда задачами и ожиданиями?
• Чётко ли распределены роли и зоны ответственности?
• Достаточно ли у команды ресурсов и поддержки для выполнения работы?

• Нет ли системных проблем в процессах, которые мешают работе и развитию?

Единый чек-лист для тим-лида:

1. Цели команды понятны, достижимы и разделяются всеми участниками.

2. Каждый знает свои роли и зоны ответственности.

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

4. Команда понимает, как её успех оценивается (метрики, критерии качества).

5. Процессы не мешают работе, а помогают — есть баланс структуры и гибкости.

6. Конфликты обсуждаются открыто и решаются конструктивно.

7. У команды есть возможности для профессионального роста.

8. Тимлид следит за собственным развитием и рефлексирует над своими действиями.

9. Проблемы не замалчиваются, а выявляются и устраняются без страха наказания.

10. Изменения в процессах объясняются заранее и обсуждаются с командой.

11. Успехи команды замечаются и признаются.

12. Фокус — не только на результатах, но и на атмосфере и здоровье команды.

Как устроена виртуальная команда

Традиционная команда — это структура, в которой все участники подчиняются одному общему руководителю, тимлиду или техническому директору, в зависимости от масштаба проекта. В такую команду входят специалисты разных направлений: backend и frontend-разработчики, мобильные разработчики, дизайнеры, тестировщики и другие. Руководитель контролирует все процессы и, как правило, участвует в вопросах оплаты труда.

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

Различные подходы к организации командной работы

Традиционная команда — это фиксированная структура с прямой веткой управления. Её преимущества:

• Четкая иерархия. У сотрудников есть прямой руководитель, который ставит задачи и контролирует их выполнение.
• Быстрое принятие решений. Процесс согласования при такой структуре происходит быстрее.
• Эффективность. Традиционный тип команды подходит для проектов с жесткими сроками или разработчиками без большого опыта — в ситуациях, где нужно быстрое исполнение без лишних обсуждений.

Главным недостатком такого формата считается обмен сотрудниками. Если разработчиков перемещают между командами, они вынуждены менять и руководителей. Это приводит к:

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

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

• Гибкость и масштабируемость. Легкое перераспределение между проектами без привязки к фиксированным командам.
• Высокая адаптивность. Сотруднику не нужно привыкать к новым руководителям, так как управление строится вокруг задач, а не жесткой структуры.
• Коллегиальное принятие решений. Такой подход повышает вовлеченность и качество проработки задач.

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

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

Как управлять виртуальными командами

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

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

• Сосредоточьтесь на проектной роли. Контролируйте процессы, следите за сроками и координируйте работу. Имейте в виду, что обязанности и роли могут варьироваться в зависимости от команды — четких границ здесь нет.
• Оценивайте каждого сотрудника. Если сотрудник уже опытный, вам достаточно регулярно проводить синки и получать обновления о ходе работы. Если начинающий — нужен более плотный контроль, помощь в планировании, постановке задач и отслеживании прогресса.
• Не допускайте микроменеджмента. В каждой виртуальной команде желательно иметь техлида или старшего разработчика, который возьмет на себя оперативное управление проектной деятельностью. Без такого человека вам придется самостоятельно погружаться в детали работы, а это будет требовать большого фокуса и не оставит времени на другие проекты.

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

• Запланируйте регулярные встречи. Проводите общие собрания и конференции для всей команды, чтобы каждый рассказал о своих задачах, планах и технических решениях.
• Используйте трекеры. Системы управления задачами используются в большинстве команд, и виртуальные — не исключение. Подойдут любые удобные вам, например, JIRA или «Яндекс 360».
• Визуализируйте проекты. Например, можно использовать диаграмму Ганта для контроля задач по срокам и приоритетам, отслеживания прогресса и динамики в виртуальных командах. Это поможет взглянуть на весь процесс со стороны и оперативно заметить, если какой-то этап отстал от плана. Для точечных задач (визуализация процессов, мозговые штурмы) удобно применять доски в Miro.
• Создайте каналы для взаимодействия. Подойдет чат в любом мессенджере, но важно использовать его строго по назначению, без лишней информации. В одном из чатов, например, каждый может делиться выполненными задачами в формате скриншотов или ссылок на тестовые стенды.
• Проводите технические встречи. Организуйте отдельные встречи для обсуждения общих технических вопросов. На них разработчики могут регулярно собирать список неудобных инструментов и актуальных проблем. На встречах команда будет приоритезировать задачи и решать их поэтапно. Такой подход не только помогает устранять мелкие неудобства, но и способствует постоянному улучшению эффективности процессов разработки.

В чем сложность

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

Необходимо синхронизировать все эти процессы. Например, мы в Поиске разрабатываем разные сценарии покупок, которые бывают у пользователя. Человек может искать конкретную модель фена по параметрам — в этом случае система отображает карточку товара с характеристиками, отзывами и предложениями магазинов. Также доступен визуальный поиск: например, можно загрузить фото дивана и найти похожие модели. В обоих случаях результат представлен в едином формате карточки товара. Эти сценарии (параметрический и визуальный поиск) разрабатываются разными командами, но их реализация должна быть согласована: карточки должны выглядеть и работать одинаково.

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

• Несогласованность интерфейсов. Например, схожая функция будет выглядеть иначе в случае разных сценариев.
• Конфликты экспериментов. Одна команда запускает A/B-тест, изменяющий продукт, а другая в это же время тестирует свою версию — возникают баги на пересечении экспериментов.
• Отсутствие централизованного контроля. Команды не ведут общую систему управления задачами, не фиксируют изменения. Из-за этого часть задач может выпадать, а часть, наоборот, дублироваться.

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

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

Как работать в виртуальных командах

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

• Проявляйте инициативу. Она важна всегда, но в виртуальной команде это необходимость: нужно вникать в продукт, понимать общий контекст и разделять ответственность за результат всей команды. Задачи здесь зачастую не очень формализованы: они требуют дополнительной проработки, уточнений и поиска оптимальных решений.
• Вникайте в суть задач команды и продукта. Важно четко осознавать, какие задачи стоят перед продуктом и какие метрики нужно растить. Лучше заранее подумать и задать любые вопросы, чем потратить время не на ту задачу.
• Вовлекайтесь в работу команды. Не замыкайтесь на своем функционале: интересуйтесь работой коллег и участвуйте в обсуждениях и доработке требований по проектам. Так вы лучше поймете, как можно влиять на процесс.
• Развивайте критическое мышление. Если задача не ведет к цели или устарела — предложите альтернативные способы достижения результата.
• Предотвращайте лишнюю работу. В горизонтальной структуре за задачами порой сложно следить: они могут устаревать или задваиваться. Это нехорошо, но так бывает. Поэтому перед началом работы лучше убедитесь, что конкретное задание актуально, а вы понимаете, для чего оно нужно.

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

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

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

Виртуальные команды — это классно. А больше инсайтов и советов читайте в нашем тг-канале.

Аким Саввин, тимлид команды бэкэнда в ВСК, ментор Эйч Навыки и автор тг-канала, расскажет, зачем разработчики скручивают и накручивают опыт и как это помогает им попасть в компанию.

Опыт — новая нефть

Недавно мы писали про то, что рынок IT перегрет, зарплаты падают, джунов — не берут на работу. Усугубляется ситуация тем, что молодых специалистов стало очень много. Например, на hh.ru количество откликов на джуниор-вакансию может достигать нескольких тысяч. И самые банальные критерии, по которым кандидатов будут отсеивать эйчары — вуз, опыт и возраст. Даже если в объявлении указан минимальный опыт и «базовые знания», на собеседования будут звать тех, у кого был серьезный опыт в разработке — и то, далеко не всех.

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

Недавно в ТикТоке завирусились видео одного «разработчика», который решил провести эксперимент, сможет ли он выдумать резюме, пройти эйчаров и попасть в компанию на зарплату 500+ тысяч. Вы не поверите, но у него получилось — он уже прошел одно техсобеседование, а скоро его ждет второе в другой компании. Отвечать на вопросы, кстати, ему помогает искусственный интеллект. Считайте, он накрутил себе огромный стаж и полностью придумал все достижения на предыдущих местах работы. Здесь возникают вопросы: по каким критериям в принципе эйчары и команда отбирают специалистов? Получается, врать в резюме — просто необходимость? И можно ли оправдать тех, кто скручивает или накручивает опыт, чтобы попасть в компанию?

А этот опыт — он сейчас с вами в одной комнате?

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

Один из простых, но не самых честных вариантов для нашего Паши — банально накинуть себе еще 1-2 года опыта. Это реальный способ пробиться через жесткие фильтры HR и ATS-систем, которые часто отсекают кандидатов с недостаточным стажем. Главное здесь — не переусердствовать, иначе этого разговора из небезызвестного фильма не избежать:

Лично я никогда не крутил опыт, но зачем другие люди это делают? Опыт крутят, чтобы было больше шансов попасть на собеседование. Задача HR’ов и нанимающих менеджеров максимально сузить круг подходящих кандидатов. Главная задача — найти самого скилового кандидата. Хороший опыт дает человеку возможность опробовать себя в разных условиях, пообщаться с разными людьми и получить больше практики на разных задачах, а, соответственно, и больше хард- и софт-скиллов.

Кейс 2: Дмитрий Александрович, Java-разработчик с 20-летним стажем хочет перейти в новую компанию по личным причинам, допустим, ему наскучили задачи. Однако такой количество такого большого опыта совершенно не значит, что компании будут стучаться к нему в профиль каждые 3 минуты, поскольку это тоже может быть ред-флагом для эйчаров.

Зачастую скручивают сильно опытные специалисты у кого за 10-15, а, может, и за 20 лет опыта. Мне кажется, это происходит по большей части из-за проявления эйджизма к старшему поколению. Но здесь есть определенная логика: технологии, которые были актуальны 10 лет назад, сегодня уже никому не нужны и знания человека, которые он получил в своем опыте 10-летней давности, соответственно, тоже. Поэтому стаж становится фактически не релевантным и это то же самое, что не писать в резюме опыт предыдущей профессии.

Какие в этой системе проблемы

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

Потеря доверия

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

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

Несоответствие ожиданиям

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

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

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

Репутационные риски

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

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

Вместо заключения: как сделать реальный опыт

Накрутка и скрутка — не единственные способы вырасти в айти. Вот несколько альтернативных вариантов:

1. Фриланс и open-source. Новички могут брать небольшие проекты на фриланс-платформах или участвовать в open-source проектах, чтобы набраться реального опыта.
2. Стажировки. Многие компании предлагают стажировки для джуниоров, которые помогают получить первый опыт без необходимости «накручивать» стаж.
3. Портфолио. Хорошо оформленное портфолио с реальными или пет-проектами точно усилят ваше резюме, если будут выбирать из нескольких человек с одинаковым опытом.
4. Честная самопрезентация. Если вы опытный специалист, фокусируйтесь на реальных навыках и четко объясняйте, почему предыдущий опыт не будет препятствием.
5. Нетворкинг. Посещайте ярмарки вакансий, конференции и хакатоны — там вас могут заметить и позвать в команду.

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

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

Разработчики редко уходят просто так. Их не испугать дедлайнами или сложными задачами. Но если внутри компании что-то «ломается» — даже самый увлечённый специалист начнёт смотреть в сторону выхода. Иногда проблема в микроменеджменте, иногда — в ощущении, что он застрял в бесконечном рефакторинге и уже не растёт.

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

В России статистика причин увольнений выглядит так.

Но за этими формулировками часто скрываются более сложные факторы, которые не измерить цифрами.

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

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

Причина 1. Некомфортные условия → «Я бы не увольнялся, но работать здесь стало невозможно»

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

Удобный офис — это важный критерий, по которому люди оценивают потенциальных работодателей, например, как в этой истории.

Если у людей возникают жалобы, руководство может рассуждать так: «Они просто не привыкли к таким условиям, у нас всегда так было».

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

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

Одни люди вовремя замечают проблему.

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

Ситуация с картинки — это не шутка, а реальный пример. Один парень из IT-компании, назовём его Димой, рассказывал, как полгода сидел под кондиционером, который дул прямо в шею.

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

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

Итог один: в обоих примерах люди уволились.

Кстати, климатические условия много кого доводят до ручки.

Что на самом деле скрывается за проблемой

Сотрудник уходит не просто из-за дискомфорта — за этим стоит ощущение, что компания не ценит свою команду.

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

• «Если даже такая мелочь, как рабочее место, никого не волнует, то что говорить о моих задачах и вкладе?»
• «Я тут просто ресурс, а не специалист, которого хотят удержать».
• «Другие компании заботятся о сотрудниках, зачем мне оставаться здесь?»

Когда человек постоянно сталкивается с таким отношением, он перестаёт верить, что в этой компании вообще можно чего-то добиться.

Как проверить, всем ли комфортно

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

Ещё один вариант — посмотреть, сколько сотрудников трудятся на удалёнке, хотя раньше работали в офисе. Не потому, что там продуктивнее, а потому что рабочее место вызывает сплошной дискомфорт.

Как создать условия, в которых люди захотят остаться

1. Рассматривать условия труда как ключевой фактор, а не как необязательный бонус. Адекватная мебель, рабочие кондиционеры, хорошее освещение — это оценят и команда, и соискатели.
2. Отслеживать накопленные проблемы: если жалобы на одно и то же звучат не один раз, значит, люди начинают задумываться: «А стоит ли это того?» Улучшить условия обойдётся дешевле, чем искать новых сотрудников.
3. Показывать, что проблемы решаются. Даже если перемены требуют времени, важно, чтобы люди видели, что работа в этом направлении идёт.

Причина 2. Неудобный рабочий софт → «Я пришёл работать, а не бороться с системой»

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

• Софт внедряют без учёта реальных задач команды. В этом случае часто выбирают новые системы, ориентируясь на тренды или удобство с точки зрения управления. Но при этом не учитывают, как этим софтом будет пользоваться команда.
• Людям дают задачу освоить сложный инструмент, но не дают времени на адаптацию. Иногда внедрение проходит в формате «сами разберитесь, как это работает», без качественного обучения и тестирования. В итоге сотрудники больше заняты борьбой с системой, чем своими задачами.
• Автоматизация превращается в дополнительную работу. Вместо того чтобы помогать сотрудникам, новые инструменты добавляют ещё больше действий. Менеджеры заполняют отчёты в нескольких системах, программисты теряют время на избыточные согласования, аналитики тратят часы на экспорт данных, хотя раньше всё можно было сделать за пару минут.

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

Но так бывает не всегда.

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

Чем всё кончилось — неизвестно. Ольга не выдержала и уволилась. И такой случай не единичный.

Что на самом деле скрывается за проблемой

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

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

• Компании внедряют инструменты не для удобства сотрудников, а ради контроля и отчётности.
• Привычная работа усложняется, но это никого не волнует.
• Время сотрудников никто не считает ценным ресурсом.

Как понять, мешает ли рабочий софт команде

1. Провести опрос среди сотрудников. Узнать сколько времени в день уходит на работу с системой? Какие задачи приходится делать вручную, хотя можно было бы автоматизировать? Что именно вызывает наибольшее раздражение?
   
2. Замерить время, которое уходит на решение повторяющихся задач. Выбрать несколько типичных задач (например, оформление заявки, создание отчёта, поиск данных) и попросите сотрудников записать, сколько времени на это уходит. Если выполнение занимает в разы больше, чем должно, система неэффективна.
3. Анализировать логи и статистику в системе. Некоторые инструменты сами показывают метрики:

Если видно, что на простые операции уходит слишком много времени, это повод задуматься о переезде в другую систему или упростить процессы.

Что можно сделать в случае неудобного софта

• Внедрять новые инструменты с учётом реальных рабочих процессов.

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

1. создать удобную базу знаний, в которой любую информацию можно будет найти в пару кликов, например, в Minerva Knowledge;
2. зафиксировать правила работы с разными инструментами;
3. назначить ответственных за ведение, наполнение и оптимизацию системы, а также за обновление и актуализацию статей.

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

Причина 3. Дополнительные обязанности → «Работаю за двоих, но это не про развитие»

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

Люди рассказывают, как выглядит работа в таких ситуациях:

• Зарплата остаётся той же, но задач становится вдвое больше.
• Каждое новое поручение «временное», но его никто не снимает.
• Руководство просит потерпеть в сложный период, который длится уже два года.
• Менеджеры часто говорят: «Ты справляешься лучше всех, поэтому тебе доверили больше», но перераспределения нагрузки не происходит.

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

Выгорание — это не просто усталость, а состояние внутреннего кризиса, когда работа теряет смысл, а энергия уходит в минус. Согласно исследованиям, около 45% работающих россиян находятся в состоянии профессионального выгорания.

На западе дела обстоят не лучше. По крайней мере, в 2018 году команда Blind провела анонимный опрос сотрудников ведущих технологических компаний, таких как Microsoft, Amazon, Google, Uber, LinkedIn и Facebook. Тогда 57% опрошенных сотрудников сообщили о профессиональном выгорании. Наибольший процент был зафиксирован в компаниях Credit Karma (70,73%), Twitch (68,75%) и Nvidia (65,38%).

Учёные доказали, что выгорание — это реальная проблема, которая ухудшает работу мозга.

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

Но чаще всего выгорание — это точка невозврата. Когда отпуск или смена задач уже не помогают и человек решает всё бросить здесь и сейчас.

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

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

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

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

Случаи критического переутомления из-за работы фиксируются уже давно. В Японии даже существует официальный термин — кароси, который означает смерть от переутомления. Проблема во много связана с тем, что у людей болезненные отношения с работой. А некоторые и вовсе не представляют без неё жизни.

Что на самом деле скрывается за увольнением из-за выгорания

Объяснение кажется простым: «устал», «решил сменить сферу». Но как мы уже разобрались, это не просто усталость, а ощущение, что работа потеряла смысл.

Какие мысли могут предшествовать увольнению?

• «Я ничего не успеваю, но это никого не волнует». Когда человек делает больше, чем раньше, но никто не пересматривает его задачи или зарплату, у него формируется ощущение несправедливости.
• «Если я уйду, никто даже не заметит». Выгорание часто сопровождается чувством невидимости. Когда сотрудник долгое время работает на пределе, но получает только новые поручения, а не поддержку, он начинает верить, что его вклад не имеет значения.
• «Я больше не могу этим заниматься». Человек может любить свою профессию, но если условия становятся невыносимыми, работа перестаёт приносить удовольствие. В таком состоянии даже любимое дело превращается в источник стресса.
• «Я уже пробовал что-то изменить, но это не сработало». Те, кто уходит из-за выгорания, обычно не делают этого импульсивно. Они сначала пытаются найти выход: просят перераспределить нагрузку, обсуждают с руководством, берут отпуск.

В конечном итоге человек увольняется из-за ощущения, что его ресурсами распоряжаются бездумно, а вклад не имеет веса.

Как проверить нагрузку команды

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

Есть несколько способов, как можно понять, не перешла ли нагрузка критическую черту:

• Посмотреть, как изменился объём задач за последние полгода. Например, если сотрудник раньше закрывал 10 задач в неделю, а теперь должен выполнять 15, значит, либо он работает быстрее за счёт качества, либо задерживается и трудится в нерабочее время.
• Обратить внимание, кто регулярно остаётся после окончания рабочего дня или отвечает в рабочих чатах по выходным. Иногда это сигнализирует о том, что человек просто не успевает справляться с объёмом работы.
• Обсудить ситуацию на one-to-one. Открытый вопрос вроде «Как ты оцениваешь свою текущую нагрузку?» поможет понять, насколько комфортно сотруднику в его ритме.

Как помочь своей команде

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

Вот что можно сделать:

1. Разделять «развитие» и «нагрузку». Если у человека стало больше задач, должен быть пропорциональный рост зарплаты, статуса или хотя бы компенсация переработок.
2. Пересмотреть отношение к повышению. Больше денег не равно больше задач. Рост — это в первую очередь про скиллы.
3. Не считать эффективных сотрудников «универсальными солдатами». Если человек справляется с разными задачами, это не значит, что он должен делать всё.
4. Прогнозировать расширение штата — исходя из KPI. Заранее открывать позиции, чтобы команде не пришлось долго работать на износ в сложный период.
5. Предложить гибкий график или удалёнку. Многие компании предоставляют сотрудникам возможность выбирать удобное время начала рабочего дня и работать из дома.
6. Ввести чёткие правила рабочего времени. В некоторых странах уже проводятся эксперименты по сокращению рабочей недели без уменьшения зарплаты. Например, в Испании правительство согласилось на трёхлетний эксперимент, в рамках которого около 200 компаний и 3-6 тысяч сотрудников будут работать 32 часа в неделю.
7. Внедрить программы поддержки ментального здоровья. Это могут быть тренинги по управлению стрессом и консультации с психологами.

Причина 4. Плохая адаптация → «Я принял решение уйти ещё в первый месяц»

Новый сотрудник — это как путешественник в чужом городе, только без карты и GPS. Всё сложно, непонятно и, скорее всего, ещё и на «новом» языке. Есть те, кто без труда встраивается в коллектив и становится главным заводилой на кофе-брейке. Но таких мало. Обычно новичок стесняется, пытается справиться сам, потому что не хочет казаться глупым или неопытным.

Сложности с онбордингом в компаниях возникают часто. Вот пара примеров с форумов.

Доказательство того, что правильная адаптация — залог лояльности нового сотрудника. Тут человек проработал только три дня и покинул компанию, потому что не понимал, что он вообще здесь должен делать

Люди в таких случаях редко уходят сразу. Но если адаптация провалилась, они с первых недель начинают искать запасные варианты: 70% новых сотрудников в течение первого месяца решают, подходит ли им эта работа.

Обычно о таких людях могут подумать: «Не вписался в культуру компании». Но на самом деле грамотная адаптация — важный пункт при принятии решения о трудоустройстве.

Ещё один пример из опыта коллег. Антон устроился джуном-бэкендером в стартап, но быстро понял, что разбираться придётся самому. Тимлид был перегружен, коллеги отправляли в код — «он сам всё объяснит», а документация обновлялась очень долго.

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

Что на самом деле скрывается за проблемой

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

Что создаёт такой эффект:

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

Как проверить, что с адаптацией всё в порядке

Для этого важно отслеживать результаты:

• Сколько сотрудников уходит в первые 3-6 месяцев? Высокая текучка на этом этапе может сигнализировать о проблемах с онбордингом и дальнейшей адаптацией.
• Как быстро новички выходят на полноценную продуктивность? Если сотрудник спустя несколько месяцев всё ещё теряется в задачах, значит, процесс адаптации требует доработки.
• Чувствуют ли новые сотрудники поддержку? Полезно проводить короткие встречи через 2-3 месяца после выхода. Узнавать, насколько комфортно человеку работать, всё ли понятно в задачах, есть ли сложности с коммуникацией.

Как улучшить онбординг и адаптацию новичков

Есть несколько способов:

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

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

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

А ещё можно построить обучение, основанное на знаниях компании. Например, создать в Minerva Learn индивидуальные курсы для новичков. В основе будут статьи из базы знаний Minerva Knowledge — так сотрудники быстрее познакомятся с процессами компании, получат пошаговые инструкции и пройдут тестирование. А дальше смогут применять те же самые знания в работе.

Причина 5. Разные рабочие стили → «Мы работаем вместе, но говорим на разных языках»

В команде взаимодействуют два сотрудника. Один вносит таску в Jira, оставляет развёрнутый комментарий и зовёт всех на созвон. Второй читает, пишет «ок» в Slack и уходит работать. Через час первый нервничает: «Почему никто не отвечает?», второй раздражается: «Зачем тратить время, если можно просто написать три строчки?».

Разные поколения выросли в разных условиях и по-разному относятся к работе. Например:

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

Если в компании не учитывают эти различия, сотрудники не находят общий язык и уходят.

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

Но мало кто готов отступиться от своих привычных методов работы. И пока негативных примеров больше.

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

Опытный архитектор предлагал структурировать процессы и предупреждал о рисках, но его воспринимали как «слишком осторожного». Его идеи часто игнорировали. В итоге он понял, что не вписывается в команду, и ушёл сам.

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

Что на самом деле скрывается за проблемой

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

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

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

Как проверить, есть ли в команде проблемы с коммуникацией

Чтобы определить, действительно ли разница в подходах мешает работе, а не просто отражает «особенности поколений», можно:

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

Как создать условия, в которых комфортно работать разным поколениям

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

Что можно сделать:

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

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

А у вас были похожие ситуации? Расскажите, из-за чего вы или ваши коллеги уходили с работы.

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

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

Container + Presentational Components

На первом месте работы ещё во время разработки на Vue мы с подачи нашего тимлида решили ввести этот паттерн. Глобально у нас были так называемые «умные» и «тупые» компоненты (или как я тактично называл их на демо — визуальные). Как вы наверняка догадались, роль Container у нас исполняли «умные» компоненты, а роль Presentational — «тупые». В чём, собственно, суть этого паттерна? Слышали выражение «разделяй и властвуй»? Паттерн Container & Presentational Components (контейнерные и презентационные компоненты) ровно об этом: он разделяет логику (данные и взаимодействие с ними) и отображение (UI) на разные компоненты.

Presentational Components отвечают только за то, как что-то выглядит. Они получают данные через props и отображают их, больше ничего. Это, как правило, чистые функциональные компоненты, часто без собственного состояния (ну разве что мелкий UI-стейт типа «раскрыт ли dropdown»). Им всё равно, каким образом взять список пользователей — они просто ожидают условный props.users и отображают его в соответствии с дизайном.

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

Зачем же нужен такой подход? Во-первых, лучшая разделённость ответственности (UI отдельно, данные отдельно) упрощает понимание и поддержку приложения. Во-вторых, улучшается переиспользование: один визуальный компонент вероятно использовать с разными источниками данных через разные контейнеры. Дизайнеры могут менять внешний вид компонента в одном месте, не затрагивая бизнес-логику. И тестировать тоже проще: можно отдельно протестировать логику контейнера (без верстки) и отдельно визуальный компонент (с моком данных).

В этом примере UserList не содержит никакого стейта, не подписан на store или контекст, лишь отображает список. Ему всё равно, как и где получают пользователей — просто принимает проп users и выводит его. Контейнер UserListContainer же занимается работой с данными: делает fetch, сохраняет результат в useState, и потом рендерит UserList, прокидывая в него данные. Благодаря такому делению компонент UserList легко переиспользовать — хоть для локальных данных, хоть для данных из Redux или context — достаточно написать другой контейнер.

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

Стоит отметить, что с появлением React-хуков граница между логикой и отображением несколько размылась. Теперь можно выносить логику в кастомные хуки и вызывать их прямо внутри компонента, вместо того чтобы создавать отдельный контейнер-класс, как это делали до 2018 года. Тем не менее, принцип «держи логику отдельно от представления» по-прежнему полезен. Даже с хуками можно структурировать код, разделяя функциональность: написать хук useUsersData() для получения пользователей и применять его в разных компонентах (вместо дублирования запроса).

Плюсы: чёткое разделение обязанностей, возможность переиспользовать и заменять части независимо (UI-компонент можно переиспользовать с разными данными), облегчение тестирования.

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

Higher-Order Component (HOC)

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

Зачем это может понадобиться? Представим, у нас есть несколько разных компонентов, и всем им нужно что-то общее: например, обработка ошибок или подписка на внешние данные. Можно было бы скопировать этот код в каждый из компонентов, но куда элегантнее написать HOC один раз и применить ко всем. Классический пример — Redux-функция connect: вы пишете export default connect(mapState)(MyComponent), и ваш компонент получает пропсы из глобального стейта.

connect — как раз и есть HOC, который инъектирует данные из Redux в компонент, не требуя от вас переписывать все под Redux вручную.

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

Здесь withCounter — HOC, он возвращает новый функциональный компонент WithCounter, который внутри себя использует useState и передаёт состояние и функцию увеличения внутрь WrappedComponent. В итоге EnhancedButton — это улучшенная версия ClickButton, которая умеет считать клики, даже если исходный ClickButton об этом не знал.

Плюсы: один HOC может добавить функциональность множеству компонентов сразу — не надо копировать код везде. Логику обновляется в одном месте (внутри HOC) — и все обёрнутые компоненты получают изменения. HOC можно комбинировать: например, обернуть компонент сначала в HOC, добавляющий тему оформления, потом в HOC, добавляющий логирование, и т.д. В итоге получим компонент, обладающий сразу несколькими дополнительными возможностями.

Минусы: за такую магию мы платим усложнением структуры. Когда компонентов обёрток становится много, React-дерево раздувается, и возникает эффект «матрёшки». В DevTools вы могли видеть что-то вроде: Connect(withRouter(WithTheme(MyComponent))) — разобраться, что к чему, становится сложнее. Дебаг таких цепочек — тоже удовольствие то ещё, приходится пробираться через несколько уровней абстракций. Кроме того, HOC часто прокидывают пропсы во внутренний компонент, что чревато конфликтами имён (нужно следить, чтобы, например, prop.title от HOC не перезаписал пропс title, который вы передали самому компоненту). Ещё нюанс — HOC усложняют типизацию в TypeScript (надо правильно описывать generic для пропсов), но это выходит за рамки нашей темы.

React-разработчики со временем несколько охладели к HOC. В официальной документации прямо сказано: «компоненты высшего порядка не так часто используются в современном React-коде». Отчасти их вытеснили хуки, тем не менее, HOC никуда не делись: их продолжают применять сторонние библиотеки — тот же Redux, Relay и другие. Да, и в старом проекте вы почти наверняка встретите хотя бы пару HOC. Поэтому понимать этот паттерн стоит. Просто имейте в виду современные альтернативы и используйте HOC там, где это действительно необходимо.

Паттерн Render Props

Следующий паттерн я бы назвал «перевёрнутый HOC». Render Props — это подход, когда компонент сам не рендерит что-то внутри себя, а принимает функцию (часто через проп render или просто используя детей как функцию) и вызывает её, чтобы получить содержимое. То есть мы передаём компоненту инструкцию, что именно отрендерить, а он сам обеспечивает, когда и с какими данными вызвать эту инструкцию.

Представьте компонент <MouseTracker> для отслеживания положения курсора. Классически он может хранить x, y в своём состоянии и отрисовывать, скажем, <p>Mouse at (x, y)</p>. Но что, если мы хотим переиспользовать эту логику уже с другим UI? Паттерн Render Props предлагает сделать компонент <Mouse>, который не определяет жёстко JSX внутри себя, а вызывает функцию, переданную через проп (или children функцию), передавая ей координаты. Эта функция сама решит, что рисовать. Таким образом, <Mouse> инкапсулирует логику (слежение за мышкой), а отображение делегирует наружу.

Пример: реализуем компонент-утилиту <FilteredList items={...} filter={...}>, который отображает список на основе передаваемого фильтра. Вместо того чтобы жёстко прописывать разметку элемента списка, сделаем его с render проп через children:

Здесь <FilteredList> знает, как отфильтровать массив (items.filter(filter)), но не знает, как отрисовать каждый элемент. Вместо этого он вызывает функцию, которую мы передали в качестве дочернего элемента (children), для каждого элемента списка. Эта функция возвращает <li> для каждого item. В результате логика фильтрации инкапсулируется внутри FilteredList, а конкретное отображение списка задаётся извне. Мы могли бы так же использовать этот компонент для массива объектов, отрисовывая, например, товары — достаточно передать другую children-функцию.

Паттерн Render Props здорово повышает гибкость компонентов. Мы можем переиспользовать <FilteredList> для списков чего угодно — чисел, пользователей, товаров — просто изменяя функцию отображения. Другой пример: компонент <Mouse> может предоставлять координаты курсора, а внешний код решит, просто вывести текст, нарисовать по координатам картинку или вызвать какую-то совершенно другую логику — не нужно делать несколько вариаций компонента для каждого кейса.

Плюсы: Render Props позволяет компоненту-провайдеру (в примере выше FilteredList является провайдером данных) быть максимально универсальным, а конкретную разметку делегировать наружу. Многие библиотеки воспользовались этим паттерном: например, React Router (до версии 6) позволял вместо компонента страницы передать проп render в <Route> — функцию, которая отрисует JSX на основе параметров маршрута. Formik предлагал компонент <Formik> с функцией-ребёнком для рендеринга формы. Downshift (библиотека для автокомплитов) — тоже классический пример паттерна render props.

Минусы: главное неудобство — излишний шум в JSX. Код с вложенными функциями бывает тяжело читать. В нашем простом примере всё компактно, но представьте, если у вас будет несколько уровней таких компонентов: <Foo>{foo => ( <Bar>{bar => ( ... )}</Bar> )}</Foo> — легко получить «оберточный ад» из стрелочных функций прямо в разметке. Это значительно затруднит отладку такого кода при возникновении каких-либо проблем. К тому же, каждый раз при рендере создаётся новая функция, что может негативно сказаться на производительности, если таких компонентов много (React конечно оптимизирует функции в пропсах через механизм сравнения, но всё же). Также возникает неявная связь: внешний код должен знать, какие аргументы ожидает функция. TypeScript конечно помогает, но при чтении кода не сразу видно, что children, например, это не просто элемент, а функция.

Как и HOC, паттерн Render Props сейчас используется реже. Многие задачи, решаемые через него, теперь элегантнее с точки зрения кода решаются хуками, в официальной документации это также отмечено. Но всё же понимать его нужно, потому что легаси-код и некоторые библиотеки всё ещё работают на нём. Если видите, что компонент принимает функцию в виде пропса (чаще всего называется render или передаваётся через детей), знайте — это он, Render Props.

В следующей части расскажу про хуки и кастомные хуки, а также про Compound Components и Серверные компоненты и Suspense.

Разбираемся, какие основные задачи закрывает проджект и нужно ли ему знать программирование и уметь кодить. В этом нам поможет Артем Харченков — автор Telegram-канала «IT Инсайты», где он делится мыслями об IT и тимлидстве. Артем руководит командой 40+ человек более 4 лет, управляет департаментами разработки, тестирования, аналитики и DevOps, является спикером TeamLead Conf и участником подкастов и ведущим вебинаров. Был инженером внедрения и Java-программистом.

Какие главные задачи у PM в айти

Менеджер проекта (или Project Manager, PM) — это функциональный руководитель команды, которая работает над определенным проектом. PM отвечает за то, кто и что в команде делает, чтобы достичь поставленных целей.

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

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

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

Нужно ли в принципе проджекту учить программирование или он его должен знать изначально

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

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

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

Какие базовые штуки из программирования нужно знать PM-у, чтобы не теряться в разговорах с кодерами

Начинать стоит не с изучения самого языка программирования, а с общих определений и с понимания того, какой из инструментов зачем используется. Например, чтобы на встрече программистов обсуждение для проджекта не превращалось в «белый шум» нужно знать, что такое, например, «релиз», «деплой», «ветка в гите», «рефакторинг», «кубер» и так далее. Не обязательно самому практиковаться в технологиях, но требуется понимать, для чего они используются. Именно понимание того, какую задачу какой инструмент решает, наиболее важно для PM’а, а вот умение писать код или отличать абстрактный класс от интерфейса не пригодится практически никогда.

При правильном распределении обязанностей на проекте PM’у вообще не требуется читать код: ни настоящий, ни псевдо. Его задача — организация процесса, а не техническая реализация.

Как знание кода помогает адекватно оценивать дедлайны

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

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

Про технические штуки: что нужно и не нужно знать

Стоит ли вникать в Git

Git — важный инструмент для командной работы программистов, он уже стал стандартом в современных проектах. Как и в других технических инструментах, PM не обязан знать команды push, fetch или merge и уметь ими пользоваться, но должен иметь общее понимание базовых вещей (например, «ветка», «репозиторий», «merge request», «commit»). Без этих знаний PM не сможет эффективно управлять процессом доставки функций и выпуска релизов, выявлять их узкие места и принимать взвешенные решения по устранению проблем.

Нужно ли знать, чем монолит отличается от микросервисов

Понимание этой разницы — сейчас базовое требование в IT. Я рекомендую изучить плюсы и минусы обоих подходов к построению систем. Хорошо, что современные ИИ-помощники позволяют разобраться в этом за пару часов: они опишут всё подробно «на пальцах» и с примерами.

Должен ли PM знать подходы к разработке, например, CI/CD или TDD

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

Как понимание тестов (типа юнит-тестов) спасает при проверке качества

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

Базы данных — это важно для PM-ов или только для разработчиков

Важность понимания принципов работы баз данных для PM зависит от предметной области проекта. Например, при разработке стандартной CRM-системы база данных — лишь один из модулей продукта. В этом случае PM должен понимать только то, что это за база, какие данные в ней хранятся и обрабатываются.

Если же проект связан с созданием ПО для работы с базами данных (например, клиента для БД или системы оптимизации SQL-запросов), потребуется гораздо более глубокое знание их принципов работы.

Веб, мобилки, данные — отличается ли набор знаний для PM-а в этих стеках

В общем случае — нет. Различия между этими типами проектов в основном технические, но во всех случаях над достижением цели работает команда с распределёнными ролями. Навыки PM в первую очередь — это способность её мотивировать, выделять приоритеты, проводить эффективные встречи и обеспечивать выполнение задач в срок. Технические инструменты PM (например, таск-трекеры, диаграммы Ганта или покер-планирование) могут различаться, но они не связаны напрямую с инструментами разработки, аналитики или тестирования.

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

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

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

Взаимодействие

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

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

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

Совет 1: Ставьте себя на место других людей

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

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

Тут сотрудники могут выбрать два возможных пути:

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

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

В итоге дедлайн подходит, а дашборда нет. Аналитик злится на менеджера из-за его постоянных напоминаний, а менеджер недовлен, потому что аналитик не принёс дашборд вовремя и не сообщил о проблемах в начале. Дедлайн сдвигается.

Второй аналитик, заметив проблемы, сразу назначает звонок с менеджером. Он объясняет, какие сложности возникли, задаёт проясняющие вопросы.

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

Давайте разберёмся, что тут произошло.

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

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

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

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

Совет 2: Учитесь возражать и ставить под сомнение чужие идеи

Бэклог аналитиков всегда заполнен задачами, а спринты расписаны на месяцы вперёд. Но почему-то всегда находится ещё одна «сверхважная» задача, которую необходимо взять в работу. Здесь аналитики обычно делятся на две группы:

1. Сразу говорят «нет» любой новой задаче, если она не была запланирована. В итоге такие задачи либо уходят в глубокий бэклог и забываются, либо выполняются для галочки.
2. Напротив, всегда готовы взять любую задачу, откуда бы она ни пришла. Такие люди часто перерабатывают, быстро выгорают и со временем превращаются в аналитиков из первой группы. Потому что, соглашаясь на всё, они вынуждены делать много задач в сжатые сроки.

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

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

Учитесь погружаться в суть задачи

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

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

Универсального списка вопросов нет — каждый аналитик формирует его по-своему. Однако всегда нужно знать ответ на один главный вопрос: «Что изменится после выполнения этой задачи?».

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

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

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

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

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

Пример, как применить совет на практике. Представьте, что менеджер просит вас провести A/B-тест для проверки новой функции. Неправильным подходом будет автоматически отвергать эту инициативу или бездумно соглашаться. Вот почему:

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

Оптимальный подход будет звучать так:

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

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

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

В процессе аналитик может заметить интересные зависимости, помочь сделать инициативу лучше, придумать планы или предложить альтернативное решение.

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

Совет 3: Регулярно собирайте обратную связь

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

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

Когда я работал senior аналитиком, мой руководитель редко проводил со мной встречи. Я самостоятельно приоритизировал задачи и взаимодействовал с менеджерами, а ему лишь сообщал о проделанной работе. Он обычно отвечал фразами вроде: «Всё в порядке, двигаешься в верном направлении», не углубляясь в процессы. Перед ревью я ожидал отличных результатов — выше среднего, поскольку все менеджеры были довольны моей работой, задачи были выполнены, и мы даже превзошли поставленные цели. Однако я был неприятно удивлён, когда узнал, что моя оценка оказалась ниже среднего. Руководитель объяснил это тем, что, изучив мои результаты, он посчитал их недостаточно сложными и впечатляющими с точки зрения аналитики. Я не согласился с такой оценкой: в течение полугода он был доволен моей работой и не предлагал никаких корректировок, а на ревью высказал совершенно иное мнение. В итоге я принял решение продолжить свою карьеру в другой команде. Теперь, руководя своей командой аналитиков, я стараюсь избегать подобных ситуаций. Регулярно провожу индивидуальные встречи со всеми ребятами, вникаю в суть их задач и даю обратную связь. Это позволяет сотрудникам заранее улучшить результаты и корректировать фокус, если мы вместе замечаем, что что-то идёт не по плану. Благодаря такой стратегии, за последние полгода половина моей команды получила повышение. Я убеждён, что гораздо эффективнее давать обратную связь регулярно, а не ждать ревью. Таким образом, компания получает более лояльных и мотивированных сотрудников.

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

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

Говорите с руководителем

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

2. Совместно составьте план достижения этих целей, определите сроки и ключевые задачи. Уже на этом этапе можно узнать, насколько реалистично достичь поставленных целей в установленные сроки.

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

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

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

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

Матрица компетенций аналитиков Авито на Github

Собирайте обратную связь от коллег

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

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

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

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

Ещё рекомендуем записывать все задачи, которые вы выполняете в течение текущего периода ревью. Часто мы не замечаем, сколько всего делаем на работе, из-за этого может казаться, что мы стоим на месте, пока все вокруг активно развиваются.

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

Самочувствие

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

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

На рынке ходит стереотип, что у консультантов в McKinsey нарушен баланс между работой и отдыхом. Скажу, что это далеко не всегда так, и всё зависит от проекта, но не буду скрывать, что тяжёлые проекты случаются. На одном из таких работал я. Сроки на нём были настолько сжаты, что мы работали без выходных и спали по 3–5 часов. Последний месяц превратился в день сурка: работа с утра до ночи, короткий сон и всё заново. В итоге переутомление дало о себе знать — в один из вечеров мне стало плохо, и я выпал из работы на неделю. Это сильно ударило по здоровью и заставило пересмотреть приоритеты. Теперь я уделяю больше внимания work-life балансу и строю работу так, чтобы сохранять комфорт и энергию.

Совет 1: Создавайте комфортные условия

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

Как улучшить ситуацию:

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

Старайтесь управлять нагрузкой. Реально оценивайте время, которое требуется для выполнения задачи, и корректируйте сроки в процессе работы. Если не укладываетесь, сообщайте об этом коллегам вместо того, чтобы работать в нерабочее время. Для соблюдения границ ставьте блокеры — встречи с друзьями или занятия после работы. Это поможет избегать переработок.

Благодаря управлению временем ваша продуктивность будет оставаться на прежнем уровне.

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

1. Сообщите руководителю о своём состоянии и попробуйте изменить текущие условия, как описано выше.
2. Возьмите отпуск, чтобы перезагрузиться. Люди часто забывают, что отдых — это необходимая часть работы.
3. Рассмотрите варианты ротации или смены работы. Если изменить что-то не представляется возможным или команда вам не подходит — стоит искать новое место. Процесс поиска можно совмещать с текущей работой.

Не бойтесь переходов — новая работа принесёт новые знания и ценный опыт.

Совет 2: Меняйте своё отношение к работе

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

Помните о принципе: «Ты ничего не знаешь, другие ничего не знают»

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

1. Ты ничего не знаешь.
2. Другие тоже ничего не знают.

Что это значит:

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

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

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

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

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

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

Со временем становится понятно, что никто не застрахован от ошибок, а способность критически мыслить и учиться помогает перестать ощущать себя «самозванцем» и расти профессионально.

Совет 3: Не бойтесь допускать ошибки

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

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

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

Разбирайте причины ошибок. Честно определяйте, почему так произошло. Может быть, дело в том, что вы поверхностно поняли задачу или не задали уточняющие вопросы на старте. Установив причину, вы сможете лучше понять свои слабые стороны и сосредоточиться на их развитии. Постепенная работа над этими аспектами поможет вам стать более профессиональным и уверенным аналитиком.

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

Решение задач

Одна из основных проблем аналитиков — недостаток внимания к тому, как организована их работа. Теоретически они знают, как структурировать решение задачи, но на практике часто начинают действовать хаотично. Еще одна распространенная сложность — неуверенность в своих силах, которая возникает из-за ощущения, что в других командах решают более амбициозные и масштабные задачи, словно строят «космолет», в то время как собственные проекты кажутся менее значимыми и простыми.

Нашей команде поручили выделить среди новых клиентов тех, кто приносит наиболее высокий доход (LTV), чтобы назначить им персонального менеджера. Аналитик, который взялся за задачу, предложил использовать ML-моделирование для оценки клиентов, но неуверенность в собственных силах из-за недостатка опыта в подобных задачах замедлила прогресс. Ему казалось, что кто-то из коллег справился бы с задачей лучше, и это мешало ему сосредоточиться. В итоге за первые две недели у нас практически не было результатов, так как аналитик сразу бросился в расчёты без продуманного плана. Чтобы исправить ситуацию, мы провели встречу, разложили задачу на ключевые шаги и определили, что нужно сделать в каждом из них. Прописали сроки и риски для каждого этапа. Это позволило двигаться постепенно, шаг за шагом улучшая модель. В итоге мы смогли создать несколько версий модели, которые успешно прошли тестирование. Хотя наш скоринг имел свои недостатки, на общем митапе команда восприняла его с большим энтузиазмом — казалось, что мы действительно собрали тот самый «космолёт».

Совет 1: Декомпозируйте задачи — сложные решения состоят из более простых

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

Делим задачи на два ключевых типа:

1. Исследование. Это задачи, где результатом должно быть выявление взаимосвязей, сегментов или расчёт ещё неизвестной метрики. На старте может даже не быть гипотез.
2. Разработка. Здесь уже есть представление о конечном результате или функционале модели/инструмента, и задача состоит в том, чтобы определить четкий путь к цели.

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

Исследование

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

В подобных ситуациях полезно использовать принцип MECE (Mutually Exclusive/взаимно исключающие и Collectively Exhaustive/совместно исчерпывающие). На него делают особый упор в рамках собеседований в компаниях большой тройки (McKinsey, Bain, BCG). Этот принцип структурирует информацию, разделяя её на взаимно исключающие и полностью исчерпывающие части, что позволяет охватить все аспекты проблемы. Чтобы было понятнее рассмотрим на примере.

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

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

Я применял метод MECE на своем прошлом месте работы, когда нужно было разобраться с проблемами в приложении для курьеров Яндекс.Еды. Он помог выстроить работу так, чтобы ничего не упустить и не запутаться. Мы начали с классификации всех проблем: критические — те, что блокируют работу, значительные — создающие неудобства, и незначительные — мелочи, которые всё равно требуют внимания. Это позволило понять, что действительно важно, а что может подождать. Затем углубились в критические проблемы, разделив их на группы: интерфейс, функциональность, производительность и интеграции. Разработчикам стало проще расставить приоритеты и сосредоточиться на самом важном. Когда оказалось, что корень многих сложностей — производительность, мы снова применили MECE: разделили всё на серверные, клиентские, сетевые и платформенные проблемы. Глубже копнули в серверную часть — там выяснилось, что основные узкие места связаны с базой данных, балансировкой нагрузки и настройкой серверов. В результате разработчики чётко знали, что делать, задачи решались быстро, а работа всей команды стала продуктивнее. MECE помог нам превратить хаос в структуру, а проблемы — в задачи, которые легко решать.

Общая рекомендация — попробовать выделять время для декомпозиции повседневных задач по принципу MECE. Со временем взгляд на задачи станет более структурированным, и процесс деления задач на логические части начнёт происходить автоматически. Этот принцип полезен не только для решения задач, но и для развития системного образа мышления.

Разработка

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

Например, для построения модели поиска высокопотенциальных клиентов мы сначала остановились на базовом подходе по созданию ML-модели:

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

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

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

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

Совет 2: Научитесь планировать задачи и управлять ожиданиями

Одна из частых проблем при работе с аналитиком — это несоблюдение сроков. Рассчитываем одно время, но реальный результат почти всегда задерживается. Мы решили попробовать нащупать какое-то правило, по которому можно было бы прикидывать, сколько времени нужно на самом деле. После нескольких экспертных замеров, получилось, что реалистичный срок – это негативный сценарий по оценке аналитика (мы столкнемся с багами, заказчики запросят доработки, параллельно прилетит n задач), умноженный на два.

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

У нас был случай, когда аналитик пообещал построить модель прогноза спроса за три дня. Заказчик из коммерческого отдела настаивал на сжатых сроках, и аналитик, чтобы показать свою эффективность, согласился, не учтя объём работы и возможные сложности. Когда началась работа, оказалось, что данные из нового региона неполные, их качество низкое, а доступ к некоторым источникам требует согласований. Параллельно всплыли уточнения по параметрам модели, которые также затянули процесс. Уже на второй день стало ясно, что уложиться в сроки невозможно. Аналитику пришлось работать ночами, но модель всё равно получилась сырой. Её доработка заняла ещё несколько дней, а сам аналитик был вымотан. Этот случай стал уроком: лучше изначально дать реалистичную оценку сроков и честно объяснить заказчику все риски. Если возникают сомнения, стоит запросить время на уточнение или обсудить проблемы сразу, как они появляются. Прозрачность помогает избежать выгорания и приносит больше пользы заказчику, чем героические попытки сделать невозможное.

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

Также часто складывается ситуация, что решение необходимо сильно раньше, чем его может предоставить аналитик. В таких случаях важно не соглашаться на нереалистичные сроки, которые могут привести к переработкам. Например, при разработке модели для оценки потенциала клиентов, нас попросили создать скоринг за месяц. Мы объяснили, что ML-решение за это время невозможно, и предложили более простую сегментацию по бизнес-правилам. Это позволило уложиться в срок и выиграть дополнительное время для полноценного решения.

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

Совет 3: Помните, что обертка аналитики не менее важна того, что внутри

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

Весь процесс работы аналитика в целом сводится к двум составляющим:

1. Провести расчёты.
2. Убедительно и понятно презентовать результаты.

Расчеты

Когда вы пишите скрипт, держите в голове, что его может захотеть посмотреть другой аналитик или же вы сами вернетесь к нему в будущем. Например, если вы создаете SQL-скрипт для витрины данных, представьте, что коллега может попросить его для анализа логики расчета некоторых столбцов. Если в скрипте нет форматирования, длинные операторы записаны в одну строку, пробелы и табуляции расставлены несистемно, а команды вроде SELECT указаны то в верхнем, то в нижнем регистре, в таком коде будет сложно разобраться. Четкая структура и комментарии помогут другому аналитику легко понять логику и снизят вероятность ошибок.

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

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

Презентация

Собирайте материалы для рассказа

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

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

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

Учитывайте специфику аудитории, для которой вы делаете рассказ

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

1. Ключевые заказчики имеют много задач, и для них ваша модель — всего лишь часть большого проекта. Им важен эффект и область применения модели, а не технические детали. Скорее всего, у них будет немного времени, поэтому подготовьте лаконичный документ с ключевыми моментами и выводами. Цель — кратко и ясно объяснить пользу модели, избегая перегрузки информацией.
2. Другие аналитики интересуются технической частью — как и почему вы пришли к такому решению. Хотя они знакомы с аналитическими инструментами, просто показывать им скрипты недостаточно. Бывает ситуация, когда слушаешь презентацию, и, хотя тема интересна, разобраться сложно. Поэтому стоит упростить материал, добавить визуализации и примеры.
3. Друзья не нуждаются в технических деталях, и, разумеется, нельзя рассказывать им информацию под NDA. Здесь лучше всего делиться общими впечатлениями или забавными моментами. Важно учитывать интересы собеседников, чтобы не утомить их рассказом о работе.

Однажды мы представляли менеджерам по продажам идею внедрения RFM-сегментации клиентской базы. Мы подробно объяснили, как рассчитываются метрики, зачем нужны перцентили и как мы проверяли результаты через корреляционный анализ. Нам казалось, что всё изложено ясно. Но для менеджеров это оказалось непонятным и сложным. Они не увидели, как эти данные связаны с их задачами. Мы взяли паузу и переработали презентацию. Вместо аналитических терминов использовали простой язык: показали, как сегментация помогает повышать конверсии, экономить время и точнее работать с клиентами. Вместо сложных расчётов — понятные категории: активные клиенты, спящие, премиальные. В новой версии мы сосредоточились на том, какую пользу это принесёт именно их работе. Результат не заставил себя ждать. Менеджеры поняли суть, стали задавать вопросы и обсуждать внедрение. Этот случай научил нас: успешная презентация — это не демонстрация вашей экспертизы, а способность говорить на языке аудитории. Поймите, что важно для ваших слушателей, отберите только ключевые моменты и покажите, как это улучшит их результаты. Тогда ваше сообщение будет услышано.

P.S. Больше о RFM-сегментации, её пользе и тонкостях расчётов вы можете найти в этой статье Сергея.

Совет 4: Не ищите сложные решения

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

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

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

В одном из проектов в McKinsey мы разрабатывали персонализированные предложения для ритейл-компании, чтобы увеличить средний чек клиентов. Сначала мы использовали простой метод — RFM-сегментацию, который быстро внедрили. Затем у нас было несколько месяцев на разработку ML-модели. Однако в первом тесте RFM-сегментация показала лучшие результаты, и только после нескольких доработок ML-модель смогла её обогнать.

В Яндекс.Маркете мы решали задачу кластеризации поисковых запросов. Команда предложила использовать нейронные сети, чтобы анализировать семантику запросов и находить между ними связи. Решение выглядело перспективным, но на практике оказалось сложным, требовало постоянных доработок и всё равно не давало ожидаемых результатов. Тогда я предложил упростить подход: вместо анализа семантики просто посмотреть на совпадения URL-адресов в выдаче Google. Если у двух запросов было хотя бы три общих URL из десяти, мы объединяли их в один кластер. На реализацию ушло всего несколько часов, а результаты превзошли все предыдущие попытки. Метод оказался не только точным, но и легко реализуемым. Этот случай напомнил, что сложные решения не всегда оправданы. Простое, но продуманное решение может быть быстрее, эффективнее и понятнее. Иногда стоит остановиться, взглянуть на задачу по-новому и сначала попробовать наиболее очевидный путь.

Совет 5: Помните, что отсутствие результата — тоже результат

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

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

1. Привязка к числам. Если прямого влияния на прибыль нет, результаты можно выразить через экономию времени (FTE), человекочасы, потенциальные потери или выгоды. Даже в сложных проектах стоит искать количественные показатели, которые помогут обосновать ценность работы.
2. Признание ценности опыта. Важно фиксировать, какие знания и навыки были получены в процессе, какие направления стоит развивать, а какие оказались неэффективными. Даже если эксперимент не дал ожидаемого результата, он помогает компании двигаться вперёд. Без таких попыток прогресс остановится.

Развитие

Когда задач много, а свободное время хочется потратить на что-то, не связанное с аналитикой, возникает вопрос: как развивать новые навыки и не терять уже имеющиеся?

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

Совет 1: Посещайте внутренние и внешние аналитические встречи

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

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

Совет 2: Ищите ответы в процессе работы

Сегодня навык поиска информации стал важнее, чем умение помнить всё наизусть. Например, вместо того чтобы держать в голове различия между precision и recall, достаточно найти это в интернете. Умение быстро искать ответы через Google, Яндекс или AI-ботов помогает не только решать конкретные задачи, но и изучать новые темы.

Когда использовать поиск для развития:

1. В процессе решения задач. Если подход известен, но никогда не применялся на практике, или задача вовсе кажется новой, имеет смысл выделить время для изучения темы. Такой подход позволяет не только познакомиться с новым методом, но и сразу закрепить его через практику.
2. Во время встреч и мероприятий. На рабочих синках, демо или конференциях часто звучат незнакомые решения. Если они кажутся полезными или актуальными, стоит погрузиться в тему, чтобы понять основы и расширить кругозор.
3. Через общение с коллегами. Работа с опытными специалистами открывает возможность учиться у них. Если тема кажется интересной, можно договориться о встрече, чтобы коллега объяснил детали и ответил на вопросы. Это не только помогает лучше понять материал, но и укрепляет профессиональные отношения.

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

Вся статья кратко:

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

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

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

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

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

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

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

Если вам интересно строить карьеру аналитика и развиваться вместе с сильной командой, приходите работать в Авито! Мы всегда ищем талантливых специалистов. Подробности можно найти на нашем карьерном сайте.

Какие главные выводы вы сделали из собственного опыта работы аналитиком? Поделитесь своими наблюдениями в комментариях — будет интересно обсудить!

Вместе с Акимом Саввиным, тимлидом команды бэкенда в ВСК, ментором Эйч Навыки и автором телеграм-канала о разработке и менеджменте, разбираемся, как программисту вырасти в руководителя и не пожалеть, какие навыки нужно развивать, чему учиться и как строить план перехода на новую должность.

Шаг 1. Определяем цели и мотивацию

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

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

• Готов ли я к кардинальной смене профиля деятельности психологически и физически?
• Нацелен ли на развитие команды и компании в целом?
• Готов ли серьезно работать над собой, развивать новые навыки, менять подход к решению проблем?

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

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

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

Какие качества развивать для перехода в менеджмент:

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

Шаг 2. Развиваем навыки

Как правило, на позицию управленца претендуют сотрудники, которые уже освоили hard skills и хотят двигаться дальше. В сфере ИТ-менеджмента база — знание процессов разработки и понимание общей архитектуры.

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

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

Частая ошибка — думать, что хороший менеджер должен быть лучшим в техническом плане. На самом деле, soft skills для него важнее, чем hard skills. Если в разработке это вспомогательный навык, то в управлении — ключевой. Нужно развивать эмоциональный интеллект, бизнес-мышление и навыки управления людьми. Без этого даже самый опытный разработчик вряд ли станет эффективным руководителем.

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

Рассмотрим ключевые софты, которые стоит развить.

Коммуникация

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

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

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

Главное в коммуникации – понимать, чего хочет собеседник. Если заказчику важен результат, он не будет вникать в технические детали, его нужно просто успокоить и дать четкое понимание сроков. Если в команде кто-то выгорел, возможно, стоит пересмотреть его задачи или дать передышку. Конфликты лучше решать без эмоций: обозначить проблему, найти ее источник и предложить компромисс.

Хорошие переговорные навыки позволяют менеджеру защитить команду от неоправданных требований, избежать штрафов и подписания невыгодных соглашений. А главное — они сглаживают традиционные «углы», например, перенос сроков.

Как преодолеть барьеры в общении?

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

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

Ответственность

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

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

Мы используем гибкие методологии, но главный принцип – давать людям то, что им нужно. Заказчику – уверенность в результате. Ему не интересны технические детали вроде новых микросервисов и покрытых тестами API, ему важно понимать, какую бизнес-ценность это несет. Если изменение неочевидно, важно объяснить его эффект: например, шаблон микросервиса ускорит будущие разработки, а e2e-тесты снизят риски багов.

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

Пунктуальность

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

Один из полезных инструментов тайм-менеджмента — матрица Эйзенхауэра. Даже если не использовать ее постоянно, стоит понимать базовые принципы приоритизации задач. Также важно завести удобный личный календарь — это ваш основной рабочий инструмент.

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

Проактивность

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

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

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

Другие навыки и умения

Помимо перечисленного, менеджеру нужно прокачать следующие способности:

• Оценивать задачи по уровню сложности. Необходимо понимать, сколько времени займет выполнение, справится ли с ней один специалист или ему потребуется помощь. Понимаете специфики поможет узнать, не тянет ли исполнитель время и не запрашивает ли слишком высокую цену за свою работу.
• Просчитывать риски. Рабочий процесс редко идет как по маслу. Специалисты могут заболеть, облениться, уволиться. Закладывайте сроки с учетом задержек в исполнении, особенно если задачи нетиповые.
• Уметь контролировать эмоции. Менеджер, который выходит из себя по поводу и без не способен эффективно управлять. Научиться спокойствию непросто, но это ценный навык, который идет на пользу всему рабочему процессу.
• Делегировать. Фигура высшего пилотажа — умение распределять задачи таким образом, чтобы все сотрудники развивали свой потенциал и выдавали максимальный результат. Самому руководителю стоит сосредоточиться на стратегическом развитии.

Шаг 3. Обучаемся менеджменту

Должности тимлида придется учиться с нуля. В управлении важны сроки и результат, а не стремление к совершенству. Руководитель отвечает не только за свои, но и за чужие ошибки. Давить на подчиненных авторитетом, которого еще нет, не получится. В лучшем случае давление станет взаимным со стороны команды. Так можно «доруководиться» до саботажа.

Параллельно с развитием софтов, начните читать тематическую литературу. Если не хватает времени, слушайте аудиоверсии, но базовый пакет знаний получить необходимо.

Это примерный список для ориентира:

• «Эффективный руководитель» — Питер Друкер. Книга рассказывает о том, как и чем должен заниматься руководитель, какие правила соблюдать, чтобы добиваться результата в любом деле.
• «45 татуировок менеджера» — Максим Батырев. В формате жизненных историй и конфликтных ситуаций рассказывает о том, как сформировать характер и личность руководителя.
• «Привычка работать вместе» — Твайла Тарп. Опыт успешной коммуникации в команде на примерах из разных сфер.
• «Пять пороков команды» — Патрик Ленсиони. Книга о том, как преодолеть недоверие, безответственность и безразличие к результату работы.
• «Мотивация» — Макс Эггерт. Ценный справочник, полный советов и инструментов, необходимых в работе менеджера.
• «Карьера менеджера IT-проекта» — Гэйл Лакман Макдауэлл и Джеки Баваро. Практическое руководство по ведению проектов и подготовке к собеседованию на позицию ИТ-менеджера.

Полезными будут и онлайн-курсы и тренинги по менеджменту. В числе самых известных — Agile Project Management, интенсив-тренинг для начинающих руководителей. Методология Agile — эффективный подход к реализации проектов с планированием, разбивкой на этапы и активным сотрудничеством всех участников.

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

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

Шаг 4. Переходим на желаемую должность

Советуем следовать конкретному плану:

1. Установите сроки. Переход в менеджеры — дело не одного дня. Процесс займет несколько месяцев, при этом форсировать события точно не стоит.
2. Согласуйте переход в менеджеры с руководством компании. Если в вашей фирме не заинтересованы в подобной инициативе, поищите вакансии в других организациях. В целом хорошие управленцы в ИТ-отрасли нужны всегда.
3. Определите свои сильные и слабые стороны. Подумайте, что можно сделать, чтобы нивелировать недостатки и выработать качества, без которых руководителю не обойтись.
4. Найдите ментора из числа опытных управленцев вашей компании. Научитесь у него всему, что он знает, особенно в плане взаимодействия с исполнителями и руководством.
5. Договоритесь о собеседовании на позицию менеджера. Если вы действуете внутри компании, вести беседу будет гораздо проще. Помните главное: собеседование — не экзамен, работодатель не делает вам одолжений, а тоже заинтересован в ответственных и активных работниках.

Не стоит при переходе занимать позицию джуна (новичка без опыта). У вас уже есть навыки работы в ИТ, вы знаете, как создаются продукты, знакомы со спецификой и нюансами. Называйте себя мидлом и позиционируйте соответствующим образом.

Шаг 5. Работаем над вызовами

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

• Длительные согласования. Чем больше заинтересованных в проекте сторон (стейкхолдеров), тем сложнее. Готовьте документы, инструкции и самого клиента заранее. Все, что нужно предоставить с вашей стороны, должно быть предоставлено. Помогайте заказчику всем, чем можете, и будьте на связи, чтобы в любой момент ответить на вопросы.
• Частые переносы встреч. Клиенты бывают занятыми и иногда откладывают встречи. Проблему можно решить только одним способом — договориться, выбрав нужные слова, и вежливый, но решительный тон.
• Предложение от заказчика переделать функционал. То есть по сути обнулить результат уже проделанной работы. Задача менеджера в такой ситуации — оценить целесообразность решения. Возможно клиент руководствуется пользовательским опытом, но может быть и так, что это его сугубо личное мнение. В последнем случае придется собрать фактический материал и спокойно объяснить заказчику, с какими издержками придется столкнуться.

Менее значительные трудности устраняются универсальными решениями. Используйте делегирование, если замечаете, что не справляетесь с текущими задачами. Не бойтесь говорить правду. Лучше сразу сказать клиенту, что задача не сделана, чем скрываться от него. Общайтесь с коллегами, не стесняйтесь обращаться за помощью в профессиональные сообщества. Будьте готовы меняться и адаптироваться, ибо стабильность — это иллюзия.

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

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

Рынок IT в России: текущее состояние и перспективы

Спрос на айтишников в России остается высоким на протяжении уже нескольких лет. Более того, дефицит кадров постоянно растет. По данным газеты Известия, в середине 2024 года потребность в IT-специалистах выросла вдвое по сравнению с 2023-м. Дефицит айтишников объясняется не только технологическим ростом во всех сферах жизни, но и массовым оттоком специалистов из России в 2022 году.

Мы выяснили, что средний рост зарплат за прошедший 2024 год составил 18%. Медианные зарплаты в IT выросли в 2024 году до 151 тыс. руб. в месяц. Максимальный рост зарплат наблюдался у разработчиков 1С — он увеличился на 46%. Доходы существенно повысились и у системных аналитиков.

При этом зарплата в ИТ-сфере зависит от региона. В Москве средний показатель в отрасли составляет 200 тыс. руб., в Санкт-Петербурге — 165 тыс., в регионах — 135 тыс.

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

Указанная выше медианная зарплата в 151 тыс. руб. касается айтишников с опытом работы от 3 лет и выше. У новичков без опыта показатели более скромные — 42 тыс. руб. Специалистам с опытом до 3 лет предлагают до 100-120 тыс. руб.

Какие специальности наиболее востребованы среди работодателей:

• Разработчики всех направлений, в том числе в сфере ИИ;
• DevOps-инженеры — айтишники, отвечающие за сборку, настройку и развертывание ПО;
• Инженеры машинного обучения;
• Системные администраторы и специалисты техподдержки;
• Дата-сайентисты — специалисты по работе с данными, работающие на стыке машинного обучения, программирования и математики;
• Аналитики различного профиля;
• Специалисты по кибербезопасности.

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

Далее мы рассмотрим ИТ-профессии, в которых специалисты могут рассчитывать на самые высокие зарплаты.

Какие специалисты зарабатывают больше всех

Список наиболее востребованных и высокооплачиваемых профессий постоянно меняется на рекрутинговых ресурсах и сайтах вакансий. Спрос зависит от мировых трендов в отрасли, ситуации в экономике и сезонных тенденций. Рейтинг самых высокооплачиваемых ИТ-профессий 2025 года основан на открытой информации с порталов hh.ru и Работа.ру.

Разработчик

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

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

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

Медианная зарплата разработчиков в России — 184 тыс. руб. В зависимости от опыта и специализации этот показатель сдвигается в обе стороны. Разрабы уровня сеньор, занятые в сложных проектах для бизнеса, получают 400 тыс. и более.

Внутри направления наиболее востребованы архитекторы ПО, которые получают от 380 тыс., разработчики мобильных приложений — 217 тыс., бэкенды и разработчики баз данных — по 200 тыс.

Что касается языков программирования, то наиболее высоко оплачиваются разработчики на Objective-С (средняя зарплата 342 тыс. руб.), Elixir (312 тыс.), Scala (300 тыс.).

DevOps-инженер

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

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

Методология DevOps направлена на эффективное взаимодействие программистов, тестировщиков и других специалистов ИТ-отдела. Инженер отвечает за внедрение принципов DevOps в работу компании и стремится к полной автоматизации всех рутинных процессов. Он также отвечает за обновление продукта и его корректную работу.

Мидлы в этой отрасли могут рассчитывать на зарплату около 250 тыс. руб., сеньоры — от 350 и выше.

Аналитик

В ИТ аналитик собирает данные, выявляет проблемы, потребности и на их основании предлагает эффективные решения. Это посредник между клиентами и разработчиками, который формулирует креативную идею или концепцию. Реализацией этих идей занимаются уже программисты.

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

IT-аналитики нужны во многих сферах — в маркетинге, финансах, здравоохранении, электронной коммерции. Есть системные, продуктовые, бизнес-аналитики и более узкие специалисты с ценными навыками.

Ожидается, что аналитики в 2025 году станут самыми востребованными специалистами в IT. Их средняя зарплата составляет 160 тыс. руб. Мидлы получают до 250 тыс., сеньоры — 300-350 тыс.

Дата-сайентист

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

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

Одно из направлений работы — использование нейросетей, которые помогают компании анализировать данные, делать выводы, моделировать стратегии развития и принимать правильные решения.

Для работы в Data Science требуются знания в математических науках: линейной алгебре, статистике и теории вероятности, матанализе. Кроме того, дата-сайентист должен знать языки программирования и уметь обращаться с библиотеками.

Зарплата специалистов мидл-уровня в этой отрасли — от 280 тыс. руб. Сеньоры получают до 700 тыс.

AI-разработчик

AI Developer — специалист по машинному обучению, созданию и внедрению систем ИИ. Он разрабатывает алгоритмы и интегрирует ИИ-решения в рабочие процессы и действующее ПО.

Сегодня ИИ активно внедряется в различные отрасли, включая медицину, производство, финансы, образование, маркетинг и дизайн. Системы AI распознают речь, анализируют и интерпретируют данные, делают выводы, создают изображения, тексты, инфографику. Спрос на разработчиков ИИ с каждым годом увеличивается на 20-40%.

AI Developer разбирается в математике, статистике, знает языки программирования, знаком с фреймворками, созданными для работы с нейросетями, имеет навыки работы с Big Data (большими данными).

Разработчики AI-продуктов уровня милд получает около 200 тыс. руб., сеньоры, создающие продукты для крупного бизнеса могут рассчитывать на зарплату от 500 тыс. и выше.

Продуктовый менеджер

Специалист отвечает за продукт от разработки концепции до выхода на рынок. Это могут быть приложения, веб-сервисы, девайсы, ПО различного назначения. Задача менеджера — сделать продукт интересным аудитории и прибыльным для компании.

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

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

В 2025 году зарплата продакт-менеджера продвинутого уровня — 250-450 тыс. руб. Новички могут рассчитывать на 90-100 тыс., мидлы — на 150-200 тыс.

Специалист по кибербезопасности

Задача такого сотрудника — защищать информационные системы, личные и корпоративные данные, сети и сервера от внешних угроз, утечек и несанкционированного доступа. Специалист по кибербезопасности предотвращает финансовые, репутационные и юридические потери организации.

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

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

Чтобы стать специалистом по информационной безопасности, нужны глубокие знания в сфере сетевой архитектуры, криптографии и других отраслях IT, умение анализировать риски и адаптироваться к постоянным изменениям в цифровой среде.

Медианная зарплата в этой отрасли — 130 тыс. руб., однако опытные безопасники в крупных компаниях получают от 400 тыс. и выше.

Чего ожидать по зарплатам в IT в ближайшем будущем

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

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

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

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

Мы поговорили с Даниилом Динько, тимлидом в международной компании-лидере в кибербезе, который стал руководителем в ХХ лет, а также с эйчар-экспертами Эйч — Анной Динельт и Еленой Артемьевой, и узнали, что это значит — быть молодым тимлидом, как справляться с критикой и какая в целом ситуация на рынке.

— Даниил, расскажи, как ты пришел в программирование и как развивалась твоя карьера до тимлидства?

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

Также в раннем детстве я играл в Майнкрафт — и где, если не там, углубляться в программирование. Желание создавать в Майнкрафт реализуется сполна: игра как раз про это, но в какой-то момент становится скучно, и хочется попробовать нечто более серьезное. И тут происходит мое соприкосновение с первым языком программирования — Java, я изучаю его, чтобы пилить что-то вокруг Майнкрафта.

Через некоторое время мы с ребятами, движимыми той же идеей, поднимаем первый свой сервер, который набирает в пике 150 человек в онлайне и приносит нам какой-то первый кэш. Представляете, насколько это было приятно на тот момент? Во-первых, ты создал что-то с минимальными усилиями (не пришлось даже чего-то мастерить, речь просто про правильную последовательность нажатий по клавиатуре). Во-вторых, это работает, и этим пользуются люди — еще один огромный источник мотивации. В-третьих, небольшой проект приносит какие-то деньги — можно уже самому сходить и купить что-то приятное. Это и был мой старт в IT.

Затем я просто начал ресерчить другие сферы, изучать разные языки программирования, и понял, что веб-разработка выглядит приятнее всего. Почему — не знаю до сих пор, просто лежала душа. Так я создал свои первые пет-проекты и вышел на фриланс в качестве Fullstack разработчика на NodeJS. Стэком у меня тогда были ReactJS/Angular, MongoDB, NestJS.

А еще через время понял, что мне больше все-таки нравится писать логику — бэкенд. Я пробовал разные языки, но зацепил только один — Golang. Поначалу только синтаксисом, о его мощных инструментах я узнал уже позже. Так и определился со стеком. Затем устроился в первую компанию, получил первый коммерческий опыт не на фрилансе — в сфере криптовалют (тогда туда брали почти всех). А потом уже попал в Ситидрайв, Ozon, а сейчас я тимлид в международной компании-лидере в сфере кибербезопасности (название, к сожалению, говорить не могу).

— Как же ты стал тимлидом?

— Честно говоря, лидом получилось стать весьма спонтанно. Я тогда менял работу, поскольку мне совсем не зашёл тот домен в Озоне, где я работал — логистика на складах, и зарплата была не в рынке. На тот момент я был сеньором и искал вакансии на соответствующую позицию в других компаниях. У меня уже было несколько интересных офферов, но тут вдруг меня приглашают на интервью на позицию TeamLead + TechLead команды в одном лице.

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

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

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

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

— Расскажи, как к тебе относились коллеги? Были ли ситуации, когда приходилось доказывать свою компетентность?

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

Я работаю в Яндексе, и здесь к молодым руководителям относятся очень позитивно. Назначения связаны не с возрастом, а с профессиональными навыками и лидерскими качествами. Талантливые ребята рано становятся руководителями, и это круто!

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

Однако с предвзятым отношением я столкнулся в другой сфере, связанной с IT — в менторстве. Я провел более 15 трансляций на большую аудиторию, каждая из которых набрала более 1 500 просмотров и 100 человек в лайве. На первых трансляциях в силу того, что я выгляжу весьма молодо, от некоторых ребят слышал хейт в сторону возраста, и он вполне оправдан: ты уже состоявшийся разработчик не совсем молодого возраста, и тут ты приходишь на стрим, где тебе какой-то молодой «чувачок» пытается что-то объяснить неуверенным голосом. Конечно ты будешь возмущаться.

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

Что для этого нужно было? Во-первых, чувствовать себя уверенно, потому что если ты не сильно уверен в своих компетенциях (синдром самозванца), то и другие тем более. Во-вторых, нужно уметь правильно общаться с аудиторией. У меня следующий принцип: я представляю, что передо мной сидит мой друг, который хочет что-то понять, и мне нужно это объяснить. Аудитории обычно заходит именно такой формат.

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

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

Что говорят эйчар-эксперты

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

Я думаю, что молодой возраст — идеальное время, чтобы пробовать разное и искать себя. Поэтому «0% осуждения, 100% понимания» с моей стороны! В «красный флажок» это превращается, когда человек бессистемно меняет места, проработав на каждом менее 6-8 месяцев. При этом в динамике нет ни роста дохода, ни понятной карьерной траектории. В таком случае для меня на месте нанимающего менеджера это выглядит подозрительно.

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

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

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

Я видела много случаев, когда ребята уходили (в том числе из моих команд) на роль лида, руководителя направления и т.п., со словами «я хочу делать все с нуля и под себя». В итоге 90% из них очень быстро понимали, что роль руководителя — это не то, что они себе представляли, и они либо очень быстро увольнялись и переходили на грейд ниже в новую компанию, либо их увольняли, иногда до конца испытательного срока. Были и исключения, но только для тех, кто быстро понимал, что такое роль лида, какая ответственность на нем лежит, и кто быстро перестраивал свою модель поведения из исполнителя в лидера команды.

— Даниил, скажи, можно ли вырасти до тимлида в одной компании так же быстро?

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

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

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

— Как твой возраст повлиял на карьеру? Было ли проще или сложнее проходить собеседования, вливаться в коллектив?

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

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

От редакции скажем — дерзайте и верьте в себя. Рынок меняется, и для молодых ребят открывается гораздо больше возможностей, главное — их не упустить!

Еще в институте я был фанатом Linux, собирал его на дискете. С третьего курса работал системным администратором, а позже — фулстек-разработчиком в корпорации. Потом начал изучать Java и стал Java-разработчиком на позиции джуниора.

Через некоторое время я решил, что корпорации — это не для меня. Занимался тем, что привлекало, изучал совершенно разные вещи — от дизайна до истории искусств — и работал в интересных для меня стартапах.

Затем снова вернулся в корпорацию уже на позицию мидл-разработчика Java. В это же время проникся идеей Agile, подписал Agile Manifest и стал продвигать его в командах, где работал.

Постепенно дорос до сеньор-разработчика. В этот момент узнал о Software Craftsmanship — подходе к разработке как к мастерству. Это расширило границы, которые я видел для себя. Сейчас совмещаю роли скрам-мастера, тимлида, архитектора решений. Одновременно продвигаю и популяризирую идею Software Craftsmanship, подходы TDD (Type Driven Development), DDD (Domain Driven Design) и Clean Code.

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

С чего начать путь в профессию и как развиваться дальше

Начинающему бэкенд-разработчику придется многое изучить. Я собрал список книг с понятным и кратким материалом для новичков:

• «Думай как математик: Как решать любые задачи быстрее и эффективнее», Барбара Оакли.

• «Грокаем алгоритмы. Иллюстрированное пособие для программистов», Адитья Бхаргава.

• «SQL: быстрое погружение», Уолтер Шилдс.

• «JAVA. Эффективное программирование», Джошуа Блох.

• «Чистый код», Роберт Мартин.

• «Идеальный программист. Как стать профессионалом разработки», Роберт Мартин.

• «Как на самом деле работают компьютеры», Мэтью Джастис.

• «Компьютерные сети», 5-е изд., Эндрю Таненбаум, Дэвид Уэзеролл.

• «Java. Руководство для начинающих», Герберт Шилд.

Две последние книги более скучные, но такая справочная информация тоже нужна.

Полезно посмотреть, как реализованы структуры и алгоритмы в стандартных библиотеках Java. Еще помогают разобраться в деталях Study Guide для подготовки к экзаменам на сертификаты Java OCA, OCP.

Если хотите пойти в веб-разработку, будет полезно почитать SQL Tuning Дэна Тоу. Тем, кто интересуется Kotlin, рекомендую книгу Дмитрия Жемерова и Светланы Исаковой Kotlin in Action.

Список книг для специалистов разных уровней будет ниже.

Старайтесь сразу применять все новые знания. Это поможет отработать навыки и собрать первое портфолио. Задачи можно придумывать самостоятельно — отталкивайтесь от того, что интересно лично вам. Например, найдите потребность, которую можете закрыть приложением, и напишите его — что угодно, хоть календарь настроения. Или поднимите свой http-сервер, сделайте демо социальной сети или интернет-магазина. Ищите простые и красивые решения. Но чтобы научиться видеть их, нужно изучать лучшие подходы и паттерны.

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

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

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

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

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

Наконец, джуниору нужно проверять и тестировать все свои решения, как минимум — уметь писать юнит-тесты. Кстати, не все тесты одинаково полезны — понять это поможет книга Владимира Хорикова «Принципы юнит-тестирования».

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

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

Что почитать джуниору:

• «Чистый код», Роберт Мартин.

• «Чистая архитектура», Роберт Мартин.

• «Java. Эффективное программирование», Джошуа Блох.

• «Принципы юнит-тестирования», Владимир Хориков

На вдумчивое изучение этих книг уйдет 3–6 месяцев. Они помогут познакомиться с лучшими практиками, расширить границы понимания кода и разработки в целом. Не нужно совершать кучу ошибок, чтобы осознать ценность этих практик. У Мартина, Блоха, Хорикова есть советы, как стоит поступать, и все они действительно работают.

Мидл-разработчик углубляется в архитектуру приложений. Умеет работать с микросервисами. Понимает, что такое Kubernetes, например может развернуть мини-куб на своем ноутбуке. Чаще работает с SQL, NoSQL, хотя конкретные инструменты зависят от проекта.

Отлично, если мидл знает и применяет методологию TDD (Test Driven Development) — разработку через тестирование. Этот подход помогает писать более чистый и качественный код. А как при этом писать меньше тестов, делать их эффективнее, избегать подводных камней, рассказывает Владимир Хориков.

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

Что почитать мидлу:

• Методология «Двенадцатифакторное приложение».
• Статья 7 Software Development Principles That Should Be Embraced Daily.
• «Приемы объектно-ориентированного проектирования. Паттерны проектирования», Эрих Гамма, Джон Влиссидес, Ральф Джонсон, Ричард Хелм.
• «Создание микросервисов», Сэм Ньюмен.
• «Микросервисы. Паттерны разработки и рефакторинга», Крис Ричардсон.

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

Через три года (если включить год джуниором) вы станете хорошим мидлом и сможете претендовать на следующую ступень.

Сеньор-разработчик отвечает за качество работы всей команды. Он надежда и опора для остальных разработчиков — и особенно для джуниоров. Это «старший брат», к которому можно обратиться за советом. Если в компании работают по скраму, сеньор может попробовать себя в роли скрам-мастера, продвигать Agile.

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

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

Для более глубокого погружения в дизайн сеньор-разработчик может изучить DDD, или предметно-ориентированное проектирование. Этот подход отталкивается от предметной области и нужд бизнеса.

Я начал изучать топик DDD c книги Domain Modeling Made Functional Скотта Влашина. Затем прочитал DDD The First 15 Years. После этого начал изучать труд Эрика Эванса «Предметно-ориентированное проектирование», в котором он много пишет об общих подходах к разработке и взаимодействии с людьми. Советую вам такой же порядок чтения.

Другой подход, который полезно знать сеньору, — TDD, или разработка на основе типов. Он связан с математическим моделированием и строгим описанием типов. Подход описан также у Скотта Влашина и в книге DDD The First 15 Years.

Наконец, сеньор-разработчик должен отлично знать предметную область. Он отвечает за качественную работу каждого элемента в проекте.

Что почитать сеньору:

• System design, Алекс Сюй.

• «Предметно-ориентированное проектирование. Структуризация сложных программных систем», Эрик Эванс.

• DDD The First 15 Years, сборник статей разных авторов.

• Domain Modeling Made Functional, Скотт Влашин.

• «Шаблоны корпоративных приложений. Исправленное издание», Мартин Фаулер.

• «Джедайские техники конструктивного общения», Александр Орлов.

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

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

Как происходит бэкенд-разработка в энтерпрайзе

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

Работа над проектом проходит примерно одинаково в любой корпорации. Для начинающих бэкенд-разработчиков полезно знать этот пайплайн в общем виде.

Новые проекты в корпорации начинаются с проработки бизнес-требований. Их готовят бизнес-технологи или аналитики. Затем по этим требованиям одновременно начинают разрабатывать дизайн фронтенда и концептуальный дизайн.

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

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

В гибких структурах, например, agile-командах, в первых этапах участвуют все разработчики. Если среди них есть джуниор, его тоже привлекают к проектированию и оценке. Таким образом человек учится, задает вопросы и глубже погружается в проект.

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

По готовому ОТАР начинается разработка прототипа приложения и инфраструктуры. Его работоспособность проверяют на тестовом полигоне.

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

Когда инфраструктура готова, есть пайплайны для доставки приложения в продакшен, а прототип достаточно хорошо протестирован, можно выпускать MVP (Minimal Viable Product) — минимальную рабочую версию продукта. Она доступна пользователям, поэтому позволяет проверить гипотезы и определить, что делать дальше, а также наладить поддержку.

Затем цикл разработки замыкается между разработкой новых функций в формате MVP, их тестированием и выкаткой в продакшен.

Почему бэкенд-разработчику нужно много общаться

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

Это значит, что бэкенд-разработчику нужно уметь общаться с каждым членом команды. И чем выше уровень, тем больше он взаимодействует с коллегами. Джуниор чаще общается с наставником или отдельными специалистами по точечным вопросам. Сеньор общается со всеми и очень часто, потому что ему нужно глубоко разбираться в проекте.

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

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

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

Говорить на одном языке с аналитиками легче, если самому писать документацию. Также полезно исследовать хорошие примеры документации в open source и коммерческих решениях, например, у Stripe или YooMoney.

Чтобы было проще общаться с QA, стоит поднять проект с автотестами и научиться их писать. Разработчику нужно понимать суть e2e-тестирования, ценность и количество интеграционных тестов, место в пирамиде тестирования.

Бэкенд-разработчик уровня сеньора может совместно с DevOps работать над пайплайном.

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

Что еще важно для бэкенд-разработчика

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

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

Не переживать, что результат труда будет не очень заметным. Работа бэкенд-разработчика невидимая, в отличие от фронта, но она напрямую влияет на качество сервиса или приложения.

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

Главное — делайте то, что любите. Учиться придется постоянно, настройтесь на это сразу. Ищите задачи, подходы и инструменты, которые вас драйвят. Только в этом случае сложный и длинный путь бэкенд-разработчика будет интересным.

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

Вместе с менторами Solvery Ольгой Мазур, Анастасией Золотых и Алексеем Шкиль разберемся в плюсах и минусах обоих путей.

Когда пора быть тимлидом и кому это подходит

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

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

Тимлидом нужно становиться, когда:

• У вас сильная техническая база и широкий технический кругозор.
• Обладаете soft skills и навыками управления и понимаете, зачем они необходимы, ĸаĸ выстроить ĸоммуниĸацию ĸаĸ внутри своей ĸоманды, таĸ и со смежными, можете найти выход из ĸонфлиĸтной ситуации, ĸаĸ проводится деĸомпозиция и планирование задач, понимаете ценность задач для бизнеса.
• У вас есть есть опыт менторства. Например, вы помогали новичкам освоиться в компании, составляли ИПР (индивидуальный план развития) и ĸонтролировали процесс развития сотрудниĸов.
• Имеете зрелое понимание зачем и почему вы хотите стать тимлидом. Например, «У меня есть понимание и видение ĸаĸ сделать продуĸт лучше».

Каĸ правило, таĸим набором навыĸов и умений обладают специалисты уровня middle / middle+, прошедшие огонь и воду. Поэтому если вы замечаете, что вам нравится менторить, вы находите общий язык с разными людьми и умеете выстраивать долгосрочные отношения, — это ваш сигнал. Ведь если вы встали на менеджерский путь, то скиллы, которые раньше были soft, теперь станут вашими hard-скиллами.

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

Для компании: нанимать или растить

Зачастую тимлиды вырастают из сеньоров, и в этом есть своя логика. Компании хотят «взращивать» лидеров из своих рядов, потому что это надежно. Человек уже знает процессы, культуру, ценности и команду — его не нужно адаптировать.

Развитие ĸаĸ тимлидов, таĸ и других специалистов требует от ĸомпании выстраивания процессов: онбординг, регламенты по ĸарьерным целям, регламент perfomance-review, матрица знаний и ĸомпетенции, пересмотры подходов ĸ проведению собеседований, 360, индивидуальный план развития и таĸ далее. Это сформирует явное понимание для сотрудниĸов, чего ĸомпания и руĸоводство ожидают от ĸаждого, ĸаĸ развиваться, ĸаĸие ĸомпетенции необходимы.

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

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

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

История помнит много примеров, ĸогда сеньора ставили тимлидом со словами «ты же знаешь, ĸаĸ писать ĸачественный ĸод? Вот и научи ĸоллег». Каĸ правило, это выходит боĸом ĸаĸ для ĸоманды, таĸ и для самого тимлида. Например, senior-разработчиĸу интереснее заниматься тольĸо техничесĸой частью проеĸта, решать сложные задачи, проводить ревью, принимать решения, относящиеся ĸ техничесĸой стороне. А руĸоводство проеĸта или ĸомпании в этот момент ожидает же, что ĸоманда будет организована, что будет составлен план работ. Полный рассинхрон.

Найм готовых синьеров с рынĸа тоже имеет место быть. Например, ĸомпания отĸрывает новое направление для себя новое направление или отдел, условно Computer Vision, и ей необходим лид этого направления — в таĸом случае организация привлеĸает специалиста с готовой эĸспертизой.

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

Для тимлидов: оставаться или уходить

Что касается самих тимлидов, которые стоят на перепутье: оставаться им в компании и развивать команду или уходить в другую — здесь универсального ответа нет. Все зависит от того, какие цели преследует лид, есть ли что-то, что его не устраивает.

К сожалению, возможность действительно влиять на команду и развивать её — редкое явление.

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

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

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

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

Уходить же могут по следующим причинами:

• Нет условий для развития — как личного, так и команды.
• Нет понимания, куда необходимо двигаться в следующий месяц, три, полгода, приоритеты меняются слишком часто без объяснения почему так происходит («СРО так решил»).
• Красные флажки внутри компании (сокращение соседнего отдела, сокращение ранее предоставляемых плюшек — участие в конференциях, ДМС и пр. — всё это свидетельствует о финансовых проблемах внутри компании, которое вряд ли ведут к чему-то хорошему; неприятные кейсы увольнения среди коллег, хамство, поощрение неприятного общения – внутри компании нет культуры, и когда-то это может затронуть и вас).

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

Как выстраивать карьеру в роли тимлида

Кажется, что тимлид — пик карьеры разработчика (до запуска собственной компании), но это совсем не так. После роли тимлида перед вами открываются разные пути. Вы можете идти в сторону менеджмента, становиться CTO или Engineering Manager. А можете вернуться к технологиям, углубиться в архитектуру.

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

А еще стоит начать думать именно ĸаĸ тимлид — на первом месте должна быть ĸоманда.

Стоит забыть о посиделĸах за ĸодом, исследовании и решении инцидентов. Необходимо научиться делегировать решение проблем участниĸам ĸоманды, давать направление в развитии. Каĸ сформировать и адаптировать процессы, чтобы они были удобные для ĸоманды, чтобы не страдало ĸачество выпусĸаемого продуĸта.

Немаловажным фаĸтором развития тимлида является получение знаний об опыте других тимлидов, например, в рамĸах ĸомпании. Стоит посещать или прослушивать леĸции, подĸасты, выступления. Тимлид — это первая ступень в техничесĸом менеджменте, поэтому не стоит бояться что у вас что-то не получится, и не стесняйтесь обращайться за советом ĸ страшим товарищам.

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

Если вы же отвечаете себе «нет», и вы «новоиспеченный» тимлид (6-9 месяцев), то стоит честно обсудить с руĸоводителем сложившуюся ситуацию, возможно, вы по-разному представляли свою роль и чем вам предстоит заниматься, и вместе сможете найти решение. А может, вы поймете, что вам гораздо интересное писать ĸод и решите вернуться в техничесĸим задачам — в этом нет ничего страшного.

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

Я — Даниил Динько, веду свой личный телеграм-канал, где рассказываю о себе, об IT и о Golang, а также являюсь экспертом и спикером в компании Эйч Навыки, TeamLeadом в компании-лидере в международном кибербезе, ex. старшим разработчиком в Ozon Tech. Вместе разбираемся, в чем польза ежедневных встреч и как их спланировать так, чтобы ни у кого не закатывались глаза.

Зачем нужны созвоны и какую роль они играют

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

Тогда продукт разрабатывали два человека, и регулярные митинги им были не нужны. Однако после успешного MVP продукт заинтересовал компании в сфере информационной безопасности, что привело к росту не только числа клиентов, но и багов.

Старый тимлид ушёл, и меня наняли возглавить команду и оптимизировать процессы развивающегося продукта. Ранее я работал в Озоне, где созвоны вставляли по всем возможным и невозможным причинам и практикам. Теперь мне предстояло вспомнить практики прошлой компании, понять, зачем они вообще нужны, и внедрить в мою новую команду.

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

Какие бывают созвоны

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

• Стендапы/дейлики — базированная база, краткие созвоны по 15 минут с целью получения статусов каждого из исполнителей: что делал вчера? что сегодня?
• Груминги — это встречи, на которых вы собираетесь и вместе приходите к решению какой-то из проблем. К примеру: «Груминг по вопросу проектирования платежей»: собираетесь и вместе думаете над архитектурой платежей.
• Ретро — вы собираетесь вместе, чтобы обсудить хорошие и плохие моменты за последний период работы. В процессе обсуждения будет круто, если вы придете к каким-то Action Pointам — задачам, которые помогут устранить плохие моменты.

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

Стендапы и дейлики: фокус или отвлечение?

Первым делом Даниил с лидом QA приняли решение внедрить 15-ти минутные ежедневные встречи по утрам.

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

Для начала важно отметить, что дейлик = стендап. Оба термина используются в Agile-методологиях (особенно в Scrum) и означают одно и то же мероприятие.

Теперь давайте представим себя на моем месте и объективно подумаем, какие плюсы есть у стендапа, чтобы даже с утра пораньше они были оправданы:

• Явная точка старта рабочего дня. Особенно актуально на удаленке, где у каждого рабочий день начинается в свое время, плюс есть те, кто не обладает силой воли каждый день в константное время вставать с кровати — для них стендап будет той самой жесткой точкой, к которой они должны войти в фокус.
• Мотивация на результат. Стендапы подстегивают думать: «А что я скажу завтра?» Это мотивирует завершать задачи и продуктивно использовать день.
• Напоминание о темпе. Работает в том случае, если в одной команде есть и нереально продуктивные сотрудники, и те, кто работают медленнее. Вторые будут испытывать страх и волнение и думать: «Я работаю гораздо медленнее, чем Саша… А вдруг это не нравится руководству? А вдруг премию не дадут?» И как раз благодаря стендапам и наглядному прогрессу коллег ребята могут подкорректировать свой темп, чтобы не отставать и соответствовать ожиданиям. Но здесь не перегнуть палку, чтобы избежать выгорания.
• Для руководителей. Понимаешь, кто чем занимается, направляешь, ставишь приоритеты. В моем случае ситуация такова: задач много, исполнителей мало, так еще и стоят они дорого, каждый час дорог, нужно контролировать.
• Новости по продукту или про компанию. Это занимает обычно не более 5 минут, стендапы хорошо подходят для таких мини-сводок.
• Решение вопросов, которые затрагивают большое количество людей. Если понимаете, что текстом решить какой-то вопрос не получится и важно мнение каждого, есть смысл обсудить его на стендапе. Главное избежать такой ситуации: два исполнителя общаются между собой, пока другие просто сидят и бессмысленно тратят время. В нашем случае желательная граница созвона — 25 минут (стендап классически длится 15 минут, но иногда этого не хватает еще и для ответа на вопросы и мини-синка). Если на это уходит больше времени, нужно оптимизировать. Локальные вопросы лучше обсуждать текстом — так сохраняется история размышлений и выводов, плюс не привлекаются другие сотрудники.

Внедрение стендапов прошло хорошо — после адаптации мы заметили хорошие результаты по каждому из пунктов.

Формат стендапа: наш отработанный план встреч

Мы пришли к такому формату стендапов — он, по моему мнению, реализует максимум из того, что возможно за короткий срок до 25 минут:

1. Пробегаемся по новостям о продукте (желательно перед этим написать о них подробнее в чате и на дейлике сослаться на сообщение, потому что иногда важные новости в чате не просматриваются)

2. Даём слово исполнителю, задавая несколько вопросов:

• Что сделал вчера? (тут можно уточнить у разработчика про статусы по важным задачам — таким образом подтолкнуть и узнать, как идет работа)
• Что планируешь делать сегодня? (здесь можно скорректировать приоритеты)
• Есть блокеры или какие-то вопросы, которые можно вкратце обсудить сейчас? (важно вовремя остановиться, чтобы дейлик не превратился в груминг)

А еще можно напомнить про вопросы в чате, на которые еще не получены ответы.

3. Всем хорошего дня — всё.

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

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

Груминги: что это такое и с чем едят?

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

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

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

Резюмируем: зачем нужны груминги

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

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

Несколько советов, как нужно проводить груминг

Довольно быстро я пришел к следующему довольно очевидному формату:

1. Ставим встречу в первый день недели (а лучше в пятницу прошлой недели), пишешь в чате о груминге и его теме и уведомляешь каждый день на протяжении недели на стендапах то, что у нас в четверг (ориентировочно) будет груминг. Просим подготовиться, немного подумать на тему — люди обычно ленятся, но если повторять много раз так или иначе будут результаты. А еще можно попросить поставить встречу коллегу — в ребятах тоже важно растить софты таким образом, чтобы найти себе преемника и двигаться дальше в будущем.
2. На самом груминге сначала отмечаем проблему, предлагаем свои теоретические варианты решения.
3. Потом поочередно спрашиваем каждого члена команды, чтобы уничтожить фактор стеснения — так люди вынуждены будут что-то сказать.
4. Готово — дальше вы обсуждаем вопрос и приходим к решению

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

Теперь о самом приятном — ретро

Ретро — пожалуй, лучший вариант созвона для членов команды. Это время, когда можно похвалить друг друга за успехи и честно обсудить, что можно улучшить. Но когда я внедрял эту идею к нам в команде, результаты были не очень позитивные — ребята просто не знали, что нужно писать, поскольку 2 недели в Kanban — это не очень много. Поэтому в случае ретро важно правильно продумать периодичность встреч. Наиболее оптимальная схема для меня — раз в один/два месяца по ситуации. В Озоне мы, однако, пришли к одному ретро в неделю, поскольку формат работы был совсем другой — слишком меняющийся и с моментами, где правда нужно собраться и обсудить и что-то улучшить.

Какие смыслы несет ретро

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

На самом деле в случае ретро я не буду рекомендовать ничего конкретного, потому что у каждой команды своя специфика. Человек — это не системное существо, а эмоциональное Сумма всех характеров и образует специфику команды. Под эту специфику вам и нужно будет подстраиваться.

Принуждение к встречам: свобода vs. контроль

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

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

Как тимлидам оптимизировать встречи

• Не допускайте того, о чем я писал выше: стендапы не должны превращаться в груминги
• Не ленитесь устраивать груминги — это полезно, поскольку вы спрашиваете мнение каждого из команды
• В ретро важно выстроить доверительное отношение — пытайтесь максимально переходить на другие темы
• Внимательно слушайте каждого члена команды. Часто бывают ситуации, когда стендапы деградируют по уровню ответов следующим образом: делал X, вот сейчас делаю Y — всё. Уточняйте, вежливо выводите человека на чистую воду, и тогда стендап не будет лишь формальностью

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

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

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

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

Типы наставничества

Формальное и неформальное наставничество

Наставничество бывает двух типов, и каждый из них полезен в разных ситуациях:

• Формальное наставничество: есть чёткие цели, расписание встреч, и прогресс отслеживается по заранее утверждённым метрикам. Например, в IT-компаниях создаются внутренние программы, где младшие разработчики проходят обучение под руководством старших коллег. Для этого даже выделяются отдельные платформы, где фиксируются задачи, отслеживаются результаты и собирается обратная связь. Такой подход удобен, если нужно быстро обучить сотрудников работе с конкретными технологиями или инструментами.
  
  
• Неформальное наставничество: здесь всё проще, представьте, вы с коллегой случайно завели small talk, он спросил совета по проекту, а вы рассказали, как это можно реализовать. Такой формат наставничества строится на человеческом взаимодействии, без расписаний и строгих правил. Часто он помогает решить проблемы, которые не всегда очевидны, например, выбор подхода к разработке или личный рост в команде. Подобный стиль часто встречается в небольших компаниях или стартапах, где формальных программ нет, но культура взаимопомощи сильна.

Индивидуальное наставничество

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

Групповое наставничество

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

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

Равное наставничество

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

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

Обратное наставничество

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

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

Кросс-функциональное наставничество

Этот формат на стыке технологий и управления. Здесь наставничество строится между сотрудниками из разных отделов. Например, backend-разработчик делится своими знаниями о построении API с аналитиком, который хочет лучше понимать, как обрабатывать данные.

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

Качества эффективного наставника

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

Основные качества

• Техническая экспертиза — наставник должен знать теорию, практику и решать нестандартные задачи, чтобы давать подопечным точные и полезные советы.
  
  
• Эмпатия и коммуникация — наставник должен уметь слушать и понимать чувства подопечного. Важно улавливать, где человек испытывает затруднения, и находить способ объяснить сложные вещи простым языком.
  
  
• Опыт — здесь речь идёт не только о профессиональных достижениях, но и об ошибках. Наставник, который не боится рассказывать о своих провалах, вызывает больше доверия. Поэтому если вы однажды установили неподходящий фреймворк, это может научить подопечных проверять совместимость технологий с реальными задачами.

Проверьте модели поведения

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

7 шагов, чтобы стать наставником

Если вы хотите стать наставником, важно не только обладать необходимыми качествами, но и правильно выстроить процесс. Вот несколько шагов, которые помогут вам в этом:

1. Выбор подопечных — посмотрите вокруг: кто в вашей команде или профессиональном сообществе нуждается в поддержке? Если вы видите, что новый сотрудник часто задаёт вопросы о процессе работы, это сигнал, что ему может быть полезен наставник.
   
   
2. Установление контакта — наставничество начинается с первого разговора. Пригласите коллегу на кофе или организуйте неформальный звонок, чтобы узнать, чем вы можете быть полезны.
   
   
3. Определение границ и ожиданий — с самого начала обсудите, как будет построено взаимодействие. Как часто вы будете встречаться, какие вопросы вы готовы обсуждать, а какие нет. Это поможет избежать выгорания и недопонимания.
   
   
4. Постановка целей и составление плана — вместе с подопечным определите, чему он хочет научиться, и составьте план. Если цель — освоить новую технологию, добавьте этапы: изучение основ, выполнение учебных задач, работа над реальным проектом.
   
   
5. Создание учебной среды — наставник должен поощрять вопросы и обсуждения. Вместо того чтобы сразу дать готовый ответ, попросите подопечного подумать над решением задачи самому, а затем разберите его предложение.
   
   
6. Поддержка роста — наставничество — это не только про обучение, но и про вдохновение. Рассказывайте подопечному, как навыки, которые он сейчас изучает, помогут ему в будущем карьерном росте.
   
   
7. Постоянное совершенствование — наставник тоже должен учиться. Анализируйте, что получилось хорошо, а что можно было сделать лучше, и корректируйте свои методы.

Как выстроить отношения с подопечным

Ставьте чёткие ожидания и цели

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

Стройте доверительные отношения

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

Поддерживайте открытую коммуникацию

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

Пример структуры встречи:

1. Ретроспектива: Что удалось за прошлую неделю, какие были сложности?
2. Анализ: Как можно улучшить процесс или подойти к задаче иначе?
3. План: Какие шаги предстоит сделать до следующей встречи?

Практикуйте активное слушание

Иногда наставники совершают ошибку, когда пытаются сразу дать совет, не разобравшись в сути проблемы. Вместо этого сосредоточьтесь на слушании. Например, если подопечный говорит: «Я не понимаю, как работает эта библиотека», спросите: «Что именно вызывает у тебя сложность? Документация или примеры?»

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

• Что ты уже пробовал?
• Какие ещё варианты ты видишь?
• Какой из них тебе кажется самым перспективным?

Совместно решайте проблемы

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

Поддерживайте баланс

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

Отслеживайте прогресс

Регулярно оценивайте, как идут дела. Например, если вы работаете над обучением новому фреймворку, отмечайте, какие шаги уже выполнены, а какие ещё предстоит сделать.

Проблемы в наставничестве

Коммуникационные барьеры

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

Как решить:

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

Временные затраты

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

Как решить:

• Запланируйте фиксированное время для встреч. Например, каждую среду с 16:00 до 17:00.
• Используйте асинхронные методы коммуникации: оставляйте комментарии в коде или записывайте короткие видеоролики с объяснениями.
• Пересмотрите свои ожидания: возможно, вы пытаетесь охватить слишком много за один раз.
• Делегируйте часть задач более опытным членам команды, если вы перегружены.

Установление границ

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

Как решить:

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

Разнообразие стилей обучения

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

Как решить:

• Узнайте, как подопечному удобнее учиться. Удобно ли ему разбирать задачи самостоятельно или лучше, чтобы вы работали в паре.
• Используйте разные форматы: статьи, видеоуроки, живые обсуждения.

Эмоциональные сложности

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

Как решить:

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

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

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

В итоге это помогает не только отдельным специалистам, но и всей айтишке двигаться вперёд.

Самой прибыльной профессией оказался разработчик на языке Solidity, который используется для создания блокчейн-платформ. Средняя зарплата таких специалистов достигает 640 тыс рублей в месяц.

Топ-5 самых высокооплачиваемых профессий в IT:

1. Разработчик на Solidity — 640 тыс рублей. Этот язык активно используется в блокчейн-проектах.
2. Продакт-менеджер — до 580 тыс рублей. Этот специалист отвечает за разработку и реализацию IT-продукта.
3. Тимлид — 550 тыс рублей. Руководитель команды разработчиков.
4. Python-разработчики в финтехе и Linux-инженеры — 520 тыс рублей. Python в данном контексте используется в финансовых технологиях, а Linux-инженеры администрируют серверы и сервисы.
5. QA-инженеры — 450 тыс рублей. Они занимаются тестированием и контролем качества продуктов.

Рынок IT в России продолжает расти

Согласно данным службы занятости и hh.ru, в России IT-сфера остаётся востребованной.

С начала 2024 года было открыто более 120 тыс вакансий для программистов и разработчиков, что на 6% больше, чем в прошлом году. Средняя зарплата программиста выросла на 10% и достигла 147.7 тыс рублей.

Что такое LeadHub и как эти встречи появились

Идея организовывать встречи для тимлидов Сравни появилась в 2021 году. Тогда технический директор, Дмитрий Парфенов, собрал лидеров команд, чтобы рассказать, как будет развиваться IT-направление. Изначально это была полностью односторонняя история — CTO говорит, а остальные слушают.

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

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

Помимо дилеммы «онлайн VS офлайн», нужно было определиться с частотностью мероприятий.

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

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

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

После каждой Leadhub-встречи проводится опрос среди тимлидов: что понравилось и что стоит улучшить. С помощью опроса получилось определить для себя требования к помещению. Так выяснили, что столы для работы в группах — must-have.

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

Как выстроили рабочие процессы внутри

В Сравни больше 300 IT-специалистов — 39 команд. Каждая сосредоточена на своей специализации: например, команда, в которой три бэкенд- и четыре фронтенд-разработчика, занимается только продуктом ОСАГО (продажа электронных полисов). Глобально компания придерживается принципов Agile, а разработка строится на базе микросервисной архитектуры.

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

В ИТ-команде Сравни нет строгой иерархии: компания отказалась от классической вертикальной модели подчинения.

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

Одной из центральных тем на недавней встрече в формате Leadhub был вопрос про внутренние коммуникациях.

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

Задача 1. Лидам не всегда хватает уверенности затребовать информацию у других команд. Как выстроить процесс так, чтобы весь нужный контекст своевременно поступал к лидерам команд и они могли держать руку на пульсе и быть в курсе всех подробностей.

Мы не можем к каждому из 40 человек ходить в «личку» и задавать вопросы, поэтому ставим общие теги, но не все реагируют. Некоторые просто не обращают внимания, а до тех пор, пока не случится ответ, мы можем не понимать, есть или или нет проблема, о которой спрашиваем. Думая, что все в порядке, запускаем в работу, а оказывается, что есть ошибка. И сразу прилетает вопрос от тимлидов: а почему вы не сказали?

Задача 2. При возникновении общих вопросов команда сталкивается с низкой активностью в ответах на них, которая обычно составляет всего 5-10%. Встал вопрос: как увеличить количество оперативных откликов на эти запросы?

Задача 3. Внутри команд есть нюансы в управлении людьми и общении. Не все тимлиды следят за одними и теми же метриками и коммуницируют напрямую со всеми сотрудниками. Случается, что тимлид, который уже четвертый год руководит командой, ни разу не проводил one-to-one с ребятами из своего юнита, руководствуясь принципом «работают и работают».

Портрет идеального тимлида

В бэклоге типичного тимлида в Сравни разработка своими руками — это порядка 10-20% от всех задач. Остальное время — people-менеджмент и задачи на стыке разработки и бизнеса, а также исследование новых инструментов и проработка архитектурных решений. Чтобы команда достигала целей по метрикам, а внутри у ребят было все нормально с мотивацией, важно давать лидам навыки и инструменты для работы с командой по разным направлениям — от коммуникации до стратегического планирования.

Тимлид — Kubernetes среди людей.

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

Важной темой недавней Leadhub-встречи была матрица компетенций тимлида. Ребята попробовали сформировать требования к самим себе и соответствующим компетенциям. Тимлиды разбирали все скиллы, присущие «настоящему» лиду, и обосновывали свои идеи: что именно нужно развивать. Они собирались в команды, делали наброски компетенций, давали друг другу обратную связь, а затем выбирали из них наиболее важные.

Вот несколько инсайтов из этого обсуждения. Тимлид должен:

1. Быть молодцом
2. Уметь читать и писать
3. Завязывать шнурки

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

Итак, обязательный стартер-пак тимлида

• Тимлид должен обладать сильными техническими навыками. Может звучать как продолжение списка про «завязывать шнурки», но это действительно важная история. В задачи лида, как минимум, входит написание кода — коллега должен быть на уровне, чтобы он как руководитель мог помочь и брать на себя ответственность за архитектурные решения.
• Тимлид должен управлять командой. И отлично управлять. В его задачи входит: подсвечивать приоритеты от бизнеса, знать сильные и слабые стороны команды, управлять временем команды. А еще — уметь делегировать, потому что невозможно тащить все на своих плечах.
• Тимлид должен быть инициатором. Например, в одной команде долго не хотели писать юнит-тесты, но затем пришел тимлид, который сам взялся их писать и зарядил всю команду.
• Тимлид должен обладать хорошими навыками коммуникации. Внутри команды и вовне. Должен быть открытым и дружелюбным, чтобы к нему могли обратиться за помощью, и чтобы ему не «боялись» ее оказывать. Нужно проводить частые one-to-one: узнавать у сотрудников, как они себя чувствуют, не нагружают ли их задачами сверх возможностей — те самые «разговоры у кулера».
  

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

• Тимлид должен быть адаптивным. Это касается как софт-скиллов (например, находить компромиссы, воспринимать критику, расставлять приоритеты, признавать свои ошибки), так и хард-скиллов — обладать широким техническим кругозором, чтобы выбирать правильные технологии.
• Тимлид должен грамотно ставить задачи команде. История про бизнес-логику, выделение типовых и системных решений, декомпозицию, знание ресурсов и зависимостей (внутри и вовне команды), высокое погружение в проект и знание текущих трендов.
• Тимлид должен помнить о бизнесе. Любой компании важно регулярно получать прибыль и растить ее, поэтому тимлид должен держать это в голове, чтобы продукт на выходе был крутым с бизнесовой точки зрения. Здесь ключевыми являются метрики сервиса, контроль качества и финансовое планирование, а еще тимлид должен уметь выступать в роли заказчика.
• Тимлид должен быть самостоятельным. Организовывать встречи, выбирать технологии (например, изменить фреймворк), управлять процессами найма и увольнения. Тимлид не должен работать только в рамках бэклога и отчитываться перед фаундерами, а скорее должен воспринимать проект как свое детище и понимать точки развития.
• Тимлид должен погружаться во внешние коммуникации. Статьи, доклады, выступления. Это здорово, когда лидер может проявить инициативу и рассказать внутри компании или широкой аудитории о новом сервисе и выступить экспертом.

Это именно те навыки, над которыми тимлиды Сравни будут работать в дальнейшем. Что из этого получится — узнаем на следующей встрече в формате Leadhub.

Leadhub: про людей от людей

У нас в компании нет карго-культа. Процессы, которые придумываются в другой компании, закрывают ее боли и задачи, и нам они могут не подходить. Наша идея фикс — отталкиваться от людей и верить в них. Когда я пришел в Сравни, здесь было 50 человек. А сейчас нас 600. Компания сильно выросла, я видел, как меняются люди, эпохи. И сотрудники, которые могут драйвить процессы, заряжают на это других людей и мотивируют компанию расти дальше, поскольку мы видим результат. Поэтому мы делаем акцент именно на людях, и, конечно, на тимлидах, от которых зависят не всегда большие, но крайне важные улучшения для команд.

Если хотите побольше узнать о команде Сравни и их корпоративной культуре, можно почитать телеграм-канал компании и посмотреть YouTube.

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

В этой статье мы постараемся ответить на эти вопросы, а также рассмотрим:

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

Общая статистика разработчиков в мире

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

В начале 2017 года сайт Stack Overflow провел опрос, который содержит ответы 64 000 разработчиков. Среди них 88,6 % составили мужчины, и лишь 7,6 % – женщины. 2,6 % респондентов предпочли не указывать пол. Хотя представительниц прекрасного пола не так много среди разработчиков, тем не менее наблюдается некоторый рост процентного соотношения женщин в этих областях, ведь в 2016 году среди 50 000 опрошенных разработчиков женщины составляли только 5,8 %.

Помним, что данные сайта Stack Overflow относятся к разработчикам в целом, а не конкретно к тимлидам. Тем не менее, респонденты по уровню образования распределяются следующим образом:

• степень бакалавра — 42,0 %;
• степень магистра — 21,7 %;
• колледжи или университеты (не степень бакалавра) — 15,8 %;
• средняя школа — 11,5 %;
• докторантура — 2,5 %;
• предпочли не отвечать — 2,2 %;
• учёная степень — 1,4 %;
• начальная/средняя школа — 2,0 %;
• без профильного образования — 0,8 %.

Таким образом, у 76,5 % респондентов степень бакалавра или выше, у 27,3 % есть как минимум среднее образование, в том числе среднее специальное (колледж) или неоконченное высшее.

А теперь перейдем непосредственно к тимлидам.

Успешные тимлиды и где они обитают

Согласно исследованию Stack Overflow, 76,7 % тимлидов работают полный рабочий день, 6,7% — фрилансерами или в качестве независимых подрядчиков, остальные 5,2 % – неполный рабочий день.

LinkedIn проанализировала (диаграмма выше) свои данные для определения ведущих отраслей, в которых работают следующее количество тимлидов:

• информационные технологии — 20 748;
• компьютерное программное обеспечение — 11 637;
• телекоммуникации — 5 438;
• финансовые услуги — 5 402;
• маркетинг и реклама — 4 033;
• автомобильная промышленность — 3 895;
• нефтяной и энергетический сектор — 3 554;
• управленческий консалтинг — 3 448;
• фармацевтические услуги — 3 434;
• банковское дело — 3 303.

Большая часть тимлидов работает в Соединенных Штатах, хотя у тимлидов из других стран также есть широкие возможности:

• США – 31 342;
• Соединенное Королевство – 25 564;
• Австралия – 11 080.

LinkedIn также представила статистику ведущих компаний-работодателей, которые ищут или в которых уже работают тимлиды:

• IBM — 801;
• Microsoft — 393;
• Oracle — 381;
• Nokia —  359;
• Hewlett Packard Enterprise — 342;
• Ericsson — 313;
• Vodafone — 264;
• Shell — 243;
• Cisco — 224;
• Pfizer — 224.

Согласно результатам опроса Stack Overflow, количество тимлидов по отраслям распределяется следующим образом:

• программное обеспечение — 28,2 %;
• интернет или Web-сервисы — 14,3 %;
• финансы, банковское дело или страхование — 8,5 %;
• медиа, реклама, публикации или развлечения — 4,9 %;
• другое — 4,5 %;
• консалтинг — 4,3 %;
• образование — 4,2 %;
• медицинское обслуживание — 3,7 %;
• телекоммуникации — 3,2 %
• розничная или оптовая торговля — 2,9 %;
• правительство (включая военные) — 2,9 %;
• предпочитаю не отвечать — 2,8 %;
• компьютерная техника и бытовая электроника — 2,3 %;
• транспорт, логистика и складирование — 2,0 %.

Количество тимлидов в игровой индустрии составляет всего 1,7 % от общего числа.

Информация о зарплате тимлидов

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

По данным PayScale.com, медианная заработная плата тимлидов составляет $98 679, варьируя в пределах от $70 203 до $138 086.

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

Ниже вы можете посмотреть среднюю заработную плату разработчиков разного типа (фронтенд, full-stack и т.д.). Как видно, тимлид (Software Engineering Manager) зарабатывает на несколько десятков тысяч больше, чем младшие разработчики и стажеры:

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

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

• начальный уровень (опыт 0-5 лет) — $75 000;
• средняя карьера (5-10 лет) — $88 000;
• опытный (10-15 лет) — $109 000;
• очень опытный (более 15 лет) — $120 000.

Советы, как стать успешным тимлидом

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

Основные навыки, которые требуются лидерам команды разработчиков:

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

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

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