Увольнять или терпеть? Что делать, если сильный разработчик начинает факапить

Увольнение хорошего разработчика – это серьёзная проблема для компании. Это может поставить под угрозу реализацию текущих проектов, затормозить работу целой команды, и в результате принести убытки и репутационные потери. Но и удерживать специалиста «любой ценой» – тоже не лучший вариант. О том, как поступить руководителю компании, если сильный разработчик начинает факапить, в своей авторской колонке для портала Biz360.ru рассказал технический директор группы компаний X-Com Андрей Шишкин.

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

В таких компаниях, как правило, малая текучка кадров, поэтому и сильного HR-бренда нет. Поиск каждого нового участника команды – это долго, неудобно и рискованно, ведь впереди ещё onboarding (адаптация) новенького. Да и размер компании не позволяет на равных конкурировать за кадры с крупными IT-компаниями.

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

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

Итак, ваша команда делает некий проект. Вы на этот проект возлагаете серьёзные надежды в получении некоторого value. Подтянули к проекту другие ресурсы: маркетинг, юристов, логистов, бухгалтеров и т.д. (в зависимости от проекта). Поначалу всё идет хорошо, но в какой-то момент вы начинаете замечать, что ваш ключевой программист «изменился»: затягивает сроки, неохотно идёт на контакт, принимает какие-то полумеры, публикует плохо работающие части кода, часто пропускает встречи. Но при этом в личном общении он утверждает, что с ним всё в порядке, он готов дальше работать и проект сделает в срок, он просто «устал. Растёт риск завалить проект.

Дилемма: надеяться на него и верить в чудо, или быстро его заменить? Решение принять крайне сложно, ведь увольнять – это как резать по живому. Больно. Однако важно распознать «гангрену» как можно раньше и купировать её, чем надеяться, что не придется ампутировать целое направление.

Разберем ситуацию со стороны компании. 

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

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

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

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

«Задвинуть» на второй план

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

Отправить в отпуск 

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

Изменить финансовую мотивацию 

Изменить финансовую часть так, чтобы его доход был явно привязан к успеху проекта. Не стоит забывать про пряник. Просто перевести его текущий оклад в некий KPI не сработает, он скорее всего уволится. А вот дать ему, например, 50% к окладу за сдачу проекта в срок – это хорошее решение. При этом за срыв проекта ввести штрафы. (отмечу, что понятие «штраф» в Трудовом кодексе РФ не предусмотрено, но каждый бухгалтер знает, как оформляются подобные вычеты). 

Дать другую должность 

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

Произвести замену 

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

Предложить увольнение 

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

Оставить без «будущего» 

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

Предложить мягкое увольнение с «парашютом» 

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

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

• Вводить посуточный или другой детальный контроль действий. Это лишь усугубит ситуацию. 

• Оставлять всё как есть. В данном случае поговорка «время лечит» не сработает. 
  
  

• Штрафовать или менять схему оплаты труда в негативную сторону, то есть применять наказание.
  
  

• Заливать проблему деньгами. Программисты почти всегда работают скорее за интерес, а не за деньги. Деньги – это временная штука, уже через 2-3 месяца запал у программиста начнёт спадать. Плюс это может привести к общему дисбалансу зарплат у всей команды, что негативно отразится на всех. /
  
  

• Ругаться с программистом и заставлять его работать. Это приведёт лишь к плохо написанному проекту в стиле «и так сойдёт». 
  
  

• Увольнять в одностороннем порядке, без попытки решить ситуацию. 
  
  

• В одностороннем порядке замещать программиста другими специалистами. 
  
  

• Пытаться «выбить» из него причину падения производительности. Скорее всего он что-то соврёт, вы сделаете неверные выводы – и проблему не исправите. 

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

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

Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал, страницу в «ВКонтакте» и канал на «Яндекс.Дзен».
biz360