13 ошибок за которые увольняют программистов 1с
Обновлено: 07.07.2024
Разработчик Джозеф Круз составил список причин, по которым программисты могут лишиться должности. Описанные случаи не совсем очевидны и к ним не относятся, например, увольнение из-за кражи, лжи в резюме или ошибки при найме. Автор уверен, что если исключить стандартные ситуации, то количество причин сводится всего к 13 пунктам. В восьми из них — причина в самом программисте, а еще в пяти — скорее, в плохом руководстве.
Плохой разработчик
1. Неспособность соблюдать дедлайны
Многие разработчики, несмотря на объем работы, стараются всегда искать идеальное решение задачи. Когда это приводит к задержке проекта, программиста увольняют. Из-за невозможности или неспособности вовремя разорвать трудовые отношения с таким сотрудником пострадало немало проектов.
2. Неспособность работать в команде
Некоторые разработчики не понимают, что времена «программиста-одиночки» закончились. Большинство проектов требуют совместной работы и взаимодействия между отделами. Те, кто не могут работать в команде, потому что якобы «знают все лучше всех», обречены на увольнение.
Это не касается программистов, которые стараются работать в команде, но им просто не хватает коммуникативных навыков и эмпатии. Взаимодействовать с такими сотрудниками проще, чем с эгоистами и «нарциссами».
3. Неспособность работать над продуктом из-за раздутого эго
Некоторые разработчики спорят с клиентами и дизайнерами продукта, потому что думают, что всегда лучше знают, что делать. Поэтому они просто не делают то, о чем их просят, или делают это неохотно.
4. Ущемление других сотрудников
Хороший руководитель не терпит такого поведения, особенно когда оно направлено против целого класса коллег, например, против женщин.
А если руководитель отдела не увольняет такого человека, то для HR вполне логично будет уволить обоих. Компания не может позволить себе наличия таких отношений внутри коллектива ни при каких обстоятельствах.
5. Неспособность идти в ногу со временем
Инструменты разработки быстро развиваются. Многие программисты используют для работы более одного языка, среды и платформы. Хорошо иметь сильные базовые знания, но также важно иметь возможность изучать новые технологии, которые могут быть полезны компании. Иначе при старте нового проекта с вами могут попрощаться.
6. Внедрение новых инструментов в компании без согласования
Это, как правило, не очень одобряется, даже если действия разработчика в итоге привели к положительным последствиям.
7. Поддержание плохой атмосферы в команде
Незрелость и непрофессиональное поведение часто становятся причиной увольнения. Если в команде есть человек, который движется не потому же курсу, что и компания, сроки разработки то и дело не будут соблюдаться, а конечный продукт будет неполным и некачественным.
8. Плохой код
Если кто-то продолжает делать ошибки и не проводит тестирование, затраты компании будут расти, особенно если клиент обнаружит ошибки.
В итоге вся команда, так или иначе, расплачивается за нерабочий продукт и теряет доверие.
Плохой босс
9. Неспособность управлять «пессимистами»
Многие программисты всегда и во всем видят отрицательную сторону, но, вероятно, именно поэтому отлично выявляют проблемы и критические точки. Такие разработчики очень ценны, поэтому руководитель обязан вывести их из пессимистичного состояния, чтобы они при этом не потеряли навыки обнаружения и устранения изъянов. Не все руководители знают, как работать с такими сотрудниками или в принципе как тянуть команду, поэтому предпочитают просто увольнять таких людей.
10. Использование неправильных метрик
Некоторые менеджеры не из IT-отраслей любят простые целевые показатели, чтобы измерять производительность разработчиков. По словам Джозефа Круза, из-за метрик, которые оценивали программистов по количеству написанных строк кода, он однажды чуть не уволил специалиста.
11. Эго и нарциссизм руководства
Разработчикам надо время от времени позволять решать задачи своим способом. Руководитель должен понимать, когда именно. Непонимание влечет за собой конфликты и увольнения. Управление разработчиком требует умения слушать и способности менять свое мнение.
12. Главное не что, а как
Некоторые управленцы больше уделяют внимания тому, как все делается, чем тому, что делается. Теряется видение ситуации, а сомнение в навыках разработчиков приводит к том, что они делают все по инструкции, отсюда конфликты и увольнения.
13. Неспособность доносить мысли
Продакт-менеджеры и руководители отделов должны пояснять команде бизнес-задачи. Тогда разработчики поймут реальные возможности и вычислят приблизительное время для реализации проекта. Когда ответственное лицо не может это сделать хорошо, наступает хаос. Кто виноват в таком случае? Обычно — самый уязвимый программист, а не ответственный.
Highload нужны авторы технических текстов. Вы наш человек, если разбираетесь в разработке, знаете языки программирования и умеете просто писать о сложном!
Откликнуться на вакансию можно здесь .
Как и весь письменный контент, будь то курсовая или статья, код не может быть легко создан. Каждый программист должен знать: чтобы написать приложение или отдельный модуль, необходимо придерживаться следующего порядка действий:
обдумать, исследовать, составить план, написать код, протестировать его, изменить то, что требует изменений.
В большинстве случаев ошибки, возникающие в коде начинающих программистов, являются результатом игнорирования вышеизложенного порядка действий. Если вы уже опытный разработчик, то, скорее всего, сможете вспомнить несколько моментов, когда сразу же без раздумий бросались писать код, только увидев задачу.
Это правило больше подходит для крупных задач, которые делятся на подзадачи. Ведь вряд ли вы будете обдумывать реализацию сортировки массива и составлять для неё план.
При написании кода важно учитывать его читабельность. Новички пренебрегают пробелами, полноценными и понятными именами переменных, предпочитая не обращать на эти вещи внимания и называть первую переменную “a”, вторую – “b” и т. д. Никогда не недооценивайте важность чистоты кода. В интернете есть множество статей, посвящённых кодстайлу для каждого из ЯП. Наши материалы по общим рекомендациям:
“Всегда думайте, будто парень, который будет поддерживать ваш код, – это жестокий психопат, который знает, где вы живёте.” – Джон Вудс.
Каждый программист, сталкивающийся с проблемой, пытается её решить, что естественно. Опытный программист знает, что нельзя применять к своему коду первое попавшееся решение. Необходимо сравнить его с остальными найденными и выбрать оптимальное. Новичок, скорее всего, использует первое попавшееся решение и даже не заметит, что, допустим, сложность алгоритма возрастёт, а соответственно возрастёт и время его выполнения.
Работа в качестве профессионального программиста заключается не в том, чтобы просто найти решение, а в том, чтобы выбрать самое простое и оптимальное. Код должен быть достаточно простым и для дальнейшей поддержки.
Как сказал Энтони Ричард Хоар, существует два принципа написания ПО:
- Первый: написать код настолько просто, что в нём не будет недостатков.
- Второй: сделать код настолько сложным, чтобы в нём нельзя было найти недостатки.
Ещё одна из самых распространённых ошибок заключается в том, что после выбора неоптимального решения новички не хотят расставаться с написанным кодом. Вероятно, это психологически связано с настроем “не бросать недоделанным”. Такое убеждение играет хорошую роль в большинстве видов деятельности, но не в отдельных случаях в программировании.
В тот момент, когда выбранное вами решение кажется сомнительным, вы должны подумать о том, чтобы избавиться от него и пересмотреть проблему. Такое решение проблемы будет благоприятным в любом случае, независимо от того, сколько времени и сил вы вложили в нерабочий код.
Быть может, у вас бывали случаи, когда вы тратили драгоценное время, пытаясь решить возникшую проблему (именно проблему, а не задачу), вместо того чтобы нагуглить решение.
Если вы не используете передовую технологию, скорее всего, кто-то другой уже сталкивался с вашей проблемой и нашёл для неё решение. Сохраните своё время и просто погуглите. Возможно, то, что вы считаете проблемой, на самом деле ею не является, и вам не надо ничего исправлять.
Однако если вы новичок, читающий эту статью, то будьте осторожны с этим пунктом. Большинство из начинающих грешит копированием чужого кода без понимания. Даже если этот код решает вашу проблему, вы никогда не должны использовать его без полного понимания.
При подготовке к собеседованию начинающие программисты уделяют достаточно времени алгоритмам. Если вы знаете множество структур данных и умеете их применять, для работодателя это явно будет плюсом. Однако этого бывает недостаточно. Важным моментом является “уместность” применения этих структур.
Вот два небольших примера:
Использование списков (массивов) вместо хешей (объектов) для управления записями.
Да, для управления списком записей рекомендуется использовать хеш. Хоть это правило больше подходит для случая с большим количеством данных, лучше использовать его постоянно. Почему так? Потому что при поиске записей с помощью идентификаторов, хеши гораздо быстрее списков.
Неприменение стеков.
При написании кода, требующего рекурсии, всегда возникает соблазн использовать простые рекурсивные функции. Как правило, рекурсивный код трудно оптимизировать, особенно в однопоточной среде. Новички зачастую игнорируют альтернативу рекурсивных функций – стековую структуру. Можно добавлять вызовы функций в стек и доставать их, когда нужно пройтись по вызовам в обратном порядке.
Обычно под словом “рефакторинг” подразумевается улучшение кода для более ясного понимания и оптимизации. Однако не все новички умеют улучшать читабельность своего кода.
Например, сделать проект более грязным может дублирующийся код. Вместо написания функции с необходимыми параметрами, новички обычно просто копипастят раздел кода, чтобы изменить одну-единственную строчку; объясняют они это “введением нового функционала”. Если вы выбираете стул, то согласитесь, что рациональнее купить один регулируемый по высоте, вместо десяти разной высоты.
Есть один способ избежать комментариев и сделать код более понятным – заменять комментарии на очевидно заданные элементы.
Вместо следующего кода:
можно написать такой:
Одно только использование понятных имён для функций делает большинство комментариев ненужными. Комментарии нужны тогда, когда нужно объяснить, почему данный код находится здесь, вместо того чтобы объяснять, что именно делает этот код.
Если вам нужно написать пояснения к коду, не пишите об очевидных вещах. Ниже пример кода, бесполезные комментарии в котором создают лишний шум:
Одна из самых распространённых ошибок. Скорее всего, если вы не пишете тесты, то проверяете код вручную. В случае создания веб-приложения, вы, наверняка, обновляете приложение после нескольких написанных строк кода. В таком тестировании нет ничего плохого. Однако сложный код всё-таки стоит проверять автоматическим способом. Обычно пишется скрипт, который выполняет определённые действия после добавления n-ого количества строк кода в проект. Чтобы не забывать тестировать приложение после каждого внесённого изменения, используйте компьютер.
"Преждевременная оптимизация – корень всех зол (как минимум, большей их части) в программировании." – Дональд Кнут, 1974.
Следует помнить: если вы не можете обозначить проблемы оптимизации в вашем коде, не пытайтесь оптимизировать его.
Безусловно, существуют способы оптимизации, которые вы должны применять практически во всех случаях. Например, в Node.js крайне важно, чтобы вы не переполнили цикл событий или не блокировали стек вызовов.
Главное, не переборщить с оптимизацией. То, что по-вашему может положительно влиять на производительность, может стать источником новых неожиданных проблем.
Опытный разработчик представляет себе то, что нужно пользователям. Он думает о том, как облегчить пользователю работу с приложением и упростить доступ к тем или иным функциям.
Этот момент довольно спорный, потому что изобретать колесо иногда полезно. Такой способ помогает лучше понять алгоритм/структуру/функцию и, в случае чего, реализовать собственный алгоритм/структуру/функцию, но, например, с расширенным функционалом.
С другой стороны, если вам нужно “обычное колесо”, которое не требует никакого дополнительного функционала/оптимизации, не изобретайте его повторно. Просто используйте то, что написано уже до вас. Не тратьте своё время на изобретение лучшего “обычного колеса”. Постарайтесь пользоваться “колёсами” с открытым исходным кодом, чтобы их можно было легко отлаживать, добавлять функционал и заменять при необходимости.
Один из признаков начинающего программиста – восприятие code review как осуждение, критику. Он недоволен этой критикой, не ценит её или даже боится. Это в корне неправильное отношение к ревью. Если вы так себя чувствуйте, убедительно рекомендуем пересмотреть и изменить своё отношение. Смотрите на каждое ревью как на обучение, возможность узнать что-то новое. Самое главное, благодарите своих рецензентов, когда они вас чему-то учат. Большинство из них поделится с вами опытом, который, возможно, упростит вашу деятельность и положительно скажется на продуктивности.
После статьи нуралиева хочу поделиться своими мыслями!
Для молодого специалиста 1С очень много радужных перспектив, это быстрый старт и высокая зарплата почти в первый год в профессии.
Но, подумайте, вот вам уже 40 и программистом вас брать захочет одна компания из 100, даже если аы супер профи. Почему?
Сделал эксперимент, создал вакансию написал, год рождения, хороший опыт в 1С и среднюю ЗП (100 для хорошего спеца неплохая ЗП в Москве)
И что же отказы, в одном месте прямо сказали, что коллектив молодой и вам будет у нас некомфортно работать (или нам с вами, не суть)
Итак, опыт для них был не столь важен, возможно на очень крупных проектах типа, но этих вакансий немного.
Итак, твой опыт в 40 лет не особо ценен для работодателя. Когда я снизел возраст (при том же резюме) до 25, мой ящик ломился от предложений молчащих работодателей.
Итак, борис, ты не прав, мне нет смысла расти в суперпрограммиста
Есть пара знакомых 1Сников, старше 40 лет. Работают в Москве, проблем с трудоустройством не испытывали никаких.Пишу, со смартфона, по этому частями.
Итак, рост в специалиста по знанию бизнеса. Ну это примерно, как рост секретарши до уровня ген директора,
Будучи именно программистом 1С в крупной белой и пушистой компании, знаний про бизнес у меня не прибыло - я же программирую, у меня даже нет времени понимать, почему та или иная проводка, а ведь это только учет, никак не знания про бизнес.
Тут и консультант по бух учету не вырастит в консультанта по бизнесу, куда уж программисту - все что я знаю это СКД, управляемые формы и немного предметки. Это как уметь водить машину, но не понимать, как её чинить или собирать - две большие разницы.
(1) это я вообще про IT спецов, 1С, только как пример.
Дальше, в менеджеры по продажам не уйти, да и их как собак не резанных, некоторые сами хотят прийти программистами 1с :)
Директором IT. Мой бывший руководитель (бывший директор) уже год не может найти работу, хотя специалист он хороший, и человек с большой буквы, но 40 с плюсом.
Не берут нигде, подрабатывает теперь сис админом.
Вообщем вывод такой: работай программистом лет до 30, максимум до 35 и думай, что твое время уходит безвозвратно.
Но это не повод впадать в уныние. Это повод расширять "кругозор".
Для меня сейчас работа с 1С связанна с непрерывным стрессом, ежедневной переработкой, постоянной "угрозой" увольнения и хорошей белой зарплатой, в качестве утешительного приза за старания(или страдания).
Моя тема это не повод поплакаться, я неплохо за мою зарплату (я её называю компенсацией) я посмотрел многие страны с продвинутой демократией и социальной защитой. Поговорил с местными бомжами, угадайте из какой они страны?! :) не они не программисты 1с если что
эм. мне 45, два года назад менял работу, ни одного отказа из-за возраста не услышал, вполне легко нашел 2 реальных предложения.
На текущем месте работы меня РЕАЛЬНО ценят, не смотря на то, что я во всей конторе почти самый старший (старше меня только глав. бух), проблем в общении нет ни у меня ни со мной.
так что сабж полная туфта.
хотя сейчас уже не хочется работать чистым прогом.
Итак, все таки постараюсь подытожить свои мысли:Будущее программиста (в россии) в том, что бы стать владельцем своего бизнеса или топ менеджмент в крупной компании - в этом есть перспектива, программирование останется программированием и хобби для прыщавых подростков типа тех, кто здесь будет писать про меня, что я неудачник. Да просто я пишу правду для тех, кто боится о ней даже подумать (9) напрямую никто не скажет, мне только один раз на это намекнули по телефону, хотя по голосу они усомнились в декларируемом возрасте (10) я пришел в 1С в 43, через 3 месяца открыл свой франч, через 3 года вложил 100k$ в неИТ-бизнес и понеслось . :) (14) ты можешь похвалиться сам, что мол имеешь свой бизнес, как в (13) или зарплату в 200 тысяч, иначе твой пост просто обычное тяфканье (0) Не трахайте нам мозг. Мне под 50 и до сих пор я еще выбираю, на кого работать, а на кого нет. Никогда не понимал людей, пытающихся оскорбить других на форуме, самомнение так поднять пытаются, что ли
(15) кстати, если менеджер по продажам к 40 не стал коммерческим директором, то без сворованной клиентской базы поиск новой работы будет для него долог и печален.
40-летнему кодеру 1С действительно не просто сменить место работы, значительно больше шансов у программиста 1С с предпринимательской жилкой - здесь и интернет-шопы по продукции своей фирмы, фрилансерство, на нехудой конец можно стать альфонсом при финдиректорше :)
Мы часто пишем о поиске работы и делимся историями успешного трудоустройства студентов. В реальности программисты не только находят работу, но и теряют её. Поинтересовались у экспертов, в каких случаях работодатели могут уволить разработчика. Ответы руководителей и опытных программистов ниже.
Важный момент: сразу несколько специалистов отказалось участвовать в опросе из-за деликатности вопроса.
Алексей Резвов: увольнял, если сотрудник не соблюдал договорённости или был недостаточно компетентным
Алексей Резвов, больше 10 лет руковожу разработкой в разных компаниях. Работал как над собственными продуктами компаний, так и при разработке под заказ, в режиме удаленных разработчиков и в офисе. Разрабатывали веб-приложения, десктоп, мобильные. Заказчики от стартапов до самого серьезного энтерпрайза. Люблю решать задачи связанные с организацией разработки программного обеспечения.
Увольнение по инициативе работодателя болезненно не только для работника, но и для работодателя. Увольнение сказывается на моральном духе коллектива: не всем сотрудникам известны причины увольнения, они домысливают, беспокоятся, не постигнет ли их та же участь. Стоит ли говорить, как это сказывается на эффективности работы коллектива?
Кроме того, уволенный работник — потенциальный распространитель негативной репутации о компании. В «интернетах» практически всегда пользователи займут сторону работника.
Таким образом, увольнение по инициативе работодателя — ситуация, которой работодатель, заботящийся о собственной репутации и моральном духе в команде, постарается всеми силами избежать.
Стоит заметить также, что бывают случаи, когда производительность всей команды упадёт, если сотрудника не уволить.
Итак, случаи, в которых увольнял сотрудников я.
Сотрудник не соблюдает наши договорённости
Рассмотрим на примере систематических опозданий, в случаях когда устав компании и бизнес-процессы не допускают такого. При приёме на работу мы явно договорились о распорядке дня с разработчиком. Но он регулярно опаздывает на работу. Сначала делаются устные предупреждения. Если ситуация не меняется, сотрудник вызывается на разговор, в котором мы пытаемся выяснить, есть ли какая-то объективная причина для этих опозданий. Если нет, напоминаю, что договоренности следует соблюдать, и что мы не сможем сотрудничать в ином случае.
Если опоздания продолжаются, следует последний серьёзный разговор, в котором уже явно оговариваем, что при следующем опоздании я инициирую увольнение.
Вместо опозданий в этот алгоритм можно вписать многое: несоблюдение style guide, игнорирование инструкций по работе с продом, грубое поведение при общении с коллегами, срыв сроков сдачи задач (по оценке сотрудника же) и тому подобное. Было даже появление на рабочем месте в пьяном виде в совокупности с опозданиями однажды. Действия такие же: предупреждения, разговор, последнее предупреждение, увольнение.
За весь мой опыт руководства до увольнения в таких случаях доходило лишь в редких случаях, обычно люди понимают всё после предупреждения или после разговора.
Да, бывает, что сотрудники принимают решение покинуть компанию, например, в результате выгорания, или график не устраивает, или развития для сотрудника нет. В таком случае, если мне не удаётся предложить приемлемого варианта, происходит дружественное расставание, с хорошими рекомендациями сотруднику и открытыми дверями, в случае если сотрудник захочет вернуться.
Недостаточная компетентность сотрудника для решения поставленных задач
Этот случай я отношу к собственным ошибкам. Такой вариант развития событий возможен только на испытательном сроке и только для специалистов, заявляющих высокую компетенцию. Кандидат оказывается неспособен решать поставленные перед ним задачи в силу недостатка опыта, знаний, развитых навыков, и нет возможности это компенсировать чем-то. Ошибка моя, так как не смог определить несоответствие кандидата должности в процессе найма, однако кандидатам от этого не легче. Нужно сказать, что таких случаев у меня было два, но запомнил я их крепко и навсегда.
Для тех, кто только начинает карьеру в индустрии разработки и смежных сферах, я бы порекомендовал запрашивать фидбек от руководителя, если он не дает обратную связь о вашей работе сам.
Тут стоит учитывать психологический аспект — негативный мотивированный фидбек давать трудно, поэтому часто осознанно или неосознанно руководитель избегает этого.
Запрашивая фидбек вы провоцируете руководителя выложить свои сомнения, если они есть. Кроме того, запрос фидбека сам по себе хороший сигнал в пользу сотрудника, говорящий о том, что сотрудник анализирует свою деятельность, пытается соответствовать должности и развиваться.
Это даже не говоря о том, что фидбек не только дает понимание того, как руководство оценивает сотрудничество, но и помогает себе самому определить вектор дальнейшего развития.
Анна Ишмухаметова: увольняют из-за некачественного продукта или неспособности адаптироваться к культуре компании
Анна Ишмухаметова, Software Development Engineer в Energi Cryptocurrency.
Причины для увольнения могу быть такими:
- В одной канадской компании уволили разработчиков из-за «политического» решения сократить отдел разработки. Продукт был неудачным, уволили руководителя отдела и его команду.
- Опыт китайской компании: уволили разработчика, так как он был изгоем в команде. Не смог адаптироваться к культуре компании.
- Опыт австралийской компании: увольняют из-за недостаточной экспертизы, плохого качества кода.
- Ещё одна причина — непоследовательность, недостаточный вклад в общее дело.
Артём Алейник: равнодушие, оторванность от бизнеса, неумение общаться — смертные грехи разработчика
Равнодушие к результатам своего труда
Если сотрудник работает на должности разработчика, это уже подразумевает, что он должен в процессе выполнения своих обязанностей задаваться какими-то вопросами:
- Зачем это делается?
- Почему именно так?
- Можно ли упростить?
- А кто будет работать с результатами моего труда на следующем этапе?
В этом суть профессионального подхода, в этом разделение ответственности за результат. Поэтому, если разработчик выбрал удобную позицию «копать от столба и до обеда», то лучше с таким попрощаться.
Оторванность от бизнес-процессов
Неразрешимые проблемы в коммуникациях
Все люди разные, у всех разное прошлое, психологический и эмоциональный бэкграунд. Если в общении возникает сложности, всегда можно попробовать найти компромисс. Если человеку не удается победить в себе агрессию или завышенную самооценку, то коллеги, скорее всего, будут всячески избегать общения с ним. Это повлечет провал в коммуникациях, который будет особенно болезненным для бизнеса, если сотрудник хорош в профессиональном плане.
Александра Шинкевич: разработчика можно уволить за нарушение юридических соглашений
Александра Шинкевич, Lead full-stack Node.js разработчик. Соорганизатор митапов MinskCSS и MinskJS, и конференции CSS-Minsk-JS.
Процесс увольнения неприятен для обеих сторон. Как правило, хороших разработчиков никто намеренно не будет увольнять. Все просто: работодателям дорого обходится процесс поиска и найма новых сотрудников, и с точки зрения денег проще удержать текущую команду, чем нанять новую. Работодатель скорее всего приложит все силы, чтобы удержать сотрудника, а не увольнять его внезапно. В некоторых случаях увольнение — единственный способ закончить сотрудничество и разойтись без больших потерь.
Разработчика, как и любого другого наемного сотрудника, можно уволить за нарушение юридических соглашений. Например, условий договора/контракта, трудового кодекса или других законов. К таким нарушениям могут относиться систематические прогулы или невыполнение поставленных задач. Речь не идет о том, когда джуниору дали задачи уровня Senior, и он — кто бы мог подумать — не справился (спойлер: в этом случае виноват в первую очередь тот, кто поставил ему такую задачу и вовремя не заметил несоответствие компетенции). Нет, для официального увольнения должны быть действительно веские причины, прописанные в договоре или ТК страны, где работает разработчик. В этом плане официально устроенный разработчик защищен со стороны государства, так как его нельзя просто так взять и уволить.
Более грустная, как мне кажется, история — это когда разработчик не оправдывает ожидания. Такое бывает не так уж редко. Многие IT-компании набирают разработчиков и сами их «растят»: проводят тренинги, внутренние митапы, мастер-классы, практикуют менторство и так далее. И вполне логично, что не все могут или хотят развиваться в том темпе, в котором от них ожидается. Или наоборот — overqualified, то есть разработчик «слишком хорош» для тех задач, которые выполняет. В обоих случаях получается, что для таких сотрудников нет подходящих задач, ведь для первого все слишком сложно, а для второго — слишком легко и скучно. Часто во втором случае разработчик сам понимает, что ему пора искать другое место работы, если перспектив роста у текущего работодателя больше нет.
Как поступают, когда официальных поводов для увольнения нет, а уволить очень хочется? Ждут окончания срока контракта или договариваются. Работодателю невыгодно портить свою репутацию как HR-бренда. Варианты могут быть разные: от денежной компенсации до рекомендации компании-партнера, куда можно устроиться увольняемому разработчику. Все зависит от условий заключенного трудового договора, размера компании, области деятельности и ещё сотни факторов.
Михаил Ларченко: причины для увольнения могут быть абсолютно разные
Михаил Ларченко, работаю техническим руководителем в компании Sytac B.V. Аккаунт в Twitter.
Причины для увольнения могут быть абсолютно разные, хотя официально будет что-нибудь из прописанного в трудовом кодексе. Конечно же, есть какой-то стандартный набор провинностей, за которые увольняют: прогулы, пьянство, невыполнение своих обязанностей и тому подобное. Я думаю, здесь всё понятно, и никаких вопросов вызывать не может.
Конечно же, кража может послужить поводом для увольнения. И я имею ввиду не деньги или компьютеры, а интеллектуальную собственность. В контрактах очень часто прописано, что является интеллектуальной собственностью, и какую информацию работник не имеет права разглашать (NDA). За нарушение этих пунктов контракта конечно же увольняют, и в придачу отсуживают у бывшего работника много денег.
В современном мире могут уволить также за неподобающее поведение на публике (включая социальные сети), которое нарушает принципы и нормы работодателя. Мне понятно почему, но я лично в корне с этим не согласен. Это же личное мнение, на которое каждый человек имеет право.
Иван Акулов: найти нового человека, нанять его, ввести его в проект — очень дорого
Иван Акулов, фронтенд-разработчик, автор канала в Telegram.
Увольнение — крайняя мера. Увольнять разработчика имеет смысл только тогда, когда у него ну совсем не получается справляться с задачами и мы не смогли ему с этим помочь.
Как можно помочь человеку?
В первую очередь, просто поговорить о проблемах. Может, человек просто не знает, что что-то нужно делать по-другому. Или, может, у него дома беда случилась, и ему просто нужно время. Если выяснится, что проблема в скучных задачах, то можно помочь найти более интересный проект. Если выяснится, что не хватает знаний, то попробовать дать ментора. Куча вариантов.
Зачем тратить на это время?
Кроме чисто человеческих причин, есть ещё экономические. Найти нового человека, нанять его, ввести его в проект — очень дорого. Гораздо выгоднее помочь тому, кто уже работает.
Что насчёт увольнений за катастрофические ошибки?
У меня есть любимая история про то, как начинающий разработчик в первый день работы случайно стёр продакшен-базу данных, и его тут же выгнали. Обычно это решается на эмоциях, и это глупо. Человек, который случайно стёр базу данных в проде, теперь всю жизнь будет бояться повторить эту ошибку. И он будет беречь от неё других. Этот человек получил уникальный опыт! Это ценно.
Евгений Обрезков: на первом месте среди причин увольнения находятся плохие soft skills
Евгений Обрезков, Senior Software Engineer. Аккаунт в Twitter.
Прежде чем ответить, хотелось бы прояснить, что нету «правильного» комментария или ответа на вопрос «почему работодатель меня уволил». Все сказанное мною — это просто личный опыт, через который я прошёл, и он может не коррелировать с вашим.
Начну с самой частой причины. Обычно работодатели говорят «не сработались», «не сошлись характерами», «тяжелый человек», «с ним было трудно работать» и тому подобное. Все они, обычно, скрывают под собой одну причину — плохие soft skills. Что подразумевается под soft skills? Это способность человека вживаться в команде, взаимодействовать с людьми. Все эти люди с разными характерами, принципами, амбициями. Довольно часто на этой почве могут возникать конфликты между членами команды. Так вот, человек с хорошими soft skills сможет найти решение, найти общий язык с людьми, нивелировать конфликт. Люди же с плохими soft skills будут наоборот подливать масла в огонь, разжигать. Они это могут делать даже неосознанно и не специально, вот они такие просто есть, «со своим характером». Поэтому будьте хорошим и адекватным человеком, который готов принять фидбек не на личный счёт и обидеться на всю команду, а отталкиваться от него и рефлексировать, стараясь стать лучше. И вам не придется слушать от работодателя фразу «не сработались».
И уже после идут причины технического характера (hard skills). Они случаются реже всего по моему опыту. Это когда человек хороший, команда с ним сработалась, всё прекрасно. Но вот он никак не может изучить проект, не может понять, что в нём происходит, постоянно задаёт одни и те же глупые вопросы без каких-либо видов на прогресс. Тут начинают люди себя спрашивать: «А есть ли польза от него, если он за всё это время так и не смог разобраться?»
В крупных компаниях такие вопросы обычно решаются сменой команды на более легкие проекты, например. Но если у компании только один продукт, а сотрудник так и не смог в нем разобраться и начать приносить пользу, то скорее всего с этим сотрудником попрощаются.
Хотелось бы ещё сказать, что ситуации у всех уникальные, и какого-то списка правил, по которым работодатель увольняет своих сотрудников, нету. Всё, что мы можем, это пытаться обобщать эти уникальные ситуации и находить общие признаки. Но если вы попали в ситуацию, что вас хотят уволить — лучше не ищите советов в интернете, а поговорите со своей командой, со своим работодателем и попытайтесь решить проблему индивидуально. Скорее всего, вы найдете корень всех зол и придумаете компромиссное решение в этой ситуации. Спасибо за уделенное время :-)
Дмитрий Горячев: у нас увольняют только неадекватных
У нас увольняют только совсем неадекватных или сокращают, если закрывается или переносится в другую страну проект.
Дмитрий Ивахненко: если человек скрывает косяки, его можно уволить
Можно уволить за ошибки. Но с правильно выстроенными процессами увольнять людей за ошибки — преступление. На ошибках мы учимся.
Если человек по какой-либо причине скрывает, что он накосячил, или ошибается раз за разом в одном месте, то его можно уволить.
Роман Слободенюк: на моей памяти ни одного программиста не увольняли
Любопытно, я тут задумался и понял, что на моей памяти ни одного программиста не увольняли, с которым бы я работал или которого бы знал. Все как-то сами добровольно переходили в другие компании.
Аноним: сотрудников нельзя увольнять без консультации с юристом
Лев Солнцев: причины могут быть разными — от разглашения внутренней информации до каналов с мемами в чате
Лев Солнцев, фронтенд-разработчик.
Работодатель может уволить за что угодно, мало ли, что взбредёт в голову. В случае с программистами увольняют чаще всего, наверное, потому что сотрудник по мнению работодателя не выдаёт достаточного результата. Хотя бывает всякое, от разглашения внутренней информации до каналов с мемами в чате. Иногда не увольняют, но переводят на плохие позиции, где результаты заведомо будут неудовлетворительными, или просто не повышают зарплату. Но мой опыт ограничен более или менее приличными крупными IT-компаниями.
Антон Немцев: наиболее серьезными являются проблемы, которые влияют на работу других людей
- независимый разработчик на протяжении 16 лет. Продался корпорациям;
- Jack of all trades, master of none. Скорее последнее;
- создатель и главный редактор Frontender Magazine. Всё про*рал;
- докладчик на международных и поместных конференциях. Чем дальше, тем поместнее.
- эксперт UA Web Challenge. Бывший.
Руководитель может уволить разработчика, если он не соответствует ожиданиям компании относительно роли, которую занимает.
Если есть проблема, руководитель встречается с разработчиком и обсуждает её. Если разработчик проблемы не видит, вероятно, стоит попрощаться. Если разработчик согласен, что проблема есть, и понимает её, то руководитель и разработчик вместе думают, как её решить. Через какое-то время, необходимое для решение проблемы, следует повторная встреча. Если проблема не решена — руководитель обсуждает почему, нужна и возможна ли вторая итерация. Или увольняет.
Ожидания могут быть в самых разных областях:
- профессиональные ожидания;
- качество коммуникации;
- соответствие культуре компании;
- .
Наиболее серьезными являются проблемы, которые влияют на работу других людей. Очень часто это проблемы в области коммуникации.
В определенном смысле в этом можно увидеть аналогию с романтическими отношениями.
Пожалуйста, в комментариях поделитесь своим опытом и мнением: за что увольняют или могут уволить программиста?
Читайте также: