94% университетских преподавателей в одном из исследований оценили качество своей работы как «выше среднего». Для IT это узнаваемая цифра: мы читаем статьи, спорим в комментариях, сохраняем полезное, но развитие навыков часто так и не доходит до практики. В итоге знание есть, а нового поведения нет.
Именно об этом пишет автор колонки в корпоративном блоге SmartValues, сообщает Habr / Карьера. Тезис неприятный, но рабочий: проблема чаще не в лени и не в дефиците мотивации, а в системных ловушках мышления. Между «я прочитал» и «я начал делать» встают четыре препятствия: одна большая яма под названием «я это уже знаю» и три барьера на выходе из нее.
Первая ловушка описана через старую, но до сих пор полезную модель Ноэля Бёрча, предложенную в 1970-х в Gordon Training International. Она делит освоение навыка на четыре стадии: неосознаваемая некомпетентность, осознаваемая некомпетентность, осознаваемая компетентность и автоматический навык. Главная проблема, по версии автора, начинается уже на старте: человек не просто чего-то не умеет, а еще и уверен, что умеет. Формула знакомая любому тимлиду: «это очевидно», «мы это пробовали», «в реальной жизни так не работает». После такой реплики можно спокойно идти читать следующую статью и ничего не менять.
Для IT-среды эта история особенно болезненна там, где нет жесткой технической проверки. Если разработчик не умеет писать код, это довольно быстро покажут компилятор, тесты или прод. С коммуникацией, обратной связью и управлением командами встроенного компилятора нет. Автор приводит характерный пример из обсуждения на Хабре: человек выступает за уважительное общение и тут же завершает свой комментарий словом «бред». Противоречие он не замечает. В этом и суть ловушки: декларируемое знание и реальное поведение часто живут как соседи, которые давно не разговаривают.
Отсюда вырастает и первый барьер: признать, что проблема может быть не в «токсичной команде», «неадекватном заказчике» или «неправильной культуре», а в собственных действиях. Психология давно называет это переходом от внешнего локуса контроля к внутреннему. Автор ссылается на работы Джулиана Роттера и более поздние исследования, где люди с внутренним локусом контроля показывают лучшие академические результаты, более высокую удовлетворенность карьерой и более высокий доход. При этом около 70% людей, по данным исследований в менеджменте, склонны объяснять свои провалы внешними обстоятельствами, а успехи записывать на личный счет. Для профессионала это неприятный момент: вчера ты был «тем, кто все понимает», а сегодня вынужден признать, что не умеешь добиваться результата. Субъективно это выглядит как шаг назад, хотя без него никакого развития навыков не будет.
Второй барьер связан не с ответственностью, а с тем, как человек вообще видит ситуацию. Автор опирается на модель Стивена Кови «Вижу — Делаю — Получаю»: результат определяется не только действиями, но и картиной мира, из которой эти действия вырастают. На примере code review разница видна сразу. Если ревью понимать как охоту на ошибки, рецензент начинает играть прокурора: цепляется к мелочам, пишет жестко, продавливает правки. Если же ревью — это способ улучшить продукт и помочь коллеге расти, меняется тон, структура вопросов и итог разговора. Техническая компетентность может быть той же самой, а эффект для команды — совершенно разным.
Этот тезис автор выводит и на уровень отрасли. В качестве примера он напоминает переход от коробочного ПО к SaaS и continuous delivery. Старая модель относилась к релизу как к редкому и опасному событию, которое нужно пережить с максимальным стрессом и минимальной частотой. Новая парадигма рассматривает релиз как рутинную операцию: небольшие изменения, автоматизация, быстрый откат, постоянная обратная связь. В статье приводятся цифры из ежегодного отчета DORA: элитные команды деплоят в 208 раз чаще, чем низкопроизводительные, и при этом имеют в 7 раз более низкий уровень отказов изменений. Смысл здесь не в том, что DevOps опять победил всех, а в том, что без смены базовой управленческой логики новые ритуалы не работают. Можно провести десять стендапов и не приблизиться к Agile ни на метр.
Для руководителей и старших специалистов здесь есть еще один неприятный вывод. Масштабное исследование Google Project Oxygen показало, что из восьми ключевых качеств успешного менеджера семь относятся к мягким навыкам. То есть в зоне наибольшего карьерного влияния часто лежит именно то, что в инженерной культуре привычно считать вторичным фоном. Обратная связь, активное слушание, управление конфликтом, создание психологической безопасности не выглядят «твердым» результатом, поэтому их особенно удобно считать уже освоенными. Пока команда не начинает сыпаться на простых человеческих сценариях.
Третий барьер куда прозаичнее и потому опаснее: даже если человек признал проблему и пересобрал свою картину мира, остается привычка. Автор ссылается на популярную модель Чарльза Дахигга: сигнал, действие, вознаграждение. Более 40% наших ежедневных действий, по приводимым в статье данным, вообще совершаются по привычному шаблону, а не через осознанное решение. Отсюда и знакомая многим сцена: на тренинге все было убедительно, вечером человек даже составил план, а утром снова отвечает в чате тем же тоном, проводит ревью так же жестко и откладывает неприятный разговор еще на неделю. Не потому, что передумал, а потому, что старый нейронный маршрут быстрее нового.
Практический вывод у автора довольно трезвый. Старые привычки не удаляются кнопкой «очистить кэш», их можно только замещать. На формирование нового шаблона, по данным, которые он приводит, уходит от 18 до 254 дней. Поэтому лучше искать не абстрактную мотивацию, а конкретные стартовые привычки, которые запускают цепочку поведения, и снижать трение для нового действия. Иными словами, не обещать себе «с понедельника стану зрелым лидом», а менять один повторяемый момент: как начинается сложный разговор, как формулируется первый комментарий в ревью, какой вопрос задается перед тем, как назвать чужую идею ерундой.
Для русскоязычной IT-аудитории этот текст ценен не психологическими терминами, а довольно точным диагнозом профессиональной среды. Мы привыкли считать обучение почти автоматическим процессом: прочитал, понял, значит, уже вооружен. Но рынок давно требует другого. Рост разработчика, продакта или руководителя все чаще определяется не количеством потребленного контента, а способностью заметить собственную слепую зону, признать ее без драматургии и перестроить повседневное поведение. И здесь самый неудобный вопрос звучит слишком просто: сколько наших «я это уже знаю» на самом деле означают «я до сих пор этого не делаю»?