Когда закончился очередной поток онлайн-курса «Как читать умные книги?», несколько участников выразили желание поработать в проекте «IT-Классика». Вот только проект к этому оказался не готов... Что помешало? Давайте разбираться.
Во-первых, поначалу проект и его тематика сильно плавали. И хотя заявлено, что мы «копаемся» в истории компьютеров, программирования и Computer Science, адаптируем знаковые моменты в истории для современных специалистов, все не так просто. К проекту то и дело прилипали обрывки работ других участников, и какое-то более-менее единое видение сформировалось буквально за месяц до появления новичков.
Во-вторых, проект «откололся» от уже существовавшей группы «IT-pro» (объединение IT-разработчиков на базе издательства LIVREZON). Все участники «IT-классики» – опытные члены Клуба авторов. А это значит, что: а) уже выработан общий язык, общая культура; б) участники самостоятельны, и можно без больших опасений на некоторое время «пустить работу на самотёк».
В-третьих, за тот небольшой промежуток времени, когда проект «устаканился», появились наброски моделей и прочих атрибутов. Ожидаемо, что эти наброски не высечены в камне и вполне могут содержать ошибки и неточности (точно содержат!), а то и вовсе оказаться в корне неверными. Это нормально для исследовательской работы. Поэтому какие-то нюансы, детали и оговорки, принятые участниками, вообще не фиксировались и существовали за счёт общего контекста.
Даже если устроить серию «погружающих» лекций, проблема не решится. Мы просто зальём головы участников кашей, которой они не смогут воспользоваться.
Абсолютный. Первобытный. Хаос.
Участники, пришедшие сразу после курса «КЧУК?», ведут исследования в правильно поставленном рабочем ритме. Но если после окончания курса кто-то решит сделать «перерыв» от такого темпа, то все усилия пойдут насмарку. Придётся потратить немало времени и сил, чтобы поставить ритм заново.
Так что участникам надо сразу выдать готовых заданий, а в идеале – погрузить их в бурный поток рабочих задач.
Однако и тут есть опасность: если мы просто заставим их разбирать какие-то кейсы, то это быстро обернётся кафкианским адом. Что делаем? Зачем делаем? Неизвестно. Есть только обязанности и наказания. Такое уже случалось не раз, и со мной в том числе. Участник теряется в работе, теряет ориентиры, причины, смысл и остаётся один на один с пачкой каких-то бессмысленных (с его, участника, перспективы) задач.
А если все пойдет совсем плохо, то в конечном итоге групповой проект просто сожрёт и те ресурсы, что участник должен был использовать на своих персональных проектах. Для опытных участников это не проблема, они могут разделять (и успешно разделяют) вереницы персональных и групповых проектов, но для новых людей это неизведанная территория.
И что мы получим в итоге?
В лучшем (!) случае участники просто убегут на другие проекты. А могут полностью разочароваться в работе над исследовательскими проектами и забросят работу, в том числе и индивидуальную.
Сойдут с дистанции.
Этого мы допустить очень сильно не хотим.
Итак, у нас есть сырые модели, есть набор терминологии и коллективной эрудиции, есть свежая и исполнительная кровь. Также имеются проблемы в организации работы и формулировке центральной задачи, на решение которых нужно время.
Мы взяли нашу сырую модель, оставили в ней только ключевые узлы и выдали её новым участникам вместе с пачкой кейсов, которые нужно было протащить по этой модели. Основные и самые главные понятия – то, что встречается в описании самой модели, – оформили отдельным документом. Что-то вроде статьи с пояснениями ключевых идей.
В результате мы убили двух зайцев.
По ходу разборов постепенно проявляются дыры в знаниях коллег. Видно, что и где коллеги не понимают или не знают. Это можно корректировать прямо по ходу выполнения заданий, например, комментариями. Если дыр набирается много, можно устроить мини-лекцию на тему. Так как материал с мини-лекций привязан к конкретным задачам, которые участник уже пытался выполнить, его намного легче понимать.
Проявляются ошибки, дыры и неточности в самой модели. То есть, работа уже со старта становится полезной для проекта, и участники работают с некоторой понятной целью, что делает всё это куда меньше похожим на каторгу.
Частая ошибка, которую допускают многие, – это компьютероцентризм. На самом деле, для нас это был известный эффект, и я например, иногда ловлю его на себе. Это частный случай инерции мышления, когда программист, разбирая техническую систему с компьютером, застревает именно в компьютерных понятиях. Тут есть неочевидный момент, который мы обнаружили: чтобы разобраться в технико-программной системе, для начала нужно выбросить «техническость» из уравнения и разложить работу пользователя на серию целенаправленных актов.
Другими словами, мы смотрим, что пытается сделать пользователь – но не в терминах типа «создать файл» или «открыть окно программы», а в пользовательских понятиях: «написать книгу», «составить план работы на неделю» и т. д. Целенаправленный акт в данном случае – это действие или конкретное символическое преобразование, которое приближает пользователя к его цели. Только когда ясны действия и преобразования, мы начинаем рассматривать инструменты для их совершения, в уравнение начинают возвращаться «мыши», «файлы», «окна» и т. д.
Что интересно, это так же отражается на терминологии. Например, одно из наших ключевых понятий – символ – пришло из семиотики, что-то взято из кибернетики и т. д., но почти ничего не взято из программирования или компьютеров. Из-за этого компьютероцентризм может легко загнать в ступор при попытке разобрать кейс. Думаешь о создании файлов и структуре директорий, а таблица от тебя требует указать, что пытается сделать писатель, которому нужно написать аннотацию главы романа – что-то явно не сходится.
Это постепенно корректируется с опытом, но чтобы сделать сходства целевых операций наглядными, мы делали параллельные разборы одной и той же цели, но с разным набором технических инструментов.
У нас всё ещё есть ряд насущных проблем. Например, обсуждение запускается с большой задержкой, так как отчётный период длинный. Ещё мы никак не страхуемся от работы в последний момент, что нехорошо сказывается на индивидуальной рабочей дисциплине и сильно тормозит прогресс самого проекта – мы просто поздно видим ошибки, «затыки», вопросы и т. д.
Предполагаю, что проблему отчётного периода можно уменьшить, если двинуть дедлайн задач на воскресенье, и в этот же день выдать новые задачи, в то время как групповые созвоны оставить в середине рабочей недели. по средам. Так обсуждения станут более предметными и вертеться вокруг конкретных задач – участники успеют ознакомиться с материалами и попытаются, как минимум, сформулировать вопросы.
Задача будет «вариться» в голове в течении половины недели и, предположительно, участнику будет проще возвращаться к ней, да и качество работы, так же гипотетически, должно вырасти. Сейчас мы проверяем эту идею, и в будущем я поделюсь с вами новостями этого маленького эксперимента. Оставайтесь на связи.