Скоро начнется большая студенческая олимпиада «Я — Профессионал». Она уже несколько лет проходит в онлайне и офлайне. Участвовать могут студенты самых разных специальностей, включая технические. Поддержку олимпиаде оказывают ВШЭ, МГУ, МГТУ, МФТИ, МИФИ, СПбГУ, ИТМО и еще около 20 вузов.
Яндекс — технический партнер проекта. Для нас «Я — Профессионал» уже второй год подряд становится хорошим поводом поговорить про важность софт-скиллз (гибких навыков) в работе разработчиков и других специалистов. Год назад в нашем московском офисе прошла встреча для участников олимпиады, посвященная софт-скиллам. Говорил о них и руководитель офиса разработки Яндекса в Новосибирске Сергей Бражник, выступая на тренинге, входящем в программу «Я — Профессионал». Сегодня Сергей и еще двое руководителей в Яндексе — Анна Федосова и Олег Мохов — расскажут для Хабра о гибких навыках: какие они бывают, какие из них нужны разработчику, где их получать и как их наличие сказывается на росте в компании.
Сергей Бражник, руководитель офиса разработки в Новосибирске, директор по развитию региональных образовательных проектов
— Для разработчика важны «4К»: критическое , креативность, кооперация и коммуникация. Принято считать, что коммуникация в этой профессии — не важный навык, но если задуматься, он необходим для профессионального роста: нужно уметь задавать вопросы, слушать и слышать собеседника, объяснять свою точку зрения и принимать чужую, говорить и договариваться. Стажер может не уметь работать в команде или критически мыслить — и это нормально, потому что у него еще нет такого бэкграунда.
Если к нам на собеседование приходит уже созревший специалист, то все эти скиллы мы оцениваем во время разговора. Смотрим на то, как человек рассказывает о себе. По ходу задаем наводящие вопросы и много уточняем. Критическое проверяем на задачах. С одной стороны, нам важно, чтобы он их решил, с другой — мы смотрим, как именно он их решает.У разработчика, который уже работает в компании, есть два способа определить, каких навыков ему не хватает. Первый — запросить фидбек у руководителя. Если тебе ничего не говорят, это не значит, что все хорошо. Сомневаешься — переспроси. За текущими задачами и бизнес-целями руководители могут забывать про софт-направление — важно им о нем напоминать. Второй способ — можно попробовать оценить себя относительно других коллег в коллективе, например, во время брейнштормов, когда все накидывают идеи и затем их обсуждают, критикуют.
Допустим, вы поняли, каких навыков вам не хватает. Это первый и самый важный шаг — осознать, что да, действительно, у меня здесь чего-то сбоит. Далее в идеале найти наставника — хотя бы друга, у которого развиты эти навыки. За другом можно просто понаблюдать. А если найдете именно ментора, то он способен дать советы и проконтролировать ваш рост. Ментором может быть ваш коллега (сразу понятно, зачем ему кураторство — вы работаете на одну цель) или иногда даже внешний эксперт (но это обычно ваш знакомый, иначе его мотивация не ясна). Книги, лекции, тренинги — тоже вариант, но так вы получите только знания. Чтобы знание превратилось в навык, нужна регулярная практика.
Коммуникативные скиллы отлично прокачиваются во время стендапов — ежедневных коротких планерок, где каждый участник команды рассказывает, над чем он сейчас работает. Также помогают любые публичные выступления. И старайтесь побольше общаться с коллегами и делиться опытом внутри команды.
Если нужно выбрать руководителя группы между техническим проджект-менеджером и разработчиком — нет однозначного ответа, кто из них лучше. У нас в Яндексе даже проджект, как правило, умеет писать код. Поэтому я бы сначала сравнил менеджера и разработчика по нескольким параметрам: как они умеют ставить задачи и контролировать исполнение, как драйвят команду и в целом какие отношения у них с командой складываются. Бывает, человек хорошо ставит задачи и следит за сроками, но при этом хуже ладит с командой. Все зависит еще и от того, кто принимает решение. Тот, кто сам был разработчиком, а не менеджером, с большей вероятностью выберет руководителем еще одного разработчика.
На одних хард-скиллах можно стать тимлидом — случаи были. Но руководителей, которые двигают такого человека в тимлиды, нужно бить по рукам. Потому что он, учась в процессе, столько дров наломает, что команда будет демотивирована. Дальше все зависит от того, насколько ребята сильные. Либо они дождутся, когда человек подрастет и осознает, что происходит. Либо не дождутся и начнут разбегаться.
Если все-таки делать хардкорного разработчика руководителем, то сначала надо его сильно подготовить и затем обязательно менторить первые три-шесть месяцев.
Анна Федосова, руководитель отдела обучения и развития
— Трудно составить полный список навыков. Так, модель компетенций Lominger включает 67 позиций. Внутри Яндекса мы делим навыки на универсальные и те, что нужны руководителям.
Универсальные навыки связаны с личной эффективностью и с взаимодействием с другими. С личной эффективностью связаны, например, умение управлять собой, своим временем, рабочими процессами, ориентация на результат, критическое , а также умение учиться. Современную экономику отличает от экономики тридцатилетней давности то, что вы вряд ли будете делать одно и то же всю жизнь. Скорее всего, что-то поменяется, и надо быть к этому готовым.
Другая группа универсальных навыков связана с общением с другими людьми. Мы уже не живем во времена конвейерного производства. Что бы вы ни делали, скорее всего придется договариваться и обсуждать это с другими людьми. Процесс коммуникации в таком случае становится очень важен. В IT-компаниях, где горизонт планирования совсем небольшой из-за постоянного развития технологий, даже техническим специалистам приходится принимать множество коллективных решений, которые рождаются в процессе обсуждения. И сотрудники не могут позволить переговорам зайти в тупик, иначе работа попросту встанет.
Отдельный большой пласт — это навыки для руководителей. К ним относятся умение ставить и оценивать задачи, мотивировать других и развиваться самому, быть лидером, строить свою команду и взаимодействовать с другими командами.
В Яндексе программы обучения гибким навыкам устроены так, чтобы сотрудники могли проработать различные ситуации в безопасной среде. Это могут быть ситуации, с которыми они раньше не сталкивались, или конкретные случаи из их практики, в которых они хотели бы получить лучший результат. Проработать можно многое, начиная от найма новых людей и постановки задач, до конфликта интересов и вопросов мотивации. Как правило, ситуации недопонимания между сотрудником и руководителем сложны для обеих сторон, но можно научиться с ними справляться.
Можно применять разные методы обучения. Так, довольно тяжело научиться командной работе. В школе нас учат работать индивидуально, оценки ставят за личные академические успехи. Но именно в команде люди учатся брать на себя ответственность, распределять между собой роли, договариваться об общих целях и результатах. И часто получается, что этому приходится учить уже во взрослом возрасте на работе. Сейчас в некоторых школах практикуется в том числе проектное обучение и совместное выполнение заданий. Это должно помочь научиться командной работе с детства.
Как научить взрослых людей учиться и самостоятельно добывать знания? Иногда помогает опыт получения высшего образования. В магистратуре и аспирантуре учат пониманию того, что важно, а что неважно, где искать релевантные знания. Но часто это приходится осваивать уже в процессе работы. Не удивительно, что один из самых популярных курсов на Coursera называется Learning how to learn.
Нет ничего полезнее для обучения, чем узнать себя получше: посмотреть на себя со стороны с помощью обратной связи, полученной от коллег, лишний раз подумать о том, что получается хорошо, а что не очень, найти людей, на которых вы хотите быть похожи, и сравнить себя с ними.
Следует помнить, что в основе всего лежит мотивация. Если вы понимаете, что вы нелюдимы, но вам нужно это изменить, например, это важно для команды, то появятся и мотивация, и потребность меняться. Если же по работе вам не нужно ни с кем общаться, то зачем переступать через себя?
Олег Мохов, руководитель разработки HR-проектов и сервиса Яндекс.Контест, на котором проходит онлайн-часть олимпиады
— Разработчикам без амбиций тимлида софт-скиллз не то чтобы нужны. Важно уметь задавать вопросы, слушать, доносить свою мысль. Для прокачивания этих скиллов можно выступить с докладом на конференции или почитать лекции в вузе. Все мы когда-то учились, а значит, можем и сами кого-то поучить. Студенты, заразы, задают самые подковерные вопросики. Умение быстро на них ответить, подвешенность языка помогает тебе сохранять спокойствие в жарких дискуссиях.
Книжки не помогают с софт-скиллами. Тренинги помогают, только если регулярно их посещать. Зато очень полезно прийти по конференцию и занять активную позицию. Просто позадавать вопросы докладчику.
На собеседованиях я иногда подвергаю сомнению даже верный ответ кандидата — смотрю, как он мыслит. Но это работает, только если человек уверен в себе. Вообще, софт-скиллз лучше анализировать на финальных собеседованиях. Например, прошу рассказать про самую интересную задачу, которую кандидат делал. Так можно узнать, что человеку интереснее — кодить, исследовать, получить результат или коммуницировать.
Многие, у кого дико развиты софт-скиллз, становятся высокоранговыми руководителями, у которых весь день состоит из встреч. Как поддерживать умение кодить? Говоришь себе: два часа я программирую. Отрубаешь все уведомления, телефон, только так. Я знаю руководителей, которые так делают. Ну и собеседовать, проводить технические секции — тоже помогает развивать. В Яндексе ты только перестал быть младшим, и тебя уже привлекут к собеседованию. Это как налог на то, что ты работаешь в большой компании.
Если нужно выбрать руководителя группы между менеджером и разработчиком, то тут все зависит от будущих обязанностей руководителя. Одно дело, если менеджер когда-то и сам был разработчиком. Тогда у него больше шансов. Другое, если это проджект-универсал. Он взаимодействует с командой бэкенда, фронтенда, дизайнерами, аналитиками. Но он не знает, как во фронтенде работает конкретная библиотечка, в бэкенде не знаком с асинхронным программированием, не представляет, почему это сложно. Рост разработчика — это погружение вглубь. А суть менеджерства — собрать поверхностный слой, понять проблему и настроить связи, процессы. Поэтому я считаю, что прокачивать у людей разработческие навыки менеджер скорее всего не сможет.
К человеку со стороны у команды может возникнуть неприязнь. Так что я бы выбирал руководителя из числа самих разработчиков, и возможно, выбрал бы не самого сильного из них. Предположим, человек работал пять лет, теперь он senior developer, но за эти пять лет у него росли только харды, а софты не растут. Тогда я не могу ожидать, что они резко начнут расти, если я дам ему должность. А вот когда разработчик работает год, но я вижу, что у него хорошо подвешен язык, он общается, может связать нескольких человек, разрешить конфликт между ними — вот это для меня тимлид, даже если он не старший разработчик.
В историю, когда человек становится руководителем на одних хард-скиллах, я не верю. Тимлид без софтов скорее всего где-то не выполняет свою функцию. Когда это может работать? Когда подчиненные самодостаточные. У меня для новых руководителей есть крылатая фраза: котиками просто управлять. Тимлиды расстраиваются, когда у них возникают сложные кейсы — один сотрудник хочет уволиться, другой захандрил и стал меньше перформить, третий конфликтный. Я на такое говорю их тимлиду — радуйся, тебе впервые нужно поработать как руководителю. Потому что котиками — вот они мяукают, добренькие, веселые — ими очень просто управлять.
Автор: Леонид Клюев
