Код

#статьи

22 авг 2023
0

«Главный скилл — это уважение»: Евгений Антонов о самых важных soft skills в IT

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

Кадр: сериал «Теория Большого взрыва» / Warner Bros. Television

Максим Сафронов

Шеф-редактор Skillbox Media «Код». Пишет о разработке, софт-скиллах и культовых личностях в IT. Обожает Swift, продукты Apple и мемы про код.

Евгений Антонов

Старший технический менеджер проектов Yandex Infrastructure, IT-консультант. Более 15 лет в IT‑индустрии. Ведущий подкаста «Кода кода» и автор телеграм-канала «Тимлид Очевидность».

Часто говорят: для успешной карьеры в IT важны не технические знания, а так называемые софт-скиллы — то есть навыки самоорганизации, делового общения и работы в команде. Существует даже мнение, что «софты» освоить сложнее, чем языки, базы данных и фреймворки.

Чтобы выяснить, так это или нет, мы обратились к Евгению Антонову — старшему техническому менеджеру проектов Yandex Infrastructure и опытному IT-консультанту. Поговорили о силе и важности мягких навыков, о том, как их проверяют работодатели, а заодно собрали стартер-пак главных софт-скиллов для разработчика.

Евгений рассказал:

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

Что такое soft skills

Soft skills — это ёмкое и комплексное название группы навыков, связанных с людьми: конкретной личностью, взаимодействием между двумя личностями и работой с группой личностей. В IT софты противопоставляются хард-скиллам — то есть владению языками, технологиями и инструментами.

Личность

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

Рефлексия — способность разобраться в своих потребностях. Иначе говоря, умение задать себе вопросы: «А точно ли оно мне нужно? И если да, то почему?» Эдакое личное целеполагание.

Гибкость — умение адаптироваться под постоянно изменяющуюся реальность. Способность и желание учиться новому. Для IT это было важно всегда, ведь новые технологии, инструменты и релизы появляются постоянно — важно успевать подстраиваться.

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

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

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

Взаимодействие двух личностей

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

Работа с мотивацией — умение понимать, что драйвит людей, а что, наоборот, демотивирует их, злит, делает грустными и неработоспособными.

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

А во-вторых, это умение токсичность погасить.

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

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

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

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

Работа с группами

Следующий набор навыков — для старших разработчиков, тимлидов и управленцев в IT. Джунам почитать о них тоже будет полезно.

Управление конфликтами — умение анализировать интересы и эмоции сторон конфликта, способность находить компромиссы. Умение не раздувать и гасить уже раздутые конфликты. Например, иногда полезно «рассадить» людей по разным задачам, чтобы они успокоились и привыкли друг к другу, а потом снова сошлись на общем кусочке проекта и жили дружно.

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

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

Фасилитация собраний — навыки организации и проведения встреч. Сейчас в IT все «провисают» на бесконечных созвонах. Чтобы не расходовать впустую недешёвое рабочее время программистов, важно уметь правильно готовить и продуктивно проводить собрания, да ещё и делать постобработку их результатов.

Если хотите лучше разбираться в фасилитации, советую подписаться на телеграм-канал «Нестыдная фасилитация» и периодически его почитывать — там много разных методик, которые помогают грамотно проводить встречи. Ещё можете посмотреть мой доклад о фасилитации на форуме TechTalks во Владимире.

Meta skill: уважение

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

Например:

✅ Если ты тимлид, ты уделяешь время подготовке к собраниям: продумываешь и рассылаешь команде агенду — примерный план встречи и список обсуждаемых задач. Люди понимают, чего от них хотят, и приходят подготовленными. В результате на собрании меньше времени людей тратится впустую. Ты уважаешь и их время, и своё.

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

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

Обратные примеры:

❌ На всё соглашаются. Люди, которые всегда готовы брать новые задачи, даже если у них и так много работы. И если совсем зелёному джуну это можно простить, то для тимлидов и менеджеров это плохо: из желания казаться хорошими ребятами и девчатами они набирают кучу проектов, и вся команда потом работает по вечерам и выходным, устаёт и выгорает.

❌ Боятся увольнять. Бывает так, что человеку плохо в компании, и он начинает всячески саботировать работу: лениться, срывать сроки, токсичить, ругаться с коллегами. В таких случаях тимлид не должен бояться расставаться с сотрудником, иначе будут страдать и проект, и команда.

Почему мягкие навыки важны для IT

Строго говоря, софт-скиллы востребованы не только в IT, но и в любой сфере, где люди создают что-то в команде: от судостроения до контент-маркетинга.

Вы наверняка встречали людей, про которых можно сказать: «классный, душевный, чуткий». Всё у них по полочкам, всё по справедливости, всё по уму. Работать с такими людьми — одно удовольствие, поэтому они и ценятся везде.

Однако в IT софт-скиллы имеют особое значение, так как ручной труд почти полностью исключён и большинство того, что производится, — это продукты труда интеллектуального. Тут не работает простой принцип «копать от забора до обеда». Чтобы создать качественный продукт, важно уметь хорошо, комфортно и эффективно работать с людьми.

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

Джунам развивать мягкие навыки тоже необходимо, чтобы и работа была продуктивной, и движение по карьерной лестнице шло быстрее. Правда, стоит сделать оговорку насчёт карьерного роста — очень многое зависит от компании. Где‑то только харды могут унести вас высоко вверх, а где-то невозможно будет продвинуться без софт-скиллов, договороспособности, умения найти общий язык со многими коллегами.

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

Как компании оценивают софт-скиллы на собеседовании

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

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

Разговор об опыте. Стандартные вопросы о рабочих ситуациях, с которыми сталкивался кандидат. Например: случались ли у вас фейлы или конфликты с руководителем? А с коллегами? Как вы с ними справлялись? Что из этого вынесли? Как договаривались со смежниками и заказчиками? И всё в таком духе.

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

Допустим, вы управляете коллективом разработчиков. Один программист в вашей команде постоянно заворачивает другого на код-ревью и не даёт коммитить — то есть загружать готовый код в проект. Что будете делать?

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

Психологические тесты. Некоторые эйчары используют тесты-опросники для определения психотипа и оценки личности кандидата. Одна из часто упоминающихся классификаций — DISC. Некоторые курсы и книги для управленцев её активно продвигают.

Возможно, в опросниках и есть смысл, но я слабо в это верю.

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

О подготовке к публичным выступлениям

Умение выступать на публике — важный софт-скилл для программиста, и вот почему.

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

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

Если вы нацелены именно на выступления на конференциях, то главный совет, который я могу дать, — просто начните. Я понимаю, что это «просто» для многих будет весьма непросто. Тем не менее: чем раньше вы начнёте это практиковать, тем лучше.

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

Меня уговорил один известный в IT деятель, Виталий Шароватов. Он сказал: «У тебя нормальные темы, иди выступи». Я отвечаю: «Да я стесняюсь и боюсь, это же самая большая конференция для тимлидов». А Виталий настаивал: «Подайся, подайся». Думаю: «Я подамся, лишь бы ты перестал настаивать :)». И я подался. И мне написали: «Вы приняты».

Перед конференцией я репетировал свой доклад около 20 раз. К счастью, у меня есть замечательная жена, на которой можно «тестировать» все выступления. Это помогает примерно представить работу с аудиторией и скорректировать объём доклада. Фишка в том, что, когда рассказываешь кому-то, скорость речи повышается — и то, что ты сам с собой растянул на 45 минут, можно вполне стройно изложить за 35.

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

Чтобы успокоиться перед самим выступлением, многим помогает дыхательная гимнастика. Дыхание животом насытит кровь кислородом и поможет расслабиться.

Я много общался с разными спикерами, и они говорят, что первые пять минут — самые нервные: колотится сердце, ускоряется речь, может сбиться дыхание. После того как перешагнёшь этот рубеж, становится спокойнее: входишь в режим рассказчика и общаешься с аудиторией, как с собеседником.

Если чувствуете сильное волнение, можно прямо сказать об этом аудитории — как Ларри Кинг во время своего первого радиоэфира. Но с этим не стоит перебарщивать. Помню, на одной из конференций спикер 15 минут не мог начать говорить. Он просто твердил: «Я волнуюсь, у меня паническая атака, я не могу начать». Все ему хлопали, пытались успокоить, но было тяжело.

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

И напоследок: существует теория о том, что, чтобы зрители запомнили какую-то мысль, нужно повторить её минимум три раза. Поэтому я стараюсь в начале доклада обозначить основные мысли, по ходу доклада их разъяснять, а в конце подвести итоги, это всё суммировав и повторив.

Где учиться софт-скиллам: книги, курсы и лекции

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

О том, как эффективно совмещать теорию с практикой, есть замечательный курс на Coursera — он называется Learning How to Learn («Научитесь учиться»). Ещё рекомендую видео Максима Дорофеева про три столпа обучения. Можно посмотреть и мой доклад о том, как читать книги с пользой для ума и дела.

Книги об эффективной коммуникации

Александр Орлов, «Джедайские техники конструктивного общения». Как понимать людей и доносить до них свою точку зрения. Коротко, по делу, с примерами, очень толково ?
Максим Ильяхов, «Новые правила деловой переписки». Как в переписке быть уважительным, приятным и эффективным. Смело рекомендовал бы её и разработчикам, и менеджерам, и вообще всем.
Марк Гоулстон, «Как разговаривать с мудаками». О том, что не все проблемные отношения и коммуникацию можно разрешить с помощью рациональных доводов, и о том, что делать в таких случаях.

Книги о личной эффективности

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

Книги об управлении

Никколо Макиавелли, «Государь». Порекомендовал бы менеджерам в компаниях, где много подковёрной борьбы, но вы почему-то хотите там остаться и даже расти. Труд незаурядного политика поможет вам во внутрикорпоративной возне. Читать и применять следует осознанно, не бездумно.
Том ДеМарко, «Deadline. Роман об управлении проектами». Лёгкое и интересное чтиво в художественном формате об управлении IT-проектами.
Том ДеМарко, Тимоти Листер, «Вальсируя с медведями». О том, как предсказывать риски и управлять ими. Порекомендовал бы менеджерам средних и крупных проектов.
Дж. Ханк Рейнвотер, «Как пасти котов». О руководстве IT-проектами для начинающих или будущих управленцев. Людям с опытом, наверное, покажется немного тривиальной.
Фредерик Брукс, «Мифический человеко-месяц». Обязательно к прочтению управленцам (руководителям, менеджерам) и околоуправленцам (ведущим, тимлидам). Расскажет о техниках управления проектами, а ещё о том, почему девять женщин за один месяц не смогут родить ребёнка.

Этот список — краткая версия моего треда о книгах в Twitter. Загляните, если хотите запастись полезной литературой о разработке и софт-скиллах в IT.

Курсы и конференции

Конференция TeamLead Conf. Если не можете посетить сами, посмотрите записи докладов — обычно их выкладывают с задержкой в полгода. Очень много материалов по менеджменту, продуктивности и софт-скиллам.
Курсы переговоров от Ильи Синельникова. Стоят довольно дорого, поэтому для начала послушайте его выступление в «Подлодке», чтобы решить, нужно ли это вам.
PSYvIT — курсы по софт-скиллам и психологической грамотности для тех, кто работает в IT.
Конференции Podlodka Teamlead Crew и Podlodka Soft Skills Crew. Записи можно посмотреть здесь.
Курсы школы Stratoplan по управлению командами и проектами.

Подкасты

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