Длительность лекций

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

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

Третью уложил в полтора часа.

Большие лекции — плохо

Чем больше лекция, тем больше там полезной информации. А много информации тяжело запомнить. Надо разбивать.

Внимание держится только 45 минут. Далее необходим перерыв. Я его себе позволить не мог. А значит, слушали меня хуже.

Больше лекция — меньше времени на вопросы.

Но мои лекции не так уж провальны

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

Во второй я объяснил язык с нуля, с азов. Рассчитывая на то, что таких знаний хватит, чтоб понимать работу языков, а не думать, что для другого языка надо переучиваться программировать.

В третей я рассказал самые модные концепты последних лет: типографику и ООП.

Мои ожидания оказались слишком завышенными

Я надеялся, что команда сообразит, что можно параллельно вести процессы: дизайн, верстку, набор первоначальной информации, написание документации.

Возьмём список фильмов. Как будет выглядеть блок списка можно договориться за 5 минут предложив основную концепцию: «Список — это набор фильмов. Каждый фильм можно отмечать просмотренным». Ещё пять минут дизайнеру на схему главной: шапка, меню, несколько списков, футер. Дальше, каждый идёт и дорабатывает свою часть.

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

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

Суровая реальность ударит поддых

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

Были те, кто домашку проваливал, неумения управлять временем. Сообщать о том, что они что-то не сделают заранее, видимо, было стыдно.

Это привело к почти нулевой успеваемости

Только в первую неделю и только один проект был сделан, согласно текущих знаний. Большинство групп только темы проектов взяли и успокоились (времени то ещё 7 недель — успеется). Правда, одной группе пришлось поменять тему из-за моего недосмотра. Одна группа сверстала хотя бы одну страницу (сделанный проект не учитываю). Ещё две только согласовывали дизайн.

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

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

Вся группа ждала, пока лидер даст отмашку, что тема проекта взята. Потом ждали дизайнера, пока сам согласует. Потом ждали верстальщика.

И неуспеваемость исключительно моя вина. Я людям не сумел объяснить, что так делать не стоит. Никаких отсрочек не будет — проект развивается или ритмично или умирает. Сообщать о проблемах надо заранее. Что надо параллелить процессы — вы команда.

Что нужно было сделать

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

Вообще, в конце каждой лекции лучше подводить итоги и говорить, чем научились. А то и в начале лекции объяснять, чему научимся.

Разъяснить, что лидеры это те, кто распределяют нагрузку. Если лидера нет или вы с лидером не согласны — надо привлекать меня. Ну и, конечно, мне самому понять, что надо быть строже.

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

Разъяснить, что учимся программировать на реальном проекте, а не конкретному языку или каким-то фреймворкам или CMS. Потому что надо не научить в нужные отверстия квадраты и треугольники совать, а выпиливать эти квадраты и треугольники.

Объяснить, что если не собираешься выполнять взятые обязательства, то уведомляй заранее, а не постфактум. «Я не смогу сделать это, завтра в командировку» —, а не «Я был в командировке, поэтому ничего не сделали».

Что я реально сделал

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

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

Случайно сделал себе дополнительный контроль

Я не подумав выслал администраторские доступы ко всем проектам всем. Осознав ошибку, я быстро поменял пароль. А вот все опоздавшие уже писали мне, что их пароли не подходят и я говорил как исправлять, зато знал, когда они только приступили к выкладке первых поделок на хостинг.