В этом материале разберем комплексную проблему младших специалистов — почему они стали не нужны бизнесу, чем это может навредить всей индустрии, и чем здесь может помочь аутстаффинг.
Почему не хотят нанимать джуниор-разработчиков
Вакансий для разработчиков все больше, но младшим специалистам непросто получить приглашение на собеседование. Почему так?
Сложный вход в профессию
С одной стороны, появилось много высокоуровневых языков программирования и готовых инструментов, с другой — усложняется структура приложений, требуется знать и уметь больше. Раньше любой веб-разработчик умел верстать и пользоваться JQuery, сейчас сформировалась отдельная специализация фронтенд-разработчика, который должен ориентироваться среди фреймворков и отличать Nest.js, Next.js и Nuxt.js.
Избыток «вайтишников»
Зарплаты разработчиков растут, на рынке дефицит кадров — люди из других отраслей ищут способы «войти в IT». Ситуацией пользуется рынок онлайн-образования. Реклама курсов программирования обещает блистательную карьеру и высокую зарплату. Работодатели же к выпускникам относятся настороженно из-за качества самих курсов, а также из-за завышенных ожиданий — соискатели без опыта сразу хотят много денег, при этом мало могут предложить взамен.
Туториальный ад
Проблема с онлайн-курсами, платными или бесплатными, не только в завышенных ожиданиях, но и в том, что это просто контент, набор инструкций. На курсах повышается осведомленность — студент что-то слушает, читает, пробует, но по мере продвижения обучения в этом все меньше пользы, потому что не нарабатывается навык. Студент без попытки разобраться бесконечно копирует проекты из туториалов, что никак не готовит его к реальным коммерческим задачам.
Упущенная прибыль
На первых этапах джуниор-разработчик отнимает много времени — его нужно направлять, проводить код-ревью, возвращать неоптимальный код на доработку. Продуктовые компании редко могут позволить опытным разработчикам тратить время на наставничество, потому что в этом нет прямой выгоды бизнесу.
Аутсорсинг и автоматизация
Простые задачи компании предпочитают отдавать на аутсорсинг внешним исполнителям. Многое из того, что разработчикам десять лет назад приходилось делать вручную, и можно было доверить младшим специалистам, сейчас автоматизировано, а благодаря алгоритмам машинного обучения и программам вроде Copilot ситуация только усугубится.
Распределенные команды и удаленка
Пандемия заставила многие компании резко перестроиться под удаленный формат работы. Хлопот с новым форматом хватало и без адаптации и обучения стажеров. От них решили совсем отказаться или вернуться к найму позже, так как младшие позиции традиционно легче всего закрыть.
Как это влияет на кадровую экосистему
Внезапный спрос на разработку означает, что компаниям необходимо масштабироваться, продолжать внедрять инновации, чтобы сохранить лидерские позиции. Для этого им нужны опытные инженеры. Лучшие из лучших. Таких сотрудников можно взращивать, что очень долго и затратно, либо нанимать готовыми. Вторая стратегия подразумевает переманивание кадров из компаний на ступень ниже.
Ведущие компании нанимают самых талантливых разработчиков, предлагая им более высокую зарплату, крупные предприятия нанимают разработчиков, которые не могут получить работу в ведущих компаниях, и так по цепочке. Замыкается цепь на агентствах и аутсорс-продакшнах, которые взращивают кадры.
Аутсорсинговые компании всегда выступали для рынка как кадровые доноры. Но сейчас эта модель перестает работать. Все дело в том, что младший разработчик — это инвестиция, а с учетом того, как часто программисты меняют работу в этой отрасли, это может быть рискованным вложением.
Например, компания нанимает младшего программиста, вкладывается в его обучение — платит зарплату и первые месяцы не получает никакой коммерческой выгоды. Более того, компания жертвует временем более опытных разработчиков и упускает часть прибыли. Как только специалист получает первый опыт — его переманивают на зарплату повыше, не дав компании успеть заработать.
Нарушается цикл обучения, компании дестабилизируются. Если раньше у компании был шанс получить внутри senior-специалиста, чтобы продолжать академический конвейер, то сейчас эти возможности тают. В итоге это приведет к тому, что вся экосистема перестанет насыщаться кадрами. Этот феномен известен как трагедия общих ресурсов: отдельные компании получат краткосрочную выгоду, но в долгосрочной перспективе все понесут большие потери. Если из озера выловить всю взрослую рыбу, то не будет и потомства.
Кризис сениорности
Побочным эффектом стратегии переманивания становится то, что реально опытных разработчиков сложно отличить от разработчиков с выслугой лет.
В IT частая смена работы стала своего рода нормой. Рекрутеры закрывают глаза на то, что программист не задерживался на одном месте больше года, а иногда и полугода. Но что в действительности означает частая смена работы в IT?
Опыт нарабатывается циклично, и важнейший этап цикла — получение обратной связи. В разработке цикл получения обратной связи это не код-ревью отдельного коммита, а полный цикл — от формализации функциональных-требований до поддержки системы в эксплуатации.
Именно в течение всего жизненного цикла проекта разработчик приобретает по-настоящему ценный опыт и понимание общей картины. Сюда входит написание кода, управление изменениями, тестирование, развертывание, поддержка и доработка решений, которые были придуманы на этапе проектирования. Также это дает более глубокое понимание индустрии и принципов взаимодействия с другими командами. На серьезных проектах это может занимать годы.
За меньший срок разработчик не успевает пройти полный цикл и получить опыт, его знания не преумножаются. На каждом новом месте разработчик повторяет одну и ту же работу. Вместо цельных десяти лет опыта получается один и тот же год опыта, умноженный на десять.
Индустрия научилась вознаграждать инженеров за посредственные или не поддающиеся количественной оценке результаты. Чтобы прочувствовать этот момент, вспомните, сталкивались ли вы с празднованием по поводу релиза, который превысил бюджет, отстал от графика и содержал ошибки? А сколько компаний отказываются от поддержки системы в пользу полного переписывания и повторяют этот цикл позже? При этом разработчики продвигаются дальше по карьерной лестнице.
Второе неприятное последствие называют эффектом «мертвого моря». Суть в том, что попадая в бюрократизированную среду корпораций, талантливые инженеры уходят из найма. Часто им становится скучно в найме, и они становятся независимыми консультантами, авторами книг, участниками конференций, создателями технологий и продуктов для профессионального сообщества. В общем, они перестают быть штатными сотрудниками.
И последнее — чтобы стать старшим разработчиком, нужно уметь работать в команде с менее опытными специалистами, помогать в декомпозиции и распределении задач, координировать командную работу. Без такого опыта сениором стать не получится. Старшие разработчики продвигают лучшие практики, инициируют обсуждение проблем, советуют другим, что и как можно улучшить. Если в компании нет младших специалистов, то не будет и культуры обмена знаниями, что приведет к стагнации.
Манипуляция грейдами
Профессиональных разрядов в IT нет. Здесь принято делить специалистов на три категории — junior/middle/senior. Это достаточно грубое упрощение. Например, популярная дрейфусовская модель приобретения навыков включает шесть ступеней:
- Новичок
- Продвинутый начинающий
- Компетентный
- Опытный
- Эксперт
- Мастер
Такое количество ступеней можно встретить много где, например, в изучении английского языка:
- A1 Beginner
- A2 Elementary
- B1 Intermediate
- B2 Upper-Intermediate
- C1 Advanced
- C2 Proficiency
Разумеется, и в IT многие приняли более расширенную шестиступенчатую градацию:
- Junior
- Pre-middle
- Middle
- Middle plus (strong)
- Senior
- Lead / Architect
Даже такое расширенное толкование не спасает от фундаментальных различий в восприятии. PHP-разработчик в студии, которая по принципу конвейера делает сайты на популярных CMS, может внутри коллектива считаться старшим специалистом, но не пройдет по параметрам на джунскую вакансию в продукт или продакшн. Отрасли не хватает стандартов, поэтому каждый трактует грейды выгодным для себя образом.
Как спасти ситуацию с помощью аутстаффинга
Нередко случается так, что перед CTO или техлидом становится задача по подбору команды. Руководство настаивает на найме опытных разработчиков, так как нет административного ресурса для обучения джуниоров. При этом не все задачи на проекте требуют большого опыта или глубоких знаний, оверквалифайд разработчикам с ними скучно.
Классический аутсорсинг может не подходить по причинам выбранной методологии разработки, внутренним процессам. Возникают слишком большие издержки на то, чтобы формализовать делегируемые задачи, обозначить границы ответственности и критерии готовности. Иными словами, нет возможности отдельно составлять ТЗ, проводить приемки этапов и заморачиваться с другими нюансами проектной разработки под ключ.
В такой ситуации следует задуматься о лизинге персонала, аутстаффинге IT-специалистов. За 2021 год такой формат сотрудничества показал свою эффективность при точечном усилении команд специалистами среднего уровня, но почему-то до сих пор вызывает сомнения, если речь заходит о младших специалистах.
Во многих аутсорс-продакшнах есть свои академии и системы обучения. Кандидаты проходят отбор, стажировку под присмотром наставника, выполняют учебные проекты. Длительность стажировок и качество обучающих программ может отличаться, так как у всех поставщиков разное представление о грейдах и требованиях к специалистам. Но если найти надежного поставщика, с которым вы совпадаете по оценке навыков, то проблему получится решить надолго.
Основной страх при аутстаффинге младших специалистов обычно состоит в том, что заказчик обучает разработчика, а поставщик снимает сливки.
Как мы уже описали выше, это не совсем так. Во-первых, заказчик получает прямую выгоду для себя, потому что специалист пишет код и выполняет задачи. Во-вторых, есть и неочевидная косвенная выгода — инхаус команда продолжает развиваться, выполняя задачи, которые соответствуют их уровню, и оттачивая навыки управления с отчетливой вертикальной структурой технического отдела.
Для повышения вовлеченности работают все те же инструменты, что и при найме, поэтому не бойтесь менторить аутстафферов, не бойтесь давать им доступ к своей инфраструктуре и базам знаний. Вы получите проактивного специалиста, который будет вовлечен в ваш продукт. А когда его навыки превысят ваши потребности, поставщик предоставит нового, и цикл повторится. Это настоящие win-win отношения.
Чек-лист: проверьте себя и поставщика
Если вы решили попробовать аутстаффинг младших специалистов, то проверьте, подходит ли вам такое решение. Прежде чем выбирать поставщика, убедитесь, что у вас есть:
- Опыт работы в распределенной команде: на проекте имеются регламенты по онбордингу удаленных сотрудников, зафиксированы ответственные лица и каналы коммуникации;
- Проектное управление: налажен процесс командной работы, есть четкая приоритизация задач, ведется документация, есть инструкции по развертыванию проекта, гит-флоу, требования к код-стайлу;
- Бизнес- или системный аналитик: большим плюсом будет, если задачи поступают не от бизнеса напрямую к команде, а от аналитика, который занимается составлением функциональных требований;
- Процесс отбора: у вас готовы вопросы для технического собеседования, которые соответствуют уровню кандидата, либо небольшие практические задачи для проверки кандидата.
При выборе поставщика обратите внимание на следующие нюансы:
- Штатные сотрудники: специалисты являются наемными сотрудниками и официально состоят в штате компании поставщика;
- Система стажировок: у поставщика есть четкая программа обучения, максимально приближенная к коммерческой разработке, уровень выпускников стабилен;
- Пробный период: поставщик готов разделить с вами риски на случай, если разработчик не подойдет;
- Подробная отчетность: поставщик ведет подробный учет времени сотрудников по задачам до минут, отчеты предоставляются еженедельно;
Бизнес-модель любой аутсорсинговой компании строится на том, чтобы продать работу дороже, чем ее себестоимость. В классической проектной разработке это возможно за счет эффективного распределения задач между специалистами разной квалификации, когда большую часть работы выполняют младшие разработчики. В случае аутстаффинга это возможно за счет региональной разницы в уровне оплаты труда, а также вложений в отбор, найм и обучение сотрудников, которые остаются на стороне поставщика.
Привлекать на аутстаффинг младших специалистов уместно, когда нужно выполнять небольшие объемы работы, для которых нет смысла нанимать специалистов в штат, оснащать их всем необходимым и проходить этапы командообразования.
