В данной публикации дается обзор существующего сейчас в технических ВУЗах явления под названием «проектная деятельность». Показываются ее слабые и сильные стороны. Освещаются сложности реализации проекта с точки зрения преподавателя. Даются различные варианты действий преподавателя, ведущего проект, в зависимости от поставленной цели обучения.

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

С начала внедрения ПД в нашем институте прошло уже 4 года, и первое поколение студентов, занимавшихся им с первого курса, в этом году заканчивает бакалавриат. Уже можно подвести какие-то итоги. Напомню смысл для тех, кто не слышал об этой теме: команда студентов в течение семестра решает небольшую инженерную задачу, предложенную им профильным предприятием. Для студентов польза – знакомство с актуальными задачами, получение практических навыков, слаженность при работе в командах. Для предприятия польза – решить какие-то задачи силами студентов, а также возможность присмотреть себе толковых ребят, не беря при этом обязательств для их трудоустройства.

База для анализа на текущий момент у меня оставляет 93 проекта, проводившиеся по специальности «Управление в технических системах» с 2020 по 2022гг. Около 10% этих проектов вел я как куратор, остальные слушал на защите как эксперт.

Действующие лица:

• Заказчик проекта: может быть и предприятием и отдельным человеком. Человек этот может быть как внешним по отношению к институту, так и являться сотрудником института

• Куратор проекта: сотрудник института, выделенный для сопровождения проекта и оформления бюрократических процедур в автоматизированных системах института (регистрация проекта, выставление оценок студентам и т.п.)

• Группа из 3-5 студентов – исполнители проекта

Возможные источники тем проектов:

• Внешнее предприятие. В этом случае куратором проекта назначается преподаватель, ведущий близкую к теме проекта дисциплину.

• Сотрудники института. В этом случае заказчик и куратор – одно лицо

• Сами студенты. Сначала договариваются с возможным куратором о теме, и если предложенная тема соответствует профилю обучения, она принимается. Руководство специальности достаточно лояльно в этом плане.

Первое заблуждение, с которым сталкиваются почти все студенты и некоторые преподаватели, состоит в том, что предприятия с удовольствием участвуют в проектах и разбирают студентов как горячие пирожки. Здесь может сказываться специфика специальности (например, наша специальность – АСУТП – не так популярна и востребована на рынке, как IT). Но если знать, что проектное обучение начинается на 1-м курсе, то легко задать вопрос: чем студент-первокурсник может быть полезен предприятию ? Ответ очевиден. У предприятия в этом случае два пути. Первый – выделить человека, который под видом проектной деятельности просто будет учить студента какой-нибудь базе (типа электроники, или основ программирования). При этом этот человек будет отвлечен от своей непосредственной работы. Плюс надо понимать, что практик-электронщик хуже справится с объяснением основ электроники, чем штатный преподаватель университета. Второй выход для предприятия – не связываться с этим делом совсем. Есть еще третий подход – имитация, когда предприятие дает тему проекта, но не тратит на его выполнение силы своих сотрудников, предоставляя студенту что-то делать на его усмотрение. В этом случае студент что-то поделал, с умным видом рассказал это на защите, а после нее вся работа отправляется в мусорную корзину, т.к. не имеет практической ценности. Помогает ли такая деятельность предприятию – нет, помогает ли студенту – неизвестно (может и помогает, но оценить сложно).

Второе заблуждение: проекты, выполненные студентами имеют какую-то практическую ценность. Ни один из почти ста проектов, которые прошли перед моими глазами не получил развития после защиты. Это касается и тех проектов, которые предлагали внешние заказчики-предприятия. Один-два проекта показывали признаки жизни после защиты, и то в связи с трудоустройством студента на данное предприятие и его личной заинтересованностью в результате своего проекта. Из этого следует, что проекты, предложенные самими студентами, имеют околонулевую практическую ценность, как бы они ни казались перспективными им самим. Предприятиям эти проекты не нужны, а студенты быстро охладевают к ним после защиты проекта. Исключений пока не было.

Значит ли это, что проектная деятельность бесполезна ? Нет, не значит. Но ее плюсы состоят вовсе не в декларируемых целях. Для пояснения этой мысли, я опишу более подробно этапы работы над проектом.

Выбор темы проекта

Как уже было сказано, ПД вводилась директивно, начиная со второго семестра первого курса обучения. Итогом в первый год введения ПД стало отсутствие проектов от предприятий: богатых предприятий в АСУТП, которые могли бы тратить время своих сотрудников на обучение первокурсников не нашлось, а на имитацию рука ни у кого не поднялась, в том числе и у преподавателей, которым пришлось бы курировать такие проекты. Итогом стали внутривузовские проекты, придуманные самими преподавателями, и курируемые ими же: по сути усложненные лабораторные работы по программированию. Так как из специальных дисциплин к середине первого курса студенты знакомы только с программированием и математикой, то и темы были выбраны соответствующие. Основными двумя группами тем были: дискретная математика (алгоритмы на графах, Дейкстры, Прима и т.п.) и вычислительная математика (например, задачи на гомановские маневры спутников на орбите).

Работа над проектом ведется в течение семестра, поэтому каждый прошедший семестр расширяет доступные студенту возможности. На втором курсе появляются темы, связанные с электроникой, схемотехникой (например, из электроники – работы по импульсным блокам питания, из микропроцессорной части - работы с семейством ардуиноподобных конструкторов). Особняком стоят проекты, ориентированные на программирование: парсеры протоколов обмена, драйверы для оборудования, программы для тестирования датчиков, программы для ПЛК и т.п..

Однако на всех курсах наблюдается тенденция дефицита проектов, инициированных внешними заказчиками. Появление такого проекта – это как правило результат похода преподавателя к заказчику и выпрашивания темы. При согласовании темы преподаватель должен держать в уме, что курировать этот проект придется ему самому. Также нужно понимать наличие студентов, потенциально могущих справиться с проектом, и желающих им заняться. Эти множества могут не пересекаться. Но для успешного выполнения необходимо, чтобы у студента были И способности, И желание. Отсюда и риск для преподавателя – договоришься с внешним заказчиком, а студенты сольют проект. Очевидно, что все эти движения не входят в круг обязанностей преподавателя и являются скорее его личной инициативой. Что не есть правильно – система должна поощрять личную инициативу людей, но не должна держаться только на ней.

Вторая тенденция, противодействующая первой, состоит в том, что чем старше становятся студенты, тем легче согласовать для них тему, интересную предприятию. Итогом работы этих двух противоборствующих сил стало увеличение внешних проектов к середине четвертого курса до 50% от общего числа проектов (см. рис.1). 7-й семестр – это, по сути, конец бакалавриата, т.к. в 8-м семестре уже преддипломная практика и ПД нет.

Подбор состава команды исполнителей

Самая большая ошибка куратора – дать студентам самим выбрать состав своей команды. Как правило, студенты делают выбор сокомандников, нисколько не ориентируясь не то что на навыки, а даже на желание других работать над какой-либо темой. Зачастую более активный студент, соблазнившись красивой темой проекта, сманивает своих менее активных приятелей. Получив задание, он убеждается, что всю работу придётся делать ему одному, потому что дружба дружбой, а табачок – врозь. Соответственно, такая ситуация демотивирует студента-инициатора, и проект, как правило, оказывается завален. Если на внутриуниверситетских проектах такой итог в общем закономерен, и не вызывает сильного удивления преподавателей, то внешние заказчики, увидев такой исход, только еще раз убеждаются, что связываться со студенческими проектами – пустая трата времени. И выбить у них следующий проект становится сложнее. Поэтому было принято решение, начиная с 3-4 курса, искусственно объединять студентов в команды, ориентируясь в первую очередь на замотивированность на работу, во вторую – на навык.

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

Ведение проекта

Это самый важный вопрос, от которого, по сути зависит все. Здесь, считаю, очень многое зависит от куратора. В проектах не соблюдается основной принцип обучения новому: «не больше одной незнакомой сущности за раз». Знакомство с новым должно строиться постепенно на базе уже знакомых понятий и умений. Проекты внешних заказчиков не соблюдают этот принцип, т.к. подобраны из практических интересов. Например, нужно написать драйвер для работы с датчиком по заданному протоколу. Тут сразу несколько незнакомых для студента областей: 1 – протокол обмена, 2 – интерфейс (COM, TCP/UDP, и т.п.), 3 – архитектура программы (например M-V-C), 4- создание архитектуры классов под задачу, 5 – создание пользовательского интерфейса для тестирования драйвера на базе какой-нибудь библиотеки. Даже если студенты знакомы из лекций с этими понятиями, обучение применению каждого из них требует по сути полноценного курса с множеством лабораторных работ. Идеальный вариант – разделить работу между участниками проекта, тогда каждый из них сталкивается только с одной незнакомой сущностью и осваивает ее. Потом сделанные каждым участником части складываются вместе и получается готовый проект. К сожалению, такой способ не работает никогда.

Первое препятствие я озвучивал в предыдущем пункте: далеко не все участники команды готовы работать одинаково эффективно. И не помогают модные сейчас мозговые штурмы, совместные совещания, дашборды, дедлайны, и прочее в том же духе. В итоге даже если в команде есть студент, готовый трудиться, он ничего не сможет сделать, т.к. незнакомых сущностей много, а коллективность не работает. А значит и этот студент ничему не научится, и, как и остальные участники, потратит время впустую. На рис.2. я попытался изобразить процесс выполнения студентами проекта, выделив часть каждого студента своим цветом. В данном случае видно, что студент 1 выполнил свою часть еще на 1-м этапе и у него осталось много времени. Студенты 2 и 3 выполнили свои части позже. А студент 4 – не смог/не захотел сделать свою часть.

Второй момент – незнакомых сущностей может быть больше, чем имеющихся студентов в команде. Конечно, перед принятием темы проекта и заказчик и куратор исходя из своего опыта оценивают его сложность, но не всегда они точно могут предсказать истинную трудоемкость проекта, а также состав и качество команды студентов, которые его выберут.

Поэтому идеализированный вариант выполнения проекта нереален.

Какие существуют альтернативы ?

Самая частая альтернатива, которую я видел: не можем сделать как надо, сделаем как можем. Это достойный вариант, если подходить к нему ответственно. Нет ничего зазорного сказать честно: «Мы работали, но задача оказалась слишком сложна, поэтому мы взяли и сделали только вот этот кусочек». Это находит понимание и на защите у комиссии, и у заказчика, который, что уж греха таить, не ждет многого от студентов. Плохо то, что в этом случае студенты, как правило, остаются на том же уровне знаний, что и до выполнения проекта. Погрузиться в задачу частично можно только каким-то очень поверхностным образом. Например, если брать предыдущий пример с драйвером, если изучен только протокол (пункт 1), но не запрограммирован, не проверен по имеющейся трассировке, то такое знание почти бесполезно для студента. Невозможно познакомиться подробно с процессом обмена по этому протоколу, посмотреть почему за одной командой идет другая. А значит и нет цельной картины в голове. И в следующий раз, если в проекте будет такой же протокол, начинать придется опять с нуля.

Другой подход преодоления несоразмерности задачи и возможностей команды я использую сам, когда выступаю куратором проекта. Но не могу назвать ее лучшим вариантом: скорее – лучшим из худших. Я пришел к нему постепенно на собственном опыте, но мне он нравится больше, чем частичное выполнение. Я исходил из того, что для опытного разработчика студенческий проект не представляет трудности сделать даже в одиночку и за сравнительно небольшое время. Поэтому я на первых этапах выполнения проекта определяю потенциал студентов в команде, и помещаю каждого из них в ситуацию, когда они движутся каждый в своем темпе. «Но как же взаимодействие ?», спросите Вы: ведь работа одного зависит от работы другого.  Ответ – куратор создает для каждого студента окружение, в котором не хватает только его части. Т.е. каждый из участников в любой момент времени видит вокруг себя проект, который «ждет» только его, а в остальном полностью готов. Для демонстрирующего самый быстрый прогресс студента это «окружение» разработано куратором. И его часть по мере готовности встраивается в программу куратора и тестируется вместе с ней. «Идущий» вторым студент видит вокруг себя проект, частично разработанный куратором и частично – первым студентом. Он тестирует в нем свою часть, и эта часть по мере готовности замещает одну из «инородных» составляющих. Следующий поспевший студент работает с проектом, в котором составляющая куратора еще присутствует, но в меньшем объеме. Если он успевает доделать свою часть, она встает на место. Может быть, к концу выполнения проекта кода куратора в проекте не будет совсем, а может – будет частично. Пример показан на рис.3.

Есть много возражений к такому подходу ведения проекта куратором.

1. «Лучше пусть студенты сделают что-то похуже, зато сами от начала до конца». Но здесь я апеллирую к цели: что мы хотим достичь, выполняя проект. Если научить студента полезным знаниям, то при моем подходе глубина изученных знаний существенно больше, чем если бы студентов просто оставили в покое и они сами бы сделали, что могли. В этом случае знания всех студентов остались бы на околонулевом уровне (см. абзац про частичное выполнение проекта).

2. «А где же тут командная работа». Все верно. При таком подходе студенты не получают навыки работы с себе подобными. Потому что, по сути, куратор является командой для каждого студента больше, чем остальные студенты. Но, как и все преподы старой формации, я считаю важнее hardskills, а не softskills. Важнее дать студенту технические знания, а для приобретения навыков командной работы у него сейчас есть масса других возможностей, от университетских (внутристуденческих сходок, конкурсов и т.п.), до индустриальных (многие IT-компании регулярно проводят хакатоны, командные олимпиады и др.).

3. «Что студенты скажут на защите ?» Примерно то же, что и при частично выполненном проекте. Что лучше: сказать, «Мы сделали вот эту часть, а другая осталась несделанной». Или сказать, «Мы сделали вот эту часть, а другая – сделана куратором» ? На мой взгляд – и так и эдак плохо, но второе не хуже первого.  Ведь и в реальной жизни работа одного сотрудника – это всегда часть общей работы, и зависит от работы других.

Что требуется от куратора при таком подходе. Здесь, конечно, надо сказать, что объем работы возрастает колоссально при выполнении по второму варианту. Особенно трудно приходится с проектами внешних предприятий, каждый из которых содержит специфику работы конкретной отрасли (энергетика, транспорт, химия и т.п.). Сложнее, но и интереснее. Знакомство с новой для себя областью всегда оставляет в человеке какой-то отпечаток, след, обогащающий его. Конечно, куратору необязательно делать весь проект самостоятельно от начала до конца. Достаточно быть лишь на шаг впереди идущего самым первым студента. Т.е. его работу необходимо делать куратору, и подставлять ему «ступеньку», оставляя до готовности незаполненной только одну часть программы, для которой требуется знакомство строго с одной незнакомой студенту сущностью. Если «знакомство» прошло успешно, то можно дать этому же студенту на разработку следующую часть. Если уже очевидно, что некоторые сокомандники не справятся с работой, то эта следующая часть может быть и их частью. Например, на рис.4. студент 1 делает сначала свою часть, а потом часть студента 4.

Таким образом, польза проектной деятельности в том виде как она заявлена и пропагандируется не очевидна. Но применить ее для повышения навыка студентов – реально. К сожалению, сделать это можно только за счет повышения (добровольной!) нагрузки на преподавателя-куратора. Допускаю, что есть другие точки зрения, и хотелось бы их увидеть в комментариях. Очень дискуссионная тема, но в ней пока очень мало конкретики, а больше или лозунгов, или огульной критики.

P.S. При подготовке данной статьи я искал какие-либо объективные данные о пользе этого вида обучения, но в публикациях как правило все сводится к перечислению полезностей, которые студенты получают от ПД. А хотелось бы видеть цифры сравнений: вот группа обучаемых без ПД – такое-то значение критерия (какого?), вот с ПД – такое-то. Если кто-то может поделиться подобным, то был бы очень благодарен.