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

Куратор IT-Центра МАИ, советник ректора и руководитель магистерской программы «Интернет вещей» Дмитрий Волошин рассказал на vc.ru, как в IT-отрасли меняются формы подготовки специалистов и почему к сегодняшним айтишникам предъявляются новые требования.

История вопроса

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

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

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

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

Профиль современного IT-специалиста

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

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

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

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

Вместо заключения

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