18 March 2026

Грань, которую опасно переходить: риск гипертрофированных soft skills

Про софт-скиллы уже написано много и с разных сторон. Мне захотелось поучаствовать в этой дискуссии, тем более что недавно я прочитал несколько статей, задающих ключевые вопросы: «А зачем они нужны? И кому они нужны?» В данном материале я хочу в первую очередь рассмотреть влияние развития soft skills на разработчиков.

Начнем с краткого раскрытия информации о том, что по определению входит в перечень soft skills (мягких навыков):

  • Коммуникативные навыки
  • Навыки командной работы
  • Эмоциональный интеллект
  • Мышление и решение проблем
  • Самоорганизация
  • Управленческие навыки
  • Адаптивность

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

Вольные трактовки и влияние методологий

При этом у понятия soft skills существует достаточно вольная трактовка. Например, встречаются следующие определения:

  • Социальный клей — социализация.
  • Умение не бесить людей — избегание неприятностей.
  • Навыки втирания в доверие — достижение личных целей.

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

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

  1. Люди и взаимодействие важнее процессов и инструментов. Команда важнее строгих регламентов.
  2. Работающий продукт важнее исчерпывающей документации. Главный показатель прогресса — готовый функционал.
  3. Сотрудничество с заказчиком важнее согласования условий контракта. Необходим постоянный диалог с клиентом для создания нужного продукта.
  4. Готовность к изменениям важнее следования первоначальному плану. Гибкость и адаптация к новым условиям важнее упрямого следования графику.

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

Когда Scrum становится фактором риска

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

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

Сложим все составляющие:

  • Стартап: принципы Scrum позволяют действовать гибко и быстро реагировать на изменения рынка. Поэтому soft skills здесь — база, на которой строится и существует проект, пока не перерастет в бизнес.
  • Бизнес: происходит уход от Scrum, когда компании требуются прогнозируемость и повторяемость результатов за счет жестких регламентов. В этом случае принципы Scrum перестают работать, а значит, избыточная ценность soft skills может дать прямо противоположный (деструктивный) эффект.

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

Получается, что рабочая среда и обстоятельства должны определять требования к личностным характеристикам человека. Усредненные требования к сотрудникам в определенных обстоятельствах могут стать вредительскими. Простыми словами: не всем и не везде нужно одинаково развивать soft skills.

Проблема разработчика как «говорящего рта»

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

  • Разговаривающий разработчик меньше уделяет времени техническим аспектам, смещая фокус на развитие навыков общения. Теряются компетенции. Это потеря личного времени специалиста, а компания теряет общую производительность.
  • Разработчик привыкает к уменьшению технической нагрузки, так как говорить в целом проще, чем думать. (Это не касается случаев, когда нужно тщательно обдумывать каждое слово, а применимо к встречам, где требуется лишь пересказ технических андеграундов). Специалист чаще участвует в разговорах, чем в разработке, что ведет к потере мотивации к программированию.
  • Размывается ценность менеджеров в глазах такого разработчика. Ему начинает казаться, что менеджеры просто «болтают» вместо выполнения реальной работы. Создается ложное представление о сложности чужих профессий, снижается интегрированность команды, подрываются авторитеты и принципы управления. Для компании это может стоить больших денег.

Модель PAEI Ицхака Адизеса в контексте soft skills

В качестве теоретической основы советую ознакомиться с моделью PAEI Ицхака Адизеса. Код I (Интеграция) в этой модели ближе всего относится к soft skills. В концепции Адизеса характеристика I напрямую конфликтует с характеристикой P (Производство результатов), отвечающей за генерацию основного продукта. Фактически, искусственно развивая в компании I-характеристики, руководство оказывает давление на P-характеристики.

  • Причина конфликта: Для компонента P важна скорость и конкретный результат «здесь и сейчас». Его раздражают долгие совещания, обсуждение чувств и попытки прийти к консенсусу. Он считает, что компонент I просто тратит время на пустую болтовню.
  • Суть спора: Производитель (P) говорит: «Плевать на атмосферу, нам нужно сдать проект к утру!». Интегратор (I) отвечает: «Если мы сейчас перегнем палку, люди перегорят и завтра уволятся».

Подробнее о влиянии каждой из характеристик PAEI-кода вы можете прочитать в книге Ицхака Адизеса «Идеальный руководитель. Почему им нельзя стать и что из этого следует».

Какие мягкие навыки действительно важны разработчику?

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

  • умение открыто заявлять о возникающих проблемах;
  • способность критически оценивать себя и своих коллег;
  • умение вовремя попросить помощи и обмениваться опытом;
  • способность прямо заявить об усталости и выгорании;
  • возможность организовать рабочий процесс в условиях неопределенности (в частности, проводить декомпозицию задач в рамках своей компетенции).

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

Заключение

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

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

Расскажите о вашем проекте и задайте вопросы — мы скоро ответим

Как не слить бюджет? Проверьте подрядчика

  • Вам назвали точную цену за 5 минут без детального ТЗ?
  • Кому будут принадлежать авторские права на исходный код?
  • Что вы будете делать, если ведущий разработчик проекта уйдет?
  • Как вы будете контролировать работу — поэтапно или «в черную»?

Оставить заявку

Оставьте заявку на бесплатную 30-минутную консультацию с нашим тимлидом. Разберем вашу задачу и предложим архитектуру решения

Спасибо!

Мы свяжемся с вами в ближайшее время