За что увольняют программистов
Хороший программист — это не обязательно хороший сотрудник. И как бы ни была сейчас ценна профессия айтишника, даже талантливых специалистов иногда увольняют с работы. Давайте разберемся, почему.
Код ради кода
«Наняли человека — хорошо прошел собеседование. Миддл. Сам меня нашел через DOU», — рассказывает Владимир Железняк, СТО небольшой продуктовой компании FundSeeder.
Через неделю ознакомления/работы новому сотруднику дали задачу — дописать пару строчек («отправить письмо по действию пользователя, см. пример, как мы это делаем вот тут»). В результате оказалось, что он переписал много старого кода, подтянул пачку новых библиотек.
По мнению руководства, для миддла на второй неделе работы в большом проекте — такое поведение несколько неожиданно. Когда выяснили ситуацию, оказалось, что этот программист полагал, что его наняли на рефакторинг проекта и внедрение лучших практик. Тогда ему объяснили, что о рефакторинге можно будет поговорить спустя несколько месяцев, когда он в достаточной мере поймет проект, а пока от него требуется просто выполнение задач по разработке.
В итоге эту задачу с отправкой письма возвращали на доработку два раза — и каждый раз там в коде было нечто очень неожиданное — новые директории, новый API и т.д. Это всё хорошо — но тогда, когда оно действительно нужно. Часто решить проблему можно намного проще и менее затратным способом — стоит только вникнуть и разобраться.
Чуть позже возник еще один случай — на двухнедельном Iteration Review подняли проблему, что есть задержка в несколько дней между запросом от пользователя и ответом саппорта. Новый сотрудник начал предлагать решения, какие тулзы и сервисы можно прикрутить. Но это всё уже и так было. Выяснили, что проблема появилась из-за неверного назначения ответственного сотрудника в сервисах. А разработчик бросился предлагать решения, не понимая проблемы.
Сотрудника уволили на третьей неделе работы — за непонимание связи между написанием кода и бизнес-потребностями проекта.
А нам всё равно
О следующем случае рассказал Алексей Колупаев, СТО стартапа MeinFernbus. Когда искали программиста на одну из вакансий, им подвернулся кандидат, который не знал нужного фреймворка. Тогда ему предложили написать что-то на этом фреймворке для себя, придумать и реализовать простенький проект. В 90% случаев соискатели после такого исчезают, но этот разработчик выполнил задание, показал нормальный результат, и его приняли.
Со временем, когда спала повышенная работоспособность, свойственная только что нанятым сотрудникам, оказалось, что новый сотрудник регулярно косячит, но не видит в этом какого-то экстраординарного явления, takes it easy. В принципе, человеку свойственно ошибаться, еще и новому. Но неприятные моменты накапливались. Выводы не делались.
Компания в то время была стартапом на очень ранней фазе, но уже добились определенных успехов, темп был очень высоким. В один из поздних вечерних деплоев на продакшн попал очень неприятный баг, который случался в каждом букинге. Откат деплоя не помог. Букинги с ошибкой поступали. Через два часа выяснилось, что баг проистекает из неправильной конфигурации на сервере. Нового сотрудника в офисе уже не было, а по телефону он сказал, что уже вечер, он отдыхает, утром придет в офис, тогда и разберется.
После этого компания прервала его испытательный срок.
Сам себе на уме
Этот пункт посвящен непроработанным soft skills и навыкам личной эффективности.
Алексей Коваль, СТО проекта UA2WEB, сталкивался с ситуаций, когда проект перерос одного человека, а этот человек оказывается неспособным перестроиться с работы в одиночку на труд в команде. Выглядит это так: проект начинает один человек, проект растёт, неизбежным становиться участие большего количества исполнителей, менеджеров, а человек не может интегрироваться, не может или не желает общаться с другими людьми, принимать коллективные решения. Возможно, он пишет неплохой код, его работа как раз и привела к успеху проекта, но на этапе присоединения других участников его приходится увольнять
Но, по словам Алексея, первая по количеству увольнений статья — это некачественная работа, когда человек, обладая знаниями и умениями, не выполняет задание из-за проблем с личной дисциплиной и организованностью.
Еще один кейс, о котором стоит упомянуть — когда специалист не желает выстраивать отношения с менеджментом компании. Такой случай был в практике Насти Шафрановой, hr-менеджера Timecode. Разработчик, хороший технический специалист, полностью игнорировал рабочие миттинги, не предупреждал, что у него не получается присутствовать. Пришлось с ним попрощаться после испытательного срока.
Похожая ситуация — некорректное поведение с заказчиком. По словам Сергея Немчинского, тимлида в IntroPro, если разговор об аутсорсе, то за подобные промахи людей увольняют в 24 часа. Слишком уж аутсорс зависит от заказчика. Жестоко, но вариантов нет — найти нового разработчика существенно проще, чем заказчика
P.S. Есть еще одна категория fire-листа — невыполнение рабочих обязанностей. Бывает, что человек старается, а результатов мало. Но тут, пожалуй, и так всё понятно.
