Этот вопрос может оказаться слишком расплывчатым и ошибочным по нескольким причинам, поэтому я иду на риск, но я думаю, что это что-то общее, и я попытаюсь ограничить сферу, поэтому, пожалуйста, дайте ему шанс.
Я работаю в небольшой технологической компании с разработчиками программного обеспечения, администраторами баз данных, devops и т. д. У всех нас есть специальные навыки, и это часто создает проблему, когда один из нас не работает, поэтому я думаю о том, как мы можем научить друг друга нашим экспертиза в лучшем формате.
Меня интересует не то, какую медиатехнологию использовать, а формат процесса — возможно, такие элементы, как:
Я хотел бы услышать об опыте людей и мнениях о том, что работает. Моя цель состоит не только в том, чтобы научить всех строго соответствующим навыкам, но и в том, чтобы укрепить способность каждого уверенно и ясно выражать свои мысли, выступать перед публикой и т. д.
Так что ты думаешь?
В моей предыдущей компании мы организовали «Обедай и учись», люди могли представить все, что им вздумается, чтобы помочь им освежить свои навыки презентации. У нас будут вопросы и отзывы о содержании и о презентации в целом. Часто люди выбирали тему, связанную с работой, что действительно помогало придать смысл тому, что они делали. Однако это не лучший формат для реального обучения кого-то мелочам.
Что касается более правильного кросс-тренинга в команде, то мы много использовали парное программирование. Таким образом, менее опытный человек сидел с более опытным человеком, чтобы выполнить задачу, обычно с менее опытным человеком, управляющим клавиатурой. Они должны чувствовать, что могут задавать уточняющие вопросы и делать заметки. Мы также использовали командное вики-пространство (у нашей компании был Confluence, но есть и другие варианты) для хранения документации, инструкций и т. д. Парное программирование может быть утомительным, поэтому лучше не заниматься им весь день каждый день, но, безусловно, помогает всем учиться друг у друга.
Я пришел из области разработки программного обеспечения и электронного дизайна, поэтому этот ответ сильно склоняется в этом направлении.
Легче всего передавать знания непосредственно во время разработки, а не после. Для этого мы активно используем обзоры кода или дизайна. Не просто говорите: «Эй, посмотрите на мой дизайн быстро, чтобы я мог его опубликовать». Назначайте встречи, на которых вы и хотя бы один коллега знакомитесь с новым дизайном и рассказываете о нем. Не останавливайтесь, пока коллега все не понял и не нашел хотя бы одну ошибку. Как и во всех проверках кода/дизайна, убедитесь, что количество изменений является управляемым. Если за одно собрание уже слишком много нужно усвоить, разделите его и проведите несколько сессий.
Я хотел бы услышать об опыте людей и мнениях о том, что работает.
Боюсь, есть целые курсы и книги на эту тему.
Это сводится к следующему: существует около двух десятков практических методов обучения, а не какая-то научная теория.
Это потому, что нет одного лучшего метода, это зависит от . Это зависит от аудитории, темы и преподавателя. А потом внешние воздействия. Я уверен, что люди хотели бы услышать об этом кластере суперкомпьютеров, но у вас просто нет денег, чтобы иметь его для демонстрации. Другим примером могут быть новые функции синтаксиса и использование git. Использование Git важно, если вы его испортите, вы можете нанести большой ущерб, но если вы не помните новый синтаксис... в худшем случае вы получите ошибку компилятора.
Итак... в передаче знаний не существует универсального подхода. Вам нужно будет найти кого-то, кто знает эти вещи, или вам нужно будет найти кого-то, кто хочет узнать эти вещи. Или вы можете просто пойти методом проб и ошибок, делать то, что считаете лучшим, и адаптироваться.
Если в вашей компании есть ученики, поищите их наставника, они должны знать об этих методах.
j4nd3r53n
Джулиана Карасава Соуза
j4nd3r53n
Нельсон
j4nd3r53n
Нельсон