Работая в ИТ сфере региона, пережившего массовый исход ИТ специалистов, мы попали в непривычную ранее для фирмы ситуацию, когда спрос на нашу работу растет и ширится, а удовлетворить его уже попросту не кем. Территория нашей локализации сама по себе не очень большая, все игроки ИТ рынка подсчитаны и варятся в общем региональном ИТ котле, видимо поэтому хантить сотрудников у соседей, как-то по провинциальному не принято. Попав в такой бизнес-тупик, мы еще долго сопротивлялись объективной необходимости бросить свой взор в сторону образовательных учреждений, с целью привлечения студенчества к работе на наших проектах. Причиной тому - гордыня. Мы всегда кичились своим профессионализмом, а разбавлять его дилетантами, размывая завоеванный трудом и потом авторитет, не вписывалось в наши представления об успешном видении бизнеса. Но время шло, мы с тоской смотрели на пролетающие мимо упущенные возможности, и помянув об утопающих и вариантах их спасения, подались в наш региональный университет на свой страх и риск искать сотрудничества. Как оказалось, утечке ИТ мозгов из региона подверглись не только предприятия, но и ВУЗы. А посему, к нашей радости, в глазах руководства университета мы увидели, зеркальное отражение тоски, точь в точь сродни нашей. В общем встретили нас радушно, с распростертыми объятиями, заложив смычку ИТ бизнеса с ИТ обучением. Таким образом, ресурсный голод толкнул меня на тропу преподавательской деятельности. Я и до этого практиковал обучение, но среди действующих ИТ специалистов, повышая их профессиональный уровень отдельными внесистемными тренингами. А тут мы подрядились сразу на ведение двух предметов, которые надо было читать системно, на протяжении года, шаг за шагом приближая студентов к совершенству. Работа длительная, стратегическая, ставшая для маленькой такой компании, как наша, настоящим вызовом. Но, как оказалось, и в таком подходе можно отыскать множество своих плюсов. Из полуфабриката Айтшника с абсолютно не зашоренными стереотипами мозгами, чистыми бескорыстными душами, ежесекундно рвущимися в бой, оказалось можно лепить сотрудника по образу и подобию, воображаемого нами идеала специалиста.
Вы не любите студентов? Вы просто не умеете их готовить.
Последние лет 15 в ИТ отрасли я занимаюсь системным анализом. Видимо из-за профессиональной деформации, все время пытаюсь все вокруг формализовать, структурировать и объяснять другим. Не стал исключением и мой опыт преподавания в ВУЗе. Поэтому хочу поделиться с Вами своими наблюдениями, выводами и предложениями.
Извините меня методисты и функционеры ИТ образования, но начну я с проблем.
Непоследовательность преподавания знаний
Из моей практики: на 2_ом курсе ВУЗа преподают предмет - «Базы данных», а на 3_ем Проектирование ПО, где как раз и учат проектировать, в том числе те самые хранилища данных. На 4_ом курсе студентам преподают «Компьютерное моделирование» и язык UML (универсальный язык моделирования), который по-хорошему критично нужен был для предмета «Проектирование ПО», каковой, как сказано выше, уже прошли на 3_ем курсе. И так далее. Я не сноб и понимаю, что в принципе можно организовать обучение и в таком (не совсем последовательном) порядке. Но для этого необходимо четко сориентировать студентов на то, что какие-то связанные компетенции они будут получать позже, анонсируя для них краткий, сжатый обзор, подогревая интерес, давая прочувствовать студенту нехватку знаний и инструментов для комфортного и эффективного выполнения работ по текущему предмету.
Оторванность преподаваемого материала, от понимания реальной применимости полученных знаний в решении реальных (не учебных) задач
Недавно, читая курсы повышения квалификации молодым ИТ аналитикам выяснилось, что они в стенах ВУЗа изучали системный анализ. Но вот что означает понятие Система и какими свойствами она характеризуются, они не имеют ни малейшего представления. Зато точно вспомнили, что на предмете в экселевских таблицах рассчитывали по каким-то формулам..., а вот о чем были те формулы, вспомнить так и не удалось.
По факту, большинство курсов в ВУЗах преподается, как сухая теория с практическими занятиями напрочь оторванными от реальности. К примеру, курс проектирования в UML дается без тренировки применения диаграмм в реальных проектах. В частности, для оптимизации своего конкретного хранилища данных, или для устранения зацикленности своего рабочего (или точнее нерабочего) кода, или для разбора алгоритма сложного процесса, который тяжело охватить целиком своим воображением и т.п. Такая практика лишь закладывает некий фундамент, весьма полезный (на будущее), но без понимания того, как его можно именно сейчас использовать. Знания без понимания того, как ими можно воспользоваться делают процесс обучения тяжелым и непривлекательным, как для студентов, так и для преподавателей.
Особенно негативно просчеты такого стиля преподавания сказываются на компетенции - проектировать ИТ продукт перед тем, как его реализовывать. Азы проектирования вроде прошли, но абсолютно изолировано от процесса воплощения проекта в жизнь. Чаще всего, это два несвязанных предмета, начитывающиеся разыми преподавателями с «разных планет». Видимо поэтому, у большинства студентов в начале процесса создания ПО руки чешутся сразу сесть писать код. А уже позже, у деформированных таким подходом программистов, возникает вопрос, а зачем в проектах нужны архитекторы и аналитики, зачем там кто-то чертит какие-то не нужные диаграммы и схемы? Ведь можно в коде оставить комментарии, и вся архитектура решения станет всем сразу понятна.
Кстати, об архитектуре. Попробовал на свой страх и риск в процессе преподавания предмета «Технологии разработки ПО» дать курс ИТ Архитектуры. Пример тизеров занятий можно увидеть на моем YouTube канале:
Сама тема сложная и вязкая, даже для уже действующих ИТ специалистов. Но оказалось, что молодые, не обремененные излишними шаблонами мозги, быстро и относительно легко ее схватывают. А самое главное, у них возникает пространственное видение компонентов системы. Они начинают осознавать, что ПО не просто монолитный листинг кода, а множество слоев в разных плоскостях. Они с интересом, например, пробрасывают элементы бизнес-слоя через срезы Бизнес-архитектуры, распределяя их по компонентам Архитектуры программного продукта. Естественно, такая сложная тема требует кропотливого отслеживания выполнения работ и корректировки со стороны преподавателя. Пример того, как проходят практические занятия по ИТ Архитектуре для студентов 3-го курса, Вы может увидеть на моем YouTube канале:
Низкий уровень погружения в командную работу и развития эмоционального интеллекта
Глядя на программы ВУЗов для ИТ образования, можно заметить, что в них не принято рассказывать об эмоциональном интеллекте, биомеханике использования эмоциональной (бессознательной) и логической (сознательной) составляющей в процессе выработки и принятия решений. Никто не объясняет тонкости управлении своими и чужими эмоциями в организации социальных сообществ. Навыки социальной адаптации студенты получают в фоновом режиме, при прохождении образовательных программ, без акцентов на понимание почему это происходит именно так. У них напрочь отсутствуют навыки управления своей социальной карьерой в сообществе.
Большинство ВУЗов воспитывает студентов, как специалистов-одиночек. В течении изучения предмета, непреднамеренно развивается чувство соревнования отдельных личностей, а не командных игроков. Да, иногда точечно организуются командные хакатоны, олимпиады и прочие групповые соревнования, но без упора на дух сплоченности и ответственности за совместный результат. После таких мероприятий у большинства студентов лишь усиливается чувство того, что тянуть на себе еще кого-то не стоит тех «коврижек», что вручили после, в торжественной обстановке.
Я, например, стараюсь при проведение практических занятий, формировать из студентов команды по 4-6 человек на весь курс, со своим лидером, ролями: аналитиков, разработчиков, тестировщиков и т.д. В течении учебного проекта роли могут меняться, в том числе путем естественного отбора. Студенты в таких командах могут наконец почувствовать себя специалистами и начать проявлять эмоции характерные для профессионалов. Это изрядно мотивирует их в процессе и обучения.
Производство специалистов недоучек.
Зачастую ВУЗы закрывают глаза на ситуацию, когда студент работает в ИТ компании вместо получения знаний. Подчеркну мысль: не параллельно, а именно вместо. Студент с гордостью заявляет: «Я не хожу на лекции и практические занятия потому, что я уже работаю ИТ специалистом. Я уже практически равный Вам». Но в результате, оставаясь без фундаментальных знаний, такие горе-специалисты потом пишут код, в котором не может разобраться никто кроме автора. Потому что, например, понятие паттерн его просто не застало на лекциях и лабораторных. У него свой стиль, а вернее, отсутствие всякого стиля и предсказуемости в коде. Чаще всего такой «артельщик» всю карьеру работает на небольших проектах с коротким жизненным циклом. А если бы ему в ВУЗе на ранних курсах разъяснили разницу между процессом создания ИТ поделок и производством серьезных Программных продуктов, возможно ИТ отрасль получила бы еще одного профессионала.
Подготовка ВУЗами спринтеров - ИТ спортсменов на короткие дистанции
Особая гордость ВУЗов – это подготовка призеров всевозможных олимпиад и соревнований. Студентов натаскивают на непродолжительные инновационные проекты, для решения коротких, но трудно решаемых задач. В жизни же большинства ИТ компаний им придется заниматься монотонными, растянутыми во времени работами, зачастую заставляющими возвращаться на исходные позиции для нового прохождения уже протоптанных дорожек. Подготовленные для спринта специалисты быстро выгорают на стайерских дистанциях реальных проектов. Финансовые запросы у таких личностей обычно высокие, а выхлоп в среднестатистическом проекте не очень. Вот и мытарятся они по разным компаниям, блестяще проходя собеседования.
Об успехах системы
Теперь надо обозначить и успехи наших высших учебных заведений в области ИТ, а то подача будет выглядеть как-то однобоко и несправедливо. На сайтах: Министерства цифрового развития, связи и массовых коммуникаций РФ ( https://digital.gov.ru/ru/activity/directions/481/ ), Министерства науки и высшего образования РФ https://www.minobrnauki.gov.ru/ Вы можете найти достоверную информацию о достижениях и завоеваниях нашего образования, и я с ней полностью согласен и поддерживаю во всех начинаниях.
А теперь выводы и предложения
Для решения озвученных выше проблем, хотелось бы, чтобы процесс преподавания в ИТ ВУЗах был организован в виде связанных, последовательных блоков обучения, соответствующих процессу производства ПО.
Для этого:
Во-первых, необходимо структурированность процесс преподавания дисциплин, сопрягая его с самим процессом производства Программных продуктов. Например, от обучения методам сбора и формализации потребностей заказчика, к обучению планирования процесса производства Программного продукта. От проектирования продукта и инфраструктуры для его использования, к методам и способам его реализации и верификации и т.п. А для этого: во-вторых, необходимо с самого начала глубоко «имплантировать» в будущих ИТ специалистов четкое понимание самого процесса и технологий производства программных продуктов, создавая на весь период обучения Технологическую Карту процесса производства ИТ продукта. Далее проводить большую часть дисциплин, как реализацию этой Карты, постоянно привязывая выполняемую работу к ее этапам и вехам. Такая Карта должна быть все время перед глазами во время обучения.
Можно начиная с 3-го курса организовать в ВУЗе, совместно с заинтересованными работодателями, «песочницы» по производству ПО. Не коммерческого, а скорее исследовательского (пилоты, прототипы). Формировать группы (команды) студентов проекта по 3-6 человек, которые должны шаг за шагом за 2 курса (3-4) создать артефакты для получения конечного ПРОДУКТА (ПО или ИТ системы), такие как: Видение проекта, План-график проекта, ТЗ, программный код, сборки продукта, тест кейсы, результаты тестирования, планы разворачивания ПО и т.д. Желательно и защиту диплома производить на базе этого, созданного ПРОДУКТА. Пример работы студентов в пилотном проекте ИТ фирмы Вы можете увидеть на YouTube канале фирмы:
В-третьих, необходимо включить в программы ИТ ВУЗов предметы по социальной инженерии. Психология, социология, командная работа, эмоциональный интеллект и т.п. Организовывать разбор проблем наиболее часто встречающихся моделей поведения молодого специалиста в коллективе ИТ компании. Обсуждать варианты решения проблем, для разных модели поведения. Пример такого занятия Вы можете увидеть на моем YouTube канале:
В-четвертых, желательно отрегулировать законодательство, в части привлечения к работе студентов. Необходимо регламентировать официальный график работы для студентов (не больше 6 часов), способы оплаты и предоставления отпусков и т.д., чтобы упростить и вывести из тени взаимодействие работодателя с проходящими очное обучение в ВУЗах.
Все неравнодушные, добавляйте в комментариях свои предложения и кейсы о том, как эффективнее можно подготовить студентов ИТ ВУЗов в недрах самого ВУЗа.
Видео на эту тему можно посмотреть на моем YouTube канале
