Когда я присоединился к своей первой компании, меня отправили на групповое обучение вместе с 300 другими новичками.

Причина? Мы были первокурсниками колледжа. Нам не хватало самого важного навыка в отрасли: общения.

Тренинг назывался обучение навыкам межличностного общения, но в основном это было деловое общение. Он начался со случайных приветствий, затем последовало, как начать светскую беседу на английском языке, и завершилось тем, как делать заметки. Полученные навыки пригодились — они помогли мне пройти через мою карьеру в сфере услуг. Работая с клиентами в качестве бизнес-аналитика, мне удалось решить большинство поставленных задач:

  • Понимание порученной работы
  • Задавать вопросы по электронной почте/в чате
  • Отвечать на заявки клиентов и обрабатывать эскалации

Однако когда я пришел в продуктовую компанию, все начало разваливаться. Мне пришлось работать с коллегами над дизайном продуктов. Трюки, которым я научился, больше не работали.

Мои товарищи по команде считали, что я либо слишком молчалив, либо слишком многословен. Я либо не понял контекста, либо не смог своевременно ответить на их вопросы. Это было более верно, когда дело дошло до вербального общения.

Проблема усугубилась, когда Agile истощил отрасль. В моей карьере наступил момент, когда я жил своей профессией только за счет совещаний, очень мало программировал и был очень разочарован этим. Мое разочарование начало проявляться на собраниях. А это, в свою очередь, усложняло все дело.

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

Вскоре после того, как моя демонстрация закончилась, технический интервьюер отказал мне в одной строчке:

Ваше решение было неплохим, но вы не смогли его кратко продемонстрировать.

Я был озадачен; все, что я сделал, это объяснил мотив каждой функции, которую я закодировал. Тем не менее, этого было недостаточно.

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

Значит, это была краткость.

Проблема со слишком большим количеством:

Программистам часто советуют создавать решения в как можно меньшем количестве строк.

Делая еще один шаг вперед, им также рекомендуется держать все операторы функций на одном уровне абстракции. Я объяснил уровень абстракции в одном из своих последних постов.

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

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

Только при наличии ограничений вы пытаетесь:

  • Избавьтесь от лишней информации
  • Сгруппировать и упорядочить необходимую информацию

Это верно как для общения, так и для программирования. Но вот разница:

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

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

Основные принципы программной коммуникации:

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

Вы не можете позволить себе быть похожим на меня, который объяснил бы каждую функцию подробно, и при этом гордиться краткостью (я не объяснил каждое утверждение!)

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

В следующих трех разделах я расскажу о самых важных предостережениях при общении во время любого технического обмена.

# 1: Составьте ментальную дорожную карту того, что вы будете рассказывать:

Эта дорожная карта должна включать объем функциональных возможностей.

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

На своей ментальной карте вы должны расположить эти элементы горизонтально.

Затем в вертикальном направлении вы должны начать излагать то, что происходит внутри системы, то есть бизнес-уровень, уровень данных, уровень API и так далее.

Вы также можете нарисовать стрелки для соединения систем.

Обязательно пометьте каждую сущность, т. е. пользователя, компоненты, базу данных, внешние системы и т. д.

Затем попробуйте сгруппировать их по абстрактным границам, которым они принадлежат. Например, если ваш компонент проверки подлинности и база данных пользователей принадлежат микрослужбе с именем «Пользователи», обведите их оба и поставьте заголовок: Микрослужба «Пользователи».

Как только у вас будет готова ментальная дорожная карта, нанесите ее на лист бумаги или цифровую доску.

#2: Начните с самого высокого уровня абстракции:

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

«Жило-было королевство…»

«Там были джунгли…»

«Давным-давно, в далекой-далекой галактике…»

То, что мы любили/ненавидели/обожали больше всего, имело очень мало общего с королевствами, джунглями или галактиками. Тем не менее, это были ограждения, с которых они все начинали.

Потому что вложения устанавливают контекст. Ваша аудитория должна определить местонахождение вещей, прежде чем они увидят, как они происходят. Технические презентации не являются исключением.

Вы можете начать свое повествование с круговых меток (микросервис пользователей), которые мы дали на последнем шаге, а затем постепенно переходить к описанию каждой составляющей.

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

В качестве следующего шага выберите сущность, имеющую 2-й высший уровень абстракции, и так далее.

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

№3: Разберитесь с мясом, обрисуйте результат и выйдите победителем:

Мясо состоит из цели вашей презентации.

Если это собеседование, возможно, это самая сложная задача, которую вы выполняли. Если задача состоит в том, чтобы определить наиболее оптимистичный путь между узлами, мясом будет цикл for, где вы помещаете результирующие узлы пути в массив результатов.

После того, как вы взялись за зверя, не забудьте продемонстрировать какой-то измеримый результат. Если бы это был алгоритм, самым распространенным было бы время выполнения.

Если это нечто иное, чем алгоритм, вам нужно придумать эквивалентный тест, которого вы стремитесь достичь с помощью своего дизайна/предлагаемого подхода/кода:

  • Этот дизайн направлен на сокращение задержки API до x миллисекунд.
  • Этот UX пропустит 2 шага (шаг B и C) в потоке адаптации пользователя, чтобы перейти от шага A к шагу D напрямую. Поскольку мы заметили, что 25% пользователей уходят после шага C, мы ожидаем, что после улучшения UX-потока у нас будет как минимум 25%-й прирост.
  • Это изменение уменьшит циклическую избыточность между компонентами A и B и сократит время компиляции на X%.

Включение измеримого результата, который вскоре преодолеет сложность, не только создаст эффект (эффективность вашего решения). Это также делает всю вашу презентацию запоминающейся на долгое время.

Заключение:

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

Если они когда-либо задумываются о том, чтобы подняться по управленческой лестнице, они регистрируются в PMP или Agile, расширяют свой словарный запас и начинают чувствовать себя прекрасно после своих презентаций за одну ночь.

Без знания ключевых аспектов общения и рассказывания историй любое дополнительное обучение не достигает своей цели. Хуже того, это раздувает представление о самом себе и представляет человека как придурка, только болтливого.

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