На рынке труда в Java-разработке наблюдается интересная ситуация. Активных резюме разработчиков больше 100 000 и на одно резюме приходится одна вакансия. В то же время работодатели и кадровые агентства жалуются на недостаток кадров, и, несмотря на тысячи резюме, найти хорошего специалиста — тяжело. Например, Java-разработчик — продукт дефицитный: встречается редко, сокращения их не касаются, зарплаты растут, а конкуренция падает. Исследовать причины явления мы не будем, а расскажем об одном из способов, как можно эту проблему решать.
Искать технических специалистов можно долго, но работа не ждет, поэтому приходится принимать на работу не достаточно квалифицированные кадры и обучать в процессе. Из вариантов: самообучение в свободное время или курсы и семинары в рабочее, но можно выбрать и игры. Артём Ларин расскажет почему традиционные способы обучения ненадежны и почему игры — в чём-то лучше остальных.
Специальные командные настольные игры не только обучают сложным темам разработки ПО, активно вовлекая каждого участника, но и формируют общий технический язык в команде, а также решают задачу тимбилдинга и формируют корпоративную культуру.
О спикере: Артём Ларин в Java с 2004 года. Работает ведущим разработчиком, и как сеньор, периодически обучает коллег, ведет лекции и внутренние обучающие семинары. К сожалению, был и негативный опыт обучения, который привел Артёма к идее, что настольные игры — это то, что нужно в разработке.
Речь пойдет о том, как прокачивать в команде не софтовые, а хардовые технические скилы. Доклад состоит из двух частей: гуманитарной и творческой. Даже если вы не технарь, во второй части вам придется поднапрячь свои гуманитарные , потому что без технической информации никуда — я расскажу о хардовых скилах и их прокачке.
Проблемы в IT
Я считаю, что в IT есть большая проблема — и это кадровый голод. Вопрос много раз обсуждался, есть статистика от hh.ru и публикации на эту тему. На всякий случай проверим статистику сами. Если в поисковике hh.ru ввести «Java», мы увидим 5–6 тыс. вакансий по России, а количество резюме на том же hh.ru — больше 100 тыс. Кажется, что недостатка в разработчиках нет — резюме на порядок больше чем вакансий.
Посмотрим с другой стороны. На сайте hh.ru есть специальный индекс, который так и называется — hh-индекс. Это соотношение активных резюме и вакансий. Для запроса «Java» он примерно равен единице: на одну вакансию — одно резюме. Опять получается, что никакого кадрового голода нет? Компании нужен программист, она открывает вакансию, и, согласно индексу, сразу же должен прийти сеньор, устроиться на работу и закрыть вакансию.
Сеньор «должен» прийти, но не приходит. Цифры говорят, что кадрового голода нет, но в реальном мире, а не в мире hh-индекса, он есть. Java — это сверх-дефицитная профессия. За Java-сеньорами идет кровавый head-hunting: их осаждают HR’ы и рекрутеры с предложениями устроиться на работу. В среднем, один 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% эффективности. Но у него тоже есть недостатки, которые не позволяют назвать этот способ «волшебной таблеткой».
Менторинг — это всегда отношение 1:1, то есть один ментор и один менти — обучаемый. В своей практике я не встречал случаев, когда один ментор может обучать 10 человек. Менторинг очень плохо масштабируется и отвлекает сеньоров от основной работы. Могу сказать лично по себе — у меня было 2 менти, максимум. И при этом, половина моего рабочего времени, а иногда и больше, уходила на менторство, а не на решение производственных задач, за которые мне платят деньги. Поэтому 3-4 человека или больше, менторить невозможно, если говорить о качественном менторинге.
Длительный срок обучения — 1-2 года. По моему опыту, программист работает в компании в среднем тоже 2 года. Получается грустная картина: менторишь человека, вбиваешь в него знания, а потом кто-то увольняется — либо ты, либо он, и весь менторинг уходит в никуда.
Менторинг эффективен, но из-за недостатков я задумался — почему бы не найти какой-то способ, который будет эффективен также, как менторинг, но без минусов: веселый, интересный и масштабируемый. Подумав, я пришёл к идее игр — это весело, нравится мне и людям, и решает проблемы менторинга.
Игры!
Какие игры мы знаем? Шашки, шахматы, бирюльки и домино — интеллектуальное занятие, несмотря на простоту.
Карты — тоже интеллектуальная игра. Кому не нравятся классические, есть «Magic: The Gathering». Многие айтишники любят эту игру, я в том числе. Во многих IT-компаниях проводятся целые турниры, посвящённые ей.
Все эти игры игры для развлечения, а не для программистов, и я задался вопросом — а есть ли игры для программистов? И нашел, например, такую игру.
Игрок оперирует цветными блоками, составляет из них исходный код, чтобы управлять космонавтом. Очевидно, что игра совершенно детская, я бы сказал — детсадовская. Она никак не превратит игрока в сеньора.
Дальше игра покруче: 3D-ландшафт и трехмерный герой-робот.
На каком-то C-подобном языке нужно писать псевдокод для управления роботом.
Ниже скриншот третьей игры, которую я нашел.
Здесь, опять же, на псевдокоде нужно писать программу для управления персонажем: перемещать его по лабиринту, открывать и закрывать двери, манипулировать предметами.
Все остальные игры похожи на эти три, и у всех много серьезных недостатков.
Недостатки игр
Эти игры обучают лишь базовым концепциям — таким, как переменные, циклы, функции — то, что даже джуниоры узнают еще в институте. Игры оторваны от реальных промышленных задач, потому что в них нет ни многопоточности, ни транзакционности — всего того, что знает сеньор или мидл. Подобному игры не учат, и в этом их проблема.
Игрок управляет персонажем или «роботом», в то время как в реальности сеньоры и мидлы работают с очень сложными бизнес-объектами. И к тому же, игрок всегда один, в то время как в IT работают в командах. Любой софтверный проект — это командная работа. Поскольку многие программисты выросли из интровертов и командная работа для нас часто трудна, хотелось бы, чтобы игра прокачивала и командные скилы.
Личный опыт игр
В то же время в мире существует богатая культура настольных игр: Munchkin, Magic: The Gathering, Dungeons & Dragons. Но, к сожалению, я не встречал «настолок» для программистов.
Лично я и вся моя семья: жена, дочка и кот Тишка, любим «настолки». Мало того, мы с дочкой любим их создавать. Мы придумали игру по популярной в свое время программе «Ревизорро» и другие различные приключенческие игры. На этих неказистых фото 3 примера наших «настолок».
Как я пришел к идее настольных игр для программистов? Я прошел четыре этапа: негативный опыт обучения сотрудников, неутешительный анализ текущих игр, опыт игры в «настолки» и опыт их создания. Всё это привело меня к «настолкам» для программистов. Действительно, а почему бы не сделать игру самому?
Требования к игре
Насколько она должна быть футуристической либо приземленной?
Короткая игровая сессия — не больше 15-20 минут, потому что по задумке играть в эту игру нужно в рабочее время. Играя больше 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.
Моя задача заключалась в том, чтобы научить их Java-многопоточности за 20 минут. За 5 минут я кратко рассказал правила, и потом с интересом наблюдал командную динамику по Такману.
Сначала шторм, потом нормализация — команда играла самостоятельно без моей помощи, обсуждала ходы, и пришла к финалу, обогатившись знаниями. Все были довольны.
Чему еще можно обучиться в игре
Кроме deadlock, в этой игровой механике можно использовать другие важные многопоточные темы:
- Race conditions — гонки потоков, в которых обычно даже сеньоры обычно не разбираются.
- Механизм wait/notify.
- Механизм join/isAlive.
Какие игры еще можно сделать?
Помимо многопоточности можно обыграть другие важные разделы, например, машины состояний. Если вы видите на схеме квадратики со стрелочками, то это машина состояний.
Можно геймифицировать машину состояний JPA-сущности и жизненный цикл компонентов JEE/Spring. В качестве примера покажу, как сделать игру для машины состояний JPA-сущности.
Открываем раздел картинок Google, вбиваем «Машина состояний JPA-сущности».
Находим визуально понравившуюся машину состояний, красиво оформляем её в любом редакторе, и вуаля — игра готова.
Можно сделать игры на любые серьезные темы, с которыми работают сеньоры и в которых «плавают» джуниоры.
- Транзакционные механизмы JEE.
- Уровни изоляций SQL.
- Структуры данных: очереди, стеки, HashMap.
- Структуры пакета java.util.concurrent.
Везде игроки будут ставить себя на место механизмов или структур, и проживая их жизнь, осваивать сложные темы.
Когда я готовился к докладу, мне пришла в голову мысль, что с помощью такой игровой механики можно обучать людей даже бизнес-требованиям. Часто встречал ситуации, когда программисты пишут бизнес-продукт плохо понимая, как этот продукт работает. С помощью геймификации можно обучать программистов бизнес-требованиям продукта, который они пишут.
Развитие игры
Игра коллаборативная, но можно добавить элемент соревновательности. Например, раздать игрокам фишки репутации. Если один игрок делает другому замечание или передает знания, происходит обмен фишками: человек, которому сделали замечание, отдает фишку тому, кто его поправил. По итогам игры количество фишек-репутаций подсчитывается, у кого их больше, побеждает.
Принятие решений — необходимый элемент многих «настолок». Если ввести его в эту игру, то она станет жёстче. А если разрезать поле вдоль исходного кода и в начале каждой игровой сессии случайным образом переставлять строки, то каждый раз получим новое игровое поле. Элемент случайности прибавит интереса.
За обновлениями игры можно следить в Linkedin-аккаунте Артёма Ларина или на GitHub. Отсюда можно скачать элементы и попробовать внедрить игру у себя.
Этот доклад, как раз один из тех, что помог нам понять востребованность темы обучения и передачи знаний. В результате уже 26 апреля мы проводим KnowledgeConf полностью этому посвященную. И про современные нестандартные способы обучения, и про передачу опыта новичкам будет много полезных докладов. Присоединяйтесь, и проблема роста сотрудников и шаринга знаний в команде перестанет для вас быть нерешаемой.
Автор: Светлана Новикова
