Послушали недавно подкаст коллег про софт-скиллы и менторство. Тема, про которую все всё знают: коммуникация важна, делиться знаниями полезно, менторство развивает. Вроде уже много раз про это говорили.
Но фишка вот в чем: стоит перестать об этом говорить, и через полгода снова видишь команды, где разработчики не разговаривают друг с другом, сеньоры чахнут над своими уникальными знаниями, а джуны боятся задавать вопросы. Как будто коллективная амнезия.
В разговоре было много важных мыслей. Решили собрать все это в одной статье, добавить практических советов и напомнить: софт-скиллы (и менторство) — это не дополнительная фича к основной работе программиста. Это обязательная часть профессии. И если кто-то до сих пор думает, что можно просто хорошо кодить и больше ни с кем не общаться, — у нас для вас плохие новости.
Если хотите услышать оригинальный разговор со всеми деталями и историями — слушайте (и смотрите) подкаст «Техно.Логично». Там час живого обсуждения, которое стоит послушать.
Эволюция от кодера к спикеру
Можно считать, что софт-скиллы появились, когда люди поняли, что в одиночку мамонта не завалить. Нужно договориться, распределить роли, скоординироваться. Кто-то копает яму, кто-то делает копья, кто-то выслеживает добычу. А еще нужно выменять камни у соседнего племени, потому что своих нет. И найти охотников, которые не сбегут при виде мамонта. По сути, нужен проджект-менеджер уровня бог. Договорились, завалили, накормили племя. Выжили те, кто умел кооперироваться.
Сегодня вместо мамонтов — сложные системы, которые один человек физически не способен удержать в голове. Но принцип тот же: нужно уметь договариваться, делиться знаниями, координировать усилия.
Сидишь в своей каморке, пишешь код на любимом языке, никого не трогаешь. Идеальная жизнь интроверта. Но потом внезапно оказывается, что мир гораздо шире, а карьера упирается в потолок.
Проблема в том, что индустрия изменилась. Раньше узким местом был разработчик — не хватало рук, чтобы писать код. Теперь узкое место переместилось в коммуникацию. Бизнес не понимает разработку, разработка не понимает бизнес, фронт с бэком общаются через проектного менеджера как через переводчика. И все страдают.
Мы в Газпромбанке считаем так: сеньор — это не только про умение писать сложный код. Это про способность делать команду сильнее через передачу знаний. Эксперт, который держит всю экспертизу в голове и не делится опытом, — риск. Если он уйдет в отпуск? Сменит работу? Все его знания исчезнут вместе с ним.
Вопрос не только в пользе для компании. Многие не понимают простого факта: пока ты незаменим на текущей позиции, ты там и останешься. Тебя сложно повысить до архитектора или тимлида, потому что встает вопрос о передаче текущих задач. Ты становишься заложником собственной незаменимости: чем лучше ты делаешь свою работу в одиночку, тем меньше у тебя шансов вырасти.
Интроверты, выдохните
Многие считают, что если ты интроверт, то софт-скиллы — это не про тебя. Все эти выступления, нетворкинг, менторство — для экстравертов, которые обожают общаться. А интроверту лучше сидеть тихо в углу и писать код. Так вот, это неправда.
Софт-скиллы — это не про экстравертность. Есть такой тип людей, которых все боятся. Приходишь к такому с идеей, а в ответ получаешь набор неудобных вопросов и чувствуешь себя идиотом. Но когда присмотришься внимательнее, оказывается: человек просто не умеет работать с недодуманными идеями. Ну, вот так его воспитали.
Зато когда приходишь с четко сформулированной задачей и объясняешь, зачем это нужно, случается магия. Злобный сеньор начинает предлагать улучшения, додумывать детали. Секрет простой: он заговорил, потому что понял цель. Энергия высвобождается, когда есть смысл.
Мы видели самых хардкорных интровертов, которые за всю конференцию говорят только на сцене. Но если они знают, что их рассказ поможет кому-то перестать наступать на те же грабли, — выходят и рассказывают. Потому что — смысл.
Главное для интроверта — найти свое «зачем». Зачем делиться знаниями? Зачем выступать? Зачем быть ментором? Когда ответ найден, все остальное становится техническими деталями. Да, придется потратить больше энергии на коммуникацию, чем экстраверту. Но если цель ясна и важна — энергия найдется.
Публичные выступления — тайное оружие карьерного роста
Деврелы не просто так тащат всех выступать на митапах и конференциях. За каждым деврелом стоит CTO: заставь их готовить доклады, выводи на сцену, пусть рассказывают.
Подготовка к выступлению заставляет человека делать то, чему сложно научить напрямую: осмыслять процессы, структурировать опыт, находить понятные объяснения сложным вещам. Ты не можешь выйти на сцену и просто показать код — нужно объяснить контекст, проблему, решение, выводы. Нужно думать о слушателях, а не только о коде.
И разработчик, который считал своим потолком позицию индивидуального контрибьютора («пишу код в уголке, не трогайте меня»), вдруг понимает: на его знания есть запрос. Люди хотят учиться, хотят понимать, хотят избежать его ошибок.
Выше мы уже писали, но можно и повторить: эксперт, который не делится знаниями, становится заложником собственной незаменимости. Публичные выступления — это способ разорвать этот замкнутый круг. Ты учишь других, освобождаешь себя для новых задач, открываешь путь для карьерного роста.
Когда человек научился доносить мысли до аудитории, структурировать информацию, отвечать на вопросы — это практически готовый руководитель. Осталось добавить немного менеджерских методологий, и все. Барьер перед началом движения вверх разрушен.
Менторство: инвестиция, которая окупается
Все слышали про менторов у великих: Билл Гейтс, Джобс, Цукерберг — все проходили через менторские отношения. Зачем это обычному разработчику?
Начнем с ментора. Что он получает? Во-первых, это защита от экзистенциального кризиса. Когда в 40 лет просыпаешься с мыслью: «А что я вообще сделал в жизни?», можно оглянуться и увидеть выросших специалистов, которым ты помог. Это твой вклад в индустрию, твои профессиональные дети.
Во-вторых, актуализация. Менти приносит свежий взгляд, новые практики, вопросы, которые заставляют переосмыслить привычные подходы. Ментор учит, но и сам учится, — это двусторонний процесс.
В-третьих, создание профессиональной сети. Люди, с которыми ты работал как ментор, потом оказываются в разных компаниях и проектах. Но связь остается, общий контекст сохраняется. Это бесценно для карьеры и профессионального развития.
Для менти выгода очевидна: быстрый профессиональный рост, доступ к накопленному опыту, навигация в сложных ситуациях. Но главное — возможность учиться на чужих ошибках, а не набивать все шишки самостоятельно.
Война поколений, которой можно избежать
Говорить и слушать — это одно. Но что делать, когда собеседник смотрит на мир совершенно иначе? В современных командах работают люди с разницей в возрасте в 20–30 лет. У каждого поколения свои привычки, свой опыт, свое понимание «как правильно работать».
В командах часто встречаются люди из разных поколений. Молодые выросли в цифре, им проще написать, чем подойти поговорить, а старшее поколение привыкло решать вопросы лицом к лицу, за чашкой кофе.
Добавляем молодого разработчика к опытной команде. Старшие начинают проверять его на прочность, новичок защищается или замыкается. Вместо продуктивной работы начинаются, как в том анекдоте, попытки выяснить, на чем сломается «японская пила».
Что делать? Во-первых, не разделять по возрасту. Смешанные команды работают эффективнее, когда люди учатся друг у друга. Во-вторых, на старте обозначить правила игры. Собрать команду и честно обсудить: да, мы привыкли работать по-разному. Кто-то предпочитает личные встречи, кто-то — асинхронную переписку. Кто-то сразу доверяет, кто-то сначала проверяет. Признать эти различия вслух — уже половина решения.
Назначьте пары для онбординга, где опытный разработчик помогает новичку не только с кодом, но и с пониманием культуры команды. Введите регулярные one-to-one между людьми разных поколений — не для контроля, а для обмена опытом. Создайте общие ритуалы, которые устраивают всех: например, онлайн-стендапы для тех, кто любит созвоны, но раз в неделю — живая встреча.
Главное — не допустить ситуации, когда команде становится интереснее выяснять, кто круче, чем решать задачи. Если видите признаки холодной войны — вмешивайтесь сразу. Не ждите, пока само рассосется. Не рассосется.
Сколько менти может быть у одного ментора
Менторство бывает формальным и неформальным, и от этого зависит масштаб.
Формальное менторство — это когда компания официально назначает наставника новому сотруднику или джуну. Есть план встреч, есть цели, есть метрики успеха. Новичок получает выделенного человека, который помогает влиться в команду, разобраться в процессах, понять кодовую базу.
Это выгодно всем: новичок быстрее выходит на продуктивность и не тонет в неизвестности первых недель. Ментор прокачивает навыки объяснения и структурирования знаний, учится смотреть на привычные вещи свежим взглядом. Компания получает эффективного сотрудника быстрее и с меньшими рисками.
Для такой плотной работы у одного ментора может быть двое-трое менти. Если больше — размывается внимание, падает качество. Регулярные встречи, code review, ответы на вопросы, помощь с задачами… Все это требует времени и ментальных ресурсов. Перегрузишь ментора — получишь формальную отписку вместо реального развития людей.
Неформальное менторство — совсем другая история. Тут нет ограничений на количество, потому что нет обязательств по регулярности. Это может быть десятиминутный разговор в коридоре, который дает инсайт для решения задачи, над которой человек страдал неделю. Две чашки кофе — и пазл складывается. Или наоборот — месяцы периодических консультаций по сложным вопросам.
В «Яндексе» был пример ментора восьмидесятого уровня — Сегалович. Двери его кабинета были всегда открыты, любой мог зайти с вопросом и уйти с планом. Множество людей потом вспоминали эти короткие разговоры как поворотные моменты. Формально он не был ничьим ментором, но неформально повлиял на карьеры множества специалистов.
Когда пора расставаться
Менторские отношения не вечны, и это нормально. Вот признаки, что пора заканчивать: менти получил все необходимое и готов двигаться дальше или даже перерос ментора в каких-то аспектах — тоже бывает; изменился фокус развития, появились новые цели, для которых нужен другой опыт.
Главное — честно поговорить. Никаких обид и недосказанности. Формальное менторство завершается формально: подводите итоги, обсуждаете дальнейший путь развития, передаете эстафету.
Неформальное может трансформироваться в редкие консультации. Раз в год написать в «Телеграме» с вопросом, получить ответ — и до следующего раза. Многие профессиональные связи так и живут: можно не общаться годами, но при встрече продолжить с того же места.
Практические шаги
Если вы джун или мидл
Не бойтесь задавать вопросы. Нормально не знать, как устроена половина кодовой базы. Нормально не понимать, почему архитектура именно такая. Старшие коллеги помнят себя на вашем месте, они проходили через то же самое. Если в компании есть система менторства, используйте ее на полную. Если нет, найдите человека, чей код вам нравится, и спрашивайте. Большинство разработчиков любят объяснять то, в чем хорошо разбираются.
Если вы сеньор или просто опытный разработчик
Если в компании нет формальной системы менторства, но к вам приходят джуны с вопросами, — уделите им время. Пять минут на объяснение архитектурного решения, десять минут на code review — это инвестиция в будущее. Как уже говорилось, обучая других, вы освобождаете себя для роста.
Для всех
Отвечайте на технические вопросы развернуто. Не просто кидайте ссылку на документацию — объясните контекст, расскажите про подводные камни. Это займет на пару минут больше, но создаст вам репутацию человека, к которому можно обратиться.
Предложите помощь новому сотруднику. Покажите, где что лежит в репозитории, какие есть неочевидные особенности сборки, к кому идти с инфраструктурными вопросами. Помните: вы тоже когда-то были новичком, и кто-то помог вам.
Почему это важно сейчас
Код живет недолго. Даже очень хороший код через несколько лет перепишут или выкинут. Мобильные приложения обновляются каждые полгода, бэкенд переписывают при смене стека.
Но люди, которых вы научили, останутся в индустрии надолго. Знания, которыми поделились, будут передаваться дальше. Культура, которую создали в команде, будет жить годами.
Софт-скиллы — это не альтернатива техническим навыкам. Это их усилитель. В одиночку сложную систему не построишь — нужно уметь договариваться, объяснять, учить и учиться.
Мир разработки усложняется. Системы становятся больше, команды — распределеннее, задачи — комплекснее. Никто не может держать в голове все. Нужно делиться знаниями, иначе просто не справимся.
Комментарии