Стажировки для студентов есть во многих IT-компаниях (Nexign — ранее «Петер-Сервис» — не исключение). Само собой очевидно, что большинство стажёров рассчитывает на дальнейшее трудоустройство в штат. Но как представляют себе дальнейшую работу будущие IT-профи и насколько эти представления совпадают с ожиданиями компании — и современной действительностью?

Дело в том, что представления многих вчерашних выпускников с небольшим опытом работы (либо вовсе без оного) о том, каким должен быть «настоящий» программист, зачастую отстают от реальности на порядочное количество лет. На практике же портрет IT-специалиста, востребованного сегодня, уже слабо соотносится с традиционным образом угрюмого интроверта в драном свитере.

Так как же выглядит айтишник, который нужен нам здесь и сейчас?

От сепарации к full-stack

Самое, наверное, пугающее, с чем приходится сживаться молодым специалистам — это постепенная диссоциация самого понятия «программист». Такая тенденция пока не проявляется повсеместно, но в крупных и современных компаниях дело идёт именно к тому. «Программист» — это всё меньше профессия и всё больше — роль, причём лишь одна из потенциально многих.

Речь не про то, что программиста обязывают надрываться на всех фронтах одновременно. Суть в том, что он способен на это. Современный разработчик в состоянии подключаться к разным фазам работы над проектом — он может и анализировать, и тестировать, и оказывать «неотложную помощь», и доставлять продукт клиенту. И, кстати говоря, мнение о том, что девелопера надлежит держать как можно дальше от бизнеса, всячески оберегая тонко настроенную «технарскую» психику от внешних возмущений, тоже устарело. На стороне клиента, между прочим, сидят те же самые разработчики. С кем им общаться по техническим вопросам? Явно не с отделом продаж.

Здесь у некоторых выпускников возникает закономерный вопрос: как один человек может совмещать в себе все эти роли? И на скольких, в таком случае, ядрах должен работать его внутричерепной процессор?

Качаем базу

Как ни банально это прозвучит, основа всему — знание основ. Хорошее, верное понимание фундаментальных принципов и понятий — алгоритмов, БД и той же математики — нужны начинающему разработчику несомненно. Каверза заключается в том, что в нашей индустрии специалисту в некотором смысле приходится плыть против течения: срок жизни технологий постоянно сокращается. Любые новинки, — к примеру, конкретные фреймворки, — через несколько лет уже никому не нужны. На фронтэнде и вовсе постоянно всё течёт и изменяется. В итоге остаётся — что?

Остаётся тенденция к знаниям высокоуровнего порядка, абстракциям, системному мышлению. И база. Глубокие познания — это очень хорошо, когда под ними подразумевается общеинженерная подкованность. Глубокие знания java… Тоже неплохо, конечно. Но это — не стратегическая позиция.

Приходится признавать, что сегодня мультидисциплинарность, широта кругозора, сильные soft-skills и способность к синергии, как правило, перевешивают экстремально глубокие экспертные знания конкретной области. В наши дни анекдотичный замкнутый гик-кодер — это, вообще говоря, тупик. Даже если он разбирается в славных трудах Г. Шилдта в десять раз лучше самого Г. Шилдта. Само собой, и такой гений-одиночка найдёт своё место, но для этого от него потребуется быть, как минимум, знатно выдающимся талантом в своей области. Да и в этом случае карьерный рост будет, скажем так, осложнён.

Всё вышесказанное в полной мере касается молодых специалистов. Если вы хорошо владеете одной технологией, пусть даже пиковой (выучили Python), это более-менее нормально для первого места, куда вы трудоустроитесь. Но тогда нужно воспринимать это место как стартовую позицию не только для работы, но и для долгого упорного саморазвития.

Не кодом единым

IT-специалист — это не только и не обязательно программист. Ведь так? Или…

Во времена не столь отдалённые жили-были те, кто знал, как писать код. Позднее появились те, кто знал, как этот код проверять. И это было очень важно и нужно, когда повсеместно применялось ручное тестирование — чего сегодня мы уже не наблюдаем. В нашей компании, как и во многих других, позиции специалиста по ручному тестированию уже нет. И грустно было бы у нас тем тестировщикам, которые «не хотят ничего кодить, а хотят чёрный ящик».

Ещё были те, кто знал, как работать с требованиями. Звались они аналитиками, и задачей их было донести пожелания заказчика до тех, кто пишет код. Для чего, конечно, было нелишним разбираться в предметной области — но, в общем и целом, эти люди служили чем-то вроде промежуточного звена, амортизатора между клиентом и нежным мыслительным аппаратом кодера.

Сегодня системы непрерывно усложняются, и от аналитика ждут на порядок большего. Да, аналитик — это по-прежнему своего рода интерфейс, который компания-разработчик выставляет наружу для приёма-передачи сигналов извне. Но в первую очередь это человек, который ускоряет реализацию бизнес-решений. Что уже совершенно не возможно с одним только умением управлять требованиями. Аналитику приходится не только моделировать, анализировать и синтезировать, но и разбираться в том, что сотворят разработчики — настолько, чтобы говорить с ними на их языке и чётко понимать, в каких местах система работает не так, как должно. А в идеале ещё и хоть сколько-то понимать в проектировании интерфейсов.

Даже программисту надо видеть конечных потребителей и знать, что им надо. Даже тестировщику приходится писать код. А от аналитика требуется понимание общего устройства, архитектуры, функционала и интерфейса системы, да плюс ещё умение протестировать её работу на соответствие требованиям заказчика. Уже сейчас грань между архитекторами, системными и бизнес-аналитиками стала очень размытой, а в перспективе отдалённого будущего велика вероятность того, что задачи анализа будут брать на себя разработчики.

В итоге мы опять-таки получаем портрет некого сферического инженера — T-шейпера, который имеет некоторое представление и об архитектуре, и о разработке, и дизайне, и о тестировании. И — да, по возможности социализированного, в меру общительного и дружелюбного.



У молодого специалиста, которому впервые озвучили такую парадигму, может возникнуть ощущение, что его призывают поверить в какую-то утопию про сверхчеловека. Которая к нему, новичку, в любом случае никакого отношения иметь не может. Но это не так.

Откуда взять универсального солдата

В нашей компании есть такое подразделение, как Лаборатория учебно-тренировочных проектов. Это подразделение занимается, в том числе, реализацией концепции кросс-функциональных мини-команд — так называемых звеньев. Звенья собираются, правда, не из стажёров, а из специалистов, уже обладающих каким-никаким опытом работы — скажем, в год-полтора.

Выглядит это следующим образом: предположим, к нам на работу хочет устроиться человек с хорошим потенциалом. В нашем понимании это тот, кто достаточно широко охватил ту самую базу, о которой уже шла речь, и при этом активен, заинтересован и готов развиваться. Однако для нужд именно тех проектов, на которые мы набираем специалистов, он не подходит — предположим, не хватает знания конкретных технологий, с которыми работает проектная команда.

Гипотетическая компания «Х» такому соискателю, увы, откажет. Мы же можем предложить ему поучиться немного на базе лаборатории и войти в состав одного из новых звеньев.

Каждое такое звено состоит из 3-4 специалистов, которые работают под присмотром куратора (ментора), но при этом самостоятельны и решают боевые задачи. И в этих-то мини-командах T-shape затребован и задействован на все 100%. Поскольку подразумевается, во-первых, что все члены звена равноправны и способны в случае необходимости взять на себя функции товарищей. А во-вторых — что на выходе эта троица выдаст решение, пригодное к употреблению и именно такое, которое запрашивала продуктовая команда. Кстати, задачу на входе звено получает в виде бизнес-кейса, так что производимая ценность и приёмочные критерии, гарантирующие необходимое качество результата, вполне прозрачны.

Именно в силу его «широкопрофильности» такое звено можно временно подключать к разным командам и проектам (в ходе совместной работы зачастую вспыхивает взаимная любовь, и звено может влиться в команду уже на постоянной основе). Так что атипичный программист будущего — вовсе не белый единорог: он уже весьма реален и реально востребован.

Так вот, возвращаясь к летним стажировкам: в Nexign они проходят ежегодно. И, к слову, по статистике 80% стажёров остаются работать в компании. Но мы весьма тщательно отбираем кандидатов и стараемся приглашать именно тех, кого привлекает путь описанного выше мульти-айтишника. :)

Материалы для публикации предоставили начальник Лаборатории разработки БСС-бокс Александр Золотарёв, главный аналитик Егор Вершинин, начальник Лаборатории учебно-тренировочных проектов Артём Назыров и руководитель центра разработки Лаборатории Михаил Игонин.