За что еще увольняют программистов
Три года назад мы уже разбирались, за что увольняют программистов. Вакансий на IT-рынке больше, чем профессионалов, поэтому увольнения по инициативе компании случаются не часто. Но иногда приходится прощаться даже с Senior разработчиками.
Мы попросили технических специалистов, которые ответственны за наём и увольнение в своих компаниях, рассказать, из-за чего им приходилось увольнять своих коллег.
Токсичность, отсутствие мотивации и негативизм
Дмитрий Абрамов, Delivery Director, Deputy Head of Kyiv R&D Center в DataArt
Я опишу три случая из личной практики, которые мне запомнились.
Первый произошел, когда я работал СТО в большой розничной компании с развитым IT — я уволил двоих токсичных людей из своей команды. До меня доходили жалобы о том, что с ними постоянно случаются какие-то неприятные диалоги, что они много жалуются на жизнь, но ситуация в целом долго оставалась под контролем. Потом люди из их отдела пришли с жалобами на то, что эти двое прямо обвиняют их в нечестной работе и заговорах.
Поскольку я знал, что обвинения безосновательны, я решил уволить обоих в один день. Они были Senior разработчиками, работали в команде поддержки платформы, на которой держалась вся система управления розницей. Но я понял, что тянуть нет никакого смысла. Негатив дошел до того уровня, где лечить намного дороже, чем просто отрезать.
Я позвал их к себе, поблагодарил за совместную работу и сказал, что обстановка, к сожалению, такова, что нам пора расстаться. Я честно признался, что меня не устраивает климат в коллективе, а климатом этим я очень дорожу, и этого достаточно, чтобы их уволить. Коллектив был мне благодарен, а потерю бойцов мы перенесли неплохо — довольно быстро заменили их новыми людьми с рынка. Обстановка сильно улучшилась, и никакой потери производительности мы не заметили.
Во второй раз мне пришлось уволить опытного Senior разработчика. Я бы даже сказал, эксперта. К тому времени я уже работал проектным менеджером в аутсорсинге. А расстались мы с этим человеком, потому что он попросту не умел работать. У него были собственные инженерные приоритеты, ему было интересно заниматься сложными техническими проблемами. Когда его желания не совпадали с проектными задачами, последние он просто саботировал. Нужно пилить какой-нибудь модуль, деливерить релиз, но у этого человека есть мысли поинтереснее, а скучной рутиной он заниматься не будет.
Мы много раз с ним об этом говорили, он внимательно слушал, слышал и на какое-то время исправлялся, но все возвращалось на круги своя. К тому же толерантность к моим методам лечения у него возрастала, эффект от беседы с каждым разом становился все слабее.
Когда мы вышли на шестой круг, я понял, что смысла в этом нет. Пришлось объяснить, что мы не можем выделить человека для работы его личным мотиватором, и человеку, который не может найти себя в команде, стоит поискать другой проект. Через некоторое время он довольно быстро покинул и компанию: с таким отношением к работе его не стали брать и на другие проекты.
Третий кейс похож на оба, приведенных выше. Есть опытный Senior разработчик — 15 лет в бизнесе и не первый год в компании. Это довольно угрюмый тип, склонный критиковать абсолютно все, с чем сталкивается. Причем критикует это в такой едкой и непримиримой манере, что коллеги не хотят с ним ничего обсуждать. Все разговоры сводятся к тому, что все плохо и лучше никогда не будет, заказчики не умеют структурно мыслить и вообще работать, нас не уважают, как и мы не уважаем друг друга, да и процессы у нас не выстроены.
Этот негативный взгляд на мир на работу самого программиста не особенно влияет, но сильно портит климат в команде и заметен заказчику. Этот человек сменил несколько проектов. Когда его просили перестать бурчать, отвечал, что понимает проблему, и какое-то время молчал. Но потом его опять прорывало. В конце концов работать с ним не хотел никто.
В плане работы он делал все, что нужно. Был нормальным разработчиком — бывают лучше, бывают хуже. Будь он суперзвездой, может быть, его негативизм научились бы терпеть. Но найти специалиста того же уровня, лишенного этой отрицательной черты, было не так уж сложно. Значит, мучиться было ни к чему.
Последней каплей обычно становится осознание того, что мы уже несколько раз пытались решить проблему. Говорили с человеком, он вроде как пытался исправиться. Но нам приходиться давать ему шанс снова и снова. Примерно на пятом витке становится ясно, что время мы тратим впустую.
Плохой код и срыв сроков
Дмитрий Родин, CTO & TechLead в Evergreen
Основная причина увольнения любых сотрудников — это когда после нескольких «китайских» предупреждений человек упорно продолжает вести себя по-прежнему. Это демонстрирует отношение человека к работе, его нежелание или неспособность с ней справиться.
Среди разработчиков основной косяк — код, с которым другой программист не может работать.
А также — срыв сроков выполнения.
Тут действует правило РПУ:
- «Р» — рекомендуем, что исправить;
- «П» — делаем предупреждение;
- «У» — если не помогло, увольняем.
Остальные причины субъективны и больше зависят от самого человека. Вообще, косяков бывает гораздо больше, но мы стараемся дать шанс всем, кто уже с нами. Но эффективность команды важнее привязанностей и личных симпатий к человеку, на которого потрачено много времени и сил в обучении. Бывает обидно кого-то увольнять, особенно если человек отличный, но мы это делаем, когда он не эффективен как сотрудник.
Например, был у нас один Back-end Laravel разработчик. Он позиционировал себя как Middle. Мы делали проект, в административной панели которого находился дашборд с заказами. Однажды клиент пожаловался на ее производительность. Было непонятно, почему все тормозит, если все данные подтягиваются с одной модели.
Мы провели ревью кода, и оказалось:
- Разработчик, используя грабли, подключил datatable без органичной имплементации с моделью Laravel. Под это есть готовые решения, но он зачем-то прикрутил свой «велосипед».
- Он отдавал на Front-end все заказы из базы: там их от 10K, а постраничность реализована уже на фронте. Если бы он порционно реализовал server-side отдачу данных, тогда бы все летало.
После этого мы просмотрели все, что реализовал этот разработчик, и поняли, что должны его уволить. Ведь исправлять за ним нужно было много.
Неумение работать в команде при удаленной работе
Павел Никиточкин, CTO в JetThoughts
Мы работаем удаленно и изначально стараемся нанимать сотрудников, которым не чужды наши ценности. Поэтому увольнения случаются редко.
Был случай, когда наша команда при слиянии с командой клиента приняла человека на проект. При совместной работе оказалось, что его уровень знаний не соответствует тому, на который он был оценен клиентом ранее. Мы откровенно говорили об этом, и из-за несоответствия его финансовых ожиданий к нашими требованиям, он ушел с проекта.
Единственный случай, когда мы сами уволили сотрудника, был основан на подрыве доверия и лжи с его стороны. Это был Lead Ruby on Rails Engineer, который отвечал за подготовку продукта к выпуску. Для решения этой задачи ему были предоставлены полная свобода и гибкость — ответственность за решения была достаточно серьезной.
Прошло некоторое время, достаточное для продвижений по задачам, но никакой обратной связи по выполнению или проблемам от разработчика не поступало. Приближался дедлайн, мы хотели понять, что происходит. По классике жанра, исполнитель оказался недоступен и не отвечал на сообщения и звонки.
Спустя неделю человек объявился и представил много мелких правок, сгенерированные автоматическим инструментарием, которые отсутствовали в списке необходимых. Это и послужило переломным моментом.
Позже подобные вещи с его стороны все чаще стали замечать и другие члены команды. После очередной ретроспективы команда отказалась продолжать с ним работать. Это и стало причиной увольнения.
В качестве вывода: делайте максимум для того, чтобы обойтись без увольнений. Правильно описывайте вакансии, ищите людей с высокой мотивацией, уделяйте внимание адаптации и обратной связи, менторству. Человек, пришедший на новое место, должен видеть четкие задачи и понимать, как они связаны с целями компании. Регулярно обсуждайте прогресс и процессы, какимы бы высококлассным не были специалисты.
Безынициативность, безответственность, саботаж работы
Дмитрий Пискарёв, CEO (ex-CTO) Netpeak Agency
Для нас увольнение программистов — исключительная мера, которая происходила в компании всего пару раз. В первую очередь я всегда решал проблемы другими путями: сменой позиции, предложением альтернатив внутри компании и в других компаниях группы, реформами. Но, когда и это не помогает, то остается только увольнение.
За что мы увольняем? Ничего необычного: за безынициативность, безответственность, саботаж работы.
Мой пример в прошлом году как раз был связан с последним пунктом. Сотрудник на одной из senior-позиций начал демонстративно игнорировать все текущие рабочие процессы и блокировать любые идеи по развитию продукта.
Например, была ситуация, когда он открыто начал пропускать daily scrum и ретроспективы. Объяснял свое поведение тем, что и так всё знает, при этом демотивируя всю команду. Иногда это приобретало совсем причудливые формы — он мог брать задачи из бэклога, которые ему интересны, не говорить об этом остальным и создавать конфликтные куски кода.
Я пытался решить проблему в течение года разными способами: встречи в формате one-on-one, смена направлений работы этого специалиста, попытка дистанцировать его от команды. В итоге ничего из перечисленного не помогло. Сейчас я понимаю, что не надо было так долго тянуть и давать третий, четвертый и пятый шансы.
Уверен, что наилучший способ развития отдела разработчиков — растить его так, чтобы участники команды могли самостоятельно замечать и удалять тех сотрудников, кто своим отношением к работе не соответствует целям и ценностям коллектива.
