Как меняются формы подготовки IT-специалиста

Сооснователь OTUS Дмитрий Волошин рассказал, как в IT-отрасли меняются формы подготовки специалистов, и почему к сегодняшним айтишникам предъявляются новые требования.

Давным-давно я был разработчиком. Я писал код пользовательского интерфейса на C++, это было трехзвенное приложение для автоматизации производства. Мой коллега в это время писал код процедур и функций на PL/SQL в Oracle 8i, еще один – серверную часть DCOM. Одна барышня создавала тестовые сценарии и прогоняла тесты, еще одна делала модели as is и to be, превращая бизнес-логику в системную. Моя команда пользовалась весьма современным тогда RUP (Rational Unified Processes), мы имели четкую последовательность шагов проекта, описание базовых артефактов. Каждый занимался своим делом. Жизнь была предсказуема и основательна. Я знал, что мое карьерное развитие будет тем эффективнее, чем больше я погружусь в кейсы использования C++.

Каждый участник моей команды имел жесткую специализацию. Она, как правило, определялась в вузе, и 4-5 лет опыта работы были посвящены исключительно развитию в рамках этой специализации. Пройдет много лет и я узнаю, что такой сценарий развития называется I-shape (ай шейп). Этот термин впервые был упомянут в отчете McKinsey & Company, название которого затерялось во времени. Суть его следующая: развитие специалиста осуществляется «вертикально», в рамках узкого «колодца знаний» (Рисунок 1), и тем ценнее специалист, чем больше он «прокопает» этот колодец вглубь. Я был I-shape, вокруг меня были I-shapers, и мы копали и копали с упорством, достойным уважения.

Позже, когда я возглавлял ИТ-бизнес, и моя команда составляла сотни I-shapers, я понял, насколько это сложная история. Во-первых, чтобы сделать продукт, нужно было ОЧЕНЬ много инженеров и специалистов. Фактически, на каждый чих нужен был эксперт. Заказчик требует отличный от типового UI? Будь добр, найми в штат UX/UI-эксперта, даже если он будет загружен всего на 10%. Клиент просит особую логику на стороне БД? Ок, нам нужен DBA, разработчик PL/SQL, а еще один эксперт для fine tuning репликации между экземплярами базы. Это все невообразимо выращивало косты на проект, и приводило к тому, что разработчики зарабатывали меньше, чем могли.

Вторая проблема – это сложности в коммуникациях. Большие команды тем неповоротливее, чем меньше у них общего языка. Узкие специалисты плохо понимали друг друга, их словаря было недостаточно, да и фокус их внимания был у каждого на своем «колодце знаний». Было невероятно сложно «подружить» друг с другом разработчика, администратора, специалиста по тестированию и аналитика. Обычно звучало классическое «к пуговицам претензии есть?». И дело вовсе не в том, что кто-то был плох. Просто интересы разные, и было мало общего, что бы их сближало. Особенно хорошо это ощущалось на длинных «водопадных» проектах, где только согласование ТЗ с заказчиком могло растянуться на год.

Все начало меняться в 1991 году. David Guest (Дэвид Гест) предложил концепцию T-shape, которая частично решала описанные выше проблемы. Ее суть в том, что каждый специалист все еще продолжает прокапывать свой «колодец знаний», но при этом проактивно изучает смежные области. Разработчик учит тестирование и дизайн, аналитик изучает премудрости технического писательства, менеджмента в ИТ и тестирования, администратор растет в области информационной безопасности и data science. Надо отметить, что возможность обучения T-shapers возникла и потому, что ИТ стало более абстрактно и требовало уже меньше фундаментальных знаний. В отрасли стали появляться люди, о ужас, не знакомые с алгоритмами и структурами данных. И это нормально, отрасль становилась более зрелой.

Какие проблемы решило появление T-shapers? Прежде всего, возникла возможность делать меньшие, более подвижные команды. Это потом, уже в 2000-х стал известным Agile и многие выучили аббревиатуру TTM. Только вот мало кто знает, что основу для гибких методологий заложили именно T-shapers, люди, которых в начале 90-х пренебрежительно называли «универсалами». Маленькие гибкие команды понемногу захватили мир, и даже в огромных формальных банках появились трайбы и вот это все. На этом фоне начали расти зарплаты ИТ-специалистов, так как маржинальность проектов, прежде всего, аутсорсинговых, начала расти, и компании стали стимулировать своих сотрудников к развитию «вширь».

Сейчас T-shaper ценится несколькими качествами. Во-первых, знания в смежных или даже отдаленных предметных областях помогают создавать нетиповые решения, решения «на стыках». В современном, конкурентном бизнесе, это свойство – одно из самых ценных. Во-вторых, такой специалист может помочь с развитием проекта в разных его частях и на разных этапах, обеспечивая близкой к 100% утилизацию своего рабочего времени. В-третьих, он экономит время менеджера на разруливании конфликтов: меньше становится недоразумений и затрат, вызванных недопониманием. В-четвертых, такой специалист – ходячий backup для некоторых членов команды. А вдруг Python-разработчика сразит коронавирус? Наш T-shaper сможет подхватить выпавшее знамя и продолжить проект.

И, наверное, самое важное свойство T-shaper – это открытый человек, не боящийся экспериментов, стремящийся узнавать новое. Я хочу отдельно обратить внимание на это качество, так как самое серьезное изменение в отрасли произошло именно тут. Если раньше от ИТ-специалиста ждали работы «от звонка до звонка» в определенной сфере его ответственности, то теперь компании готовы подстраиваться и под гибкий график работы, и под некоторый творческий хаос. Важнее нормативов и формализации стало умение создавать новое, которое базируется на потребности учиться. Учеба, как известно, строится на рефлексии опыта, а значит компании стали более толерантно относится к ошибкам и затратам на поиск.

Три года назад мы начали решать одну из самых важных проблем в ИТ-индустрии: подготовка специалиста уровня middle, который сразу после трудоустройства начинает приносить пользу компании-работодателю, без длительной стажировки с отвлечением дорогих специалистов уровня senior. Нам казалось, что эта задача решается с помощью трех ингредиентов: преподавателей-практиков, входного тестирования и интенсивного обучения с большим объемом самостоятельной работы. Нам казалось, что достаточно 5-6 месяцев, чтобы предварительно отобрав истинных специалистов уровня junior (1-3 года опыта), сделать из них более зрелых экспертов. И мы достигли определенных успехов: примерно 30-40% наших студентов «прокачивались» и мы получали хорошую обратную связь об их уровне знаний от наших компаний-партнеров. По мере увеличения количества наших студентов стало понятно, что идея 5-6 месячного обучения не совсем верна. С одной стороны, большой части наших потенциальных студентов курс был тяжеловат. Все же совмещать работу с интенсивной учебой сложно, а интенсивность на курсах была такова, что не редко студенты даже брали отпуск, чтобы успешно закончить обучение. С другой стороны, формат не предусматривал знакомства со смежными темами. Анализируя запрос работодателей, мы пришли к выводу, что нам надо увеличивать количество курсов, не смотря на то, что часть из них будет не такими «ходовыми», как основные направления: Java, Linux, DevOps, Python, QA automation, Android и другие. Так возникли более специфические курсы, вроде безопасности в Linux, архитектуры и шаблонов проектирования, математики для Data Science и многих других.Сегодня мы полностью пересматриваем модель наших учебных программ. Во-первых, мы создаем учебные треки, посвященные каждому значимому «колодцу знаний». Для каждого из них мы разработали или разрабатываем сейчас три уровня курсов: базовый, углубленный и продвинутый. Таким образом, мы будем готовы приглашать на обучение людей, знакомых с ИТ, но с гораздо более скромным уровнем начальных знаний, и в течение одного-полутора лет «доводить» их до уверенного I-shaper. Тесты, которые мы разрабатывали эти три года, будут служить помощью нашим студентам для выбора того уровня, с которого им целесообразно начинать. Разумеется, треки будут стоить дешевле, чем если покупать три курса «в розницу».Тем студентам, кто захочет стать T-shaper и понимает пользу от этого, мы предложим специализации, состоящие из трека и смежных курсов. Это наборы из 6-8 учебных программ, которые содержат взаимосвязи друг с другом в рамках учебного процесса. Наверное, специализации можно считать подобием магистратуры, и очевидным результатом специализаций будет создание и защита индустриального проекта по задачам наших партнеров. Так же как и с треками, специализация будет стоить дешевле трека и набора курсов по отдельности. Тем же студентам, кто хочет самостоятельно выбирать свою образовательную траекторию, мы предложим годовую и полугодовую подписки (6 и 3 любых курсов соответственно). И, конечно, мы не останавливаемся в создании новых учебных программ, наша цель довести их количество до 150 в течение следующего года-полутора.

У меня для вас новость: в ИТ-отрасли обсуждают новую форму подготовки специалистов, она называет W-shape. Представьте себе, что в одном человеке могут сочетаться сразу несколько T-shapers. Это сложно, но весьма соответствует современному тренду, который называется life long learning. Сколько можно изучить «колодцев знаний» за профессиональную карьеру? Пять, шесть? А сколько можно изучить предметных областей вокруг этих колодцев? Десятки? Наверное, так и будет выглядеть самый востребованный ИТ-специалист будущего (Рисунок 3).