Челлендж для преподавателя

Сегодня Михаил Чирков, руководитель курса «Python QA Engineer», рассказывает о своем подходе к преподаванию и делится внутренней кухней подготовки к занятиям.

Добрый день! Меня зовут Михаил, я занимаюсь автоматизацией тестирования почти три года и за это время успел поработать как с различными языками Python, Kotlin, Java, так и на разных проектах. Автоматизировал тестирование web, мобильных приложений и API.

По образованию экономист, после университета служил по контракту, после чего успел поработать курьером, расклейщиком объявлений, немного в SMM, бухгалтерии и коммерческой недвижимости. Ничего кроме пары лет игры в Star Craft и Counter-Strike, а так же уроков информатики в школе с IT меня не связывало. Так что попал я в эту сферу случайно и, как принято говорить, без технического бэкграунда.

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

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

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

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

1. Исследую открытые источники. Чаще всего я анализирую англоязычные: смотрю видео, читаю статьи, различные туториалы по теме, чтобы найти какие-то интересные примеры и способы подачи материала, и обязательно увидеть какие из них не работают, или плохо доносят мысль, накладываю на это личный опыт и примеры из практики.
2. Составляю план занятия. Исходя из опыта смотрю, что именно будет полезно с точки зрения автоматизации тестирования, выделяю наиболее важные аспекты, выбираю, что можно опустить, так как время занятия и «окно усвоения материала» ограничены.
   
3. Оформляю презентацию. Вообще презентации для меня не более чем план, чтобы не забыть о чем-то рассказать, но на самих слайдах информации всегда минимум. Она больше является планом, чем источником информации.
   
4. Готовлю примеры. Это обязательный и самый важный пункт любого занятия. Примеры обязательно живые, чтобы можно было выполнять их в IDE, а не просто зачитывать код. Практику чтения кода со слайдов вообще считаю нужно запретить.

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

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

Сложные задания могут демотивировать. Я сторонник того, чтобы у студентов была возможность прилагать усилия на свой уровень подготовки, и тогда усвоение материала происходит гораздо быстрее. Когда в курсе только задачи сверхсложного уровня, это губит интерес и не приведут ни к чему, кроме массовых «дропов» с занятий.

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

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

Совместный лайвкодинг, если он присутствует, должен быть очень хорошо подготовлен, и студенты тоже должны быть готовы писать код. Преподаватель должен быть на 100% уверен, что все смогут адекватно успевать за происходящим.

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

На мой взгляд, такой подход показывает, что не бывает такого, что всегда все идеально работает. По моему личному опыту траблшутинг – это 80% задач, которыми приходится заниматься.

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

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

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

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

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

Плохо, если человек приходит с целью «кардинально изменить свою жизнь», познать новую профессию за один месяц, не имея подобного опыта и понимания, сколько сил на это реально потребуется. Такая мотивация быстро выгорает. Человек разочаровывается в курсах и начинает говорить что всё это развод и обман. Если бы можно было стать программистом, автотестером, devops'ом просто посмотрев видео, или послушав платный, или бесплатный курс, то сейчас курьеры или кассиры вполне бы могли соревноваться с IT по уровню доходов.

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

Разница всегда заметна, люди, имеющие опыт программирования, задают более предметные вопросы, быстрее схватывают концепты.

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

Я сам бросал курсы, в том числе и платные, чего уж скрывать, так как не успевал за программой, разочаровывался во всём на свете, не понимал преподавателя, так как переоценивал себя на старте. Главное не опускать руки. Для этого у нас даже есть возможность одного бесплатного перевода в следующий набор, если человек решил, что прямо сейчас он оказался не готов, но сдаваться пока не собирается.

1. Чтение слайдов. Я встречал подобное даже у опытных разработчиков, которые могли бы показать интересную практику в живом формате, но вместо этого показывали картинки с кодом и долго говорили о каких-то сложных и абстрактных вещах.

   Картинка на слайде не объясняет, как код запускать — куда идти, что набрать, какой редактор открыть, на какую кнопку нажать. Это абсолютно никак не помогает. А если у тебя возникает вопрос «А что будет если…», то в лучшем случае преподаватель выскажет своё предположение о том что должно произойти и всё. Больше всего меня лично раздражает преподавание программирования со слайдов. Такую практику нужно запретить законодательно! :)

   Я всегда показываю живые примеры, и мы работаем с ними на занятиях. Тогда у студентов возникает больше практических, конкретных вопросов. Если ты работаешь с настоящим кодом и не знаешь ответа, ты можешь сказать «давайте это попробуем» и объяснишь уже что произошло, либо сам узнаешь что-то новое. Так как процесс обучения постоянный, и разница между преподавателем и студентами лишь в том, что преподаватель продвинулся в своём обучении дальше и может показать дорогу начинающим, но думать что ты «умнее всех» и всё на свете знаешь — это очень большая ошибка.

2. Объем информации. Избыток информации может навредить, т.к. в первую очередь важно то, сколько люди смогут понять, запомнить и применить в дальнейшем, а не то, сколько ты успеешь наговорить, переключая картинки. Тут всё та же проблема окна восприятия: не может человек 1,5 часа воспринимать новую информацию физически.

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

Если вы развиваетесь в направлении тестирования или вам нужны для работы навыки автоматизации тестов, буду рад видеть вас на нашем онлайн-курсе «Python QA Engineer». До встречи в OTUS!