Жесткие и гибкие навыки в IT: все и более, и менее серьезно, чем хотелось бы думать

Original author: Yonatan Zunger
  • Translation
В последнее время мне часто приходится наблюдать очень нервную реакцию IT-специалистов при малейшем намеке на то, что их «базовые навыки» обесцениваются, и в первую очередь — в пользу других умений, которые они не оттачивали всю жизнь. Наиболее ярко это проявляется в дискуссиях, где так называемые жесткие навыки противопоставляются мягким. Такое отношение само по себе показывает, насколько важна данная проблема. Но в глубине его кроется допущение, которое, как мне кажется, несоразмерно раздувает тревогу: как бы абсурдно это ни звучало, возможно, такая резкая реакция вызвана тем, что мы относимся к мягким навыкам недостаточно серьезно. Сегодня я хотел бы поделиться своим взглядом на ситуацию и предложить ряд шагов, которые могли бы всем нам помочь.



Немного наблюдений


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

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

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

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

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

Что за этим кроется


Если посмотреть со стороны, в этом резком подъеме не будет ничего удивительного. Типаж «гений-одиночка с трудным характером» встречается все реже и реже по той причине, что мало какие технологии сейчас создаются одним человеком. На прошлой работе значительная часть моих обязанностей была связана с тем, чтобы приводить сотни, если не тысячи людей к соглашению и поддерживать этот консенсус, чтобы все двигались в едином направлении. Это была очень сложная задача; как и большую часть IT-специалистов, меня совершенно к этому не готовили, и я постоянно чувствовал, что только притворяюсь, будто знаю, что делаю, в надежде, что никто меня не раскусит.

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

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

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

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

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

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



— Специалисты из нашей области уже много лет бьются над этой проблемой.
— Больше им биться не нужно! Я здесь, чтобы решить ее при помощи алгоритмов!
*Шесть месяцев спустя*
— Ого, как тут все сложно.
— Да что ты говоришь?


(Мне это напоминают историю с Одним Знакомым Инженером. Когда его команда переезжала в другое здание, он произнес роковые слова: дескать, организовать пространство проще простого, он сам с этим справится, он же инженер. Результаты были, скажем так, занятными. Программисты, ученые и директора, похоже, страдают одной и той же болезнью: убеждением, что все прочие профессии — плевое дело.)

Хорошие новости: выход есть


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

В качестве первого шага не помешало бы убедиться, что у нас есть общий словарь для их обсуждения. Довольно сложно ценить то, у чего нет названия. Типичные задачи, которые часто выпадают из нашего поля зрения, включают: «дать всем возможность иметь общее представление о том, что происходит с проектом в данный момент», «выработать общий словарь для основных технических концептов, чтобы любой мог их объяснить», «убедиться, что у всех есть право голоса, и важные опасения не остаются невысказанными просто из страха» и «сделать так, чтобы все участники чувствовали личную заинтересованность в проекте и считали его успех своим» (и это еще далеко не все). Типичные показатели, на которые мы часто не обращаем внимания, включают: «насколько часто пользователи будет испытывать раздражение или другие отрицательные эмоции во время использования продукта и как это повлияет на удержание в долгосрочной перспективе?» или «как проходит следующая сессия после негативного опыта и как это скажется на общем впечатлении от продукта?».

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

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

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

Этот вред заключается не только в прямых последствиях (то есть в том, что нужная работа не выполняется), но и в менее очевидных — нам приходится бороться с лишними страхами. Тревога, о которой шла речь в начале статьи — это симптом того, что мы осознаем: нам не хватает чего-то критически важного, и это недостающее неизвестное с каждым днем становится все более необходимо. Если мы считаем то, чего нам не хватает, «не навыком», а чем-то, что одни умеют просто с рождения (самые популярные претенденты — женщины и «тусовщики», хорошо если не одновременно), а другие (программисты) — нет, от такого положения дел нам становится не по себе. Ведь получается, что нас вот-вот выкинут с работы и заменят какими-то непонятными людьми, которые будут смотреть на программистов свысока. Но если мы признаем все эти умения истинными навыками — то есть тем, чему люди учатся и в чем совершенствуются (ну, или не совершенствуются) всю жизнь, то это совсем другой разговор. И разговор этот звучит примерно так: «Черт, у нас в команде никто не умеет [вставить нужное] и мы выкручиваемся как придется» — то есть до боли знакомо любому, кто был задействован хоть в одном проекте. Да, люди, которые справляются с этими задачами лучше всего, обычно приходят из областей, не связанных с программированием, это чистая правда — в области программирования уже несколько десятков лет принято пренебрегать обучением подобным вещам. Но это не значит, что у них не будет ни малейшего понимания программирования и уважения к этой сфере.

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

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

Comments 26

    +5
    Один из самых надежных способов взвинтить людей в Интернете — предположить, что мягкие навыки, возможно, со временем выйдут в сфере нейрофизиологии на первый план, заслонив жесткие.

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

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

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

    А программировать компьютеры скоро будут сами, да-с.
      +3

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

        +1
        может все-таки социофоба? :)
          0

          Пардон, я опечатался в слове "социофоб", и гугл мне предложил исправление, я даже не присмотрелся на что он предложил исправить :-)

        +4
        Есть мнение, что команда дружелюбных середнячков сможет сделать нечто большее, чем несколько вечно несогласных друг с другом и сварливых звезд.

        Это сродни качественной синхронизации потоков на небыстрой машине и постоянным дедлокам на супербыстрой.

        Проблема в том, что hard skills остаются нужны не меньше, чем раньше, но вдобавок к ним нужны и soft skills. Так что профессия пограммиста становится все труднее.
          0
          Есть мнение, что команда дружелюбных середнячков сможет сделать нечто большее, чем несколько вечно несогласных друг с другом и сварливых звезд.

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

            0
            Дружелюбных, или тех, кто пытается казаться такими?


            Я не знаю реализации лежащей за интерфейсом, но если наружу это выглядит как дружелюбие, детали меня не интересуют.

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


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

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

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

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


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

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

                    –1
                    который не просто исправит течь, но еще и объяснит что было и как сделать, чтоб не повторялось.

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

              0

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


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

                0
                Например, встречали ли вы людей, которые при фиксе одного бага создают десяток новых?

                Они потом еще обижаются когда код опять не прошел код-ревью. И делают невинное выражение лица когда указываешь им что разбиралась похожая проблема и человек в курсе, но почему то все равно опять идет по граблям. И не помогают никакие софт-скилл, потому что либо чел просто уже выдохся (например не был в отпуске давно) либо он просто не желает писать код как следует — ему понимаешь ли не интересно доводить свою работу до уровня когда ее можно влить в общую ветку и не бояться что все пойдет тазом. И реально здесь требуется не софт-скилс, а хороший такой пинок под зад. (может конечно это понимают эти люди под «софт»-скилc — умение определить когда пора давать пинка и как следует разбежаться с нужной точно выверенной скоростью да не промазать ?). Но если его дать этот пинок, то все вокруг будут винить тебя — «ну нельзя же так, он не виноват, что у него не получается, надо же ему объяснить...» И в итоге реальное назначение софт-скил — это плести интрижки на работе и пробивать себе путь к креслу по шире да помягче. А сеньору (да и тимлиду) софт-скил как собаке лишния кость — есть хорошо Нет — ну и нахрен не нужно потому что мясо лучше.
                  0
                  А зачем нанимать людей, которые при фиксе одного бага делают десять новых?
                    0
                    А вы комментарий вообще читали?
                      0
                      Читал.
                        0
                        ИМХО, почему так получается: на рынке не хватает квалифицированных кадров

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

                        Добавим немного «теории заговора». В рамках аутсорса крупных проектов заморачиваться с наймом нет смысла, потому что тратятся деньги заказчика (а не аутсорс-компании), а аутсорс-компания получает деньги за человеко-часы. И пара неквалифицированных чуваков увеличивает и количество человек, и количество часов (ведь новые десять багов кто-то должен пофиксить). Т.е. аутсорсу (коего дохрена) выгоднее нанимать менее способных специалистов. Ой нет, это не теория заговора, а реальная картина мира.

                        Вот еще одна забавная вещь. При недостатке квалифицированных кадров очень важны становятся самоконтроль, доброта и терпимость к неквалифицированным кадрам (софт скиллы).
                      0
                      Ну во первых не всегда нанимающее лицо совпадает с лицом делающим код-ревью. Во вторых нанимать джунов по моему мнению имеет смысл если организация располагает материальным ресурсом их потом удержать, когда они перестанут быть джунами. Просто надо не только нанимать, но и увольнять вовремя, если джун — не адекват. Не взирая на пол, возраст, религиозные убеждения и расу — просто брать и увольнять, потому что он не желает/не может как от него требуется. Но вот с этим опять же проблема — часто либо полномочий таких нет у того кто реально способен оценить возможности нанятого, либо еще какие-нибудь проблемы — например кандидат какого то особого пола и потому его нельзя увольнять…
                0
                Что такое жесткие и гибкие навыки?
                  0
                  жесткие — это навыки чисто технические, гибкие или мягкие (софт) — социальные. К первым относятся алгоритмы, структуры, программирование, архитектура, тестирование и прочая, ко вторым — руководство людьми, совместная работа, работа, когда от тебя зависят люди, и работа, когда ты от кого-то тоже зависишь. Умение продвигать свою точку зрения.
                    0
                    гибкие навыки

                    Это такую новую идиому для приемлемой социализированности придумали.
                    +2

                    А можно спросить — с каких пор в русском языки появились эти твёрдые и мягкие навыки? Хотите писать чисто по русски — будьте добры распиывать весь набор терминов, описывающих то же понятие, что и hard skills & soft skills, не хотите — так и пишите прямые заимствования! Софт-скиллс и хард-скиллс — это понятно. Социально-направленные навыки и чисто технические навыки — это понятно. Твёрдые и мягкие, извините отнюдь не навыки, а кое-что другое, что в проруби обычно плавает.

                      0
                      После вашего комментария понял о чем речь в статье.
                      –1
                      демагогия
                      демагог это тот, кто утверждает, что мягкий член лучше твердого
                      • UFO just landed and posted this here

                      Only users with full accounts can post comments. Log in, please.