Проектный практикум в вузе. Лучше писать курсач?

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Предисловие

Всем привет, меня зовут Егор. Совсем недавно я окончил второй курс радиофака УрФУ по специальности «программная инженерия» и сейчас прохожу стажировку в качестве системного аналитика. Одной из особенностей обучения в моем институте является проектный практикум, о котором я и хочу высказать свои мысли в этом тексте.

Спасибо Даниил

Идея написать нечто подобное созрела у меня в голове где-то полгода назад, но я никак не мог решиться. Но вот недавно мой товарищ Даниил высказал свое мнение на счет проектного обучения в этой статье, чем сподвиг и меня. Не со всеми тезисами согласен, но однозначно рекомендую к прочтению

Структура обучения

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

Все предметы делятся на обязательные и по выбору. Обязательные предметы - джентльменский набор инженера-айтишника: матанализ, дискретка, компьютерные сети и т.д., конечно же не забуду упомянуть БЖД (или ОБЖ, кому как привычнее). У этих курсов мы можем выбирать преподавателей, сложность и расписание (можно посмотреть расписание пар у групп и выбрать наиболее подходящую группу). С курсами по выбору немного интереснее.

Курсы по выборы делятся на два вида: хардовые (по специальности, например, 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 раз удаленно. Проекты делятся на несколько треков. В последний раз это были: gamedav, Art-design, Application, ML, mobile, web. У каждого трека указаны эксперты (от 1 до 3) и очередь команд. В указанное время команда заходит и у докладчика есть 5 минут чтобы защитить свой проект. Затем вопросы от экспертов и конец. Что должен рассказать докладчик за 5 минут: выделить проблему, обозначить цели, задачи, показать анализ конкурентов, аудитории, рассказать о своем решение, продемонстрировать, что получилось. Если что-то отсутсвует, то обязательно спросят почему. Если заказчик захотел сам сделать велосипед, это его право, но ребят на защите завалят вопросами «зачем вы придумали велосипед?».

Я думаю и так понятно, что за 5 минут уловить суть проекта и оценить проделанную работу невозможно. Поэтому перейдем к другой проблеме защиты - оценивание. Критерии максимально размытые и это не только мое мнение, так говорят и проверяющие эксперты (сами критерии прикрепил ниже). Далее приведу пару цитат от экспертов. Мы попросили их рассказать об их участии в проектном практикуме. Я отметил основные моменты.

Я не был куратором, меня просто позвали послушать проекты.

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

Система оценивания в корне не правильная и почти бесполезная. Из тех критериев что там были, это скорее относится к презентации проекта, а не к нему самому. То есть допустим был пункт что-то вроде "проработанность проекта", но это очень обобщенное понятие и сходу не понятно как сюда все впихнуть. Для мобильщиков например было б хорошо добавить, вернее разбить проработанность на ui/ux, архитектура, кодовая база и пр. Для бэкенда допустим БД, архитектура, обоснование выбора решения и т.п. 

На второй день зачем-то убрали оценивание пункта "понятен вклад каждого члена команды", хотя он нужен по идее.

Мне кажется времени мало дается на презентацию. Они все либо торопились рассказывать, либо делали мини презентации, где ничего не раскрыто. Сделайте как на дипломах рамки 10 минут. За временем ведь никто не следит. Некоторые ребята хорошо раскрывали проекты как раз за это время. А то что там условные 15 минут на команду - у нас могли и дольше пообсуждать, если был интерес.


(С) Эксперт - мобильный разработчик

Заключение

Отвечая на вопрос в заголовке - нет, не лучше. Лично для меня. Проектный практикум и гибкое обучение это правда крутые идеи, я бы сказал прорывные, как минимум для заМКАДья. Я лишь передал мысли и взгляд конечного потребителя - студента.

Источник: https://habr.com/ru/post/567036/


Интересные статьи

Интересные статьи

Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Можем ли мы доверять Code Coverage? Ответы на эти вопросы дает мутационное тести...
Это ответ на переведенную публикацию «Почему Kotlin хуже, чем Java?». Поскольку исходная аргументация опирается всего на два примера, то не теряя времени пройдем по этим «недостаткам» Kot...
Всем привет! Меня зовут Александр, я – инженер команды, отвечающей за развитие централизованных IT-сервисов, которыми пользуются продуктовые команды в X5 R...
Завтра, 23 ноября, в 20:00 в наших соцсетях выступит Андрей Письменный, главный редактор Xakep.ru. Андрей начал карьеру в ИТ-журналистике в 2006 году, когда параллельно с учебой в ...
Фиг вы где увидите, что происходит внутри аэропорта. Всё потому, что это место, где встречается сразу куча юрисдикций: полиция и кинологи — федеральные, таможня и пограничники предпочитают вообще...