«За забором очередь»: почему замена разработчика обходится дороже, чем кажется

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

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

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

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

И почти сразу прилетает знакомое от руководителя: «Не нравится — уволим. За забором очередь».

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

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

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

Разработчик — это не строка в штатном расписании

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

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

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

«За забором очередь» не создаёт замену

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

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

Забота и удержание — это более выгодная стратегия

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

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

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

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

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

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

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

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

Что происходит после сокращений в реальных командах

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

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

Четыре вопроса перед сокращением

Для быстрой проверки команды удобно использовать модель GRPI Ричарда Бекхарда: цели, роли, процессы и отношения. Она помогает понять, где исправлять условия работы, а где проверять, справляется ли человек с ролью. Описание модели есть в рабочем материале INSEAD (PDF).

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

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

• Процессы. Есть порядок для сообщения о риске, разбора ошибки, передачи сервиса, хранения доступов и принятия решений.

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

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

Стресс разработчика — риск для прода

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

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

Выгорание — реальный профессиональный риск. ВОЗ включает его в МКБ-11 как явление, связанное с хроническим рабочим стрессом. Признаки — истощение, дистанцирование или цинизм по отношению к работе и падение профессиональной эффективности.

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

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

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

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

Психологическая надёжность — это не мягкость

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

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

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

Если собственник отвечает за результат, я бы шёл так:

1. Зафиксировать ожидаемый результат и критерии роли.

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

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

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

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

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

Последняя мысль

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

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

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

На чём основана эта позиция

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

• Richard Beckhard, GRPI framework, изложение в рабочем материале INSEAD The Leader’s Role in Building Effective Teams — о последовательной проверке целей, ролей, процессов и отношений в команде;

• R. Karasek, Job Demands, Job Decision Latitude, and Mental Strain — о сочетании высокой нагрузки и низкой свободы решений;

• A. Edmondson, Psychological Safety and Learning Behavior in Work Teams — о связи психологической безопасности с обучением и обсуждением ошибок;

• World Health Organization, Burn-out an occupational phenomenon — об определении выгорания в МКБ-11;

• A. Bakker, E. Demerouti, The Job Demands–Resources model — о соотношении требований и ресурсов работы.

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