Главная » Хабрахабр » [Перевод] Жесткие и гибкие навыки в IT: все и более, и менее серьезно, чем хотелось бы думать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Ugears: скакуны, парусники и прочие королевские развлечения

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

[Перевод] Руководство по JavaScript, часть 3: переменные, типы данных, выражения, объекты

Сегодня, в третьей части перевода руководства по JavaScript, мы поговорим о разных способах объявления переменных, о типах данных, о выражениях и об особенностях работы с объектами. → Часть 1: первая программа, особенности языка, стандарты→ Часть 2: стиль кода и структура ...