В 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-инженеры привыкли общаться на языке четких логических фактов. Но это не всегда работает в публичном выступлении — людям нужна не просто стопка цифр, а слова о том, что работать станет легче, удобнее, интереснее. Это важно учитывать, когда составляете план выступления.

Чтобы немного разнообразить свою речь, можно добавить в нее элементы сторителлинга — немного драмы, юмора, интересных историй. Этому стоит учиться не у технарей, а у писателей и сценаристов. Отличным пособием может стать книга Роберта Макки «История на миллион долларов».

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

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

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

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

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

Полезные ссылки

Комментарии (8)


  1. TsarS
    20.10.2022 13:45
    +1

    А не могли бы вы показать пример идеального публичного выступления инженера?


    1. nevoroman
      20.10.2022 15:59
      +3

      Привет!

      Идеальное — это сложно, не бывает таких. Скорее, бывают классные кандидаты в определенных номинациях.

      Я много всякого упоминал в статье про публичные выступления. Мой любимый пример развлекательно-технического доклада — «Синдром серебрянной пули» от Хади Харири. Хардкорище отличное неоднократно получалось у Алексея Шипилева: у него есть важная для хардкора черта, его приятно слушать даже тогда, когда непонятно. Из практичных мои фавориты это Scott Wlaschin и, например, «Быстрорастворимое проектирование» от marshinov.


  1. a40
    20.10.2022 14:03
    +1

    Отличная статья. Как человек, занимавшийся 7 лет развитием компетенций команды, подписываюсь под каждым тезисом.

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

    Автору в карму плюсик поставил.


    1. nevoroman
      20.10.2022 16:08

      Спасибо!

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

      Советы примерно такие:
      — Группировать отзывы. В массовых отзывах редко есть смысл исправлять что-то по отдельным отзывам, но вот три-четыре фидбека об одном и том же — это сигнал.
      — Много тех, для кого доклад «не в тему, не интересно, слишком легко»? Подумайте, на ту ли аудиторию вы вещаете. Обычно если претензии именно к теме, вы рассказываете доклад не тем людям.
      — Общайтесь с людьми. Текстовые фидбеки это прикольно, но хорошенько, со всех сторон обсудить доклад это намного полезнее. Особенно если это опытные ребята вроде ПК.
      — Не «рвите» доклад, пытаясь исправить весь фидбек. У любого доклада есть недостатки, и часто это обратная сторона его же преимуществ. У интригующего доклада похуже структура, в хардкорный трудно вникать, доклад с личным опытом легко превратится в набор советов. Хаотичные исправления могут разрушить цельность доклада, нужно аккуратно следить, как доклад меняется после правок.


    1. anna_ovzyak
      23.10.2022 00:25

      Тогда в статью стоит добавить ещё один пункт: Спикер должен уметь принимать критику и признавать ошибку, когда доклад превратился в гору цифр


  1. a40
    20.10.2022 16:16

    несколько отзывов формата «слишком много воды, непрактично» и «какой классный практичный материал!»

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

    А так-то конечно всегда найдётся какой-нибудь недовольный.


    1. nevoroman
      20.10.2022 16:20
      +2

      Да, согласен.

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

      Мораль тут только в формате «внимательно изучите условия вокруг доклада перед тем, как его хоронить/переделывать»


  1. anna_ovzyak
    23.10.2022 00:28

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