Почему IT-специалисты боятся выступлений — и как сделать так, чтобы их слушали

Есть одна фраза, которую я слышал десятки раз от разработчиков, аналитиков, архитекторов: «Я же не спикер. Зачем мне вообще выступать?»

На деле — нужно.Чтобы объяснить идею команде. Защитить решение перед заказчиком. Презентовать продукт инвестору. IT-специалисту не обязательно быть Стивом Джобсом. Но его должны понимать, слышать и доверять.

Есть задача провести обучение и интересует цена?

Расскажите, кого и чему планируете обучить, и мы рассчитаем для вас стоимость и предложим варианты. Это ни к чему вас не обяжет, ничего продавать вам не станем.

Узнать цену!

Когда разработчик открывает рот…

И начинается: «мы пробросили ingress, чтобы не потерять stateful», «тут у нас пайплайн с rollback и мониторингом по графану». И ты стоишь, киваешь, улыбаешься, а внутри — только один вопрос: а можно как-то по-людски?

Знакомо? Это не претензия. Это факт: айтишники — сильны в решениях, но слабы в объяснении. И именно это мешает проектам, коммуникации, принятию решений и росту специалистов.

Почему так происходит?

Я много лет работаю с IT-командами — от джунов до тимлидов и архитекторов. Провожу тренинги по презентациям и коммуникации. И вижу четыре главные причины, почему у айтишников проблемы, когда дело доходит до объяснений.

1. Свой язык. Слишком свой.

Разработчики говорят на языке кода. И это нормально — пока они говорят между собой. Но вот беда: на совещании сидят продуктологи, аналитики, заказчики, HR. И они не говорят на этом языке.

Фраза «мы прокинули туннель, чтобы не терять сессию при ресете» звучит примерно как «мы подлатали гиперфазный резонатор, чтобы квант не рассыпался». Понимаете? Вот и заказчик тоже не понял.

Но проблема не в терминах. А в том, что разработчик даже не догадывается, что его не понимают. Он просто продолжает говорить. Думая, что «ну это ж очевидно».

2. Много деталей. Мало смысла.

У айтишников есть сильная внутренняя потребность — объяснить, как именно они пришли к решению. С багами, фиксом, обходом, версией системы, тремя вариантами, которые не сработали, и ссылкой на StackOverflow.

В итоге слушатель тонет в потоке. Суть теряется. В голове не остается ничего, кроме «сложно, долго, не мое».

В этом смысле хороший разработчик часто превращается в плохого рассказчика.

3. «Я лучше напишу, чем скажу».

Классика жанра. Уверенный за клавиатурой, но зажатый на сцене. Вроде бы всё знает. Но голос дрожит, руки потеют, слайды прячут глаза.

Почему? Страх ошибиться. Страх, что кто-то задаст вопрос, на который он не знает ответа. Или поднимет руку и скажет: «это не работает в проде». Или просто засмеется.

И тогда — проще не лезть. Молча написать регламент. Или спрятаться за спикера. Хотя именно этот человек — автор ключевого решения. Он должен быть на сцене. Его хочется слушать — но пока он боится.

4. Слайды не для людей.

Есть презентации, которые хочется распечатать и… выкинуть. На слайде — код. Под кодом — логи. Слева — скриншот. А где вывод, логика, польза — неясно.

И это не потому, что разработчик глуп. А потому, что слайд он делает для себя. Чтобы не потеряться. Чтобы «всё было перед глазами». А не для слушателя.

Что с этим делать? Не критиковать — обучать.

1. Простыми словами — не значит глупыми.

Объяснить архитектуру микросервисов за 3 минуты — это не упрощение. Это мастерство. Настоящий эксперт умеет объяснить. Настоящий архитектор строит мост — не только между системами, но и между умами.

Как? Через метафоры. Примеры. Параллели из жизни. Не «у нас сложная шина», а «мы сделали, как на вокзале — один поезд, но разная логистика». И всё — стало понятно.

2. Структура. Всегда.

Без структуры слушатель теряется. А правильная подача — это 4 простых шага:

• Зачем мы это сделали
• Что именно сделали
• К чему это привело
• Что делать дальше

Сухо? Зато понятно. И если приправить это примерами, метафорами и живой речью — будет ещё и интересно.

3. Уверенность — через практику.

Страх сцены — это не диагноз. Это навык, который прокачивается. Нужно:

• выступать перед своей командой, а не сразу на митапе на 300 человек
• получать обратную связь: не только «что не так», но и «что получилось»
• разрешить себе не знать. Да, даже в IT

И через 2–3 выступления появляются шутки, контакт, взгляд в глаза. Не магия. Повторяемость.

4. Слайд — это якорь. Не шпаргалка.

Слайд — не копия кода. Это визуальная опора. Один тезис. Одна мысль. Один образ.

Хороший слайд не заменяет докладчика. Он помогает слушателю. Он подсвечивает суть. И делает выступление легче. Именно поэтому на тренингах мы учим: меньше — лучше. Точка опоры — вместо экрана смерти.

А что в итоге?

Я проводил корпоративный тренинг для IT-команды. На старте: боязнь сцены, отказ от выступлений, «это не моё». Через 2 дня: короткие, структурные презентации. Простые объяснения. Вопросы из зала. И главное — слушатели стали понимать, о чём говорят разработчики.

И это бесценно. Потому что разработчик — это не просто «тот, кто пишет код». Это человек, который создаёт решения. И если он может не только сделать, но и объяснить — он становится экспертом, спикером, лидером.

В результате:

IT-команды — сильны в деле. Но если вы хотите, чтобы их ещё и слушали — научите их говорить. И делать это по-человечески.

Ваша команда станет не только эффективнее, но и видимее. И вы удивитесь, как много у неё есть сказать — если дать правильную поддержку.

Если вы хотите, чтобы ваши специалисты не просто писали регламенты, а презентовали идеи, убеждали и вдохновляли — напишите. Покажу, как это работает. Без занудства. Без стыда. Только живая речь и рабочие инструменты.