В последнее время мне часто приходится наблюдать очень нервную реакцию IT-специалистов при малейшем намеке на то, что их «базовые навыки» обесцениваются, и в первую очередь — в пользу других умений, которые они не оттачивали всю жизнь. Наиболее ярко это проявляется в дискуссиях, где так называемые жесткие навыки противопоставляются мягким. Такое отношение само по себе показывает, насколько важна данная проблема. Но в глубине его кроется допущение, которое, как мне кажется, несоразмерно раздувает тревогу: как бы абсурдно это ни звучало, возможно, такая резкая реакция вызвана тем, что мы относимся к мягким навыкам недостаточно серьезно. Сегодня я хотел бы поделиться своим взглядом на ситуацию и предложить ряд шагов, которые могли бы всем нам помочь.
Немного наблюдений
Один из самых надежных способов взвинтить людей в Интернете — предположить, что мягкие навыки, возможно, со временем выйдут в IT сфере на первый план, заслонив жесткие. Когда я говорю «взвинтить», то подразумеваю не просто несогласие, но несогласие с сильным накалом эмоций. Этот накал — очень важный показатель.
Есть одна очень надежная закономерность, которую мне удалось проследить во многих ситуациях: сила эмоциональной реакции человека на какое-либо утверждение многое может сказать о том, насколько тесно это утверждение связано с больными для него темами. На словах это все вроде бы прозрачно, но в качестве метода обнаружения работает крайне эффективно. Острые реакции выводят нас на реальные проблемы и реальные угрозы.
(Этот трюк я бессовестно украл у психологов, а если конкретнее — у психотерапевтов: они используют его, чтобы выяснить, какие проблемы являются фундаментальными для пациента. Общее правило такое: чем сложнее о чем-то говорить, тем более важным оно, скорее всего, окажется. Тот же принцип можно применять и во многих других областях. Например, если человек обижается, когда ему приписывают какое-то качество или увлечение — зачастую это означает, что данное качество или увлечение характерно для группы, к которой они категорически не хотят быть причисленными, хотя и обнаруживают с ней сильно сходство.)
В нашем случае интерес вызывает тот факт, что люди почему-то так переживают именно о ценности жестких и мягких навыков относительно друг друга, а не, скажем, об экономической нестабильности в целом или перенасыщении рынка специалистами, хотя эти два фактора тоже несут в себе опасность для их статуса.
Частоту острых реакций мы можем воспринимать как своего рода неявно выраженное «общественное мнение». С точки зрения культуры это важный момент — ведь культура и создается тем самым обществом. Выявляя паттерны в разговорах и ответах на эту тему за последние несколько лет, видя, с каким высоким уровнем тревожности ведутся обсуждения, я прихожу к следующему выводу: многие люди инстинктивно предчувствуют, что мягкие навыки ожидает большой подъем, но испытывают страх от мысли, какие последствия это будет иметь для них самих.
Что за этим кроется
Если посмотреть со стороны, в этом резком подъеме не будет ничего удивительного. Типаж «гений-одиночка с трудным характером» встречается все реже и реже по той причине, что мало какие технологии сейчас создаются одним человеком. На прошлой работе значительная часть моих обязанностей была связана с тем, чтобы приводить сотни, если не тысячи людей к соглашению и поддерживать этот консенсус, чтобы все двигались в едином направлении. Это была очень сложная задача; как и большую часть IT-специалистов, меня совершенно к этому не готовили, и я постоянно чувствовал, что только притворяюсь, будто знаю, что делаю, в надежде, что никто меня не раскусит.
Когда работаешь в большом коллективе, разрешение сложностей с коммуникацией и сотрудничеством быстро превращается в определяющий фактор успеха или провала. Такие вещи, как «психологическая безопасность» и «взаимное доверие» влияют на повседневный рабочий процесс значительно сильнее, чем какие-то конкретные задачи по программированию. Для джуниоров они важны по той причине, что определяют их качество жизни: пытаться выполнять технические задачи среди людей, которые тебя терпеть не могут, и сложно, и мучительно. Когда же переходишь на более высокий уровень, создавать и поддерживать атмосферу в команде постепенно становится твоей обязанностью. Глубинное различие между позициями джуниора и сениора заключается в то числе и в этом: задача джуниора — искать ответы на вопросы, задача сениора — выяснять, какие вопросы нужно задавать. Когда пересекаешь определенный рубеж, число технических вопросов, которые соответствуют своему уровню экспертизы, резко падает, а широкое распространение разнообразных инструментов — от надежных компиляторов до Stack Exchange — означает, что сложных вопросов, на которые можно получить прямой однозначный ответ, становится все больше.
Конечно, всегда остаются самые головоломные проблемы, которые имеют критическое значение и с которыми неопытные сотрудники не справятся, сколько их ни бросай на задачу — разве что если резко прокачаются. Соответственно, продолжать отрабатывать и расширять свои навыки нам тоже нужно. Но, развиваясь как специалист, вы скоре обнаружите, что все эти невероятно трудные технические задачи занимают у вас далеко не все рабочее время. Напротив, самые фундаментальные для работы системы (и самые сложные) проблемы касаются скорее того, как она взаимодействует с окружающим миром — то есть с людьми.
Что интересно, жесткие и мягкие навыки накладываются друг на друга куда сильнее, чем кажется большинству. Когда начинаешь рассматривать свою систему как часть более крупной системы, в которой в качестве элементов функционируют люди, когда начинаешь задаваться вопросом, как люди взаимодействуют друг с другом и ведут себя, многие из старых-добрых систем, разработанных за счет жестких навыков, не только становятся понятнее, но и дают более точные ответы на вопросы, которые принято относить к сфере мягких. Два классических примера — правила эксплуатации на площадках с многочисленными пользователями и ранжирование всевозможных результатов. В обоих случаях вся суть в том, чтобы переводить «мягкое» интуитивное понимание, чего хотят люди, в «жесткие» математические выражения.
Но даже если не брать те случаи, когда сама техническая задача требует смеси мягких и жестких навыков, многие из мягких навыков, которые сейчас в цене, имеют прямое отношение к управлению сообществом. У этой сферы исторически сложилась плохая репутация среди программистов, потому что в ней (опять же, по старой традиции) всегда работали люди, ничего не понимающие в программировании, и, что еще более важно, относящиеся к нему и тем, кто им занимается, без намека на уважение. Причина в том, что большая часть этих менеджеров вышла из школы индустриального менеджмента 20-го века — а это именно та область, которая подарила нам выражения вроде «человеческий ресурс». Работники для них — это лишние хлопоты и траты, масса, которой надо «управлять», чтобы поддерживать высокие нормы выработки.
Такой тип «управления», если его вообще можно так назвать, тоже не имеет ничего общего с мягкими навыками. Его создали люди, которые нередко считали, что постигли искусство работы с людьми, хотя в действительности делали это из рук вон плохо, в некоторых случаях — до патологической степени. Уже одно то, что люди чувствуют недостаток уважения со стороны менеджеров, должно сильно настораживать. В конец концов, работа менеджера заключается в том, чтобы координировать людей и настраивать на командную работу. Если они не способны на самом базовом уровне выстроить отношения взаимоуважения между работниками и собой, другим ждать от них помощи в этом плане определенно не стоит.
Суть в том, что те мягкие навыки, о которых идет речь, не берутся из ниоткуда. Им учатся не на «уроках этикета» или «тусовках». Они складываются из наблюдения за людьми, изучения их особенностей, умения понимать их потребности, даже когда они сами не могут четко сформулировать, чего хотят — и, соответственно, отработать их невообразимо сложно, ничуть не проще, чем профессиональные умения. Наша привычка говорить о них так, словно это никакие и не навыки, отказывать им в ценности и выводить за пределы профессиональной сферы нам только вредит: когда приходит необходимость самим выполнять соответствующие задачи, быстро выясняется, что не так уж там все и примитивно.
— Специалисты из нашей области уже много лет бьются над этой проблемой.
— Больше им биться не нужно! Я здесь, чтобы решить ее при помощи алгоритмов!
*Шесть месяцев спустя*
— Ого, как тут все сложно.
— Да что ты говоришь?
(Мне это напоминают историю с Одним Знакомым Инженером. Когда его команда переезжала в другое здание, он произнес роковые слова: дескать, организовать пространство проще простого, он сам с этим справится, он же инженер. Результаты были, скажем так, занятными. Программисты, ученые и директора, похоже, страдают одной и той же болезнью: убеждением, что все прочие профессии — плевое дело.)
Хорошие новости: выход есть
Думаю, исправить ситуацию можно очень «простым» способом: начать относиться к мягким навыкам как к серьезным профессиональным умениям, ценить их наряду с последними, обучать людей и нанимать тех, кто уже их освоил — в общем, делать все то, что мы делаем по отношению ко всем прочим фундаментальным навыкам.
В качестве первого шага не помешало бы убедиться, что у нас есть общий словарь для их обсуждения. Довольно сложно ценить то, у чего нет названия. Типичные задачи, которые часто выпадают из нашего поля зрения, включают: «дать всем возможность иметь общее представление о том, что происходит с проектом в данный момент», «выработать общий словарь для основных технических концептов, чтобы любой мог их объяснить», «убедиться, что у всех есть право голоса, и важные опасения не остаются невысказанными просто из страха» и «сделать так, чтобы все участники чувствовали личную заинтересованность в проекте и считали его успех своим» (и это еще далеко не все). Типичные показатели, на которые мы часто не обращаем внимания, включают: «насколько часто пользователи будет испытывать раздражение или другие отрицательные эмоции во время использования продукта и как это повлияет на удержание в долгосрочной перспективе?» или «как проходит следующая сессия после негативного опыта и как это скажется на общем впечатлении от продукта?».
Ничего нового я в предыдущем параграфе не перечислил: это все стандартные вопросы в различных профессиональным специальностям, от управления проектами до исследования пользовательского опыта. Но если команда в целом относится к ним как к побочным соображениям, а не ключевым факторам успеха, дело может закончиться катастрофой: сроки пропущены; разные группы работают над слегка отличающимися версиями продуктов, которые начнут конфликтовать только на финальной стадии, когда их интегрируют; одна из команд исподволь саботирует продукт, потому что не хочет, чтобы он стал успешным; пользователи наталкиваются на какой-нибудь «мелкий» баг и приходят в ужас (это может привести к чему угодно: от массового бегства до судебного иска); доверие клиентов постепенно выдыхается. Я своими глазами наблюдал, как каждая из этих причин приводила к краху проекта, несмотря на то, что в техническом плане все было безукоризненно.
Если мы относимся к таким вещам как к важным, а не третьестепенным составляющим проекта, любой член команды должен иметь о них общее представление, чтобы быть в состоянии хотя бы оценить их значимость, даже если сам ими не занимается. Они должны рассматриваться как базис для отдельных ролей в команде, наравне с фронтендом, бэкендом или безопасностью, и распределяться между конкретными людьми.
Ничего страшного, если каждый инженер не будет обладать нужными навыками, чтобы исполнять все эти обязанности. Скажу больше: я буду поражен, если найдется человек, способный справиться с полным списком. Но делая из них «невидимый труд», который никем не ценится и нигде не учитывается, и притворяясь, что навыков, которые он требует, не существует, мы ничего не добьемся, только навредим себе.
Этот вред заключается не только в прямых последствиях (то есть в том, что нужная работа не выполняется), но и в менее очевидных — нам приходится бороться с лишними страхами. Тревога, о которой шла речь в начале статьи — это симптом того, что мы осознаем: нам не хватает чего-то критически важного, и это недостающее неизвестное с каждым днем становится все более необходимо. Если мы считаем то, чего нам не хватает, «не навыком», а чем-то, что одни умеют просто с рождения (самые популярные претенденты — женщины и «тусовщики», хорошо если не одновременно), а другие (программисты) — нет, от такого положения дел нам становится не по себе. Ведь получается, что нас вот-вот выкинут с работы и заменят какими-то непонятными людьми, которые будут смотреть на программистов свысока. Но если мы признаем все эти умения истинными навыками — то есть тем, чему люди учатся и в чем совершенствуются (ну, или не совершенствуются) всю жизнь, то это совсем другой разговор. И разговор этот звучит примерно так: «Черт, у нас в команде никто не умеет [вставить нужное] и мы выкручиваемся как придется» — то есть до боли знакомо любому, кто был задействован хоть в одном проекте. Да, люди, которые справляются с этими задачами лучше всего, обычно приходят из областей, не связанных с программированием, это чистая правда — в области программирования уже несколько десятков лет принято пренебрегать обучением подобным вещам. Но это не значит, что у них не будет ни малейшего понимания программирования и уважения к этой сфере.
Возможно, я скажу банальность, но если человек, в обязанности которого входит координация программистов или отладка их взаимодействия с пользователями или еще что-то в этом роде, относится к программистам без уважения, он не будет справляться с работой и нанимать его не стоит. «От общения с этим человеком у всех руки опускаются» — серьезный звоночек, а не просто неизбежный побочный эффект самой профессии.
Но нужно отметить, что это работает и в обратную сторону: каждый из участников проекта должен с уважением относиться ко всем навыкам, которые необходимы для работы над ним, и разбираться в них в достаточной степени, чтобы принимать участие в диалоге. Если есть какая-то юридическая загвоздка, связанная с работой системы, все должны знать соответствующие статьи. Если исследование пользователей показало, что что-то вызывает у них позитивную или негативную реакцию, все должны учитывать эти факты при проектировании. Если задержка блокирует какие-то типы пользовательского поведения, все должны понимать, в чем заключается проблема. И подобным же образом все должны понимать и ценить навыки работы с людьми — в конце концов, система, которую вы выстраиваете, включает в себя как минимум вас самих.
Автор: nanton
