company_banner

Какие soft skills нужны разработчику? Мнения из Яндекса

    Скоро начнется большая студенческая олимпиада «Я — профессионал». Она уже несколько лет проходит в онлайне и офлайне. Участвовать могут студенты самых разных специальностей, включая технические. Олимпиаду организуют 26 ведущих вузов: НИУ ВШЭ, МГУ, МГТУ, МФТИ, МИФИ, СПбГУ, Университет ИТМО и другие.

    Яндекс — технический партнер проекта. Для нас «Я — профессионал» уже второй год подряд становится хорошим поводом поговорить про важность софт-скиллз (гибких навыков) в работе разработчиков и других специалистов. Год назад в нашем московском офисе прошла встреча для участников олимпиады, посвященная софт-скиллам. Говорил о них и руководитель офиса разработки Яндекса в Новосибирске Сергей Бражник, выступая на тренинге, входящем в программу «Я — профессионал». Сегодня Сергей и еще двое руководителей в Яндексе — Анна Федосова и Олег Мохов Olegbl4 — расскажут для Хабра о гибких навыках: какие они бывают, какие из них нужны разработчику, где их получать и как их наличие сказывается на росте в компании.

    Сергей Бражник, руководитель офиса разработки в Новосибирске, директор по развитию региональных образовательных проектов




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

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

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

    Допустим, вы поняли, каких навыков вам не хватает. Это первый и самый важный шаг — осознать, что да, действительно, у меня здесь чего-то сбоит. Далее в идеале найти наставника — хотя бы друга, у которого развиты эти навыки. За другом можно просто понаблюдать. А если найдете именно ментора, то он способен дать советы и проконтролировать ваш рост. Ментором может быть ваш коллега (сразу понятно, зачем ему кураторство — вы работаете на одну цель) или иногда даже внешний эксперт (но это обычно ваш знакомый, иначе его мотивация не ясна). Книги, лекции, тренинги — тоже вариант, но так вы получите только знания. Чтобы знание превратилось в навык, нужна регулярная практика.

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

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

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

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

    Анна Федосова, руководитель отдела обучения и развития




    — Трудно составить полный список навыков. Так, модель компетенций Lominger включает 67 позиций. Внутри Яндекса мы делим навыки на универсальные и те, что нужны руководителям.

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

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

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

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

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

    Как научить взрослых людей учиться и самостоятельно добывать знания? Иногда помогает опыт получения высшего образования. В магистратуре и аспирантуре учат пониманию того, что важно, а что неважно, где искать релевантные знания. Но часто это приходится осваивать уже в процессе работы. Неудивительно, что один из самых популярных курсов на Coursera называется Learning how to learn.

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

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

    Олег Мохов, руководитель разработки HR-проектов и сервиса Яндекс.Контест, на котором проходит онлайн-часть олимпиады




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

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

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

    Многие, у кого дико развиты софт-скиллз, становятся высокоранговыми руководителями, у которых весь день состоит из встреч. Как поддерживать умение кодить? Говоришь себе: два часа я программирую. Отрубаешь все уведомления, телефон, только так. Я знаю руководителей, которые так делают. Ну и собеседовать, проводить технические секции — тоже помогает мозг развивать. В Яндексе ты только перестал быть младшим, и тебя уже привлекут к собеседованию. Это как налог на то, что ты работаешь в большой компании.

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

    К человеку со стороны у команды может возникнуть неприязнь. Так что я бы выбирал руководителя из числа самих разработчиков, и возможно, выбрал бы не самого сильного из них. Предположим, человек работал пять лет, теперь он senior developer, но за эти пять лет у него росли только харды, а софты не растут. Тогда я не могу ожидать, что они резко начнут расти, если я дам ему должность. А вот когда разработчик работает год, но я вижу, что у него хорошо подвешен язык, он общается, может связать нескольких человек, разрешить конфликт между ними — вот это для меня тимлид, даже если он не старший разработчик.

    В историю, когда человек становится руководителем на одних хард-скиллах, я не верю. Тимлид без софтов скорее всего где-то не выполняет свою функцию. Когда это может работать? Когда подчиненные самодостаточные. У меня для новых руководителей есть крылатая фраза: котиками просто управлять. Тимлиды расстраиваются, когда у них возникают сложные кейсы — один сотрудник хочет уволиться, другой захандрил и стал меньше перформить, третий конфликтный. Я на такое говорю их тимлиду — радуйся, тебе впервые нужно поработать как руководителю. Потому что котиками — вот они мяукают, добренькие, веселые — ими очень просто управлять.
    Яндекс
    673,24
    Как мы делаем Яндекс
    Поделиться публикацией

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

      +4
      — Разработчикам без амбиций тимлида софт-скиллз не то чтобы нужны.

      Ого, ничего себе разрыв шаблонов.

      А как же «программист должен», после которого длинный список из яп, фреймворков, сопутствующего софта, софт скиллов и прочего. Ведь программист должен всю жизнь учиться, и всю жизнь чувствовать свою ничтожность — ведь знает он всего ничего, а нужно знать вон оно сколько всего.
        –3

        Занятная у вас позиция… o_0

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

          Уже писали как обходятся в Яндексе с сотрудниками, поэтому такой вот совет.
            0
            Не удивительно, что один из самых популярных курсов на Coursera называется Learning how to learn.
            — неудивительно
              0
              Исправлено, спасибо.
                +4

                Для подобных замечаний авторам на хабре есть фича с Ctrl+Enter :)

                  +4

                  Которая особенно хорошо работает на смартфонах и планшетах.

                +2
                Не верю, что критическое мышление кому-то реально нужно, даже если его поощряют для вида типа «мы такие хорошие, всех хотим выслушать». Всё равно принимается точка зрения того, кто сильнее (т.е. руководителя), и игра в демократию рано или поздно заканчивается.
                "Котиками проще управлять" — вот это истина. Только котики программировать должны уметь и работать за еду.
                  0
                  9 лет преподавала высшую математику, готовила к ЕГЭ и немного к школьным олимпиадам. Только вот в программировании оно мне не понадобилось. Да и на собеседовании почти никто на это не обращает внимание.
                    +1
                    У меня товарищ тоже преподавал математику в ВУЗе. Потом стал программистом, попал в крупную компанию. Там на него обратил внимание отдел Data-solutions, и его математические навыки очень даже пригодились. Есть в программировании области, где математика важна. Двигайтесь в сторону Machine learning.
                      0
                      В свое время, когда меняла род деятельности, в нашем городе были как таковые только php программисты. На Machine learning другой язык программирования. Сейчас меня вряд ли возьмут джуном туда. Да и в нашем городе нет этого, только удаленка. А как я убедилась на собственном опыте — в разы быстрее учиться именно в офисе.
                        0
                        Ну, не знаю, я, например, языки меняю как перчатки. Многие популярные языки семантически сильно похожи. У хорошего разработчика знание синтаксиса конкретного языка занимает не более 5-ти процентов. Так что, как говорится, «глаза боятся — руки делают». Дерзайте. Попробуйте найти удаленную работу, если в городе небольшой выбор. Или рассмотрите вариант переезда. Серьезная математическая подготовка — это серьезный аргумент, чтобы рассмотреть переезд в Москву.
                          0
                          У хорошего разработчика знание синтаксиса конкретного языка занимает не более 5-ти процентов.
                          В том-то и проблема, что знание синтаксиса — это 5% от того, что необходимо для разработки на каком-либо языке. Синтаксис учится быстро (если только это не что-то совсем диковинное), а вот умение грамотно обходить раскиданные грабли (причем некоторые языки из этих граблей состоят чуть более чем наполовину), понимание что происходит «под капотом» чтобы код работал эффективно, а не «и так сойдет», и знание и использование best practices конкретного языка для конктретных применений — это приходит за гораздо большее время, и может занять не один год.
                            0
                            Я имел ввиду, что остальные технические знания абстрактны от конкретного языка. Это вопросы проектирования, архитектуры, алгоритмы, базы данных, тестирование, рефакторинг, качество кода, методологии разработки, распределенные системы, операционная система и общее устройство компиляторов/интерпретаторов, методики оценивания задач и т.п.

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

                              Не соглашусь от слова "совсем".
                              Есть такая старая шутка: "программист, умеющий писать на Фортране, сможет писать на любом языке, но делать это будет как на Фортране".
                              Есть огромное количество весьма важных вещей при разработке, которые не относятся ни к синтаксису, ни к алгоритмам, ни к базам данных, ни к чему что вы перечислили. И они могут и будут очень сильно различаться даже у языков с родственным синтаксисом, и очень сильно влиять на итоговый результат. Возьмите похожие по синтаксису языки: C, C++, C#, Java, JavaScript, и пусть будет еще Go, и все это разных версий и реализаций.
                              В одном случае все объекты всегда аллоцируются в хипе, а структур просто нет, в другом случае структуры на стеке, а объекты в хипе, а третьем случае и то и то может быть где угодно, смотря как объявить. Где-то деаллокация вручную, где-то по счётчику ссылок, где-то mark-and-sweep GC с разными триггерами на срабатывание, где-то GC умеет определять циклические ссылки, где-то нет. В итоге выглядеть код может практически одинаково, а вот работать под капотом совершенно по-разному, и даже при использовании абсолютно идентичного алгоритма (с отличным О-большим) вы в одном случае получите тормоза из-за постоянных ненужных аллокаций-деаллокаций, в другом случае сможете пробить стек при определенных обстоятельствах, в третьем наделать утечек.
                              Возьмите строки, казалось бы, базовый тип данных, где-то они мутабельные, где-то они и мутабельные, где-то есть COW, где-то есть COW и он портит итераторы, где-то был COW, но его запретили в новых версиях компиляторов, и если он вам нужен, придется изворачиваться. В итоге последствия те же самые: в одном случае можно огрести тормозов, в другом случае — неприятных побочных эффектов и получить вообще не тот результат что планировался. Это не говоря уж о потенциальных дырах безопасности.
                              Та же фигня с исключениями. Где-то они не дают просадки по производительности, но сильно раздувают код бинарника, где-то они тормозят из-за необходимости раскрутки стека и использовать их принято только при реальной необходимости, а не на каждый чих, где-то их нельзя использовать в конструкторах (и компилятор вас об этом забудет предупредить), и т.д.
                              Да что там, возьмите C с его UB, алиасингом, и подобным. Действия и конструкции, которые могут быть абсолютно корректными и часто используемыми в других языках, тут в тысяче случаев могут сработать именно так как вы ожидаете, а в 1 случае совершенно непредсказуемо, в зависимости от версии компилятора, целевой платформы и фаз луны, потому что они UB.
                              Или вот C++, казалось бы, долгое время вообще являлся подмножеством Си, унаследовал его синтаксис, и до сих пор обеспечивает почти полную (но не абсолютную) обратную совместимость. И к чему это приводит? Люди, писавшие на Си, переходя на С++ начинают писать на нем как на "Си с классами". Со всеми этими char*-строками, malloc/free, а про Core Guidelines вообще не слышали. В итоге получается кривой и ненадежный код, в который C++ добавляет свои приколы, типа тех же исключений в конструкторах, и виртуальных деструкторов: человек, знающий как что работает под капотом и как компилятор сгенерирует код создания-удаления объектов, до таких вещей дойдет интуитивно, человеку же незнающему придется зазубривать набор правил или с разбегу прыгать на эти грабли.
                              То же самое с высокоуровневые и языками, где например есть корутины и async-await — казалось бы, все просто, пиши себе асинхронщину, но рано или поздно придется разбираться, как оно устроено внутри, почему так, и что с этим сделать. Или бессмертная проблема инвалидации кэша, когда простое переписывания условий вложенных циклов на определенных структурах данных может дать многократный прирост производительностью благодаря попаданий в кэш-линию процессора, вот только для разных языков (и даже для разных компиляторов) это переписывание может быть совершенно разным. А синтаксис циклов одинаковый.
                              Понятное дело, что если вы пишите какие-то несложные утилиты или банальный CRUD, или работаете на второстепенных позициях в уже написанном проекте по принципу "внесу небольшие изменения, посмотрев, как это было сделано до меня в другом месте кода" — тогда да, в таком режиме существовать можно довольно долго и вполне успешно, и знания алгоритмов и баз данных тут окажутся полезнее. Правда, на выходе получится именно то, за что заслуженно ругают современной ПО: софт жрет гигабайты на диске и сотни мегабайт в памяти, падает при неосторожном тыке, а по количеству дыр безопасности в нем напоминает решето.
                              А вот когда вы разрабатываете что-то новое, либо же то с требованиями к performance, stability и security, или же просто хотите сделать свою работу хорошо, чтобы было потом не стыдно — вот там синтаксис действительно окажется лишь 5% от необходимых знаний не сопутствующих технологий и алгоритмов, а именно особенностей и внутреннего устройства конкретного языка и его обвязки.

                                0
                                Я ценю ваши глубокие познания подкапотного устройства, но не очень отчетливо понимаю, каким образом то, что Вы описали, релевантно к девушке, которая в силу обстоятельств изучала PHP, а потом узнала, что для реализации ее математических навыков более подходит другой язык, например, Python? Что именно, не входящее в стандартный Python-Tutorial (а лучше «Learning Python» 5th edition by Mark Lutz, kimisa ), может помешать ей это осуществить?

                                Соглашусь, что я, наверное, неправильно выразился, и под «синтаксисом» я имел ввиду ту часть знаний, которая дается официальным руководством.

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

                                Где-то деаллокация вручную, где-то по счётчику ссылок, где-то mark-and-sweep GC с разными триггерами на срабатывание, где-то GC умеет определять циклические ссылки, где-то нет.
                                Ключевое слово здесь «где-то». И именно тем самым, что применяется «где-то», занимается (упомянутое мною) общее устройство компиляторов/интерпретаторов. Например, идея упомянутого Вами mark-sweep сборщика, примененного в Golang, была впервые предложена еще Дейкстрой в 1978 году.

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

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


                      Я уж не говорю о знакомстве с теорией доказательств и формальной логикой (с последней желательно чуть глубже, чем булева алгебра).

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

                    Самое читаемое