Антон проработал в компании три года — хороший разработчик, знал кодовую базу лучше всех, онбордил новичков, вкладывал душу. В пятницу он написал в личку тимлиду: «Нам надо поговорить», а в понедельник уже с заявлением.
Тимлид был искренне удивлён: «Я не видел никаких признаков!». А было ли тимлиду, где на них посмотреть?
Всем привет, я Люба из команды 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. Это помогает тимлиду или эйчару видеть живого человека с историей, а не строчку в реестре.
Антону никто не предложил поговорить не потому что не хотели, а потому что никто вокруг не держал в голове, что последний карьерный разговор с ним был девять месяцев назад, а на предпоследнем опросе он написал, что не видит для себя роста. Эти данные были, но не под рукой.
***
А вы по каким признакам определяете, что разработчика пора удерживать? Есть ли у вас данные, которые помогут вовремя среагировать?
Комментарии (24)
FixicusMaximus
10.04.2026 06:496-9 месяцев на вход в проект, вы там еб..нулись?! За 6-9 месяцев, ну ок, в среднем за 1 год, большинство проектов успевает реализовываться. >2 лет это уже долгосторой. Если у вас продукт и вам полгода надо, чтобы ввести нового сотрудника, то у вас с документацией беда и процессом онбординга. В среднем 1 месяц нужно, что бы начать профит приносить, независимо от роли.
RTFM13
10.04.2026 06:49могу предположить, что "начать приносить профит" и работать с производительностью уволившегося сотрудника это не одно и тоже. в любом случае для сложных систем это месяцы во множественном числе. за исключением может быть галер где качество результата на последнем месте.
FixicusMaximus
10.04.2026 06:49Не думаю, что человек перед увольнением на все 100% старается, бывает и такое, что новый сотрудник эффективнее старого, а вот как такого найти, эйчары уже давно позабыли, а некоторые и не знали никогда (ллм не поможет).
в любом случае для сложных систем это месяцы во множественном числе
Да вот нифига
RTFM13
10.04.2026 06:49бывает и такое, что новый сотрудник эффективнее старого
а бывает наоборот - на производительность уволившегося вообще никогда не выходит. и приходится менять еще раз. и если контора плати ниже рынка, плюс бюрократия с наймом и увольнением - можно годы потерять. и я такое видел.
FixicusMaximus
10.04.2026 06:49Дак это уже проблема с наймом вроде, нет? Ищут удобных, а потом спрашивают как с умных. Или до этого гений работал? Гении бывают, не спорю, но их гвоздями к стулу обычно приколачивают и с ложечки кормят.
RTFM13
10.04.2026 06:49все проблемы и антипаттерны обычно идут вместе благодаря талантливому менеджменту. найм всегда лоттерея. умный не всегда продуктивный. а если з/п ниже рынка, то устанешь перебирать. хорошая команда формируется годами.
FixicusMaximus
10.04.2026 06:49найм всегда лоттерея. умный не всегда продуктивный. а если з/п ниже рынка, то устанешь перебирать
Дак вам нужна хорошая экспертиза или рабочие руки, которые будут пулять в прод новыми гипотетическими фичами? Это вообще про разное. И то и то нужно, но одно другое не заменяет. На этапе найма нужно понять кто конкретно нужен и загружать его конкретными задачами. По факту же нанимают непонятно кого для непонятно каких задач, вот это лотерея.
хорошая команда формируется годами.
Для бизнеса это не ценность. Хорошо сформированная команда это ценность для самой команды. Бизнесу все равно, кто его хотелки будет делать, главное чтобы было сделано и в срок. А как оно там внутри варится: гармонично и с огоньком или в аду и с переработками, всем пофиг.
RTFM13
10.04.2026 06:49бизнесу "всё равно" потому, что во-первых бюрократия и интересы менеджера не равно интересы бизнеса. а во-вторых очень сложно оценить реальный выхлоп от разработки и еще сложнее оценить перспективы улучшения.
FixicusMaximus
10.04.2026 06:49Безнесу все равно потому, что важна сиюминутная прибыль, а не долгосрочная. Сейчас весь бигтех этим болен. Боинг самый яркий пример. Эффективные менеджеры жрут саму компанию ради показателей.
kompilainenn2
10.04.2026 06:49Эм... Хотелки бизнеса без нормальной команды будут реализованы не так, как хочет бизнес, не за те деньги и не быстро
FixicusMaximus
10.04.2026 06:49100%. Только вы это самому бизнесу объясните. И эффективным манагерам.
JuryPol
10.04.2026 06:49«Тирания показателей» Мюллера... Явно недооцененная книга.
Все эти ваши пульс-опросы, дашборды, построенные на основе дебильных сторипойнтов, прочая псевдонаучная ерунда - это отличная питательная среда для разбухания своры бездельников.
Я порой начинаю думать, что положение «нельзя управлять тем, что не измеряешь», написанное на первых страничках букваря для манагеров, отшибает остатки мозгов у вашего племени. Ментальная контузия. Только контуженные могут придумать дикую смесь из оценки сложности задач в трусах, последовательности Фибоначчи, покера и прочей хрени.
ruomserg
10.04.2026 06:49Давайте честно скажем, что компания и не могла, и не хотела ничего делать с уходящим Антоном. Ну кроме как проактивно искать ему замену. :-)
Смотрите какая логика у компании: сейчас проект открыт, он приносит сколько-то денег, и сколько-то стоит каждый месяц (и основные затраты - это зарплата разрабов). Все это, и разница между доходами и расходами (оптимитично предполагаем что проект прибыльный) - учтены в бюджете компании и расписаны на год вперед.
И вот приходит сигнал что Антон может уйти. Поднять ему зарплату ? А как вы это объясните стейкхолдерам ? А что если коллеги Антона тоже придут с тем же самым ? Вы пойдете объяснять клиентам что они должны платить больше из-за Антона ? А они вам покажут договор, или вообще фигу с маслом - и перейдут на продукт конкурента (или open-source).
С другой стороны - все "затраты" которые предприятие якобы несет из-за того что Антон ушел - они теоретические. Потому что никто не остановит развитие продукта из-за того что ушел разработчик. В российской традиции - если в отделе было пять человек, а стало - четыре, то просто четверо будут работать интенсивнее за те же деньги. В конце-концов, когда коллега уходит в отпуск - никто не прибегает требовать доплату за временное увеличение объема работы. Может быть тимлид и PO как-то поменяют приоритеты в бэклоге чтобы сдвинуть работы с учетом ввода в строй нового разраба. Затраты на найм - опять же, не смешите мои тапочки - разрабов море на рынке, главное - умей выбрать. И некоторый процент времени на собесы уже сидит в зарплате менеджера и тимлида - хоть есть эти собесы, хоть нету их.
В итоге - по деньгам в кармане стейкхолдеров - в большинстве случаев выгоднее ничего не делать, а дать человеку уйти и заменить его на кого-то другого. Исключения бывают - но в реальной жизни их мало (потому что нормальный менеджер и тимлид обязаны профилактировать bus-factor).
akamap
10.04.2026 06:49никто не прибегает требовать доплату за временное увеличение объема работы.
а вы в курсе про ст. 60.2, ст. 151 ТК РФ ?
ruomserg
10.04.2026 06:49Все в курсе - только нигде я не видел чтобы при болезни, отпуске, или вакантной должности в штатном расписании - остальным сотрудникам давали доп. соглашение об увеличении объема работы и доплату. Повторяю - НИГДЕ. Ни при развитом социализме, ни при развитом капитализме... Правовая норма есть, а культурной нормы нет. Чем собственники и менеджмент и пользуются.
Emulyator
10.04.2026 06:49На счет особого доп. соглашения не знаю, а по внутреннему приказу организации у нас сотрудники регулярно получают 30-50% прибавки от оклада отсутствующего.
Emulyator
10.04.2026 06:49Когда из нашей конторы сам ушел один из "эффективных менеджеров" (да, так бывает, на другую работу), а на его место никто не пришел, то ничего не поменялось в плане доходов фирмы, а нагрузка на сотрудников где-то даже снизилась. Если бы его ЗП разделили между его подчиненными, было бы вообще хорошо. Я так то не против менеджеров , поэтому второй пример, когда ушел на более высокую з.п. обычный весьма ответственный старательный сотрудник, который делал отчеты разного рода для начальства и еще по мелочи. Его тоже не заменили и тоже хуже не стало. Поэтому ответ на вопрос "А вы по каким признакам определяете, что разработчика пора удерживать?" у меня такой... Если в фирме начинает расти число работников делающих ненужную работу, или создающие видимость работы, то сотрудники(и ненужные и нужные) ощущают дискомфорт, работая в такой организации и подумывают о другом месте работы. Высокие ЗП наверное удержат и первых и вторых, но дискомфорт не уберут. А при невысоких ЗП увольнений не избежать.
urvanov
Теперь у нас ещё один дашборд с метриками. А разработчики как уходили, так и продолжают уходить. Потому что никто не додумался актуализировать зарплату до рыночной, а у долгожителей на проекте делать зарплату выше рыночной хотя бы в полтора раза, чтобы даже мыслей не было о том, что можно уйти.
RTFM13
В принципе, случаи когда поднимают зп ценным сотрудникам существуют. Но это надо торговаться, а это не каждый интроверт, коих много среди разрабов, любит делать.
А все эти пульсопросы... на них разве не отвечают так чтобы от тебя отстали? Или перед увольнением работник начинает давать честные ответы? Ну так значит у него уже офер на руках.
AlekseyPraskovin
Ышшо чего! Это они что, больше руководителей что ли должны получать? Это не шутка, если что: во многих компаниях стоит негласный запрет на оклад выше чем у директоров. Которые его себе ставили в 2000-лохматом-году и не парились с индексацией, потому что живут с другого)
eldog
Деньги - прекрасный демотиватор, но плохой мотиватор. Очень часто проблема не в зарплате, и уходят не потому что мало. И даже если поднимут зарплату выше рынка, запрут в золотую клетку, человек продолжит искать новое место, просто - с такими же деньгами.
kalombo
Так может сначала поднять зарплату выше рынка, а потом если всё равно уходят, то и решать проблему? :) Как минимум сократите уход тех, кто уходит из-за зарплаты.
eldog
Кто ж спорит. За труд нужно платить столько, сколько он стоит. Иначе см. про демотиватор.