Как учить всех и каждого одновременно?

Более подробно рассмотрим педагогический эксперимент, проведенный в Новосибирском государственном университете. В НГУ я 6 лет вел спецкурс по тестированию программного обеспечения на принципах смешанного и дуального обучения. Мы начали с группы в 8 человек, а в последний год на курс записались 52 человека из 100 студентов потока, включая тех, кто уже работал в тестировщиками ПО.

В статье раскрыта организация образовательного процесса, и вытекающие из него педагогические и управленческие вопросы.

В 2010 году мы, как проектная группа "Метавер", провели первый форсайт "Образование", из которого потом целое форсайт-движение возникло https://asi.ru/news/2475/. Примерно через год мне стало интересно перейти от форсайта как инструмента генерации гипотез к практике трансформации образования, благо традиции Академгородка Новосибирска этому способствовали https://academ.info/news/17736 , поэтому я переехал из Москвы в Сибирь и запустил совместно с Академпарком цепочку экспериментов. Одним из них был проект по подготовке тестировщиков программного обеспечения под корпоративного заказчика. Позже на основе такой подготовки мы собрали спецкурс для Новосибирского государственного университета. Для нас было важно не просто какой-то курс провести, а сделать его так, чтобы он помогал студентам использовать полученные знания и умения в реальной работе в ИТ-отрасли.

Запуск спецкурса

Спецкурс мы запустили на двух факультетах: физическом (ФФ) и информационных технологий (ФИТ). Так начался эксперимент длиною в 6 лет.
Мы тогда точно понимали, что хотим сделать , но не очень понимали как. Поэтому за основу взяли перевернутый класс в смешанном обучении. Коротко говоря, домашнее задание не после, а перед уроком. Преподаватель дает студентам материалы для ознакомления заранее, а на очных встречах разбирает вопросы, барьеры и озарения возникшие в результате изучения материалов. Такой подход приближает образовательный процесс к спринтам из agile-подхода, когда мы встречаемся зачем чтобы подитожить сделанное за неделю и спланировать следующие шаги. Теории об этом написано много, но тогда известных нам внедрений в России не было.
Дуальное образование предполагает тесное взаимодействие с работодателем, поэтому мы курс собирали вместе с руководителем отдела тестирования крупной аутсорсинговой компании Екатериной Синько, она задавала отраслевую планку, на которую мы ориентировались. Сейчас мы в IThub называем таких приглашенных отраслевых экспертов архитекторами специальности. Без них любой курс, особенно в IT, будет стремительно устаревать. Исходя из заданной планки подбирали учебный материал, в том числе онлайновый. Мы взяли курс на интуит.ру, в котором описано введение в тестирование ПО для теории, и релиз Mantis как bugtracker для практики. В дальнейшем студенты сильно нарастили методическую базу, но об этом ниже.

Первый год - первые грабли

Прямой перенос из мира дефицита кадров в вузовские реалии не получился.
Я предложил студентам самостоятельно поработать с онлайн-курсом, разобраться, нарисовать mindmap. Это вызывало у них недоумение, с одной стороны, и вопросы к моей профессиональной квалификации — с другой. Потому что я старательно избегал трансляции знаний, наоборот, действовал по принципу: «Вот вам пространство и материалы — разбирайтесь, а я помогу в ответ на прямой запрос». И то, что отлично сработало на соискателях, сломалось на студентах — привыкшие к тому, что все рассказывает преподаватель, студенты-физики с большой неохотой работали с внешними источниками. "Мотивация не та, Ваша Честь!"

Мы сделали выводы и на следующий семестр в 2013 году, уже со студентами ФИТа, пересобрали дизайн курса, добавив согласование мотивов и метрик образовательных результатов. Такой дизайн в дальнейшем и шлифовался год от года, и, начиная с 2015 года, на спецкурс начали записываться студенты, которые уже работали тестировщиками: для них это была хорошая возможность повысить квалификацию. Тем самым нам удалось выдержать первоначальный ориентир, заданный потребностями рынка.

За счет чего этого удалось добиться?

Согласование целей

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

А затем на первом занятии мы проводили очень простой формат:

• Кто угодно озвучивает свою цель, записывает её на доске и подписывается.
• Повторяться нельзя, но можно помогать другому сформулировать точнее.
• Высказаться должны все.

Мы так знакомились и друг с другом и с целями.
Обычно первые 5-7 высказываний это "баяны", когда группа выдает социально ожидаемые ответы. Но в дальнейшем ответы становятся глубже, начиная с того, чтобы быть востребованным специалистом, заканчивая тем, что придется работать с тестировщиками, хочется понимать, на каком языке с ними разговаривать. Мы со студентами могли сделать срез по этим ответам и выдвинуть общие критерии, к которым потом можно было относиться. Такой-то человек сказал, что вот это ему нужно, и это зафиксировано. Такой подход в том числе позволял синхронизировать ожидания. В случае, если студенты не могли сформулировать цель: всё в порядке, говорил я им, значит, вам просто не сюда. Курсов по выбору много, запишитесь на другой — это помогало.

Зачастую, особенно на больших группах 20-30 человек, прояснение целей занимало целую пару, чтобы договориться до того, зачем они реально сюда пришли и, соответственно, во что собираются вложить свое время.

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

Какие метрики мы определяли? Знания, умения, навыки, компетенция, квалификация. В последние три года студенты меня убедили и мы ввели ещё одну метрику: "командная работа".

Что скрывается за этими словами? Чтобы не уходить в трактовку, кто что под этим подразумевает и завязнуть в софизмах, мы договорились только о том, как это измерить.

Знание

Подтверждением знаний является либо результат теста, либо, в конечном счете, сертификат онлайн-курса. Тот самый курс, который я использовал еще при первой попытке, мы переиспользовали и сказали, что это слагаемое, которое является ликбезом по тестированию. С него мы начинаем. И важным условием является то, что по этому курсу студенты получат сертификат и предъявят его как основание для зачёта знаний.

Конечно, одним курсом всё не ограничилось. Студенты становились содизайнерами этого курса, предлагали дополнительную литературу, онлайн-источники. Мы обсуждали это с Екатериной и расширяли пул методических материалов. В дальнейшем это еще сыграет свою роль, но об этом позже. По всем новым источникам я просил составить mindmap. У такого формата сразу три преимущества:

• сразу видно насколько глубоко студент проработал материал;
• в mindmap видно, что он упустил или раскрыл недостаточно;
• каждый mindmap уникальный, а значит, его нельзя списать. :)

Навык

Навык фиксируется подтверждением того, что студент не просто сумел что-то сделать, а делал это многократно, хорошо и быстро. То есть многократное повторение успешного действия служит для нас метрикой формирования навыка. Очевидным образом выводится из того же лога: количество текст-кейсов, баг-репортов и т.п.

Это три метрики, которые мы довольно легко из дискуссии выводили студентами каждый раз заново.

Компетенция

Компетенция — это успешное применение знаний-умений-навыков в заданном контексте. Тем самым измерение компетенции подразумевает перебор разнообразного контекста и достижение в нём того же самого результата. В совершено разных условиях продемонстрировать умение проявлять нужное сочетание качеств. Для этого мы договорились использовать элемент деловой игры, где студентам нужно было "в шкуре тестировщика" разрешить те или иные ситуации.

Откуда взялись эти разные условия, эти ситуации? Как я уже упоминал, этот курс изначально проектировался под патронажем специалистов в тестировании. Я задал им очень простой вопрос: вы, профи, поделитесь, пожалуйста, болью, вот какие ситуации за последние 5 лет в вашей профессиональной деятельности были наиболее эмоционально окрашенными, болезненными, где прям приходилось глубоко разбираться?

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

После такой разыгранной сцены каждый: и участники, и зрители — отвечали на 3 вопроса:

• Что ребята на сцене сделали верно в соответствии с процессами отрасли?

• Что они сделали не так?

• Как бы я организовал всю коммуникацию на их месте?

Такой опрос тоже стал важным инструментом, он позволил вовлечёно анализировать ситуацию всем участникам. Соответственно вначале опрос проводился на бумаге, потом — через гугл-документ, который позволял собирать всё в едином пространстве.

Почему так много разговоров про метрики? Потому что все эти 4 слагаемых они в итоге носят объективный характер. Тестирование либо пройдено, либо нет. Логирование или зафиксировало активность, или нет. Кратное повторение одних и тех же артефактов: багрепортов, чек-листов, мастер планов — либо собрано, либо нет. Соответствующая ситуация прорефлексирована, анализ по ней сделан или нет. Все носит совершенно объективный характер, который позволяет это предъявить кому угодно, в том числе и за пределами университета.

И мы подбираемся к оставшимся двум метрикам. И они как раз субъективные.

Квалификация

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

Командная работа

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

Итого, имеем простые правила игры, которые дают нам все 6 параметров.

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

Пример того, как складывается оценка студента:

То есть кто-то мог глубже разбираться со знаниями, кто-то больше шлифовал навык. Все выполняли норму, но могли эту норму по любому из параметров повысить в 3 раза. Зачем? Если минимальная характеристика по 6 по полбалла дает 3, то максимальная 9. И вот из этих дополнительных 6 баллов каждый студент себе добирал 2, если он претендовал на "отлично".

И в конечном счете это позволяло мне занять позицию: в любой момент времени, когда любой студент набирает себе пятерку, то он может сразу ее у меня получить. Не нужно дожидаться конца сессии, не нужно делать мне красивые глаза, нужно обеспечить результат в размеченном для этого пространстве. И в зависимости от того, какие «зачем» выдвигали студенты, они так себе эту индивидуальную историю и собирали. Кто-то хотел больше практики, акцентировался на навыках, умениях. Кто хотел взаимодействовать с разработчиками — на контекстах, компетенциях и квалификации. Кто-то находился в позиции саппорта и активно помогал, качая командность.

Теоретический материал

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

Конечно же поначалу все пытаются просто пересказывать содержание. Мол, в главе излагается вот это, вот это, вот это… Это мной тут же сворачивается: а зачем вы нам это рассказываете? Мы все читали. Я читал, студенты читали, мы договорились, что вы это освоите заранее. Поэтому давайте доклад будет строиться вокруг того, что докладчик для себя понял. То есть нужны сразу выводы, информацию-то все и так читали. И отдельно то, что докладчику показалось спорным или он не понял. И важно, что здесь они не мою лекцию обсуждают, а внешний материал. А я им помогаю в этом материале разобраться. И формулировка – у лектора вот в этой части вот какая-то такая штуковина, которая вообще, на мой, докладчика, взгляд, ересь или я, докладчик, тут туплю и в этой части разобраться не смог вот по этой причине. Это нормальная формулировка, более того, желаемая.

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

Еще раз о ментальных картах

Фиксацией разобранных знаний был не конспект, а mindmap. Студенты укладывали разобранную самостоятельно и на занятиях информацию в форму ментальной карты. А как я уже говорил mindmap позволяет заглянуть студента в голову и увидеть то, что у него получилось вынести, а что нет — высветить лакуны, какие-то пробелы, которые на текущий момент у студента возникли и одновременно озарения, инсайты, выводы, которые студент на основе всего этого материала сделал.

В конспекте нужно было не просто передать содержание, а отразить выводы и эти выводы обосновать содержанием. То есть почти всегда стартовая работа выглядела так – ну давайте структурируем в качестве оглавления, подоглавления, абзацы. Хорошо, а что из этого можно сделать какой вывод? Поскольку это mindmap, то он легко пересобирался уже в подвыводы. Карта принималась с итоговыми обобщающими выводами на основе этой главы методички материала. И это позволяло увидеть авторскую позицию студента. То есть это была форма рефлексии по поводу прочитанной информации.

Возможность видеть, чем студент пренебрег, и позволяла с ним говорить именно про эту часть. Потому что у меня была выборка, во-первых, мое прочтение, а во-вторых, выборка десятков других студентов, которые на этот же самый источник делали свои ментальные карты. И у кого-то одна тема была практически не раскрыта, а другой, наоборот, именно на этом ставил свой акцент, строил свои выводы. И это позволяло говорить – смотрите, вот этот момент в карте у одного студента максимально развернут, давайте, он расскажет про это коллегам. И если в начале семестра мы говорили – расскажи про главу такую-то в формате вот такие выводы ты сделал, вот такие барьеры тут возникли, то здесь в этом же самом залоге, но мы уже обсуждали выводы по поводу материала. А предварительная рассылка mindmap позволяла заранее понимать повестку того, что мы будем обсуждать и кто будет про это рассказывать, а кто будет соответственно потребителем этой информации.

Экология проектного подхода

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

Перевернутое обсуждение внешнего материала позволяло довольно глубоко разбирать информацию, которая давалась заранее. В том числе это позволяло фиксировать и неудачи по тестированию знаний. Проходить тесты можно было сколько угодно раз. Более того, я всегда своим студентам рекомендовал и рекомендую вначале пройти тестирование, а потом уже с пониманием, как будут измерять, разбираться с информацией. Иногда тестирование не очень корректное, мы это тоже отдельно разбирали. Разговор про тест, как метрику оценки знаний.

Такой теоретический ликбез о тестировании ПО позволил разделить некую общую установку о том, что это такое, чем оно отличается от отладки и как вообще к этому вопросу подходить.

Отраслевая специфика

Следующий шаг — это знакомство с техническими стандартами, которые в тестирование заведены — что такое мастер тест-план, чек-листы, как оформлять баг-репорт и для чего это так делается. То есть зачем мы этим занимаемся, зачем мы этот материал изучаем. Из него очень понятно, почему у нас такие документы. Уже в этот момент возникала та самая инициатива, которую я упоминал ранее. Студенты начинали добавлять материал в рассмотрение. Мол, есть такой онлайн-курс, что-то на youtube или есть такая книжка, которую он хотел бы разобрать. В частности таким интенсивным методом мы разбирали методичку по тестированию Семена Костантиновича Черноножкина, из которой в магистратуре был целый курс собран. Методичка толковая, особенно хорошо описаны психологические установки тестирования. Но мы то, что растягивалось на целый курс в магистратуре, осваивали за 2-3 недели и брали в рассмотрение следующий материал.

Практика по тестированию

Такая работа с источниками, с курсом, с ментальными картами и т.д. позволяет договориться до некоторых общих оснований. В том числе проверить, что студенты владеют отраслевыми стандартами написания рабочих документов, мастер-планов, баг-репортов и т.д. После этого выбиралось программное обеспечение для тестирования. Это и с одной стороны — обучающий процесс, с другой — тестирование реальных продуктов. При выборе мы руководствовались тем, что А — есть прямой контакт с командой разработчиков, это нам понадобится на финальном этапе, Б — интересно потестировать, любопытно. Брали крупные продукты, как уже упоминалось, от компьютерных игр до яндекс.маркета и Алисы.

И для того, чтобы такой софт протестировать, нужно делать это командой. То есть с середины семестра мы становились проектным офисом компании, которая тестирует софт в режиме аутсорс. Кто-то пишет планы, чек-листы. Поскольку до этого мы разобрали как в принципе тестировать, кто-то брал на себя тестирование этого модуля, кто-то брал на себя системное тестирование, интеграционное и т.д. И шла активная работа.

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

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

В результате с самого начала все студенты понимали, что им нужно сделать, чтобы получить отлично, что можно не делать, если устраивает. И каждый спринт мы в том числе фиксировали вот эту дельту в баллах. То есть люди обосновывали свой еженедельный прирост.

Что делать с неуспевающими?

Для тех, кто страдал студенческой болезнью и появлялся в середине семестра, была уже созданная инфраструктура. Вот, пожалуйста, все материалы, вот, разбирайся. Вот коллеги, которые уже это сделали, к ним можно приходить за советом. Для них это будет с одной стороны зачет, а с другой стороны, проектная работа всегда означает, что ещё над чем-то можно поработать. Студенты могли ставить задачи друг другу, в первую очередь, не успевающим. Вот,мол, давай тогда еще вот этот модуль потестируй. Или вот этот статус-репорт оформи. Или еще что-то. И человек включался в середине семестра, он понимал, над чем ему нужно работать и насколько ему это полезно. И в конечной ведомости очень прозрачным способом, обсужденным на первом занятии, выставлялись соответствующие отметки. Кто-то вышел на удовлетворительно и ему этого хватает. Кто-то хочет больше и понимает, что для этого нужно сделать. То есть не стояла задача понравиться преподавателю как персоне, что-то ему доказать. Стояла задача обосновать результат своего труда по известным критериям. И мы соответственно могли делать выводы методом сравнения как с группой в целом, так и с уровнем квалификации в отрасли, ведь у нас была обратная связь от технологической компании. Мы понимали, сколько таких задач за неделю или за месяц решает junior, senior тестировщик, что он делает сам, что он делает автотестами. Мы соотносили результаты своего труда и скорость, с которой мы это делаем, с отраслью и это позволяло из года в год договариваться до прозрачных критериев. Поэтому больше половины студентов всегда получало пятерки, но были ребята, которые получали двойки, тройки и приходили на пересдачу именно, потому что у них не было достаточно подтвержденных зачетных единиц. Но они знали, что нужно сделать и как поработать над тем, чтобы это появилось. И отметку в свою зачетку они получали самостоятельно. Я всего лишь фиксировал и в спорных моментах требовал обоснования, почему кто-то претендует не на 0.5 балов по этому компоненту, а 0.7 или даже целый балл? Каждая десятая требовала чёткого обоснования.

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

Формальное соответствие

Мы проводили этот спецкурс в одном из ведущих вузов страны и это означает, что его нужно было защитить как на научном совете вуза, так и потом на этапе аккредитации. И, разбираясь во ФГОСах, мы не просто выстраивали курс в с соответствии с нормативным требованиям, а смотрели насколько мы можем собирать необходимую отчетность в разрезе учебный действий и компетенций на основе тех данных, которые мы собираем . Пусть для этого рабочую программу дисциплины пришлось дважды серьезно переписывать, но этот опыт позволил нам замахиваться на более серьезные эксперименты, которые легли в основу дальнейших образовательных инициатив.

Границы применимости

В 2015 году мы спроектировали англоязычную магистратуру по большим данным на мехмате НГУ в таком же залоге. Параллельно я вел другие курсы: по СУБД, предпринимательству, проектному управлению как для иностранных студентов НГУ, так и для студентов технического университета НГТУ. Этот опыт позволяет сказать, что подобный подход применим в разных предметных сферах, а не только для тестирования ПО.

Более того, начиная с 2014 года, мы в рамках i3.school начали его реализовывать в средних школах, так или иначе перелопачивая уже всю общеобразовательную программу не только в Новосибирске, но и в Томске, Тюмени, ХМАО. Так в школах Урая и Мегиона на 10 параллели нет классов, а сотни учеников учатся по своим индивидуальным траекториям.

Но, пожалуй, органичнее всего такой подход развертывается в профильном колледже IThub, который весь построен вокруг "заточки под профессию". На принципах смешанного, дуального обучения и обучения по метрикам мы выстраиваем весь методический процесс и чем раньше студент осваивает общеобразовательные дисциплины, тем быстрее он переходит к проектной работе, которая уже на 3-4 курсе позволяет ему не только окупать свое обучение, но и примерять на себя ту или иную бизнес-роль не только в игре, но и в практической деятельности. А именно такой мы и видели систему образования в далеком уже 2010 году.