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

Мы обсудили с Натальей Ёркиной, тимлидом из сервиса онлайн-бронирования отелей Ostrovok.ru, за что чаще всего увольняют разработчиков и какие ошибки допускаются при подборе сотрудников.

Увольнения на испытательном сроке

По моему опыту, вероятность увольнения на испытательном сроке равна 1:10. За шесть лет в Ostrovok.ru в моей команде испытательный срок не прошли двое из 20 человек.

Причины могут быть разными.

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

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

Взяли разработчика, который пишет на JavaScript, знает бэкенд и разбирается в алгоритмах. Но оказалось, что верстать он не умеет: переучивался с бэкенда, JS выучил, а верстать не научился. А мы на собеседовании вёрстку и не проверяли — предполагали, что если фронтендер, то автоматически умеет верстать. Отправили на курсы за счёт компании и переучили.

Не совпали по культурному коду

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

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

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

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

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

Увольнение за рабочие споры

Этот вопрос тоже сильно зависит от внутренней культуры. За шесть лет в Ostrovok.ru в моей команде не было конфликтов на такой почве.Когда я не согласна с тестировщиком, мы идём в общий чат и разбираем проблему вместе с командой. Если есть культура договорённостей, то таких конфликтов не возникает.

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

Бывают и конфликты между командами, например, разработка выступает за эффективность, а бизнес — за эффектность. Тут важна готовность искать точки соприкосновения, прислушиваться к чужому мнению и доверять экспертизе. Не забывайте, что в интересах компании работают все, а не только вы.

Посмотрите другие статьи о работе

Увольнения за плохой код

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

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

Есть и совсем универсальные правила. Например, никто не пишет git push --force, всех предупреждают, что так делать не надо.

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

Сколько раз надо накосячить в одном и том же, чтобы быть уволенным?

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

По моему опыту, в среднем проводится пять бесед о том, что «так не пойдёт», и только потом происходит «похоже, мы не можем договориться».

Можно ли работать в нескольких местах сразу?

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

В моей команде мы свободно говорим на эту тему: открыто обсуждаем, кто какому проекту помогает, и делимся опытом.

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

Почему же всё-таки увольняют?

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

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

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