Срок, проведенный на предыдущем месте работы – важный показатель для оценки кандидата. Как правило, анализ сводится к тому, чтобы понять, укладывается ли значение показателя в некий интервал, а если нет, определить наличие уважительной причины «досрочного завершения контракта». Обычно, временной интервал определяется от двух-пяти лет и чем дольше, тем лучше. Если данный показатель для соискателя меньше нижней границы интервала, как правило, от кандидатуры отказываются.
Основанием для отказа служит предположение, что есть некая проблема в кандидате и он, с большой вероятностью, не сможет пробыть на новом месте работы дольше своего среднего показателя. Как минимум, не оправдает затраты на «онбординг», как максимум – оставит свой «участок» в неподходящий момент, создав тем проблемы для компании.
В данной статье, на примере своей любимой IT-отрасли, я покажу, что предыдущий стаж работы может быть тонким инструментом, позволяющим понять: на каком этапе карьеры находится кандидат, какова его мотивация и, самое главное, как экстраполировать предыдущие значения этого показателя в условиях нового места работы. Всегда ли действует правило «чем больше, тем лучше», и какую характеристику в зависимости от стажа и должности кандидата дает этот показатель.
Программист-стажер
Цель сотрудника на данном этапе – накопление опыта, навыков применения изученного на курсах материала в рабочих условиях. Выполняемые им профессиональные обязанности идеально для этого подходят. Новые задачи сыпятся как из рога изобилия, постепенно он углубляется в предметную область – в регламент работы IT-подразделения, критерии качества программного кода.
На данном этапе стажер составляет первоначальный план своих дальнейших карьерных перспектив. Определяет для себя, кем в конечном итоге он может и хочет стать. Как правило, этот период занимает 1-2 года и это время сотрудник вкладывается в себя как в профессионала. Пока он меньше зависит от отношений на предприятии и архитектуры обслуживаемого программного комплекса. Как правило, достаточно базовых знаний в программировании и хороших отношений со своим непосредственным руководителем.
Обычно, срок стажировки проходит «на едином дыхании». На самом деле, трудно представить уважительную причину, лежащую в области трудовых отношений (кроме сокращения штатов), делающую нормальное течение процесса стажировки невозможным и лежащую в основе решения о смене места работы.
На данном этапе сотрудник не несет ответственности за работоспособность обслуживаемого программного комплекса, равно как и за сроки разработки. Он опосредованно участвует в процессах внедрения нового программного обеспечения (ПО) и не несет, в связи с этим, никакого риска. Изучение возможностей средств программной разработки, равно как и архитектуры и функциональных возможностей программного комплекса – дело, преимущественно, самостоятельное.
Поэтому, за редким исключением, досрочное завершение трудовых отношений по инициативе работника на этапе стажировки – аномалия, которая должна быть тщательным образом изучена, поскольку с большой вероятностью содержит «рисунок» будущих неудач в профессии. Грубо говоря, никакие референции к отсутствию интересных задач, токсичной атмосфере в коллективе, низкому уровню оплаты труда, недостатку уважения и прочие здесь не проходят.
Программист, ведущий программист, архитектор ПО
В процессе накопления опыта в программировании и специальных знаний в предметной области стажер становится квалифицированным специалистом. Как правило, здесь нет никакой инициации, посвящения в «настоящие» программисты. Как-то незаметно, с каждым, пусть небольшим, но успехом меняется отношение окружающих к сотруднику и в какой-то момент он уже понимает, что может делать сам, без чьей либо помощи и контроля.
Также в процессе меняется отношение к своей работе, от ответственности непосредственно за свои действия к ответственности за работу обслуживаемого программного комплекса. Иными словами, от поставщика услуг по конфигурированию программного комплекса он становится как бы поставщиком услуг этого самого программного комплекса. Этого может не случиться, но, как правило, случается. И с этого момента от накопления знаний и опыта в программировании и предметной области сотрудник переходит к накоплению ценности создаваемой им архитектуры.
В отличие от стажировки, этот процесс может длиться десятилетиями. И если в ходе стажировки сотрудник становится все более независимым специалистом, то в данном случае наоборот: программист, архитектор все больше входит в зависимость от созданной им архитектуры, возможно, уникальных, присущих только ей методов и подходов к решению рутинных задач.
Частые смены работы в этот момент могут сигнализировать об отсутствии у сотрудника способности или желания вкладываться в развитие программной архитектуры. Он заскочил, потыкался носом в проблемы и выскочил. Обратное тоже верно. Есть много фирм с крупными проблемами в архитектуре используемых программных комплексов, большим техническим долгом, которые бесконечно «крутят» вереницы «программистов на год» без возможности сдвинуться с места в решении своей проблемы.
Редкие смены работы, с одной стороны, сигнализируют о том, что сотрудник умеет и, главное, готов вкладываться в архитектуру и функционал приложения. С другой стороны, вероятно, этот сотрудник некоторое время будет испытывать серьезные затруднения на новом месте ввиду того, что ему потребуется погрузиться в ситуацию, догнать ушедший от него прогресс в отрасли, пока он занимался отладкой механизмов на прежнем месте работы. Тут еще возраст будет иметь значение.
Как правило, чтобы оставаться «актуальным», специалист меняет рабочие места примерно раз в 5 лет, переключаясь от изучения нового ко вкладу в архитектуру и наоборот, с последующим выходом на более длинный цикл. Вот здесь, на данном этапе, можно услышать от кандидата жалобы на недооцененность на предыдущем месте работы, использование устаревшей архитектуры и неинтересных задач.
Причем, чем больше вовлеченность и вклад в архитектуру программного комплекса, тем стенаний будет меньше. В то же время, верно и то, что бизнес «не раскошелится» на новый программный комплекс или обновление программной платформы, если все работает хорошо и только потому, что их программист «заскучал».
Иерархия «Программист» – «Ведущий программист» – «Архитектор программного обеспечения» может не присутствовать в полной мере даже в крупной компании. В таком случае, деятельность и ответственность отсутствующих членов иерархии распределяется между нижними уровнями. Другими словами, при отсутствии архитектора его функции выполняет ведущий программист, не выделяя это в отдельный процесс и не подтверждая его выполнение какими-либо артефактами.
Руководитель отдела
Сотрудник в этой должности одновременно вкладывается в свой профессионализм как руководителя отдела и в отношения на предприятии – даже в большей степени. Со вкладом в отношения растет их ценность, поэтому цикл здесь может быть долгим и причина разрыва, как правило, в отношениях, в сложности прохождения сотрудником какой-то ситуации.
Важно понять, что это за ситуация, потому что, единожды непройденная ситуация будет повторяться до тех пор, пока не будет правильно разрешена. Также важно понять, насколько эта ситуация осознана самим сотрудником и какое им принято в связи с этим решение.
Если руководитель отдела в причинах увольнения называет свои достижения на предыдущем месте работы и сетует на отсутствие интереса, возможно, перед вами проектный менеджер. Это не значит, что он вам не нужен, скорее, он вам не нужен на должности руководителя отдела.
Менеджер проекта
В отличие от программистов, которыми становятся, менеджерами проектов рождаются, как правило, в муках. В отечественной IT-отрасли менеджер проекта все еще экзотическая профессия. Имеющих специальное образование в этой области – еще меньше. Как правило, на предприятии роль менеджера проектов выполняют руководители IT-отделов. И первое, с чем они сталкиваются на этом поприще, – с осознанием того, что это совершенно другая деятельность.
Возможно, набив шишек в новом качестве, вложившись в свое профессиональное развитие на этом направлении, такой руководитель может принять решение, насколько ему интересно вести проектную деятельность, по сути, управлять предприятием на ресурсной базе другого предприятия, иметь особое отношение руководства, собирать бонусы и прочие ништяки в случае успеха.
Этот сотрудник также вкладывается в отношения на обслуживаемых предприятиях, но находится в более независимом в рамках проекта положении. Здесь может и не быть кропотливой и терпеливой работы с отношениями руководителя отдела. Менеджер проекта может провести «рекогносцировку на местности», оценить риски и «отскочить». Руководитель отдела отскочить не может.
Менеджер проекта, как правило, всегда «при деле» и «многостаночит» по-черному. Он должен быть успешен. Нет смысла смотреть на периоды его работы на предыдущем месте.
Руководитель проектного офиса
В любой компании быть руководителем проектного офиса – это навсегда. Он «растит» компанию с «младенчества» и любой успех или неудача проекта в области его ответственности. Наверное, единственная причина его выхода на рынок труда – различия в отношениях к рискам его и руководства с предыдущего места работы.
Выводы
В процессе работы IT-специалист вкладывается в свой личный профессионализм, в отношения или в IT-инфраструктуру или во все одновременно. Причем, если вклад в собственный профессионализм делает его независимым, то вкладывая во все остальное, он все больше становится зависимым от текущего места работы и «чаша весов» за то, чтобы остаться, становится все тяжелее.
Скрупулезный анализ каждой ситуации увольнения сотрудника с занимаемых им в прошлом должностей позволит выявить его систему приоритетов и, возможно, более достоверно укажет на его карьерный план, чем он сам об этом расскажет на собеседовании. Сравнить предполагаемый уровень зрелости сотрудника и его фактическую и декларируемую мотивацию. Позволит отсеять «летуна» или человека неглубокого или случайного в профессии от настоящего «сокровища». Понять, где у него были моменты «обучения», выявить еще на этапе собеседования проблемные места в его характере и при положительном решении о найме заранее наметить корректирующие действия.
Фото: freepik.com
Также читайте:
У меня было несколько проектов "замещающий аутсорсинг". Это когда я начинал проект в роли "Руководитель проектного офиса" со своей бригадой менеджеров и экспертов. В ходе проекта наши менеджеры, эксперты передавали компетенции сотрудникакам заказчика и, по мере готовности оных, включали их в состав проектного офиса, а своих сотрудников выводили из проекта. В последнюю очередь также, передав компетенции назначенному сотруднику заказчика, покидал проект и я. Каждый из этих проектов длился гораздо меньше двух лет. Вероятно мой преемник в проекте и станет "– это навсегда", но у меня в резюме будет 4 - 5 проектов в роли "Руководитель проектного офиса" в разных компаниях...
...и, к стати, во всех компаниях затраты на онбординг оказались мизерными, т.е. стоимость процессов учета и анализа затрат на онбординг оказывались выше самих затрат.... стоит ли их упоминать?
Хорошая статья!
Автору удалось описать опыт и понимание отрасли.
Замечу следующее.
Подобные выводы неоднозначны. Может быть сотня причин смены работы - несовпадение ожидания, близость к дому, личные неурядицы. Не всегда такие причины люди готовы откровенно назвать. С программистами-стаждёрами я тоже несомненно сталкивался, но это скорее уступка работодателя в его сторону. Или желание сэкономить. Или неверние в своё продукт, бывает и такое.
Обратил бы внимание ещё на одну сторону. В государственных или окологосударственных организациях путь от программиста к ведущему или главному специалисту предполагает расширение полномочий и ответственности. А вот в коммерческих - это просто некоторое пооощрение за "многолетний труд".
Я в принципе сторонник не обращать внимания на детали прежнего опыта. Опыт - да, интересен, а детали - ерунда. Давным-давно отношусь к программированию как к довольно рутинной работе. Раздутые сложности, выдуманные умения, ореол таинственности. Всё это в прошлом.
Обычная работа.
Все верно. Судя по тому, что вы сказали - это проект по запуску проектного офиса. Он изначально имеет сроки и критерий завершения, с последующим высвобождением ресурсов.
А по ступенькам "лестницы качества" в управлении проектами компании "побежала" уже другая команда...
Благодарю!
Исключения, конечно, могут быть. И то, о чем я говорю, это - даже не правила. Это, скорее, метод, который поможет узнать о кандидате что-то, что он сам не скажет и, возможно, даже не знает, потому что не задумывался об этом. Или не поможет. Только и всего.