Как IT-инженеру делиться опытом так, чтобы его слышали и понимали: советы для митингов и внутренних докладов
В IT-компаниях сотрудникам часто приходится выступать перед коллегами: презентовать свое решение, отчитываться на регулярном митинге или просто делиться своим опытом. Но навык таких выступлений, пусть и перед небольшим количеством людей, есть не у всех.
Мы попросили поделиться своим опытом Романа Неволина @nevoroman, который регулярно участвует в IT-конференциях и выступает с докладами публично. Он расскажет, зачем вообще выступать перед коллегами и как правильно построить выступление, чтобы тебя слушали, слышали и понимали.
Немного обо мне
Программированием я увлекся еще в 9 лет, когда мне в руки попал учебник по Visual Basic. В 15–16 лет я начал фрилансить и в то же время учился в колледже на программиста официально. Кстати, там было безумно скучно, так что я быстро перестал ходить и побил все рейтинги прогулов. В 18 устроился на официальную работу. Проект был «интересный» — оттуда ушло три РМ, а спустя три месяца после моего назначения ушел лид. И произошел мем — лидом назначили меня. В 18 лет. А еще cпустя три месяца я понял, что там к чему, и уволился сам.
Потом началась уже более адекватная история — финтех, энтерпрайз, life science, немного машинного обучения. Именно с ML, кстати, начались мои выступления — пришел послушать Андрея Акиньшина на шестой встрече SpbDotNet, рассказал Толе Кулакову о своих издевательствах с ML в .NET, и понеслось.
Сейчас я работаю техлидом в нидерландской компании Ahold, а в свободное время развиваю коммуникацию с разработчиками, делаю доклады, пишу статьи и помогаю другим делать то же, чем занимаюсь я.
Зачем вообще делиться своим опытом в IT
Равномерно распределять знания между членами команды. Самая практичная причина — чтобы внутри команды все развивались равномерно и могли друг друга подменить, например, в случае ухода в отпуск или на больничный. В команде, условно на 5 разработчиков, каждый занят чем-то своим, и часто другие вообще не понимают, что делается друг у друга. Если оставаться единственным носителем знаний своей области, в случае ухода все развалится. Поэтому полезно рассказывать другим, чем ты занимаешься, что узнал в процессе, какой опыт из этого извлек.
Структурировать знания у себя в голове. Часто в процессе подготовки к выступлению или докладу раскладываешь все по полочкам — и сам начинаешь лучше понимать тему, замечаешь пробелы в знаниях и ложную информацию. Да и просто привыкаешь подходить к любой новой информации более системно и структурированно.
Сразу приведу пример. Одно время я преподавал в университете два предмета: функциональное программирование и публичные выступления. И заметил, что те, кто ходили на публичные выступления, гораздо лучше проявляли себя в функциональном программировании — четче понимали предмет, хорошо структурировали информацию, лучше усваивали материал. То есть навык публичных выступлений сильно помогал им в более практичных вещах.
Подготовиться к релокейту. Я работаю с европейскими компаниями и заметил, что в Европе особое внимание уделяют софт-скилам. Если у нас при приеме на работу на 80–90% проверяют технические знания, то за рубежом кандидата на 50% оценивают по знаниям, и еще на 50% — по умению коммуницировать, доносить свою точку зрения, работать в коллективе. Если всего этого не уметь, то на релокейт можно не рассчитывать. В Европе считают, что человека с софт-скилами проще научить техническим вещам, чем технаря — умению общаться. И выступления перед коллегами как раз помогут наработать такие навыки.
Вакансии с релокейтом, в том числе за рубеж, можно найти в телеграм-боте getmatch. Заполните анкету — и бот сам пришлет вам подходящие предложения.
Быть в курсе происходящего. Когда делишься опытом сам — другие тоже начинают делиться в ответ. Это может стать началом хорошей практики встреч, обсуждений, сборов или даже создания целого профильного сообщества внутри компании. Особенно если пока такой практики в компании нет. Так вы сможете, в том числе, повысить свою квалификацию за счет опыта коллег.
Как научиться выступать и сделать так, чтобы тебя слушали с интересом
Многое придет с опытом, но есть несколько базовых вещей, которые серьезно помогут в подготовке публичных выступлений — как перед пятью коллегами, так и перед сотнями зрителей на конференции.
Общаться на уровне собеседника. Всегда нужно учитывать, насколько ваш слушатель технически подкован, что он понимает в вашей области, какие базовые знания у него есть.
Иногда в материалах о подготовке к выступлениям дают совет «Объяснять все как пятилетним детям». Но делать так не стоит — если вы общаетесь с технически подкованными людьми, вы вызовете только раздражение. Всегда говорите так, чтобы вас понимали, но не упрощайте до абсурда.
Не забывать о структуре. Умение структурировать информацию — в целом важный навык для разработчика, он регулярно нужен в профессиональной деятельности. Это структурирование важно переносить на публичные выступления — без структуры за вашими размышлениями будет трудно следить. Если мысль перескакивает с одной темы на другую, слушатели быстро потеряются, а значит, перестанут слушать.
Чтобы структурировать мысли до выступления, полезно накидать в блокнотик план: введение, тематические блоки с тем, о чем говорим и какую проблему решаем, выводы после блоков и всего доклада. Во время выступления за структурой поможет следить презентация.
Всегда держать в голове, зачем говорите и зачем вас слушают. Первое, что нужно сделать — понять, какую цель преследуете вы и какую пользу принесете остальным. Обычно это должно быть что-то конкретное, вроде «Я хочу, чтобы коллеги были осведомлены о моей работе. Коллеги же смогут применить те практики, которые я придумал, для себя, и сами будут работать быстрее».
Если речь не несет пользы вам — вы не сможете говорить убедительно. Если не несет пользы слушателям — вас просто не станут слушать. Не поможет даже самая крутая структура.
Помнить об эмоциональных аргументах. IT-инженеры привыкли общаться на языке четких логических фактов. Но это не всегда работает в публичном выступлении — людям нужна не просто стопка цифр, а слова о том, что работать станет легче, удобнее, интереснее. Это важно учитывать, когда составляете план выступления.
Чтобы немного разнообразить свою речь, можно добавить в нее элементы сторителлинга — немного драмы, юмора, интересных историй. Этому стоит учиться не у технарей, а у писателей и сценаристов. Отличным пособием может стать книга Роберта Макки «История на миллион долларов».
Подсматривать у других. Регулярно смотреть другие доклады и брать оттуда интересные приемы. Лучше не тратить время на изобретение колеса, а использовать опыт коллег.
Отслеживать ошибки. После выступлений проводить ретроспективу, спрашивать коллег, что было не так — где непонятно, где скучно, где слишком затянуто. На основе этого потом делать выводы.
Не замахиваться сразу высоко. Начать можно с небольшого доклада перед парой коллег. И если все пойдет хорошо, уже потом выступать перед целым отделом или даже пойти на конференцию.
Понять, что сразу не получится. Никто не может сделать идеальный доклад с первого раза. Я советую пообщаться с теми, кто уже выступал, особенно с минимальным опытом. Они расскажут вам таких историй, что вы стесняться и переживать точно перестанете. Я, например, свои первые доклады вообще бы сейчас на конференции не пропустил —, но их же пропускали. Да, они были плохими, но стали фундаментом для того, что я делаю сейчас.
И главное, помните — публичные выступления должны приносить удовольствие и пользу в первую очередь вам. Тогда все точно получится. Но если вас не тянет выступать перед людьми, можно развивать навыки коммуникации иначе. Те же чаты, личные созвоны и прочее — все это тоже ценно и развивает софт-скилы. Поэтому заставлять себя просто потому, что «все выступают — и я выступаю», точно не надо.
