Антон проработал в компании три года — хороший разработчик, знал кодовую базу лучше всех, онбордил новичков, вкладывал душу. В пятницу он написал в личку тимлиду: «Нам надо поговорить», а в понедельник уже с заявлением.
Тимлид был искренне удивлён: «Я не видел никаких признаков!». А было ли тимлиду, где на них посмотреть?
Всем привет, я Люба из команды SimpleOne HRMS. Сегодня расскажу о том, какие сигналы чаще всего предшествуют уходу разработчика, почему тимлиды замечают их слишком поздно и как собрать рабочий и HR-контекст в одну картину, чтобы успеть начать разговор до заявления.
Почему уходы кажутся внезапными
За три месяца до заявления Антон перестал вовлекаться в код ревью, не резко, по чуть-чуть. За полтора месяца его оценка в пульс-опросе упала с 7 до 3. За месяц он начал стабильно перерабатывать, но это не конвертировалось в заметный результат: задачи, которые раньше он щёлкал за день, стали занимать больше времени.
Все эти данные существовали. Они лежали в Jira, в GitLab, в HR-системе, в результатах опроса, который кто-то запускал раз в квартал и складывал в таблицу. Никто не смотрел на них вместе и не видел человека целиком — только его тикеты.
Это не про Антона история, а про то, как устроено большинство ИТ-команд в 2026 году.
У тимлидов есть дашборды с DORA-метриками, velocity, burn rate. Они знают, сколько story points закрыла команда за спринт. Но они понятия не имеют, кто из людей прямо сейчас смотрит вакансии на hh.
По отдельным оценкам, текучесть среди разработчиков может доходить до 20%, что заметно выше среднерыночных значений (10%) — это отдельная горячая зона текучести внутри ИТ. Но даже безотносительно точной цифры проблема в том, что руководители часто видят риск слишком поздно и обходятся потери слишком дорого.
Одно увольнение = 6–12 месяцев потерь
Когда Антон ушёл, команда из шести человек потеряла единственного, кто знал, как устроен платёжный модуль — не по документации, которой не было, а по памяти и опыту двух лет отладки. Новый разработчик вышел через два месяца, ещё три ушло на то, чтобы он хотя бы перестал задавать базовые вопросы. Релиз, который планировали на осень, съехал на январь.
Давайте посчитаем, сколько стоит потеря разработчика. С прямыми затратами всё понятно: по данным MirHR, сам найм обходится примерно в 2–3 месячных оклада, плюс ещё один оклад уходит на адаптацию и время команды. На этом подсчёт можно остановить, но тогда мы не оценим масштаб проблемы.
Дальше начинается самое дорогое. Новый разработчик выходит на нормальную продуктивность за 3–6 месяцев. Всё это время команда тратит время на менторинг, ревью и «подтаскивание» — и сама работает медленнее.
Если собрать всё в одну цепочку, получается довольно приземлённая арифметика:
2–3 месяца — найм
1 месяц — онбординг
3–6 месяцев — выход на продуктивность
+ 1–2 месяца — косвенные потери команды и задержки
Итого: даже в нормальном сценарии — 6–9 месяцев эффекта от одного ухода. Это совпадает с оценками по рынку: замена senior-разработчика обходится компании примерно в 6–9 месячных окладов.
Кстати, когда уходит кто-то один, оставшиеся это видят и начинают делать собственные выводы — о стабильности команды, о том, знает ли руководство что происходит, стоит ли самим начать смотреть по сторонам. Текучесть редко бывает одиночным событием, она приходит волнами, и первый уход часто запускает следующий.
При этом данные, которые позволили бы увидеть риск заранее, уже существуют в большинстве команд, просто они разбросаны по десятку инструментов и никогда не складываются в одну картину. eNPS живёт у эйчаров в Google Sheets, активность в репозитории — в GitLab, переработки — в трекере задач, запросы на рост — где-то в переписке. Тимлид физически не может мониторить всё это одновременно, поэтому ориентируется на ощущения.
По нашему опыту, сочетание этих четырёх сигналов часто встречается у сотрудников, которые находятся в зоне риска:
резкое снижение баллов в ответах на пульс-опросы;
переработки больше 20% без роста результата;
снижение участия в code review;
полное отсутствие запросов на внутренний рост при том, что роль давно не менялась.
По отдельности каждый из них можно объяснить чем угодно — усталостью, сложным проектом, личными обстоятельствами. Вместе они складываются в портрет человека, который уже принял решение. Важно: такие сигналы не должны использоваться как инструмент слежки или карательной аналитики, их задача — вовремя начать разговор. Любой сигнал требует человеческой проверки и контекста.
Для сотрудника ранний разговор тоже полезен: он может прояснить ожидания по росту, нагрузке и роли до того, как недовольство перейдёт в решение об уходе.
Как выглядит команда, которая видит риски заранее
Проблема тимлида не в том, что он не замечает людей — в большинстве случаев он замечает, просто не успевает удержать в голове всё одновременно. Когда в команде восемь человек, у каждого своя история: кто-то полгода просит перевода на другой проект, кто-то третий квартал подряд получает одинаковый грейд без объяснений, кто-то после последнего опроса поставил единицу в открытом поле и написал что-то резкое — и этот комментарий где-то есть, но никто к нему не возвращался. Всё это существует, просто оно размазано по письмам, таблицам, заметкам эйчара и памяти нескольких людей, которые давно не сверяли картинки.
Технические сигналы — активность в репозитории, динамика PR, velocity — тимлид видит сам, для этого инструментов достаточно. Однако если механически мониторить PR и переработки, можно ошибочно записать в зону риска сотрудника, который просто закрыл сложный релиз или ушёл в глубокую техзадачу. Слепая зона находится в другом месте: в HR-контексте, который накапливается годами и почти никогда не оказывается перед глазами в нужный момент. Когда именно был последний карьерный разговор? Что человек говорил на последнем пульс-опросе? Менялась ли его нагрузка последние три месяца?
Поэтому командам нужен не просто ещё один инструмент, а единое место, где можно сопоставить рабочие и HR-сигналы — это могут быть самодельные дашборды, связки нескольких систем или HRM-системы. В SimpleOne HRMS мы собираем всё, что связано с развитием сотрудника: историю должностей и грейдов, результаты опросов, карьерные запросы, записи о встречах one-on-one. Это помогает тимлиду или эйчару видеть живого человека с историей, а не строчку в реестре.
Антону никто не предложил поговорить не потому что не хотели, а потому что никто вокруг не держал в голове, что последний карьерный разговор с ним был девять месяцев назад, а на предпоследнем опросе он написал, что не видит для себя роста. Эти данные были, но не под рукой.
***
А вы по каким признакам определяете, что разработчика пора удерживать? Есть ли у вас данные, которые помогут вовремя среагировать?
