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

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

Как обычно, истина где-то посередине. Меня зовут Дмитрий Петренко, я из Московского кредитного банка, и именно на примере МКБ я хочу немного рассказать про развитие айтишных софт-скиллов. Мы занимаем второе место в списке банков с частным капиталом, у нас более 5000 сотрудников, 700+ штатных IT-специалистов и множество IT-аутсорса. Так что компетенции в плане общения и совместного выполнения задач в нашем случае — штука важная.

Сразу на старте хочу показать один пример из общения между коллегами.

Если вы думаете, что я выдумал этот диалог только ради поста, то всё не совсем так.

Итак, смотрите, какая ситуация.

Один коллега в почте задает вполне конкретный развернутый вопрос с четким запросом, а второй отвечает набором из трех букв. Когда мы потом общались с сотрудником, который ответил “нет”, он искренне не понимал, что он сделал не так.

Оказалось, что он из всего написанного выбрал только первый вопрос, решил, что он самый важный, и нужно именно на него ответить. Ответил он на него достаточно быстро, а потом спросил у меня: “А что я сделал не так? Я же быстро ответил и помог вам решить проблему.”

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

Зачем развивать софт-скиллы?

Серьезно, зачем? Есть же команда отличных HR, которые и должны нормально оценивать людей, общаться с ними и вообще они котики.

Вот с чем сталкивался лично я.

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

Тема номер 2 – массовый подбор, такой аналог первой линии сопровождения или колл-центр технический, например, консультации по работе интернет-банка и подобное. Текучка тут большая, как и поток кандидатов, поэтому больше шанс, что проскочит кто-то с неподходящими для вас компетенциями.

Третья тема – уникальная экспертиза. Будете искать какого-нибудь девопса, заточенного исключительно под нужный вам стек, на рынке в России таких наберется всего штук 10. И тогда вы, скорее всего, зажмуритесь, выберете лучшего по технической части и самого подходящего из того, что есть, потом возьмете этот риск на себя, четко понимая, что будете развивать.

И последняя тема – кадровый резерв. Кадровый резерв, как известно, лучше готовить заранее. У вас может быть достаточно хороший спец в команде, вы осознаёте, что ему нужно будет дальше расти, и следующая позиция у него будет менеджерская или псевдо-менеджерская, Team Lead например. Допустим, с «обычными» переговорами у него все круто, а вот с конфликтными переговорами и с делегированием у него уже печаль и вам потребуется ощутимо вкладываться в развитие этих компетенций.

Группы софт-скиллов

Представьте себе портрет айтишника-супермена.

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

Эти 20 можно разделить на 4 группы для удобства:

1.    коммуникации,

2.    управление,

3.    самоуправление,

4.    мышление.

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

Конечно, третья. С мышлением обычно все хорошо, потому что, если бы было плохо еще и с мышлением, то тогда вообще не понятно, что у вас такой человек делает в команде? С самоуправлением тоже более или менее ОК. То есть программист, технарь, архитектор перед очередным релизом может собрать волю в кулак, самозамотивироваться, успеть к дедлайну, при этом он может более или менее распланировать выделенные ему 1000 человеко-часов, чтобы растянуть это не на два года, а сделать действительно в нужном объеме.

А вот с коммуникациями и с менеджментом обычно уже начинаются проблемы.

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

1.    рабочая переписка,

2.    аргументация,

3.    переговоры.

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

Сейчас же рабочая переписка у нас (да и не только у нас) – более 50% коммуникаций. И дозвониться не всегда получается, календари коллег заполнены встречами и зумами.

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

То есть такой человек во время разговора понимал: “Ага, вот тот товарищ вроде тоже неплохо рассказывает, делает это вполне аргументированно и с примерами, наверное, что-то он понимает”.

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

После этого можно переходить к управлению.

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

Как мы развиваем софт-скиллы

Тут никакого rocket science нет, инструкция и все шаги простые и понятные, есть нюансы по обратной связи.

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

То есть я сам себе выстрелил в ногу, и задачи мне стали спускаться уже в ультимативном порядке, то есть первая задачка пришла  — “просто сделать”, вторая от менеджера моего.

Я подошел и спросил: “А что происходит? Раньше мы тут все обсуждали”. Он мне говорит: “Ну да, обсуждали. Ты видел, как мы обсуждали? Хоть одно решение, которое не совпадало с твоей точкой зрения, ты нормально рассмотрел?”

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

Следующий шаг – тренинги. Здесь все понятно: тренинги обязательно должны быть практическими. То есть, если у вас занятие на два дня, то минимум 1 день (половина программы) должен быть посвящен практике. В противном случае, это будет равносильно чтению книги.

Вторая особенность по тренингам – смешанный коллектив. Незнакомый состав участников – тот самый выход из зоны комфорта. Это не обязательный критерий, но крайне желательный. На этом этапе ваш сотрудник поймет, что коллективы бывают разные. Он поймет, что, общаясь со знакомым, не нужно делать никаких “выпрыгиваний из штанов”, а вот когда у тебя появляется незнакомый коллектив, здесь нужно будет применять навыки, он поймет, когда это нужно будет сделать.

Тут есть небольшой лайфхак: когда будете отправлять сотрудника на тренинг, предупредите обязательно, что будет пункт номер 3 из этого алгоритма – практика. Нужно ему будет прямо сказать: “То, что ты узнаешь сейчас на тренинге, ты будешь применять на практике, и задачи, которые тебе будут ставиться впредь, без применения полученных знаний выполнить не получится”. Вовлеченность повышается в разы. Это мы тоже проверили и по обратной связи услышали: “Да, вот этот шаг помогал”.

И практика, самое важное, без нее не будут работать два предыдущих пункта.

Не бойтесь давать задачи, которые нельзя выполнить, не применяя soft skills. Пусть это сначала будет какая-то единичная и небольшая история, например, согласовать что-нибудь в переписке. Затем пусть сотрудник проведет совещание и запротоколирует, отправит протоколы встречи письмом на участников, поймет, будут ли вопросы. Потом сможет оценить, насколько понятное он написал письмо. Дайте ему как раз тех самых джунов, особенно, самых тяжелых. Это будет отличная тренировка.

Что не работает

Эти пункты, по сути, как устав, писаны кровью. Выявлены практикой.  

Первое – просто ждать. До сих пор многие совершают эту ошибку.

Они просто ожидают и сами себя успокаивают “Ну что я с этого программиста возьму? Зато он код крутой пишет. Со временем и общаться научится.”

Нет, ребята. Он не научится.

Сработает, может быть, в 1 из 20 случаев, но это скорее будет исключение из практики.

Перекидывание из команды в команду – тоже не работает. Мы себя хотим утешить так: “Ну зачем я буду сам им заниматься? У меня есть уже 4 подготовленных товарища, которые нормально общаются, я туда засуну пятого, и они его переопылят”. Нет, и более того, здесь мы несем большой риск, что товарищ, которого условно назовем слабокомпетентным, еще перезаражает остальных. Есть высокий риск, и мы столкнулись с этим один раз на практике.

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

Мы к ним подсадили товарища, у которого было совсем плохо с коммуникациями. И… сюрприз! Через три месяца получили пять таких товарищей, потому что они посмотрели “Ага, если я буду неадекватно отвечать на письма, если я не буду подпускать к себе никого и отвечать односложно и неразвернуто, меня просто перестанут спрашивать, у меня будет меньше работы.”

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

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

Более того, есть один пример, уже на текущем месте работы. Одному из подчиненных поставили задачу — прочитать конкретную книжку. Отчитывается, что прочитал, но видно, что совсем не применяет то, о чем в книге говорится. Общаюсь с ним, задаю вопросы по содержанию, видно, что действительно читал, говорит: “Ну да, там же рассказывалось, вот так, вот так и вот так”. Спрашиваю: “Ну а что не применяешь-то? Для чего все это затевалось?” Отвечает: “На практике ж у меня на работе все по-другому, у меня же нет таких кейсов, которые в книге напрямую были описаны.”

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

И четвертое, про это уже несколько раз говорил, теоретические тренинги. Они не работают, по сути, будет равносильно чтению книг. Просто поймите это, не нужно выкидывать деньги на ветер. Четко смотрите программу и при выборе тренингов обращайте внимание на содержание. У нас в банке развита система и внутренних, и внешних тренингов, на внутренних тренингах тренеры это понимают. И если тренинг, условно, даже четырехчасовой по какой-то отдельной узенькой теме, из них часа три будет практики. Сам проходил, смотрел и подтверждаю.

Выводы

Soft skills качать нужно. Вообще без вопросов.

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

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

В приоритете развитие коммуникаций в следующем порядке:

1.    переписка,

2.    аргументация,

3.    переговоры.

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