Веб-инжиниринг. Длительность лекций и управление успеваемостью
Длительность лекций
Пришло время выступать. Пробная прочитка лекции заняла полтора часа, меня устроило. Но когда всё идёт по плану? На деле, я наговорил два часа. На мой взгляд это провал.
Вторую лекцию провёл за два с половиной часа, что во мне вызвало меньше стыда, потому что там давал больше материала.
Третью уложил в полтора часа.
Большие лекции — плохо
Чем больше лекция, тем больше там полезной информации. А много информации тяжело запомнить. Надо разбивать.
Внимание держится только 45 минут. Далее необходим перерыв. Я его себе позволить не мог. А значит, слушали меня хуже.
Больше лекция — меньше времени на вопросы.
Но мои лекции не так уж провальны
В первой, я объяснил что они будут работать в команде и через неделю сдавать готовый проект, с учётом уровня знаний. Показал все инструменты для работы в команде, продемонстрировал работу, разобрал ошибки, которые точно произойдут у каждого, объяснил азы работы. Сказал, что задавать вопросы нужно.
Во второй я объяснил язык с нуля, с азов. Рассчитывая на то, что таких знаний хватит, чтоб понимать работу языков, а не думать, что для другого языка надо переучиваться программировать.
В третей я рассказал самые модные концепты последних лет: типографику и ООП.
Мои ожидания оказались слишком завышенными
Я надеялся, что команда сообразит, что можно параллельно вести процессы: дизайн, верстку, набор первоначальной информации, написание документации.
Возьмём список фильмов. Как будет выглядеть блок списка можно договориться за 5 минут предложив основную концепцию: «Список — это набор фильмов. Каждый фильм можно отмечать просмотренным». Ещё пять минут дизайнеру на схему главной: шапка, меню, несколько списков, футер. Дальше, каждый идёт и дорабатывает свою часть.
Дизайнер рисует, подбирая картинки и цвета. Редактор сочиняет списки и набирает данные по фильмам, что в них входят. Верстальщик делает каркас страницы, верстая шапку, футер и несколько списков.
Кроме того, мне очень важно научить начинать и заканчивать проекты. Притом, заканчивать их довольно хорошо, а не оставлять видимые недоделки. Этого я не смог добиться даже спустя три недели.
Суровая реальность ударит поддых
Оказалось, что мотивации у людей нет. Решил, что программирование — не моё и ушёл по-английски, оставив группу. Тем, кто учиться не хотел, достаточно было бы об этом сообщить. Но они решили поступить подло: после провала дедлайна не выходить на связь.
Были те, кто домашку проваливал, неумения управлять временем. Сообщать о том, что они что-то не сделают заранее, видимо, было стыдно.
Это привело к почти нулевой успеваемости
Только в первую неделю и только один проект был сделан, согласно текущих знаний. Большинство групп только темы проектов взяли и успокоились (времени то ещё 7 недель — успеется). Правда, одной группе пришлось поменять тему из-за моего недосмотра. Одна группа сверстала хотя бы одну страницу (сделанный проект не учитываю). Ещё две только согласовывали дизайн.
Во вторую неделю выяснилось, что две группы и не группы вовсе, там по одному человеку. Но объединяться они не захотели.
Даже на третью неделю две команды не согласовали дизайн, и ничего не сверстали. И обсуждать эту ситуацию самостоятельно не стали.
Вся группа ждала, пока лидер даст отмашку, что тема проекта взята. Потом ждали дизайнера, пока сам согласует. Потом ждали верстальщика.
И неуспеваемость исключительно моя вина. Я людям не сумел объяснить, что так делать не стоит. Никаких отсрочек не будет — проект развивается или ритмично или умирает. Сообщать о проблемах надо заранее. Что надо параллелить процессы — вы команда.
Что нужно было сделать
В конце первой лекции подвести явные итоги, что надо писать мне про все форс-мажоры, никого не ждать, принимать решения молниеносно, а работать быстро — переделать можно на следующей неделе, сейчас важно сделать, чтоб всё работало.
Вообще, в конце каждой лекции лучше подводить итоги и говорить, чем научились. А то и в начале лекции объяснять, чему научимся.
Разъяснить, что лидеры это те, кто распределяют нагрузку. Если лидера нет или вы с лидером не согласны — надо привлекать меня. Ну и, конечно, мне самому понять, что надо быть строже.
Например, ко мне подошли две девушки с просьбой выбрать им проект, который подходит под два условия: во-первых, минимум дизайна, потому что проект надо потом переделать в интернет-магазин услуг; во-вторых больше дизайна. Тут, конечно, не надо даже слушать — а надо решать, притом не удовлетворяя никаких требований.
Разъяснить, что учимся программировать на реальном проекте, а не конкретному языку или каким-то фреймворкам или CMS. Потому что надо не научить в нужные отверстия квадраты и треугольники совать, а выпиливать эти квадраты и треугольники.
Объяснить, что если не собираешься выполнять взятые обязательства, то уведомляй заранее, а не постфактум. «Я не смогу сделать это, завтра в командировку» —, а не «Я был в командировке, поэтому ничего не сделали».
Что я реально сделал
Создал обсуждение, кто что уже сделал в проекте и что собирается делать дальше. Ответили не все, но, видимо, это сподвигло мне скидывать работы для согласования.
При каждом удобном моменте просил меня спрашивать обо всём. Скидывать все вопросы. Во-первых, так с дизайном получается гораздо быстрее: я грязно накидываю как должен выглядеть макет при моих условиях — успех. Моего времени 20 минут. А они сэкономили не менее часа.
Случайно сделал себе дополнительный контроль
Я не подумав выслал администраторские доступы ко всем проектам всем. Осознав ошибку, я быстро поменял пароль. А вот все опоздавшие уже писали мне, что их пароли не подходят и я говорил как исправлять, зато знал, когда они только приступили к выкладке первых поделок на хостинг.