Довольно очевидно, что junior-разработчику и тимлиду требуется сильно различающийся набор навыков. И если в случае hard skills всё уже миллион раз проанализировано и посчитано, то о необходимом наборе soft skills в зависимости от должности мы можем только понимать на уровне ощущений и здравого смысла.

Более того, в нашей индустрии не принято говорить после собеседования, что кандидату отказано из-за его уровня soft skills, хотя мы даже не пытаемся конкретизировать, что конкретно в нём нас не устраивает. Вы наверняка слышали или сами употребляли фразы вроде «просто человек странный», «почему-то не нравится» или «чувствуем, что он не вольется в команду». Но почему? Что на самом деле с ним не так?

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

Исследование soft skills

Начнем с того, какие soft skills на каком уровне нужны. Еще до начала карантина при поддержке кадровой компании New.HR я запустил свой очередной опрос по soft skills. В нём я предложил собственную классификацию из 40 гибких навыков и задал вопрос: «Начиная с какого уровня данный soft skill становится критически важным?» Для каждого софт скилла нужно было выбрать, кому он нужен — от junior, middle и senior-разработчика до тимлида и руководителя. Или не требуется никому.

Благодаря распространению опроса в тимлидских чатах мне удалось собрать 467 ответов, при этом ответили всего 4% junior-разработчиков, а в основном это были senior и выше (72%). В результате сложилась картина, чего программисты ожидают на уровнях ниже, чем они сами находятся. Для простоты я решил интерпретировать полученные голоса с помощью формул, где для каждого навыка «нормализовал» между собой отданные голоса за разные уровни:

  1. junior_importance = junior - middle - senior - teamlead - no_need;

  2. middle_importance = junior - middle - senior - teamlead - no_need;

  3. senior_importance =  junior - middle - senior - teamlead - no_need;

  4. teamlead_importance =  junior - middle - senior - teamlead - no_need.

где:

  • junior — количество голосов, что данный навык нужен начиная с уровня junior;

  • middle — количество голосов, что данный навык нужен начиная с уровня middle;

  • senior — количество голосов, что данный навык нужен начиная с уровня senior;

  • teamlead — количество голосов, что данный навык нужен начиная с тимлида;

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

Каждая формула применяется для голосов за каждый из гибких навыков и представляет собой отдельный график.

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

Например, если мы считаем важность для middle, то всё, что левее — middle и junior — берем в формуле со знаком плюс, а все, что правее — со знаком минус. 

Junior-разработчик

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

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

Первый перепад после третьего навыка дал бы нам слишком мало требуемых навыков, поэтому берем следующий, более резкий перепад (132 - 39 = 93 пункта). Он отсекает 8 софт скиллов, которые мы и будем считать важнейшими  для junior-разработчика:

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

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

Middle-разработчик

Теперь составим аналогичный график для уровня middle по соответствующей формуле. Те 8 гибких навыков, что мы причислили к junior-уровню, здесь не рассматриваем. 

С получившимся графиком ниже проводим аналогичные действия: ищем первый резкий перепад справа налево (121 - 30 = 91 пункт) и считаем важными для middle-разработчика те 15 навыков, которые находятся справа от перепада.

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

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

Senior-разработчик

Аналогичным образом строим график для senior-уровня для оставшихся 18 навыков.

Здесь резкий перепад фиксирует те 8 навыков, которые будем считать критически важными для senior-разработчика.

Навыки личной эффективности наконец уходят на второй план, уступая навыкам коммуникации и лидерства.

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

TeamLead

Наконец, рассмотрим последний график для тимлида для оставшихся 10 навыков. 

Изначально я не планировал здесь искать резкие перепады, так как не было цели дополнительно отсекать какую-то группу навыков. Но перепад получился настолько явным (186 - 45 = 141 пункт), что я решил для начала выделить группу из 8 навыков справа от линии перепада как ключевые для тимлида:

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

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

Руководитель

Оставшиеся 2 навыка будем считать важными для руководителей выше уровня тимлида — для руководителей отделов, технических директоров и т.д.

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

«Не понимаю, что за навык»

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

Результат меня удивил. Конечно, какие-то результаты можно было списать на погрешность того, что частично опрос проходили джуны и мидлы. Они действительно могли никогда не слышать о ситуационном руководстве (3 место). Но в лидерах оказались рефлексия и эмоциональный интеллект, хотя  мне казалось, что в период бума популярности психологов в IT эти понятия давно у всех на слуху.

Как проверить Soft Skills на собеседовании

Теперь у нас есть полноценная картина: какие навыки на каком уровне важны. Но как выявить, что они есть у человека напротив вас?

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

Например, у меня была история, когда я стандартно собеседовал человека по Python примерно 50 минут, оставив в конце 10-15 минут на вопросы. Но когда мы перешли к секции вопросов кандидата, он достал листочек с 22 вопросами. Мне импонировал этот кандидат, к тому же в тот день это была последняя встреча у меня в календаре, и я уже никуда не спешил. В итоге мы с ним еще час просидели, пока я отвечал на очень разные вопросы. Начиная с того, какое у меня хобби, и заканчивая тем, как я вижу роль devops в компании.

Эта история закончилась позитивно, потому что этот человек, во-первых, принял оффер и вышел ко мне на работу, а во-вторых, спустя неделю я от HR узнал, что он написал статью на Хабре по итогам того, как он в десятки компаний ходил на собеседования и везде задавал те самые 22 вопроса. Узнав об этом, я не смог не спросить у него, почему он в итоге выбрал нашу компанию, и получил честный ответ: «Ты не соврал мне нигде, спокойно отвечал про минусы и плюсы компании, не пытался сбежать и ни разу меня не послал». Так что старайтесь быть более гибкими, всё-таки в нашей сфере работают люди с людьми, несмотря на все автоматизации и процессы.

Проверяем джуна

Вернемся к нашим навыкам, начнем с уровня junior. Как их проверить?

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

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

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

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

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

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

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

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

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

Очень интересная ситуация с навыком восприятие критики. Для меня более ценен тот, кто сначала решил задачу неправильно, но когда вы ему сказали об этом и предложили попробовать ещё раз, быстро всё переделал. Часто встречаются кандидаты, которые расстраиваются, уходят в отрицание и говорят: «Не знаю, давайте дальше пойдем, я устал, у меня еще 14 собеседований сегодня». Плюсом к этому, вы еще можете увидеть, насколько человек умеет думать.

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

Итак, мы проверили почти все скиллы:

Осталось последнее — командная работа. Очевидно, что с нашими таймингами проверить этот навык на собеседовании почти невозможно — человек приходит и уходит один. Коллеги из других сфер подсказали мне, что есть командные кейсы, когда приходит сразу 5 человек на собеседование и им дается задача, которую нужно решить за 30-90 минут совместно и испытать решение на другой команде. Звучит отлично, но на это банально нет времени. Этот навык проще проверить на испытательном сроке.

Теперь перейдем к middle-скиллам.

Проверяем мидла

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

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

Управление собственным развитием. Как и что развивали на прошлом месте работы? Помогло ли это как-то? Куда это привело?

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

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

Мы закрыли еще несколько пунктов, теперь перейдем к тем навыкам, которые мы проверяем не напрямую, а косвенно:

Управление стрессом. Надеюсь, что в 2021 году уже никто не проводит стресс-интервью. Но можно собрать фидбэк от людей, как они увидели восприятие человеком стресса (сначала HR, потом технические специалисты, дальше вы сами), всё сопоставить и у вас сложится какая-то картина.

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

Письменное общение, обратная связь. После того как человек прошел все этапы интервью, я иногда пишу ему лично в любом мессенджере. И спрашиваю, как ему вообще — понравилось, не понравилось, что он вынес или нет. Даже по переписке в Telegram можно понять, как человек умеет донести свою мысль. Очевидно, это не про «Заранее спасибо» и «Добрый день, коллеги». К тому же заодно можно проверить навык предоставления обратной связи, спросив про то, что кандидат думает про рекрутера и коллег, которые проводили собеседования до вас.

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

Осталось несколько навыков, которые так легко не проверить за ограниченное время. 

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

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

Как развивать soft skills внутри компании

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

Как я говорил, все навыки разбиты на 4 группы: личная эффективность, мышление, коммуникации и лидерские навыки. Затем я разбил их еще по столбцам, которые назвал стримами или ролями. В результате у меня получилась схема развития навыков. По вертикали уровни от junior до chief, по горизонтали — роли. Мы идём слева снизу и направо наверх. Роли расположены в том порядке, в котором их логичнее осваивать. Все навыки одного столбца, очевидно, влияют один на другой снизу вверх, а связи между навыками в разных столбцах я обозначил дополнительными стрелками. 

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

Эта схема оказывается очень наглядной и позволяет довольно просто показать сотруднику, какие навыки требуется развить для его роста на следующий уровень. Многие используют матрицы компетенций и PDP (Personal Development Plan). Все они также прекрасно вписываются в эту схему.

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

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

Выводы

  • Благодаря опросу, мы теперь четко понимаем, чего ждать на разных уровнях развития разработчика — от junior-уровня до руководителя.

  • На низких уровнях (junior и middle) понятно, как проверить наличие навыков на собеседованиях.

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

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

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

16 и 17 сентября в Санкт-Петербурге пройдёт конференция Saint TeamLead Conf 2021. Расписание и билеты.

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


  1. hellamps
    22.08.2021 18:02
    +20

    Хорошая статья.

    Наверное, в идеальной компании(для разработчика!) оно так и должно все быть.

    Но из практики:

    Восприятие критики === Делай как я сказал и не спорь

    Умение слушать === И не задавай по второму кругу эти вопросы, делай как я сказал!

    Логическое мышление === Думай и понимай что интересно шефу, а не тебе

    Открытость новому === Нам нужно подпатчить тут код на 10летней джаве и 15 летнем mysql, это будет хорошим опытом!

    Адаптируемость === А завтра перейдешь на проект с php 5.12

    Поиск и анализ информации === Да, деталей в тикете нет, но ты почитай там эпик и остальные таски...

    Командная работа === Понимаешь, нельзя писать такое в код ревью, люди обижаются

    Управление эмоциями === ты же профессионал, и не такое видал!

    ========= тут начинается миддл, хотя мне кажется, что мы уже и курс сеньора прошли и переходим в менеджмент =======

    Самостоятельность === мог бы помочь ребятам и проактивно посмотреть, не заканчивается ли место в базе в продакшене

    Нацеленность на результат === Нашему продукту очень надо репортовать что мы доставили фичу на прод, пофиг как

    Ответственность за результат === Ну а если не доставим - то только из-за твоих глупых вопросов

    Инициацивность === А как ты сам думаешь, что мы от тебя хотим в следующий квартал?

    Управление собственным развитием === Хаскель это, конечно, хорошо... Но может со всем коллективом выучите Paradox? Надо учится на исторических примерах

    Критическое мышление === Надо было головой думать, понятно, что ты ни разу не видел 1С, но завтра же аванс!

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

    Рефлексия === Ну ладно плакать. Ну да, нам еще два драйвера надо в 2.х версию ядра портировать, но ты будешь уникальным специалистом после этого!

    Системное мышление === Знаешь ли ты, почему соты у пчел шестиугольные?

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

    Управление стрессом === коньяк вон там на полке

    Креативность === надо бы записать ролик про нашу компанию, придумаешь что до завтра?

    Письменное общение === Я тебе в чате три раза написал, а ты не отвечаешь, как можно работать и не смотреть в чат???

    Обратная связь === Отзывы на нашу передачу пишем мы сами, поэтому не волнуйтесь, ваше мнение нам известно.

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

    ======= (переходим в высший менеджмент) сеньор-помидор ========

    Наставничество === помнишь всё то, чему мы тебя учили? Пора научить и других!

    Выработка и принятие решений === всегда помни: IS THIS GOOD FOR THE COMPANY?

    Многозадачность === у тебя в спринте в два раза больше чем у Васи, ты же теперь сеньор. Автоматизируй!

    Клиентоориентированность === Всегда говори, что делаешь это ради удобства клиента, а не компании

    Планирование === А в отпуск пойдешь в марте, у нас там вроде никаких дедлайнов

    Проектное мышление === Проект заберем - а там уже по месту будем думать как и что, будет день - будет пища!

    Эмоциональный интеллект === И вот такие комменты на хабре не пиши! Какие такие? Вот этот вот!

    Постановка задач сотрудникам === Ты видел, что Петя уходит ровно в пять? Ему что, делать нечего на работе?

    Ваш токсичный сотрудник Алексей

    ps. Девелоперам: помните, что в долгосрочной перспективе компания которая успешно кормит ваши мозги экономит больше и производит больше чем та, которая кормит ваш кошелек.

    pps. Критикуя предлагай - считаю, что есть только один объективный критерий - если человек make things done - его надо брать. Если у него всё "тянется" - не надо брать. Все остальные критерии вторичны и не могут гарантировать при их наличии, что всё сложится хорошо. Иначе говоря - предложите на собеседовании написать мини-проект по вашей теме. А задачи про кольцо оставьте любителям головоломок. Это ничем не лучше найма людей, скажем, по размеру ноги, а просто покажет вам любителей решать головоломки(я из таких).


    1. hellamps
      22.08.2021 18:08

      ppps: никогда не задумывался, что фиксированная разница в радиусах дает фиксированную разницу в длине окружности...


    1. js605451
      23.08.2021 00:32
      +2

      Это вы написали не про софт скилз, а "как тяжело быть джуниором". Это джуниоров кидают с проекта на проект, с задачи на задачу - без возможности проникнуться проблемой, порефлексировать, спланировать работу на пару недель вперёд.

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

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


      1. hellamps
        23.08.2021 17:13
        +1

        Это, конечно, была ирония, переходящая в сарказм. Но в каждой шутке есть доля шутки. Я в один из перфоманс ревью поставил себе типа below expectations, потому что знал, что можно и лучше.

        Начальник переправил на above expectations, сказав что такого рода рефлексия привлекает негативное внимание к команде, вплоть до желания поставить такого сотрудника на Personal Improvement Plan.

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

        Есть люди, которые любят это. А есть те, кто любят технику именно за ее "бездушность и правильность". А есть такие, кто просто работу работает(и это не значит, что он ее плохо работает, просто увлечения у него совсем другие). А мы им этот маркетинг и здравый смысл впариваем.


        1. js605451
          23.08.2021 19:50

          А теперь вы пишете про перформанс ревью в большой компании и снова не про софт скиллз. Я понимаю о чём вы, только это не про софт скиллз всё, а про неадекватные попытки их измерять.

          ИМХО, софт скиллз - это как качество кода: у всех есть какие-то соображения насчёт хорошего и плохого кода, но вот взять кодовую базу и сказать, что качество у неё 4.92 из 10 - это всегда глупость.


          1. hellamps
            23.08.2021 20:00

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

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


            1. js605451
              23.08.2021 20:07

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


    1. dimskiy
      23.08.2021 09:02

      Статью надо просто заменить на ваш камент - самая суть и никакого доширака на ушах и «развивашек» :)


    1. alexeyinn
      23.08.2021 10:58

      ;(
      Ты чуво наделал? У меня вьетнамские флешбеки от моей первой работы в it... именно так все и было;(


    1. SanDark7 Автор
      23.08.2021 22:29

      Огонь, у тебя вся боль от плохого тимлида и руководства написана очень ёмко, если ты не против, я бы утащил это для примера в будущие доклады про soft skills.

      По поводу "make things done" соглашусь, это хороший критерий, когда нет времени на проработку всего остального. Но если есть время на декомпозицию человека относительно всех гибких навыков, то стоит попробовать, результат окажется лучше и более предсказуемый. Так же, как с большими задачами, можно просто сесть за неё, а можно разбить на подзадачи.


      1. hellamps
        25.08.2021 18:20

        Утащить можно, отчего не утащить.

        Я бы не назвал это всё плохим тимлидством или руководством. Скорее "как у всех".

        Насчет декомпозиций - это все хорошо, но где брать столько людей, чтобы еще их софтскиллы перебирать? Может в FAANG столько и идет хороших кандидатов, но в компании "второго" мира как то "так".


  1. akuleshov7
    23.08.2021 00:01
    +2

    Отличная статья. В помощь всем, кто собеседует людей и оценивает их софт скиллы. Хочется чуть больше прикладных вещей и советов в следующей статье


  1. muturgan
    23.08.2021 06:44

    Весьма интересно, спасибо.

    А можно ссылку на статью python разработчика который пришел со списком из 22 вопросов?


    1. dimskiy
      23.08.2021 09:08
      +1

      30 сек в гугле: https://habr.com/ru/post/428283/


      1. muturgan
        23.08.2021 09:10

        красавчик.
        спасибо!


      1. SanDark7 Автор
        23.08.2021 22:21

        Спасибо, уже не первый раз спрашивают!

        Пожалуй, логично сразу давать ссылку в теле статьи :)


  1. Ekrutova
    23.08.2021 21:23
    +1

    Для доработки системы можно ещё внедрять бальную оценку каждого навыка, от 1 до 5, где 1 - требует развития и не проявляется, а 5 - является ролевой моделью.

    Такая бальная система позволяет добавить «количественные» показатели, которые можно использовать по-разному: сравнивать кандидатов/сотрудников между собой, калибровать оценки в группе или использовать для измерения прогресса в индивидуальном плане развития.

    Хорошо помогает снизить субъективность оценки «на глазок».


    1. SanDark7 Автор
      23.08.2021 22:20

      Хорошая идея, спасибо, подумаю над этим.