Предисловие
Всем привет, меня зовут Егор. Совсем недавно я окончил второй курс радиофака УрФУ по специальности «программная инженерия» и сейчас прохожу стажировку в качестве системного аналитика. Одной из особенностей обучения в моем институте является проектный практикум, о котором я и хочу высказать свои мысли в этом тексте.
Спасибо Даниил
Идея написать нечто подобное созрела у меня в голове где-то полгода назад, но я никак не мог решиться. Но вот недавно мой товарищ Даниил высказал свое мнение на счет проектного обучения в этой статье, чем сподвиг и меня. Не со всеми тезисами согласен, но однозначно рекомендую к прочтению
Структура обучения
Сначала вкратце о самом процессе обучения.
Все предметы делятся на обязательные и по выбору. Обязательные предметы - джентльменский набор инженера-айтишника: матанализ, дискретка, компьютерные сети и т.д., конечно же не забуду упомянуть БЖД (или ОБЖ, кому как привычнее). У этих курсов мы можем выбирать преподавателей, сложность и расписание (можно посмотреть расписание пар у групп и выбрать наиболее подходящую группу). С курсами по выбору немного интереснее.
Курсы по выборы делятся на два вида: хардовые (по специальности, например, C++, дизайн интерфейсов и т.п.) и софтовые (психология, маркетинг и т.п.). Курсы проводятся как от университета, так и от партнеров: наумен, банк точка и др. Здесь каждый семестр полная свобода выбора, куда захочешь (и где останутся места на момент записи), туда и пойдешь.
Как все интересно! Раньше такого не было…
Да, действительно, такая модель обучения для России это что-то новое. По крайней мере, среди всех моих знакомых, широко размазанных по вузам страны, ничего подобного нет. И по-моему, это грустно. Такая модель дает удивительную гибкость при обучении. Попробовал фронт? Не понравилось? Ничего страшного, на следующий семестр выберешь DevOps. Учился C++, но ты модный и прогрессивный и хочешь попробовать машинное обучение? Да пожалуйста. И это круто.
Проблемы такого подхода на радике
К сожалению, и на солнце есть пятна. Но пятна «гибкого» обучения разрешимы.
Первое: непонятный первый курс. У нас были общие дисциплины, было программирование на шарпе. Также был очень интересный предмет «профориентация» (точного названия не помню, но суть понятна): приходили специалисты из разных фирм рассказывать о своих профессиях. И это было ужасно. Нет, дело не в специалистах. Просто, очень тяжело объяснить, чем отличается бэк от фронта людям, которые до этого учились только ЕГЭ сдавать. Конечно, были и шарящие ребята, но их мало и в чем интерес слушать такие базовые вещи? И все скатилось в балаган, когда приходил очередной оратор, а его никто не слушал. Грустно.
Вторая причина заключается в отсутствии курсов по аналитике и управлению команды. Подробнее рассмотрим далее, в контексте.
Проектный практикум на бумаге
Каждый семестр собираются заявки от сотрудников университета и компаний-партнеров. Заявки формализуют и студенты на специальном сайте прокомпетенции выбирают понравившийся проект. Состав команды от проекта в проект разный, можно как договориться заранее с товарищами и выбрать проект, так и записать одному, остальные слоты заберут другие студенты. После формирования команд, начинается работа над проектом. Команда связывается с куратором и заказчиком (иногда это один человек) и договариваются о встрече и полетели работать, создавать продукт. В конце команда за 5 минут защищает свой проект перед несколькими (1 - 3) жюри.
Проблемы
1. Сайт. Проекты самые разнообразные от «накидать тем для онлайн курса» до «разработать нейронку по распознанию чего-либо». Но большинство, в какой-то степени, да относятся к бизнесу или разработке продуктов, нацеленных на масмаркет. И как в таком разнообразии выбрать подходящий тебе проект? Как удачно, что у нас есть сайт, который призван помочь с этим! Выглядит это так: для каждого проекта заказчик указывать компетенции, которые необходимы для работы над этим проектом. Сам. Ручками по клавиатуре. Думаю вы уже поняли, в чем беда. Да, по итогу сайт хранит кучу мусора: «фигма», «дизайн в фигма», «ui/ux figma», «Figmf», «Figma» и так далее, я думаю вы поняли, это может продолжаться бесконечно. Проблема в том, что потом студенты должны из общего пула компетенций выбрать подходящие им и сервис покажет наиболее уместные проекты. Что получается в итоге прекрасно демонстрирует картинка ниже.
Как я вижу решение этой проблемы? Убрать на второй план компетенции, а во главу угла поставить специализацию. Сейчас, конечно же, указываются роли на проекте: и аналитики, и бек и фронт разработчики, но это просто наборы букв, которые никак не влияют на процесс выбора. Мне кажется, студент должен выбирать только желаемую роль в команде проекта (тимлид, аналитик, фронт, бек, смм и т.д.) и исходя из выбранной роли система будет предлагать проекты, где такой специалист нужен. Появляется новая проблема: заказчикам и модераторам карточек проектов надо с особым вниманием подбирать роли на проект, чтобы не получилось так, что в команде нет аналитика, а проект требует анализ проблемы, рынка, проектирования макетов и т.д.
2. Роли. На мой взгляд, сейчас существуют разногласия между проектным практикумом и обучением в целом. У нас на выбор есть много курсов по коду, но совсем нет курсов по аналитике и руководству технической команды. Конечно, можно начать рассуждения в стиле «технический вуз, неудивительно, что не учат менеджеров», окей, а системный аналитик? Это не айтишник? А продакты, которые ведут ваши проекты, тоже не айтишники? Они не должны разбираться в теме? Я считаю, что IT, как и любая другая сфера, требует от менеджеров достаточно глубокого понимания внутренних процессов и это достигается либо огромным опытом работы в сфере, либо профильным образованием. Но вернемся к проектному практикуму. Многие проекты подразумевают не только написание кода, а анализ проблемы, поиск путей ее решения, общение с заинтересованными сторонами и т.д. Кураторы у каждой команды разные: у кого-то куратор полностью организует работу и тогда тимлид не нужен, а кому-то с куратором не повезло и он вообще никак не реагирует на сообщения. Получается, что задачи решаем бизнесовые, а бизнес составляющей в команде нет.
Безусловно, если человеку понравилось быть аналитиком или дизайнером он сам будет развиваться в этом направлении, но кто-то боится себя попробовать в новой роли, держа в голове мысль, что от него зависят другие люди, кто-то не попадает в проекты, где нужны такого рода кадры и так далее, причин может быть много.
Решение? Профориентация, дополнительные лекции в рамках проектного практикума, обучающие курсы.
3. Мотивация. Зачем студенту тратить кучу времени на проект? Что он получит? Многие ребята относятся к этому как к очередной строке в зачетке и самое важное - это оценка (если им и это неважно, то движений по проекту вообще не производится). Далеко не все студенты имеют искреннее желание научиться чему-то новому, развить скилы, создать новый продукт, придумать новое решение. Еще реже попадаются те, у кого присутствует все сразу, а именно таким ребятам и нужен проектный практикум.
Не всех удовлетворяет такая идея. Я общался с толковыми ребятами, которые просто хотели кодить. Их не интересует бизнес составляющая. Они - чистые инженеры. Им нравится проводить исследования и добиваться результата, но их совсем не интересует аналитика и экономика. И их безумно раздражает, когда их заставляют анализировать потенциальную аудиторию вместо того, чтобы писать код. И это нормально.
Мне кажется, у студентов должен быть выбор. Хочешь ощутить себя в мини стартапе? Иди на проектный практикум. Хочешь разметить супер сложную и насыщенную страницу сайта? Разметь, а потом напиши курсовую работу о том, с какими сложностями столкнулся и как разрешил их. Вообще ничего не хочешь делать, лишь бы тройку получить? Ну тогда будь добр выбери тему для курсача из списка и сдай в конце семестра. Это как один из способов решения.
Вторая идея решения проблемы заключается в том, чтобы ввести рейтинг студентов по проектам. Самое активные и скиловые ребята будут в топе и им будет легче находить друг друга и объединяться в команды. Сейчас очень трудно найти команду, в которой 100% состава скиловые и заинтересованные. Обычно в команде 1-2 вовлеченных участника, которые тащут всех за собой.
4. Заказчики. Довольно часто бывает так, что заказчик кидает ТЗ проекта (часто и тз сделано из под палки) и забивает. Лично мне на последнем проекте мой заказчик говорил «если бы ты не написал, я бы даже не вспомнил, что проект закидывал». Но нам повезло, мы смогли найти общий язык и куратор не пропал посередине проекта (это случилось ближе к концу). На предыдущем проекте заказчик отвалился уже через 1,5 месяца. Мы вот ему отправляем модель БД на одобрение 12 ноября, а 6 декабря он отвечает «норм». Конечно, я понимаю, работа, семья, под дулом пистолета заставили, но люди берут обязательства и не выполняют их. У кого-то кураторы реально помогают, у кого-то теряются еще в начале, а кому-то и вовсе мешают делать проект (да-да и такое бывает). А оценивают проекты одинаково. Никого не интересует какой наставник у тебя был и это, на мой взгляд, неправильно.
Я не вижу простого решения этой проблемы и это не проблема студентов. Это проблема университета и партнеров. Чтобы увеличить заинтересованность заказчиков к проектам надо повышать авторитет вуза перед сторонними компаниями, а компаниям лучше следить за людьми, которые представляют лицо фирмы перед потенциальными работниками.
5. Оценка проектов. За 5 минут расскажите двум людям без лица, что у вас за проект. Звучит очень грубо, но весьма точно отражает суть. Вообще, очень много возмущения по поводу оценки проектов как от студентов, так и от специалистов в комиссии.
Обговорим сразу, да, мне важна оценка за мой труд. Нет, мне не важна цифра, мне важно, чтобы мои усилия оценили по достоинству. Если моя команда работала на отлично я ожидаю и соответствующую оценку.
Формат проведения защиты. Так как сейчас вездесущая удаленка, то и защита проходила у меня 3/4 раз удаленно. Проекты делятся на несколько треков. В последний раз это были: gamedev, Art-design, Application, ML, mobile, web. У каждого трека указаны эксперты (от 1 до 3) и очередь команд. В указанное время команда заходит и у докладчика есть 5 минут чтобы защитить свой проект. Затем вопросы от экспертов и конец. Что должен рассказать докладчик за 5 минут: выделить проблему, обозначить цели, задачи, показать анализ конкурентов, аудитории, рассказать о своем решение, продемонстрировать, что получилось. Если что-то отсутсвует, то обязательно спросят почему. Если заказчик захотел сам сделать велосипед, это его право, но ребят на защите завалят вопросами «зачем вы придумали велосипед?».
Я думаю и так понятно, что за 5 минут уловить суть проекта и оценить проделанную работу невозможно. Поэтому перейдем к другой проблеме защиты - оценивание. Критерии максимально размытые и это не только мое мнение, так говорят и проверяющие эксперты (сами критерии прикрепил ниже). Далее приведу пару цитат от экспертов. Мы попросили их рассказать об их участии в проектном практикуме. Я отметил основные моменты.
Я не был куратором, меня просто позвали послушать проекты. …
…У ребят разный уровень проработанности и не понятно как на такое реагировать, вроде что-то делали, а вроде у других в 2-3 раза больше результата (но тут и от размера команды зависит). …
…Система оценивания в корне не правильная и почти бесполезная. Из тех критериев что там были, это скорее относится к презентации проекта, а не к нему самому. …
…Мне кажется времени мало дается на презентацию. Они все либо торопились рассказывать, либо делали мини презентации, где ничего не раскрыто.
(С) Эксперт - мобильный разработчик
С точки зрения участника экспертной комиссии - очень сложно оценить как-либо проекты и команды в большинстве случаев по предоставленным критериям, так как ребятам на защиту выделяется определенное время и они за него укладывают в свой рассказ лишь общие черты проекта, без подробностей, то есть по сути ничего не рассказывают.
Заключение
Отвечая на вопрос в названии статьи - нет, не лучше. Лично для меня. Проектный практикум и гибкое обучение это правда крутые идеи, я бы сказал прорывные, как минимум для заМКАДья. Я лишь передал мысли и взгляд конечного потребителя - студента.
P.S. Так как автор ранее не писал статьи для хабра, случайно отправил на модерацию недописанную версию статьи. Теперь все должно быть ок.