Главная » Хабрахабр » Обучающие настольные игры для программистов

Обучающие настольные игры для программистов

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

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

Работает ведущим разработчиком, и как сеньор, периодически обучает коллег, ведет лекции и внутренние обучающие семинары. О спикере: Артём Ларин в Java с 2004 года. К сожалению, был и негативный опыт обучения, который привел Артёма к идее, что настольные игры — это то, что нужно в разработке.

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

Проблемы в IT

Я считаю, что в IT есть большая проблема — и это кадровый голод. Вопрос много раз обсуждался, есть статистика от hh.ru и публикации на эту тему. На всякий случай проверим статистику сами. Если в поисковике hh.ru ввести «Java», мы увидим 5–6 тыс. вакансий по России, а количество резюме на том же hh.ru — больше 100 тыс. Кажется, что недостатка в разработчиках нет — резюме на порядок больше чем вакансий.

На сайте hh.ru есть специальный индекс, который так и называется — hh-индекс. Посмотрим с другой стороны. Для запроса «Java» он примерно равен единице: на одну вакансию — одно резюме. Это соотношение активных резюме и вакансий. Компании нужен программист, она открывает вакансию, и, согласно индексу, сразу же должен прийти сеньор, устроиться на работу и закрыть вакансию. Опять получается, что никакого кадрового голода нет?

Цифры говорят, что кадрового голода нет, но в реальном мире, а не в мире hh-индекса, он есть. Сеньор «должен» прийти, но не приходит. За Java-сеньорами идет кровавый head-hunting: их осаждают HR’ы и рекрутеры с предложениями устроиться на работу. Java — это сверх-дефицитная профессия. В среднем, один Java-разработчик получает 5-6 офферов, даже если трудоустроен.

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

Поэтому мы подстраиваемся и решаем вопрос с другой стороны — обучаем. Кадровый голод мы победить не можем — только констатировать. Давайте подумаем — как обучать людей в IT-индустрии.

Способы обучения в IT-индустрии

В 1980 году National Training Laboratories в США провели исследования эффективности разных способов обучения. Выяснилось, что у лекций и чтения книг крайне низкая эффективность — всего 5-10%. Дальше идет просмотр видео лекций и прослушивание аудио. Максимальная эффективность в 90% — это обучение людьми других людей — менторинг и немедленное применение полученных знаний на практике.

На основе пирамиды обучения проведем экспресс-анализ методов обучения в IT.

Курсы

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

Внутренние семинары

Я очень люблю внутренние семинары и много раз их проводил. Считаю, что они эффективны только в случае, если аудитория интерактивно работает с преподавателем. К сожалению, так бывает редко. Обычно люди приходят на семинар, рассаживаются по местам и пассивно слушают лектора, попивая чаек. Интерактива нет, эффективность низкая — максимум 50%. Поэтому про семинары тоже можно забыть.

Конференции

Задача конференции — познакомить с новинками индустрии, но никак не хардкорное обучение. Конференции — это общение, свежие идеи, но не обучение — эффективность в этом случае всего 5-30%. Конференции также не то, что нам нужно.

Самообучение

Я, как и большинство моих друзей-программистов, пришли в профессию через самообучение. Это способ эффективный, я бы ему поставил 75% КПД, если бы не один огромный недостаток — список книг для изучения.

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

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

Это стена из 15 толстых книг, которая не дает сотне тысяч начинающих разработчиков с hh.ru попасть в заветные 5 тыс. По аналогии с «плато отчаяния» я ввел концепцию «стена отчаяния». активных вакансий сеньоров и мидлов.

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

Менторинг и коучинг

Это самый эффективный способ, если верить пирамиде обучения — 90% эффективности. Но у него тоже есть недостатки, которые не позволяют назвать этот способ «волшебной таблеткой».

В своей практике я не встречал случаев, когда один ментор может обучать 10 человек. Менторинг — это всегда отношение 1:1, то есть один ментор и один менти — обучаемый. Могу сказать лично по себе — у меня было 2 менти, максимум. Менторинг очень плохо масштабируется и отвлекает сеньоров от основной работы. Поэтому 3-4 человека или больше, менторить невозможно, если говорить о качественном менторинге. И при этом, половина моего рабочего времени, а иногда и больше, уходила на менторство, а не на решение производственных задач, за которые мне платят деньги.

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

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

Игры!

Какие игры мы знаем? Шашки, шахматы, бирюльки и домино — интеллектуальное занятие, несмотря на простоту.

Кому не нравятся классические, есть «Magic: The Gathering». Карты — тоже интеллектуальная игра. Во многих IT-компаниях проводятся целые турниры, посвящённые ей. Многие айтишники любят эту игру, я в том числе.

И нашел, например, такую игру. Все эти игры игры для развлечения, а не для программистов, и я задался вопросом — а есть ли игры для программистов?

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

Дальше игра покруче: 3D-ландшафт и трехмерный герой-робот.

На каком-то C-подобном языке нужно писать псевдокод для управления роботом.

Ниже скриншот третьей игры, которую я нашел.

Здесь, опять же, на псевдокоде нужно писать программу для управления персонажем: перемещать его по лабиринту, открывать и закрывать двери, манипулировать предметами.

Все остальные игры похожи на эти три, и у всех много серьезных недостатков.

Недостатки игр

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

И к тому же, игрок всегда один, в то время как в IT работают в командах. Игрок управляет персонажем или «роботом», в то время как в реальности сеньоры и мидлы работают с очень сложными бизнес-объектами. Поскольку многие программисты выросли из интровертов и командная работа для нас часто трудна, хотелось бы, чтобы игра прокачивала и командные скилы. Любой софтверный проект — это командная работа.

Личный опыт игр

В то же время в мире существует богатая культура настольных игр: Munchkin, Magic: The Gathering, Dungeons & Dragons. Но, к сожалению, я не встречал «настолок» для программистов.

Мало того, мы с дочкой любим их создавать. Лично я и вся моя семья: жена, дочка и кот Тишка, любим «настолки». На этих неказистых фото 3 примера наших «настолок». Мы придумали игру по популярной в свое время программе «Ревизорро» и другие различные приключенческие игры.

Я прошел четыре этапа: негативный опыт обучения сотрудников, неутешительный анализ текущих игр, опыт игры в «настолки» и опыт их создания. Как я пришел к идее настольных игр для программистов? Действительно, а почему бы не сделать игру самому? Всё это привело меня к «настолкам» для программистов.

Требования к игре

Насколько она должна быть футуристической либо приземленной?

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

Это те темы, которые часто не позволяют джуниорами перескочить в голове некий технический уровень и стать сеньорами. Игра должна обучать реальным промышленные задачам, с которыми сталкиваются настоящие сеньоры и мидлы: многопоточность, JPA, базы данных и concurrent-структуры данных. Я говорю не только про Java, а вообще про все языки, в том числе Python, C++ — везде есть многопоточность, базы данных и concurrent-структуры.

Сейчас практически в любой компании есть code review, и часто встречается ситуация: разработчики, особенно начинающие, видят исходный код, но не могут описать словами, что в нем происходит. Следующая задача, которую должна решать игра — прокачивать скилы в командной работе: формирование единого технического языка внутри команды и умение обсуждать код. Хотелось бы, чтобы игра прокачивала этот технический словарь. Они могут написать код, но обсудить его не могут — нет в голове технического словаря. Кроме того, наличие технического языка помогает писать качественную документацию.

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

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

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

Пример «Настолки»

Игра, которую я разработал, называется «Кто украл монитор?». Поскольку мы все технари, то знаем, что монитор — это не тот телевизор, в который мы смотрим на работе, а концепция из многопоточности. Задача игры — коллаборативно ознакомить команду с deadlock в Java-многопоточности. Игроки в команде не соревнуются друг с другом, а совместно решают общую задачу — настоящий тимбилдинг. Я выбрал тему многопоточности, потому что это планка для джуна, через которую он часто не может перепрыгнуть, и начать писать настоящий хороший промышленный код. Бизнес требует от нас больших мощностей, и почти каждая промышленная программа многопоточна. Поэтому критически важно и для бизнеса и для программистов знать, что такое многопоточность.

Элементы игры

Первый элемент — это поле «Исходный код» на большом листе плотного картона. На нем приведен некий фрагмент кода — у нас на языке Java.

Это цветные рамки из проволоки. Следующий элемент — жезлы текущих строк.

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

Первое — машина состояний — квадратики и стрелочки с надписями. В игре два игровых поля.

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

Следующий элемент — двухсторонние фишки потоков.

На другой стороне — бегущий человечек — поток активен. На одной стороне нарисованы закрытые глаза — это значит, что поток неактивен.

Если поток начал работать, то игрок перемещает фишку состояния в состояние «new» — начальное состояние, когда поток только что создан. Проиллюстрирую, как фишки перемещаются по машине состояний.

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

Следующий элемент игры — карты мониторов.

Каждый монитор привязан к Java-объекту, которых два: «one» и «two». Эти карточки сначала лежат в общем стеке, а потом забираются игроками в свои руки.

Последний элемент — часы потоков.

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

Рассмотрим несколько ходов из игровой сессии.

Пример игровой сессии

У нас есть три игрока:

  • Михаил работает за поток «main» — главный поток Java.
  • Евгений — поток «t1».
  • Светлана — поток «t2».

Каждый из игроков ставит себя на место одного из потоков и проживает в процессе игры его жизнь. Так он понимает, что значит быть Java-потоком.

Михаил перемещает жезл потока на первую строчку кода.

Евгений и Светлана еще спят — их потоки не созданы, и Михаил перемещает свой жезл потока на следующую строку кода, где написано <code>Thread t1 = new Thread()</code> — это значит, что будет создан поток Евгения «t1».

Евгений не зевает, берет свою фишку потока и ставит ее в состояние «runnable» — стороной с бегущим человечком.

Пример командной работы

Светлана говорит Евгению:

  • Евгений, почему ты поместил фишку своего потока не в состояние «new», а сразу в состояние «runnable»?

  • А почему бы и нет?

Видно, что Евгений самый неопытный джуниор в команде, но Светлана более опытная и говорит:

  • Евгений, согласно машине состояний, первоначальное состояние у потока — «new».

Евгений соглашается со Светланой и перемещает фишку своего потока в правильное положение.

Игра идет дальше… Это пример того, как в команде происходит передача знаний в процессе игры.

На некотором ходе уже Михаил делает замечание Евгению:

  • Евгений, ты вошел в синхроблок, но кое-что забыл сделать...

  • Точно, я забыл взять в руки монитор данного объекта!

Евгений берет монитор объекта «one». Получается, что поток «t1» Евгения владеет этим монитором.

Подробнее посмотрите на видео или на слайдах в презентации. Дальше идет игра: много ходов, пропуски, работа с часами.

В итоге и поток «t1», и поток «t2» находятся в состоянии «заблокирован», то есть мы наблюдаем deadlock. В конце игры у Евгения один монитор, а у Светланы — другой, и поток каждого из них заблокирован ожиданием мониторов.

В процессе игровой сессии каждый из игроков на своем личном опыте проверит, прочувствует, что такое deadlock, как он возникает и что это такое.

Выводы

Игровая сессия — короткая. За 20 минут люди общаются, обсуждают задачи, обмениваются опытом и знаниями, работают в команде.Можно обучать не одного человека, а целую команду — игра масштабируется 1:n.

Каждый игрок ставит себя на место потока, проживает его жизнь, как свою собственную и решает реальную промышленную задачу. Игроки проживают опыт — реальный и живой. Deadlock — это серьёзная проблема — причина многих багов, в том числе «плавающих» — heisenbug, которые не каждый может починить.

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

Опыт игры

Немного расскажу о реальном опыте применения этой игры. Был случай, который мне хорошо запомнился. В игре участвовало трое: один из игроков работал только на Delphi, второй — на C++, а третий игрок — знал только Haskell.

За 5 минут я кратко рассказал правила, и потом с интересом наблюдал командную динамику по Такману. Моя задача заключалась в том, чтобы научить их Java-многопоточности за 20 минут.

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

Чему еще можно обучиться в игре

Кроме deadlock, в этой игровой механике можно использовать другие важные многопоточные темы:

  • Race conditions — гонки потоков, в которых обычно даже сеньоры обычно не разбираются.
  • Механизм wait/notify.
  • Механизм join/isAlive.

Какие игры еще можно сделать?

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

В качестве примера покажу, как сделать игру для машины состояний JPA-сущности. Можно геймифицировать машину состояний JPA-сущности и жизненный цикл компонентов JEE/Spring.

Открываем раздел картинок Google, вбиваем «Машина состояний JPA-сущности».

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

Можно сделать игры на любые серьезные темы, с которыми работают сеньоры и в которых «плавают» джуниоры.

  • Транзакционные механизмы JEE.
  • Уровни изоляций SQL.
  • Структуры данных: очереди, стеки, HashMap.
  • Структуры пакета java.util.concurrent.

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

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

Развитие игры

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

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

Отсюда можно скачать элементы и попробовать внедрить игру у себя. За обновлениями игры можно следить в Linkedin-аккаунте Артёма Ларина или на GitHub.

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Слушаем SID-музыку через OPL3 на современных ПК

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

Пользователь в Docker

В новой статье он рассказывает, как создать пользователей в Docker. Андрей Копылов, наш технический директор, любит, активно использует и пропагандирует Docker. Правильная работа с ними, почему пользователей нельзя оставлять с root правами и, как решить задачу несовпадения идентификаторов в Dockerfile. Это кажется очень удобно, ведь ...