Дороги много; только ты можешь выбрать тот, который взять
Если вы считаете, что процесс найма технических специалистов в вашей компании или отрасли в целом достаточно хорош, этот пост для вас.
Льюис Кэрролл написал в« Алисе в стране чудес : Если вы не знаете, куда идете, любая дорога может привести вас туда . В дополнение к этому, если вы не знаете, куда идете, вы пойдете по дороге, по которой все уже прошли.
В наши дни есть общие закономерности того, как компании нанимают. Некоторые из этих шаблонов могут не принести ожидаемого результата. В этом посте я расскажу о наиболее распространенных проблемах и решениях ролевой рекламы процессов технического найма.
Если вы не знаете, куда идете, любая дорога может привести вас туда, в то же место, где уже были все остальные.
Cargo Cult Programming - это когда вы добавляете код в проект, не понимая его. Легкий способ определить Cargo Cult Programming - это когда кто-то чрезмерно увлечен фреймворками. Фреймворки диктуют, как вы должны разрабатывать свое программное обеспечение в заранее заданном фрейме. Однако проект редко умещается в произвольном фрейме. В большинстве случаев программный проект требует другой архитектуры и другого дизайна для устойчивого развития.
Избегайте приема на работу людей с большим опытом работы с фреймворками и небольшим опытом в разработке программного обеспечения. Если вы этого не сделаете, вы закончите тем, что каждый проект в вашей компании будет использовать эти фреймворки, даже если они не подходят.
Если вы намерены сократить долгосрочные затраты на процесс разработки программного обеспечения и добиться отличных результатов, вместо рекламы на досках вакансий для людей, которые знают конкретную структуру или технологию, такую как Angular, .NET, React, Redux или интерфейс, рекламируйте роли для поиска фундаментальных навыков, таких как предметно-ориентированное мышление, дизайн программного обеспечения или функциональное программирование.
Нанять разработчиков с фундаментальными навыками обходится дороже, и им требуется больше времени, чтобы ознакомиться со стеком технологий. Несколько лет назад Gitlab столкнулся с дилеммой, когда они подумали о том, чтобы нанять разработчиков, не являющихся Ruby, только для того, чтобы отступить и нанять специалистов, основанных на технологии, чтобы проявить осторожность.
Однако один разработчик с фундаментальными навыками со временем создает более устойчивую ценность, чем несколько разработчиков фреймворков или технологий.
Нанять разработчиков с фундаментальными навыками сложно. Это непростой шаг. Вам нужна смелость, чтобы идти по дороге, по которой еще никто не шел.
Нанимайте людей с фундаментальными навыками, а не с базовыми или технологическими навыками
Была эта компания, в которой работало 34 сотрудника. В той же компании также было 34 должности, а это значит, что у каждого человека в организации был свой титул. Названия варьировались от Express Developer и JavaScript Ninja до DevOps Engineer и API Influencer.
Вместо того, чтобы придумывать сумасшедшие названия ролей и часами раздумывать над тем, какое имя должно быть у каждой роли, предпочитайте называть всех разработчиками после того, как они присоединятся к компании. В конце концов, каждый несет ответственность за помощь в разработке программного обеспечения, независимо от своей предыдущей должности или навыков.
Однако при рекламе роли вам может потребоваться указать значимые заголовки; в противном случае правильные люди могут никогда не найти его в рыночном хаосе. Однако, рекламируя роль, указывайте в описании, в которой компания нуждается в данный момент, а не технические навыки, которые, по вашему мнению, необходимы компании. Например, кандидат, имеющий опыт работы в командах коучинга, или кандидат, имеющий опыт проектирования систем в финансовой сфере, а не Front-End разработчика или Java-разработчика.
Исключением из технологической рекламы является ситуация, когда компании срочно нужен кто-то для обслуживания устаревшей системы. Иногда единственный человек, который мог поддерживать систему, уже уволился из компании, и ничего не поделаешь.
Рекламируйте роль технических характеристик, которые вы ищете, а не технических навыков.
Крайне важно избегать рекламы технических навыков, которые, по вашему мнению, необходимы компании. Кандидат может быть не знаком с данной технологией, но он может предложить лучшие решения существующих проблем компании или может видеть проблемы, которые никто не видит.
Хороший пример - когда компания разрабатывает план по созданию мобильной версии своего веб-продукта. Веб-сайт представляет собой тяжелый интерфейс на основе JavaScript с бизнес-логикой, написанной на React и Redux. В этом случае широко распространена идея рекламировать роли для разработчиков iOS / Android. В этом есть смысл.
Если вы хотите создать приложение для iOS или Android с некоторой степенью сложности или сложности, вам нужно нанять кого-то, кто уже был там раньше. Однако вы уже предполагаете, что вам нужен кто-то, кто написал бы код для iOS или Android; что, если в этом нет необходимости?
Вместо того, чтобы рекламировать роль разработчиков iOS / Android, вы можете объявить, что вам нужен разработчик для создания мобильной версии существующего веб-продукта. Если вы сделаете это, вы можете привлечь разработчиков, которые понимают основы, лежащие в основе Jasonette, например, и которым не нужно писать ни одной строчки на Java или Objective C для повторного использования интерфейсной бизнес-логики в мобильном приложении. Это может быть на порядки более рентабельным, чем создание всего с нуля.
Вы, вероятно, не знаете всего о проектировании протокола HTTP, эволюционируемых API-интерфейсах, Jasonette, функциональном программировании, поиске источников событий или проектировании, основанном на событиях; так что перестаньте притворяться, что знаете, какие именно навыки нужны проекту.
Лучше, чтобы в проекте было разнообразие: люди, которые не похожи на вас. Если у людей разный набор навыков, разный образ мышления и разный опыт, у вас больше шансов добиться лучшего результата.
Если вы рекламируете только те технологии, которые вам известны, вы превзойдете разнообразие и в конечном итоге получите таких же разработчиков, как вы, а не лучше.
Наем технических специалистов - дело сложное и дорогое.
Большинство программистов оптимизируют свои навыки для технологий и фреймворков. Наем сотрудников, обладающих фундаментальными навыками, - лучший способ разорвать кругозор и привнести больше инноваций, если вы готовы внести значительную предоплату.
Если вы нанимаете людей с теми навыками, которыми обладаете, в конечном итоге вы получите только тех, кто не может принести значительную пользу вам или компании. Откажитесь от эгоцентрической мысли о том, что вы знаете, какая практика или технология нужны компании. Там есть кто-то, кто знает решение проблем, которых вы не знаете, и этот человек не будет похож на вас.
Если вы не знаете, по какой дороге идете, и вам нужна помощь, обязательно сообщите об этом. Рекламируйте проблему, а не технологию. В противном случае вы выберете дорогу, которая приведет вас туда, где все уже были.
Идти по этой дороге - все равно что никуда не двигаться.
Спасибо за прочтение. Если у вас есть отзывы, напишите мне в Twitter, Facebook или Github.
Спасибо Клеристону Бернардесу и Яну Тинсли за их полезный вклад в этот пост.
Хотите пообщаться лично? Вы можете найти меня на встрече разработчиков программного обеспечения в Сиднее.
