КАК ИЗБЕЖАТЬ ПРОФЕССИОНАЛЬНОЙ ДЕГРАДАЦИИ, РАБОТАЯ В IT: МНЕНИЕ РУКОВОДИТЕЛЕЙ
Как не упереться в потолок, работая в IT? Этой теме команда Trud.com уже посвятила статью, в которой аргументами и советами поделились разработчики. В этой публикации слово предоставляется руководителям. Позиция менеджеров – это «вид сверху». Если программист разрабатывает индивидуальный план развития и ищет возможности проявить себя, руководитель думает, как не допустить деградации и выгорания в команде. Задачи разного уровня. Разные решения. Рекомендации экспертов будут полезны и руководителям, и профессионалам на неруководящих позициях.
Дмитрий Колтович, главный инженер по разработке в «Сбербанке», победитель российского хакатона «Цифровой прорыв», поясняет, в каких случаях не стоит торопиться с переходом в новый проект или другую компанию:
"Согласно моим личным наблюдениям за поведением коллег и друзей-программистов, прежде, чем сменить работу, они в среднем остаются на одном месте 2-3 года. И в основном есть несколько причин, почему они (и я в том числе) меняют работу:
В начале карьеры стоит задержаться на одном месте работы хотя бы на пару лет, это будет хорошо смотреться в резюме, а также покажет, что было достаточно времени для того, чтобы влиться в рабочий процесс и начать справляться с поставленными задачами. Дальше можно будет переключаться между компаниями каждые 12-18 месяцев в погоне за более высокой зарплатой.
И я могу с уверенностью сказать, что смена работы не должна быть слишком частой. Гораздо надежнее в момент найма будет выглядеть разработчик, который имел 3 места работы за, допустим, 5 лет, нежели 5 мест за 4 года. А все потому, что обучение и адаптация занимают 3–6 первых месяцев работы – и это будет только знакомство с новой компанией, командой и процессами. В последующие 6-12 месяцев ваша работа начнет добавлять ценность бизнесу, и вы станете, наконец, полноценным членом команды. К 18-му месяцу вы, скорее всего, станете экспертом и сможете направлять команду/проект в нужное русло".
Павел Зиновкин, специалист с 15-летней экспертизой в области разработки и архитектуры высоконагруженных облачных систем и сервисов, рекомендует обращаться к руководству компании, чтобы обсудить личный план профессионального развития, не дожидаясь, пока кривая энтузиазма поползет вниз:
"Каждый случай уникален и зависит от целей, которые ставит перед собой IT-специалист, его предпочтений по работе, а также рабочих задач. Одно можно сказать точно: если есть четкий план развития, и решаемые задачи не вписываются в него, стоит обсудить это с руководством, не откладывая в долгий ящик. С большой вероятностью компания сможет помочь с развитием".
Илья Феоктистов, Head of DevOps, обосновывает пользу ротации сотрудников:
Действительно, работать над одним и тем же продуктом в течение долго времени может стать крайне скучным занятием. Есть типичный срок для смены проекта, это 2 года. Но по моему опыту, уже через год 50% сотрудников теряют интерес к работе над одним продуктом и просят о смене команды, где хотя бы используются другие технологии. Допустим, инженер работает на одном направлении в течение нескольких лет, техническая составляющая продукта при этом не эволюционирует или, к примеру, архитектура системы меняется для возможности масштабирования, но наш инженер не принимает в этой эволюции никакого участия – потому что занимается разработкой такого компонента, где изменения не нужны – его компетенции начнут снижаться относительно других его коллег. Ротация сотрудников между командами – это отличная возможность сохранить их в компании, делиться экспертизой и построить более тесные связи между командами, занимающимися различными направлениями внутри одной организации.
Алексей Минаков, директор практики управления проектами компании Accenture в России, приводит в качестве примера опыт конкретной компании и очерчивает возможные карьерные траектории в нескольких направлениях разработки:
"Возьмем, например, разнообразие технологий. Например, сегодняшний интерес к open-source привел к их многообразию, а вот их практическая применимость и совместимость друг с другом для решения задач, вопрос активно обсуждаемый. Плюс, в профессиональном плане работа с такими технологиями интересна, но не очень быстра. Поэтому продолжительная работа на проекте дает возможность как применять многообразие уже апробированных технологий, так и исследовать новые. На это уходит достаточно длительное время, иногда годы, поэтому ни о какой деградации здесь речи не идет.
Другой пример – разнообразие ролей. Большие проекты и программы – это минимум сотни специалистов и десятки ролей. Если взять за отправную точку, например, роль системного аналитика, то при усердной работе такого специалиста он может вырасти до руководителя аналитики команды, и далее до руководителя аналитики всей системы. А далее уже недалеко и до роли функционального архитектора.
Аналогичный путь может быть и у разработчика, который дорастает до технического архитектора; у QA специалиста, который становится архитектором тестирования; у DevOps инженера, который вырастает до DevOps архитектора.
Третий пример – переход между карьерными треками. Часть специалистов на определенном этапе развития осознают, что они хотят развиваться в направлении управления. Для таких специалистов на большом проекте возможен такой путь: системный аналитик, руководитель аналитики команды, руководитель команды, руководитель проекта. Аналогичный путь может быть и у разработчика, и у QA специалиста, и тот же самый большой проект – отличная площадка для такой смены трека.
Еще один важный момент, про который не стоит забывать – это «стоимость» входа в новый проект для самого специалиста. Она, конечно же, есть, зачастую достаточно высокая – нужно сработаться с новыми людьми, погрузиться в новые процессы производства. И это может оказаться довольно трудозатратной и не быстрой вещью с точки зрения динамики развития карьеры.
Еще один момент, который стоит принять во внимание – как ведет себя решение при длительной эксплуатации. Только будучи рядом, можно понять, какие решения были правильными, а какие требуют серьезной переработки. И для проявления некоторых недостатков достаточно месяца, а для некоторых – намного больше (например, вопросы надежности). И вот здесь как раз начинается настоящий опыт, который можно почерпнуть, только долго работая на проекте".
Борис Шишкин, Team lead компании ALNA, рассказывает о важности чувства победы для профилактики выгорания и делится советами, как самому руководителю избежать потери энтузиазма:
В компании ALNA мы смогли выстроить такую систему, которая справляется с выгоранием. Секрет в том, что программистам нужно постоянно чувствовать маленькие победы. Когда ты приходишь в компанию и тебя просят разработать какой-то модуль, ты загораешься работой, пишешь код с нуля, потом выводишь в продакшн. Всё это создаёт внутреннее чувство победы. Но когда приходит необходимый этап обслуживания, начинается рутина, которая убивает желание работать и в итоге приводит к эмоциональному выгоранию.
Чтобы этого избежать, мы регулярно проводим тимбилдинги. Во время этих мероприятий становится понятно, кто из сотрудников близок к выгоранию. Чтобы этого не допустить, мы перенаправляем программиста на другую часть проекта или даём задание по созданию внутреннего продукта, написать который ему под силу. Очередная победа придаёт сил и позволяет с новыми идеями вернуться к своему первому проекту.
Сложнее всего отследить начало выгорания самому лидеру команды. Ведь он должен быть одинаково погруженным во все части проекта, потому бывает сложно перенаправить внимание. В этом случае нашей команде помогает участие в хакатонах. Мы ввязываемся в бой, напрягаемся и пишем проект за 72 часа. Тот факт, что спустя три дня у тебя готов продукт – это уже победа, а, когда наши проекты признают лучшими в соревнованиях, это окрыляет. Происходит полная перезагрузка, благодаря которой команда с новыми силами берется за основную работу, получив новые знания и навыки.
Татьяна Бунто, аналитик проектов внедрений, руководитель продукта «Единый адрес» в HFLabs, мотивирует разработчиков к саморазвитию, которое подпитывается личным стремлением, а не стимулами извне:
Деградация в IT не зависит от сроков проекта или длительности работы в одном продукте, а зависит от самого человека и команды, с которой он работает. Можно ходить на профильные конференции, читать профессиональную литературу, узнавать тренды развития IT. Даже, если команда не хочет применять в проекте или продукте новые технологии и добавлять новый функционал, то сам человек может развиваться, расширяя свои знания вширь или вглубь. И, делая даже рутинную задачку, можно задавать себе вопросы: «А как я могу делать эту задачу быстрее, проще без потери качества? А как другие делают подобные вещи? А что нового мне надо узнать, чтобы оптимизировать свою работу? Кто или что мне с этим может помочь?».
Одному из программных продуктов нашей компании больше 10 лет, но в нем постоянно появляются новые модули, происходит его адаптация под конкретный бизнес, меняются роли и процессы внутри команды. Например, мы долгое время актуализировали документацию по продукту вручную, человеческий фактор приводил к ошибкам. Сейчас часть документации создается автоматически из программного кода, это минимизирует ошибки и время на ручную актуализацию. Кроме того, внедрение продукта в банке отличается от внедрения того же продукта в телекоме, потому что процессы и предметная область отличаются.
Бывает, человек опасается стагнации и того, что он не будет востребован другими работодателями, поскольку слишком долго был в одном проекте. Безусловно, при переходе из одной области в другую – например, из B2G в B2C – придется опуститься на ступеньку ниже. Если тестировщик банковских продуктов захочет перейти в тестирование игр, ему нужно будет наработать опыт и адаптироваться уже в новой сфере.
Это не значит, что надо пытаться объять необъятное и изучать все, что происходит в IT во всех сферах. Тем более, что без практики новые знания быстро улетучиваются. Если ты всю жизнь работал с Windows, то стать специалистом по Linux после прочтения книги невозможно.
Надежда Фердман, директор по развитию бизнеса Proto Group, рассказывает, как можно самостоятельно «прокачивать» навыки, опираясь на личный план развития:
Любому специалисту, не только в IT-сфере, если он хочет двигаться вверх по карьерной лестнице и расти профессионально, необходимо расширять знания не только в рамках своих должностных обязанностей, но и за ними – в сторону наращивания экспертизы в разных направлениях. Чтобы придать наглядности моей фразе, приведу пример из опыта по онбордингу и развитию компетенций у сотрудников из нашей команды технического сопровождения заказчиков. Для каждого сотрудника есть программа обучения по самым передовым на сегодняшний день технологиям в IT, которая включает в себя, в том числе, участие в самых крупных IT-мероприятиях, вебинарах. Плюс мы добавляем программы по развитию soft skills, делая упор на развитие навыков коммуникации, презентации. Также у нас есть клуб внеклассного чтения, в рамках которого мы обсуждаем интересные статьи по IT-тематике, опубликованные в международных изданиях, тем самым прокачивая уровень владения английским языком и понимание общемировых тенденций в отрасли.
Если в компании не применяется практика бесплатного обучения технологиям, выходящим за рамки специализации сотрудника, не развиваются его soft skills, не оплачивается участие в профильных конференциях, тогда ему придется обучаться и участвовать в конференциях за свой счет. Но, к счастью, сейчас проводится огромное количество бесплатных вебинаров, в открытом доступе много информации по любому направлению в IT. Прибегать к платным курсам/конференциям можно уже после того, как специалист изучил материал, находящийся в свободном доступе.
Главное – начать путь по расширению своих компетенций с создания четкого плана. Например, выписать себе все те технологии, с которым специалист хотел бы поработать, но сейчас не имеет такой возможности в рамках своих обязанностей.
Почитать по ним общую информацию, определить, в каких он заинтересован в первую очередь и начать планомерно углублять свои знания. Можно начать с подключения RSS-сервиса для информирования о публикации целевых материалов, вебинаров и лучше всего – на топовых международных IT-ресурсах. Далее можно создать у себя личную тестовую лабораторию – параллельно изучению теории, поднимать виртуальные машины (можно как у себя на компьютере, так и в облаке) и разворачивать изучаемые технологии. Результатом такой программы, при должном уровне внимания и заинтересованности, станет достаточно быстрое повышение квалификации.
Федор Яременко, Senior Software Engineer, раскрывает плюсы и минусы ротации разработчиков:
Однозначно ответить на вопрос, когда следует переводить разработчика на другой проект, сложно, потому что ротация – это всегда палка о двух концах. С одной стороны, когда в детали проекта погружен только небольшой коллектив программистов, то уход одного из членов команды может значительно снизить производительность и увеличить время разработки срочных исправлений. Также достаточно сложно планировать отпуска, так как без ротации страдает взаимозаменяемость сотрудников.
В IT технологии стремительно развиваются, поэтому программист – профессия, требующая непрерывного обучения. Смена проектов позволяет разработчику постоянно развиваться, изучать новые технологии и получать релевантный опыт. Также новые люди в команде привносят новые идеи и свежим взглядом смотрят на код, что, как правило, положительно сказывается на качестве реализации проекта.
Но у ротации есть и недостатки. Самый очевидный – временные затраты на знакомство нового члена команды с предметной областью, документацией и кодом проекта. Как правило, «вкатывание» в проект происходит в течение 2 недель. Почти на любом проекте есть задачи, относящиеся к категории «технический долг». При смене разработчиков такие задачи сложно решать новым членам команды, так как эти задачи накапливались старым составом. Вдобавок, для каждого программиста важно увидеть результат своей работы — завершённый продукт или успешное внедрение решения заказчику. А при периодической ротации разработчика могут перевести в другую команду до финальной фазы текущего проекта.
По моему опыту, в зависимости от масштабности и продолжительности проекта, а также размера команды, следует менять проекты каждые 6-12 месяцев. За это время оправдаются затраты на «переходный период», разработчик погрузится во все детали проекта и получит опыт работы с новыми технологиями. Также за это время можно оценить производительность программиста и понять, достоин ли он повышения, что сложно сделать при частой ротации.
Александр Беляев, старший консультант IT-департамента рекрутинговой компании Cornerstone, подчеркивает субъективную сторону оценки «мне интересно в этом проекте/работа стала рутиной» и дает рекомендации, как снизить вероятность выгорания разработчиков, учитывая их совместимость с проектом:
«Среднее время работы IT-специалиста в компании» – величина, сильно варьирующаяся в зависимости от компании и проекта. В стартапах и небольших фирмах она может составлять меньше года. В госкомпаниях и банках – превышать пять лет. Но в среднем при найме сотрудника следует оценивать период его работы в данной должности в два-три года. Насколько быстро сотрудник почувствует себя «засидевшимся», главным образом зависит от характера конкретного человека. Одному специалисту уже через полгода покажется, что его «поглощает рутина», другой же будет работать на одной позиции годами и чувствовать себя счастливым.
Наиболее эффективный способ решения проблемы ухода «засидевшихся» сотрудников – тщательный поиск кандидатов, подходящих как личностно, так и профессионально на вакансию. В молодой стартап следует рассматривать кандидатов, скорее мотивированных к росту, развитию и большому количеству работы, нежели имеющих многолетний опыт, но ищущих относительной стабильности. Последних стоит рассматривать в госкомпании или крупные финансовые организации.
Помимо этого, следует постоянно ставить сотрудников перед новыми вызовами. Для небольших продуктовых компаний это может быть как смена роли в команде на подобную, так и добавление руководящих функций. Ротацию проектов обеспечивают крупные компании или IT-интеграторы.
Алина Пожидаева, HR бизнес-партнёр Atos в России, подчеркивает важность сертификации для подтверждения экспертности и призывает проявлять инициативу:
Замедление профессионального развития и выгорание – трудности, с которыми могут столкнуться IT-специалисты при долгой работе над одним проектом.
Для того чтобы всегда оставаться перспективным сотрудником, необходимо быть в курсе последних тенденций и событий. В этом помогут профильные Telegram-каналы и сообщества в социальных сетях, где пользователи могут читать о трендах рынка.
Активно развивающаяся сфера IT также требует от специалистов регулярного повышения компетенции. Для этого многие из них проходят сертификацию у крупных вендоров, которые подтверждают их экспертность и умение работать с последними версиями программного обеспечения и инновационными технологиями. Помимо этого, следует самостоятельно проявлять инициативу: не бояться брать новые задачи, проходить профильные курсы, а также осваивать новые программы и разработки. Это позволит разнообразить ежедневные обязанности и повысить интерес к работе.
Источник: trud.com
"Согласно моим личным наблюдениям за поведением коллег и друзей-программистов, прежде, чем сменить работу, они в среднем остаются на одном месте 2-3 года. И в основном есть несколько причин, почему они (и я в том числе) меняют работу:
- вы больше не узнаете ничего нового или больше не сталкиваетесь с новыми и сложными для вас задачами и проблемами, работа превращается в рутину;
- ваши знания и инструменты начинают устаревать, а перспектив их смены или совершенствования на текущем проекте нет;
- нет перспектив карьерного роста внутри компании;
- зарплата на рынке растет быстрее, чем внутри компании.
- Однако стоит задержаться на одной работе дольше, если:
- к вам действительно прислушиваются;
- у вас есть прозрачный план развития карьеры;
- это быстрорастущий стартап, а вы – один из первых ключевых сотрудников, и в будущем сможете вырасти до более крупной должности.
В начале карьеры стоит задержаться на одном месте работы хотя бы на пару лет, это будет хорошо смотреться в резюме, а также покажет, что было достаточно времени для того, чтобы влиться в рабочий процесс и начать справляться с поставленными задачами. Дальше можно будет переключаться между компаниями каждые 12-18 месяцев в погоне за более высокой зарплатой.
И я могу с уверенностью сказать, что смена работы не должна быть слишком частой. Гораздо надежнее в момент найма будет выглядеть разработчик, который имел 3 места работы за, допустим, 5 лет, нежели 5 мест за 4 года. А все потому, что обучение и адаптация занимают 3–6 первых месяцев работы – и это будет только знакомство с новой компанией, командой и процессами. В последующие 6-12 месяцев ваша работа начнет добавлять ценность бизнесу, и вы станете, наконец, полноценным членом команды. К 18-му месяцу вы, скорее всего, станете экспертом и сможете направлять команду/проект в нужное русло".
Павел Зиновкин, специалист с 15-летней экспертизой в области разработки и архитектуры высоконагруженных облачных систем и сервисов, рекомендует обращаться к руководству компании, чтобы обсудить личный план профессионального развития, не дожидаясь, пока кривая энтузиазма поползет вниз:
"Каждый случай уникален и зависит от целей, которые ставит перед собой IT-специалист, его предпочтений по работе, а также рабочих задач. Одно можно сказать точно: если есть четкий план развития, и решаемые задачи не вписываются в него, стоит обсудить это с руководством, не откладывая в долгий ящик. С большой вероятностью компания сможет помочь с развитием".
Илья Феоктистов, Head of DevOps, обосновывает пользу ротации сотрудников:
Действительно, работать над одним и тем же продуктом в течение долго времени может стать крайне скучным занятием. Есть типичный срок для смены проекта, это 2 года. Но по моему опыту, уже через год 50% сотрудников теряют интерес к работе над одним продуктом и просят о смене команды, где хотя бы используются другие технологии. Допустим, инженер работает на одном направлении в течение нескольких лет, техническая составляющая продукта при этом не эволюционирует или, к примеру, архитектура системы меняется для возможности масштабирования, но наш инженер не принимает в этой эволюции никакого участия – потому что занимается разработкой такого компонента, где изменения не нужны – его компетенции начнут снижаться относительно других его коллег. Ротация сотрудников между командами – это отличная возможность сохранить их в компании, делиться экспертизой и построить более тесные связи между командами, занимающимися различными направлениями внутри одной организации.
Алексей Минаков, директор практики управления проектами компании Accenture в России, приводит в качестве примера опыт конкретной компании и очерчивает возможные карьерные траектории в нескольких направлениях разработки:
"Возьмем, например, разнообразие технологий. Например, сегодняшний интерес к open-source привел к их многообразию, а вот их практическая применимость и совместимость друг с другом для решения задач, вопрос активно обсуждаемый. Плюс, в профессиональном плане работа с такими технологиями интересна, но не очень быстра. Поэтому продолжительная работа на проекте дает возможность как применять многообразие уже апробированных технологий, так и исследовать новые. На это уходит достаточно длительное время, иногда годы, поэтому ни о какой деградации здесь речи не идет.
Другой пример – разнообразие ролей. Большие проекты и программы – это минимум сотни специалистов и десятки ролей. Если взять за отправную точку, например, роль системного аналитика, то при усердной работе такого специалиста он может вырасти до руководителя аналитики команды, и далее до руководителя аналитики всей системы. А далее уже недалеко и до роли функционального архитектора.
Аналогичный путь может быть и у разработчика, который дорастает до технического архитектора; у QA специалиста, который становится архитектором тестирования; у DevOps инженера, который вырастает до DevOps архитектора.
Третий пример – переход между карьерными треками. Часть специалистов на определенном этапе развития осознают, что они хотят развиваться в направлении управления. Для таких специалистов на большом проекте возможен такой путь: системный аналитик, руководитель аналитики команды, руководитель команды, руководитель проекта. Аналогичный путь может быть и у разработчика, и у QA специалиста, и тот же самый большой проект – отличная площадка для такой смены трека.
Еще один важный момент, про который не стоит забывать – это «стоимость» входа в новый проект для самого специалиста. Она, конечно же, есть, зачастую достаточно высокая – нужно сработаться с новыми людьми, погрузиться в новые процессы производства. И это может оказаться довольно трудозатратной и не быстрой вещью с точки зрения динамики развития карьеры.
Еще один момент, который стоит принять во внимание – как ведет себя решение при длительной эксплуатации. Только будучи рядом, можно понять, какие решения были правильными, а какие требуют серьезной переработки. И для проявления некоторых недостатков достаточно месяца, а для некоторых – намного больше (например, вопросы надежности). И вот здесь как раз начинается настоящий опыт, который можно почерпнуть, только долго работая на проекте".
Борис Шишкин, Team lead компании ALNA, рассказывает о важности чувства победы для профилактики выгорания и делится советами, как самому руководителю избежать потери энтузиазма:
В компании ALNA мы смогли выстроить такую систему, которая справляется с выгоранием. Секрет в том, что программистам нужно постоянно чувствовать маленькие победы. Когда ты приходишь в компанию и тебя просят разработать какой-то модуль, ты загораешься работой, пишешь код с нуля, потом выводишь в продакшн. Всё это создаёт внутреннее чувство победы. Но когда приходит необходимый этап обслуживания, начинается рутина, которая убивает желание работать и в итоге приводит к эмоциональному выгоранию.
Чтобы этого избежать, мы регулярно проводим тимбилдинги. Во время этих мероприятий становится понятно, кто из сотрудников близок к выгоранию. Чтобы этого не допустить, мы перенаправляем программиста на другую часть проекта или даём задание по созданию внутреннего продукта, написать который ему под силу. Очередная победа придаёт сил и позволяет с новыми идеями вернуться к своему первому проекту.
Сложнее всего отследить начало выгорания самому лидеру команды. Ведь он должен быть одинаково погруженным во все части проекта, потому бывает сложно перенаправить внимание. В этом случае нашей команде помогает участие в хакатонах. Мы ввязываемся в бой, напрягаемся и пишем проект за 72 часа. Тот факт, что спустя три дня у тебя готов продукт – это уже победа, а, когда наши проекты признают лучшими в соревнованиях, это окрыляет. Происходит полная перезагрузка, благодаря которой команда с новыми силами берется за основную работу, получив новые знания и навыки.
Татьяна Бунто, аналитик проектов внедрений, руководитель продукта «Единый адрес» в HFLabs, мотивирует разработчиков к саморазвитию, которое подпитывается личным стремлением, а не стимулами извне:
Деградация в IT не зависит от сроков проекта или длительности работы в одном продукте, а зависит от самого человека и команды, с которой он работает. Можно ходить на профильные конференции, читать профессиональную литературу, узнавать тренды развития IT. Даже, если команда не хочет применять в проекте или продукте новые технологии и добавлять новый функционал, то сам человек может развиваться, расширяя свои знания вширь или вглубь. И, делая даже рутинную задачку, можно задавать себе вопросы: «А как я могу делать эту задачу быстрее, проще без потери качества? А как другие делают подобные вещи? А что нового мне надо узнать, чтобы оптимизировать свою работу? Кто или что мне с этим может помочь?».
Одному из программных продуктов нашей компании больше 10 лет, но в нем постоянно появляются новые модули, происходит его адаптация под конкретный бизнес, меняются роли и процессы внутри команды. Например, мы долгое время актуализировали документацию по продукту вручную, человеческий фактор приводил к ошибкам. Сейчас часть документации создается автоматически из программного кода, это минимизирует ошибки и время на ручную актуализацию. Кроме того, внедрение продукта в банке отличается от внедрения того же продукта в телекоме, потому что процессы и предметная область отличаются.
Бывает, человек опасается стагнации и того, что он не будет востребован другими работодателями, поскольку слишком долго был в одном проекте. Безусловно, при переходе из одной области в другую – например, из B2G в B2C – придется опуститься на ступеньку ниже. Если тестировщик банковских продуктов захочет перейти в тестирование игр, ему нужно будет наработать опыт и адаптироваться уже в новой сфере.
Это не значит, что надо пытаться объять необъятное и изучать все, что происходит в IT во всех сферах. Тем более, что без практики новые знания быстро улетучиваются. Если ты всю жизнь работал с Windows, то стать специалистом по Linux после прочтения книги невозможно.
Надежда Фердман, директор по развитию бизнеса Proto Group, рассказывает, как можно самостоятельно «прокачивать» навыки, опираясь на личный план развития:
Любому специалисту, не только в IT-сфере, если он хочет двигаться вверх по карьерной лестнице и расти профессионально, необходимо расширять знания не только в рамках своих должностных обязанностей, но и за ними – в сторону наращивания экспертизы в разных направлениях. Чтобы придать наглядности моей фразе, приведу пример из опыта по онбордингу и развитию компетенций у сотрудников из нашей команды технического сопровождения заказчиков. Для каждого сотрудника есть программа обучения по самым передовым на сегодняшний день технологиям в IT, которая включает в себя, в том числе, участие в самых крупных IT-мероприятиях, вебинарах. Плюс мы добавляем программы по развитию soft skills, делая упор на развитие навыков коммуникации, презентации. Также у нас есть клуб внеклассного чтения, в рамках которого мы обсуждаем интересные статьи по IT-тематике, опубликованные в международных изданиях, тем самым прокачивая уровень владения английским языком и понимание общемировых тенденций в отрасли.
Если в компании не применяется практика бесплатного обучения технологиям, выходящим за рамки специализации сотрудника, не развиваются его soft skills, не оплачивается участие в профильных конференциях, тогда ему придется обучаться и участвовать в конференциях за свой счет. Но, к счастью, сейчас проводится огромное количество бесплатных вебинаров, в открытом доступе много информации по любому направлению в IT. Прибегать к платным курсам/конференциям можно уже после того, как специалист изучил материал, находящийся в свободном доступе.
Главное – начать путь по расширению своих компетенций с создания четкого плана. Например, выписать себе все те технологии, с которым специалист хотел бы поработать, но сейчас не имеет такой возможности в рамках своих обязанностей.
Почитать по ним общую информацию, определить, в каких он заинтересован в первую очередь и начать планомерно углублять свои знания. Можно начать с подключения RSS-сервиса для информирования о публикации целевых материалов, вебинаров и лучше всего – на топовых международных IT-ресурсах. Далее можно создать у себя личную тестовую лабораторию – параллельно изучению теории, поднимать виртуальные машины (можно как у себя на компьютере, так и в облаке) и разворачивать изучаемые технологии. Результатом такой программы, при должном уровне внимания и заинтересованности, станет достаточно быстрое повышение квалификации.
Федор Яременко, Senior Software Engineer, раскрывает плюсы и минусы ротации разработчиков:
Однозначно ответить на вопрос, когда следует переводить разработчика на другой проект, сложно, потому что ротация – это всегда палка о двух концах. С одной стороны, когда в детали проекта погружен только небольшой коллектив программистов, то уход одного из членов команды может значительно снизить производительность и увеличить время разработки срочных исправлений. Также достаточно сложно планировать отпуска, так как без ротации страдает взаимозаменяемость сотрудников.
В IT технологии стремительно развиваются, поэтому программист – профессия, требующая непрерывного обучения. Смена проектов позволяет разработчику постоянно развиваться, изучать новые технологии и получать релевантный опыт. Также новые люди в команде привносят новые идеи и свежим взглядом смотрят на код, что, как правило, положительно сказывается на качестве реализации проекта.
Но у ротации есть и недостатки. Самый очевидный – временные затраты на знакомство нового члена команды с предметной областью, документацией и кодом проекта. Как правило, «вкатывание» в проект происходит в течение 2 недель. Почти на любом проекте есть задачи, относящиеся к категории «технический долг». При смене разработчиков такие задачи сложно решать новым членам команды, так как эти задачи накапливались старым составом. Вдобавок, для каждого программиста важно увидеть результат своей работы — завершённый продукт или успешное внедрение решения заказчику. А при периодической ротации разработчика могут перевести в другую команду до финальной фазы текущего проекта.
По моему опыту, в зависимости от масштабности и продолжительности проекта, а также размера команды, следует менять проекты каждые 6-12 месяцев. За это время оправдаются затраты на «переходный период», разработчик погрузится во все детали проекта и получит опыт работы с новыми технологиями. Также за это время можно оценить производительность программиста и понять, достоин ли он повышения, что сложно сделать при частой ротации.
Александр Беляев, старший консультант IT-департамента рекрутинговой компании Cornerstone, подчеркивает субъективную сторону оценки «мне интересно в этом проекте/работа стала рутиной» и дает рекомендации, как снизить вероятность выгорания разработчиков, учитывая их совместимость с проектом:
«Среднее время работы IT-специалиста в компании» – величина, сильно варьирующаяся в зависимости от компании и проекта. В стартапах и небольших фирмах она может составлять меньше года. В госкомпаниях и банках – превышать пять лет. Но в среднем при найме сотрудника следует оценивать период его работы в данной должности в два-три года. Насколько быстро сотрудник почувствует себя «засидевшимся», главным образом зависит от характера конкретного человека. Одному специалисту уже через полгода покажется, что его «поглощает рутина», другой же будет работать на одной позиции годами и чувствовать себя счастливым.
Наиболее эффективный способ решения проблемы ухода «засидевшихся» сотрудников – тщательный поиск кандидатов, подходящих как личностно, так и профессионально на вакансию. В молодой стартап следует рассматривать кандидатов, скорее мотивированных к росту, развитию и большому количеству работы, нежели имеющих многолетний опыт, но ищущих относительной стабильности. Последних стоит рассматривать в госкомпании или крупные финансовые организации.
Помимо этого, следует постоянно ставить сотрудников перед новыми вызовами. Для небольших продуктовых компаний это может быть как смена роли в команде на подобную, так и добавление руководящих функций. Ротацию проектов обеспечивают крупные компании или IT-интеграторы.
Алина Пожидаева, HR бизнес-партнёр Atos в России, подчеркивает важность сертификации для подтверждения экспертности и призывает проявлять инициативу:
Замедление профессионального развития и выгорание – трудности, с которыми могут столкнуться IT-специалисты при долгой работе над одним проектом.
Для того чтобы всегда оставаться перспективным сотрудником, необходимо быть в курсе последних тенденций и событий. В этом помогут профильные Telegram-каналы и сообщества в социальных сетях, где пользователи могут читать о трендах рынка.
Активно развивающаяся сфера IT также требует от специалистов регулярного повышения компетенции. Для этого многие из них проходят сертификацию у крупных вендоров, которые подтверждают их экспертность и умение работать с последними версиями программного обеспечения и инновационными технологиями. Помимо этого, следует самостоятельно проявлять инициативу: не бояться брать новые задачи, проходить профильные курсы, а также осваивать новые программы и разработки. Это позволит разнообразить ежедневные обязанности и повысить интерес к работе.
Источник: trud.com