Обмен опытом в программировании: как обучать эффективнее

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

Гипотезы, которые мы выявили, основаны на обратной связи от студентов. В Skillbox мы не только постоянно экспериментируем с форматами обучения, но и оцениваем, как люди реагируют на информацию и как усваивают ее. С этой целью используем внутренние инструменты аналитики.

Среди продуктовых метрик успешности, на которые мы ориентируемся:

• Оценка контента по 5-бальной шкале. Внутри платформы, на которой учатся студенты, любому уроку можно поставить оценку, по критериям подачи и понятности материала.
• Процент проходимости — количество людей, успешно усвоивших образовательный трек
• Оценка обратной связи по домашним заданиям от преподавателей.

Благодаря системе аналитики невооруженным глазом видно, где студентам становится сложнее и когда происходит отклонение от качества (например, медианная оценка работы проверяющего преподавателя, в нашем понимании, должна быть 4.5 из 5 или выше). Эти моменты дают понимание, когда следует менять подход. Далее — несколько ключевых выводов, которые мы сделали на основе своего опыта.

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

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

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

Например, в компании Lodoss Team отмечают: почти на каждом собеседовании случается, что соискатели видят вакансию и при подготовке к интервью пытаются максимально быстро охватить новую информацию. Например, указано, что требуются специалисты со знанием фреймворков: кандидаты пытаются за короткий срок изучить документацию и сделать пару туториалов. После этого считают себя экспертами, хотя реальным опытом не обладают. Такой подход не работает — важна связность.

Новые знания нужно подавать постепенно. Это подтверждают и ученые: кажется парадоксальным, но обучение происходит гораздо быстрее, когда мы «растягиваем» обучение. В книге How We Learn Бенедикт Кэри процесс сравнивают с поливом лужайки: если поливать лужайку 3 раза в неделю по полчаса, территория будет зеленее, чем при поливе раз в неделю по 1,5 часа. Подобным образом работает мозг: есть теория, что если вы пытаетесь что-то быстро изучить, концентрация внимания снижается. Мозг уделяет учебе меньше внимания.

К примеру, перед нами стоит задачи рассказать про концепцию переменных и разных типов данных в языке программирования. Часто можно встретить подход, когда рассказ начинается с формального определения, потом перечисляем все типы, даем к каждому типу несколько примеров «в вакууме», и считаем на этом задачу передачи знаний решенной. На самом деле, при таком сценарии вероятность того, что студент действительно понял тему, невелика. Информации много, применимость для боевых задач малопонятна. Альтернатива такая: сначала даем общую концепцию, упаковываем в реальный пример и знакомим ученик пока только с одним типом данных. Пусть человек сначала не видит картины целиком, но важно, чтобы он «присвоил» новое небольшое знание. Когда понимание окрепнет, можно попрактиковаться со следующим типом данных.

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

Кстати, Патрик Ленсиони в книге «Пять пороков команды», отмечает, что установить доверительные отношения возможно, когда человек не боится показаться уязвимым и слабым. Ведь именно из-за отсутствия доверия зачастую успешная связка профессионалов проваливается. Патрик Ленсиони советует: не нужно цеплять на себя маску всезнайки. Признаваться, что в каком-то вопросе не разбираешься и попросить совета — не стыдно. Это задает нужную атмосферу, что в дальнейшем позволяет избежать ошибок.

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

Например, у нас есть программа обучения разработке на Java — она состоит из двух уровней. На первом уровне студент изучает основы языка, и его применение к практическим задачам. Большинство задач с проверкой, но есть и самопроверка. На втором уровне мы объединяем ребят в команды, и под руководством действующего программиста-практика делаем большой проект. И тимлид, который ведет команду из студентов, не всегда проводит code review сам — за двухнедельный спринт каждый студент минимум 1 раз проверяет код, залитый кем-то из сокомандников, а тимлид проверяет результат ревью и тоже дает обратную связь, и рецензенту и автору кода. Это увеличивает способность мозга впитывать информацию усиливается — необычные подходы стимулируют зоны, ответственные за обучение.

Резюме

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