Даже самый хороший программист может оказаться далеко не лучшим сотрудником. Несмотря на то, что сейчас айтишники любого уровня вполне востребованы, и на рынке огромное количество вакансий, периодически увольняют и ведущих разработчиков, и даже самых «крутых» senior’ов. Давайте разберемся в основных причинах.
«Почивает на лаврах»
Об этой проблеме пишут очень много, и все равно ситуация повторяется из раза в раз. Разработчик достигает определенного уровня знаний и останавливается в развитии. Он – прекрасный специалист, великолепно работает с определенным перечнем инструментов. Но любой проект постоянно развивается. И, как итог, разработчик перестает «тянуть».
Какое-то время таких людей оставляют в команде за прошлые заслуги, но ограничивают их работу поддержкой старых версий и тому подобными задачами. Но если разработчик вовремя не спохватится и не поймет, почему он отстранен от самых интересных направлений, рано или поздно его придется уволить.
Увлечение кодом и «самоуправство»
Нередко разработчики не «вписываются» в команду просто потому, что занимаются «исправлением кода» там, где это не нужно, потому что с их точки зрения, они исправляли «косяки» в коде и добивались эффективности.
Приведем пример. В компанию принимают мидл-разработчика. Он прекрасно проходит собеседование и показывает хороший уровень знаний при тестировании. Но далее начинаются сюрпризы.
Как новичку в команде, программисту ставят простую задачу. Нужно дописать несколько строк кода, который будет после определенных действий отправлять пользователю письмо-уведомление. При этом дают примеры готовых фрагментов. И ждут быстрых результатов, ведь задача простейшая и поставлена больше с целью знакомства нового человека с проектом.
Но проходит день, два, а результата нет. В итоге выясняется, что разработчик по своей инициативе исправил большой кусок кода, потому что «так будет лучше». В результате появились конфликты на программном уровне, пользователи начали жаловаться на баги.
Один раз такой подход могут простить, но в случае повторений «излишней инициативы» с программистом расстаются в сжатые сроки. Человек тратит массу времени на работу, которая никому не нужна в ущерб поставленной задаче. Кроме того, любые несогласованные исправления могут привести к багам.
Безответственность и саботаж
Если в примере выше программист проявлял ненужную инициативу, пусть даже из самых лучших побуждений, то здесь ситуация обратная. Разработчик выполняет поставленные задачи в последний момент или даже с опозданием, код явно написан «на коленке», тестирование либо не проводилось совсем, либо ограничилось выявлением самых явных багов.
Понятно, что все мы – люди. Иногда такое случается из-за семейных проблем или плохого самочувствия. Но если ситуация повторяется из раза в раз, руководитель проекта оказывается перед выбором: терять ценное время на исправление багов после безответственного разработчика или найти другого сотрудника.
Пример истории из реальной жизни. В стартапе работал подобный специалист. Уровень знаний у человека был высоким, но желания работать не наблюдалось. По качеству кода было понятно, что большую часть времени, выделенного на работу, он занимался чем угодно, кроме решения задачи, а в последний момент быстро что-то написал.
Некоторое время с ним мирились, пытались мотивировать и убеждать изменить свой подход. Последней «каплей» стала ситуация, когда человек написал кусок кода с критическим «багом». И без тестирования добавил его на сервер. Ошибка оказалась серьезная, исправить ее нужно было срочно. Руководитель звонит программисту, обрисовывает ситуацию. И слышит ответ – «рабочий день уже окончен, завтра приду и разберусь».
Неумение работать в команде
Эта проблема знакома практически всем, кто пытался хотя бы раз собрать коллектив разработчиков для создания проекта. Есть люди, способные взаимодействовать с другими и работать под общим руководством. А есть – одиночки, которым лучше всего оставаться самозанятыми или уходить на руководящую должность.
Особенно ярко эти личностные качества проявляются, если человек достиг уровня senior. Он уже не чувствует потребности в помощи и наставничестве, наоборот, сам вполне способен учить других. И если такой разработчик уверен, что он – прав и знает лучше, проект может завершиться крайне печально.
Вот основные варианты действий таких разработчиков:
- Человек не считает нужным прислушиваться к проект-менеджеру, а берет из общего списка те задачи, которые ему писать интереснее. В результате на одних участках работа дублируется, на других – простаивает, что приводит к хаосу и срыву сроков.
- Разработчик считает себя «слишком крутым», чтобы посещать своевременно планерки и совещания. Вроде бы, не самый страшный грех. Но подобное демонстративное поведение вносит диссонанс в работу всего коллектива, снижает уровень дисциплины. Кроме того, приходится тратить дополнительное время, чтобы оповестить «прогульщика» о важных решениях.
- Программист постоянно спорит с проект-менеджером о методах реализации проекта, критикует выбранные решения, может даже в присутствии заказчика начать рассказывать, какой «бездарный вариант» был принят к реализации. В результате снижается дисциплина, затягиваются сроки, а иногда и сам проект срывается.
В некоторых случаях такие разработчики оказываются «не у дел» после успешного старта проекта, что по-человечески, конечно обидно. Причина в том, что на начальном этапе программист работал самостоятельно или с 2-3 помощниками. Дальше по мере развития штат разработчиков увеличивался. Программист стал просто одним из команды. Но приспособиться к такому положению дел не смог.
В принципе, можно было предложить человеку на определенном этапе должность руководителя проекта. Но не все способны сменить программирование на бюрократию и организацию работы людей, а многие и сами не хотят такого карьерного роста. И тогда приходится расставаться даже с тем, кто стоял у истоков и стал автором успешных решений.
Негативизм и токсичность
Проблема, с которой сталкиваются время от времени практически в любом рабочем коллективе, независимо от направления деятельности. В числе сотрудников появляется человек, который может быть прекрасным специалистом, но его поведение и стиль общения приводят к постоянным конфликтам и негативно влияют на настроения в коллективе.
Скорей всего, вы тоже знакомы с такими людьми:
- Постоянно жалуются на жизнь, у них всегда все плохо.
- Любые перемены воспринимают с недовольством, предрекают, что «теперь-то уж точно все будет совсем плохо».
- Нетерпимы к проявлениям критики, воспринимают любые слова крайне эмоционально, даже если критика будет в мягкой форме и по делу.
- Других людей за малейший промах и ошибку критикуют в крайне резкой форме, не стесняясь в выражениях, нередко переходят на личности.
- Постоянно обсуждают отношения в коллективе, отношение руководства или заказчиков к сотрудникам в негативной форме.
- Становятся источниками межличностных конфликтов, сплетничают, провоцируют обсуждение личных дел других сотрудников и т.д.
Любое сочетание описанных выше вариантов поведения негативно влияет на климат в коллективе. Все это негативно влияет на результат работы. Потому, если такого специалиста невозможно как-то «отделить» от коллектива, например, перевести на работу удаленно, то, несмотря на прекрасные профессиональные навыки, с ними приходится расставаться.
Неорганизованность при удаленной работе
В сфере IT удаленное сотрудничество очень распространено. С одной стороны – это очень удобно и выгодно, и для заказчиков, и для руководителей проекта, и для самих программистов. С другой стороны, удаленная работа требует определенных навыков самодисциплины и умения планировать рабочий график самостоятельно.
К сожалению, далеко не все люди способны эффективно работать вне офиса и постоянного контроля со стороны руководства. Итог сходен с вариантом саботажа – постоянные проблемы со сроками, низкое качество кода, написанного в спешке и т.д.
Если удаленный сотрудник регулярно пропадает со связи, постоянно затягивает решение поставленных задач, регулярно рассказывает о каких-то форс-мажорах, с ним расстаются, несмотря ни на какие таланты.
Как избежать увольнения
Все люди – разные, а потому универсальных рецептов не существует. Но все же, по итогам описанных выше ситуаций, можно выделить основные правила:
- Никогда не останавливайтесь в развитии. Учиться нужно всегда.
- Внимательно относитесь к поставленным задачам, работайте на результат.
- Инициатива всегда должна быть уместной и согласованной с руководством, ваш код – это только часть проекта, всегда нужно об этом помнить.
- Объективно оценивайте свои личные качества. Если общение с людьми для вас – не самый комфортный вариант, выбирайте удаленную работу. Если наоборот, без офиса и коллектива работа не идет, а домашние дела оказываются важнее, ищите работу в «реале».
- Всегда оценивайте проект с точки зрения личного комфорта на этапе испытательного срока. Этот период нужен не только работодателю, но и сотруднику, чтобы оценить, сможете ли вы эффективно работать в этом проекте и с этим коллективом. Если сотрудничество вызывает негатив, лучше от него отказаться как можно раньше. Берегите нервы и не оставляйте плохих воспоминаний у работодателей.
- Относитесь к своей карьере разумно. Не соглашайтесь на долговременное сотрудничество на должности, которую вы явно уже «переросли». Скучные задачи и постоянно тлеющее раздражение от понимания, что вы могли бы сделать все иначе и даже лучше, негативно скажутся на результате.
В любом случае, помните, что работа должна не только приносить прибыль, но и просто нравиться. Оценивайте все – проект, оплату, уровень ответственности и сложности задач, отношения в коллективе. В результате вы получите работу, которую будете ценить, а работодатель – мотивированного сотрудника. И не бойтесь менять работу, если что-то пойдет не так. Не забывайте, что программисты востребованы на рынке. А в период поиска работы всегда можно «подхалтурить» фрилансом.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
уволен