«Это бесконечный путь, как у самурая: нет цели, только путь». Николай Алименков о том, кто такой IT-консультант и можно ли быть экспертом во всем

Николай Алименков — независимый IT-консультант в XP Injection с более чем 17-летним опытом разработки. Его задача как консультанта — находить проблемы в компании, будь то стартап или международный банк со множеством филиалов, и решать их. Запустить продукт, исправить архитектуру, выстроить процессы — все это зона ответственности консультанта со стороны.

Мы поговорили с Николаем о том, почему он выбрал такой путь для себя, в чем плюсы и минусы работы IT-консультанта и зачем переходить от глубины знаний к широте.

👉🏼Не забывайте подписываться на наш YouTube-канал, чтобы смотреть полные версии интервью

«Самое прекрасное и ужасное в этой работе то, что ты не знаешь, что будешь делать». О том, почему стал IT-консультантом

Разработчик для меня — это состояние души. Поэтому, в какой бы роли я не выступал, все равно продолжаю быть разработчиком. Это значит, что хотя бы минимально, но я пишу код. Именно ради этого я в свое время пришел в IT. Ведь раньше мы приходили не ради высоких зарплат, а чтобы заниматься реально интересными вещами: решали проблему бизнеса, инженерную проблему. Это то, что мотивирует оставаться программистом в душе и на практике.

Когда я только начинал работать, у меня не было плана «Что будет дальше». Я начинал как разработчик в белорусской компании, где весьма интенсивно развивался и дорос до техлида. Затем попал в Украину. Здесь была серьезная компания, так что я приехал на downgrade. Мне сказали: «Начнешь с Senior Developer, а потом посмотрим». Я быстренько стал Tech Lead.

Был вариант пойти в менеджмент. Но он мне не очень импонировал. Есть такой анекдот: попугай научился говорить «Ну что там?», и его повысили до проджект-менеджера. Это совершенно неблагодарная специальность, потому что непонятно, что за ней скрывается. В одних ситуациях Project Manager — это классный инженер и менеджер, благодаря которому все работает. А в других — это человек, который составляет какие-то планы, придумывает KPI, потому что ему нечем заняться.

Был еще вариант пойти в архитекторы или развиваться в СТО. Но туда карьерными шажками долго добираться. Поэтому я выбрал Tech Lead. Ты общаешься с бизнесом, понимаешь его потребности, организовываешь работу команды, delivery и обязательно участвуешь в разработке. Мне это всегда нравилось.

Получается, техлид — главный человек, но в маленьком масштабе. Невозможно быть техлидом на 100 команд.

Но я подумал, что было бы прикольно приходить в компании, которым нужно помочь решить проблему, и решить ее

То есть быть человеком с опытом, знаниями о том, как организовать весь процесс delivery. Этим и занимается консультант.

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

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

Консультанты работают по-разному. У меня почасовой формат, знаю многих, кто работает по дням, то есть, неважно, сколько часов консультанта ты выел — заплатишь за весь день. Чаще всего это так. Мне удобнее так, потому что иногда несколько клиентов в один день пересекаются. И неудобно и тем, и другим выставлять общий счёт. Они спросят, например, почему я в такое-то время был недоступен для созвона. Поэтому я честно работаю по часам, хотя это не очень комфортно с точки зрения внутреннего трекинга.

«Если я не понимаю, что происходит, есть ребята, которые берут часть работы на себя». О том, почему IT-консультант подключает других специалистов

XP Injection — это группа энтузиастов. В основном все еще занимаются чем-то своим: кто-то на позиции архитектора, у кого-то своя компания и так далее. Этих людей я привлекаю по тем направлениям, по которым у меня нет, например, широты экспертизы.

Допустим, .NET. Я им не занимаюсь принципиально. На протяжении всей карьеры убеждаюсь, что связываться с технологиями Microsoft бесперспективно. Но есть клиенты, которые приходят именно с этим стеком. Мы с ними можем налаживать Continuous Delivery, строим команды, а ещё им нужна технологическая помощь — сделать ревью дизайн-решения, выбрать фреймворк. И так как я вообще не понимаю, что происходит в .NET, есть ребята, которые берут эту часть на себя.

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

Или, например, мобильное приложение для «Райффайзена», с которым я работаю уже полтора года. Там есть задачи по старту MVP. Этот MVP надо организовать с процессной точки зрения, архитектурной и продуктовой. Сейчас приложение для банка делает вендор, и такая проблема у многих. По какой-то причине так было принято на рынке. Я сотрудничал с несколькими банками, и все они просто делегировали написание больших кусков или систем вендору. Свой IT — это была либо поддержка core-систем, либо development, но совсем чуть-чуть и совершенно не на современном стеке. Зачем кормить вендора и сидеть у него на крючке? Этот вопрос давно витал в воздухе.

И теперь все банки пытаются изменить систему: «Пумб», «Альфа», «Райффайзен». Они нанимают экспертизу, строят свои команды разработки, продукты. Это дает больше гибкости, потому что можно полноценно рулить продуктом, экспериментировать. То, что казалось невероятным в продукте вендора, в своём продукте становится возможным.

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

«Рыба гниет с головы». О том, кто виноват в проблемах компании

Если у компании не все гладко, то обычно проблема не в человеке. Консультант не приходит и не говорит: «Увольте тимлида, он ничего не понимает». Проблема обычно шире. Ведь если бы в организации, где все хорошо, не справлялся только тимлид, он бы там не работал.

Рыба гниет с головы, поэтому, вероятнее всего, изначальная проблема в руководстве. Компании могут идти по ложному пути несознательно. Например, они «выстрелили», но пропустили период роста: не увидели разницы между менеджментом в три человека, где друзья делают стартап, и в сто человек.

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

Бывает, что классный руководитель доверился не тем людям. Например, положился на знакомых, которые не очень хорошо разбираются в вопросе. Некоторые верят, что если они в хороших отношениях с человеком, то вряд ли в работе он будет плохой. Люди доверяют и идут по пути, который гробит их компанию.

Бывают ситуации, когда проблема исключительно в архитектуре. Когда паттерны одни и те же. Люди начинали с определенного архитектурного решения, когда компания была маленькой. Затем росли, но вместо того, чтобы поменять архитектурное решение, укладывали его костылями и подпорками. Времени нет, деньги текут, зачем что-то менять? Откладывали на следующий сезон, квартал, год и в итоге зашли в тупик. Тогда нужно предложить такие изменения, которые помогли бы и цели достичь, и при этом не развалили компанию. Нужно минимизировать риски. Нельзя прийти в фирму, где 20 Java-разработчиков, и сказать, что все нужно написать на Go. Это слишком радикально.

«Идеальный вариант сотрудничества: консультант выкатывает solution, а компания реализовывает его сама». Об этапах работы IT-консультанта

Идеальный вариант сотрудничества, когда консультант приходит, знакомится с командой, проводит микроаудит, выкатывает solution, а компания говорит, что возьмется реализовывать его сама и подключит консультанта только в некоторых моментах.

Ознакомительная встреча компании ничего не стоит. Мы встречаемся для изучения проблематики. И на этом этапе становится ясно, готовы ли мы работать друг с другом. После встречи я провожу микроаудит. Это уже про деньги, ведь, по сути, после него компания получает решение проблемы. Аудит занимает до двух полных рабочих дней. По итогу ты предоставляешь описание проблематики, которую обнаружил по наводкам сотрудников, и предложение, как все решить. Клиенты смотрят и говорят: «Бомба, идем дальше». Ну или не идем.

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

Если с компанией все же решаем поработать, то обычно процесс состоит из нескольких этапов.

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

Второй этап — не распыляться и сделать «один успешный успех». Нужна быстрая победа. Она покажет, как будет выглядеть жизнь по-новому. Тогда у людей появится не просто теоретический маяк, а конкретный кейс. Например, в «Райффайзене» мы выкатили новую платформу разработки. Это Microservices, Kubernetes, полностью новый технологический стек, всё open source, CI/CD pipeline и так далее. Мы перевели кусочек одного из направлений на эти рельсы, собрали несколько фича-команд с новым технологическим стеком и показали, какова может быть скорость разработчика в этом случае. Как было раньше, можно было никому не доказывать, все прекрасно знали, что разработка могла занимать уйму времени и никогда не увидеть мир. А здесь каждые две недели продакшн.

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

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

«У стартапа и банка из общего только проблемы». Как выглядит типичный заказчик консалтинга

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

«Я дважды в день читаю блоги, подмечаю интересное и заношу в заметки». О том, почему консультанту важна широта знаний

IT-консультант — это про широту знаний. Почему так, можно объяснить на примере Solution-архитектора. Это тот, кто переключается в определенный момент с глубины знаний на широту, ведь для него она важнее. Представим, специалист работает на Go, больше ни черта не знает, но Go знает божественно. Он любую задачу будет решать, применяя этот язык. А это значит, что как Solution Architect он уже не очень удачный. Ведь есть ML, что-то на Python лучше делать, a может, нa Java или на Kotlin. Если у тебя нет объёма знаний, ты не можешь этого.

Разрабатывать широту означает читать новости, слушать конференции, общаться в разных сообществах. Например, идешь на Data-ориентированную конференцию и там узнаешь про Python. А потом сможешь разобраться в нем детальнее. Сейчас уже нет, но когда-то я вёл что-то вроде Excel-таблички с разными заметками и технологиями. Просто чтобы не забыть о них. Потому что, когда принимаешь решение, оно не появляется в голове моментально. И может случиться так, что по итогу решение, которое ты предложил, могло быть круче, а ты просто забыл о том, что уже знал и видел.

У меня нет определенного дня, когда я собираю все, что интересно и ново, с утра до вечера. Я регулярно дважды в день читаю технологические блоги, подмечаю что-то интересное и заношу в свои заметки. Или смотрю видео с конференции — тоже фиксирую нужное. Мне проще еще потому, что я прихожу к клиентам и они показывают мне свою архитектуру. Когда вижу что-то новое, спрашиваю, что это. Мне объясняют, и я записываю.

Психотерапевты говорят, что все из детства. У нас точно так же — все со старта карьеры

Когда я пришел в белорусскую компанию, ей нужно было масштабироваться, соответственно, максимально быстро меня развить, чтобы я стал следующим тимлидом и отвечал за кусочек работы. В компании разработка была all-in-one, ведь тогда не было так, как сейчас: ты фронтендер и только. Или ты только тестировщик. Тогда ты и другие делали все.

В итоге получалось, что человек, который этим руководил, то есть Team Lead, Tech Lead, отвечал за все: за CI/CD, качество, требования от команды разработки, где мог быть хаос. У нас появилось множество инженерных практик, мы программировали парами, писали тесты, начали с клиентами работать более ориентированно на продукт, несмотря на то, что это большой enterprise. Брали ТЗ на 300–400 страниц, где все четко расписано до скрина и нет никаких вариаций. Знали, что все не успеем, потому что это невозможно. И делили по приоритетам, раскладывали в бэклог. Всему этому приходилось учиться. А когда ты это сделал раз, второй, третий, уже вроде и умеешь с этим работать. И дальше накидываешь новые практики, подходы.

Но у такого формата есть и обратная сторона. Ты только смотрел на одно, как уже смотришь совсем на другое, нужно картинки очень быстро менять местами. Получается, когда фокусируешься на широте, уходишь с глубины. Это значит, что ты хорошо можешь знать максимум что-то одно, например кусочек в Java. И все равно язык обновляется, поэтому, чтобы понять новые фичи, стоит периодически получать хендзон-опыт. Но иметь его во всем просто нереально.

GitLab, Slack, Zoom, Java, Python и JS. Какой тулсет сегодня оптимален

Запускай я проект сейчас, абстрактный, в вакууме, тулсет выглядел бы следующим образом.

Код хранил бы на GitLab. Bitbucket сразу отсею, мне кажется, что они вообще не понимают, что происходит на рынке, и делают трешак. А у GitHub как-то не энтерпрайзненько получается, в отличие от GitLab.

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

Как Messenger для общения команды мне больше нравится Slack. Но нужно понять нужды, потому что, как только к Slack появляются дополнительные требования по security, управлению учетками, кастомизации и так далее, всё рассыпается. Если таких требований нет, я бы выбрал Slack + Zoom. Мне в Slack не хватает одной фичи, как у Telegram — отложенное сообщение, чтобы оно уходило, будто я его отправил в 7 утра.

Если говорить об усредненном стеке, без привязки к конкретному проекту, то в Java хорошо быстро прототипировать. Есть миллион вариантов, тот же JHipster. Ты практически получаешь коробочку для быстрого прототипирования. И прекрасно то, что после прототипирования, когда ты накидал сущности, соединил их между собой, потом отключаешься и получаешь просто код, с которым дальше спокойно работаешь. Ровно так же Spring Boot развился. Собираешь как конструктор. Поэтому я свято верю, что это один из самых удобных стеков для прототипирования.

Python занял хорошую нишу в ML. Чтобы не иметь сильное расхождение по вебу и ML, есть компании, которые переводят бэкенд на Python. Это новая реинкарнация: вроде от этого начали чуть отходить — и опять бум пайтонистов случился.

Go занял своё место в инфраструктуре. На этом языке делают для Kubernetes, Operator, практически весь тулинг. Потому что он компактнее, больше ориентирован на это. И появляется вторая ниша для него — это микросервисы или наносервисы.

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

«Моя задача — быстрее уйти от компании, но при этом помочь решить проблему». Почему к IT-консультанту относятся настороженно

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

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

Меня не берут в штат, не говорят «наш сотрудник», а представляют как внешнего консультанта. И отношение ко мне другое

Многие относятся настороженно. И, наверное, эта часть работы сложная и неприятная, потому что она упирается в человеческий фактор и может доставить много проблем. Но я и не шоколадка, чтобы меня любили.

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

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

Иногда думаю: блин, да пошло оно всё на фиг, сидел бы сейчас где-то СТО спокойненько. Был бы кабинет, фановые мероприятия, параллельно делал бы прикольный продукт. Но не было бы, наверное, так интересно. Разве из-за этого не соглашаюсь на позицию в компании.

В штат зовут те клиенты, с которыми у консультанта складываются хорошие отношения. Можно и самому намекнуть, мол, мне так нравится у вас. И вам тут же что-то предложат. Вопрос только, какую позицию. Это выбор на инвестицию в будущее. Допустим, enterprise-организация предлагает специалисту позицию В-1, то есть на уровень ниже C-level. Это значит, что он уже на верхушке пирамидки. Если со временем, например, позиция СIO освобождается, очевидно, претендента будут рассматривать из ближайшего круга, ведь enterprise-организации славятся тем, что редко на ключевые должности берут людей с улицы. Обычно это доморощенные сотрудники, которые там работают уже 10–15 лет.

Но даже на предложенной позиции ты можешь иметь зарплату Х, бонусы Y, бонусы, накапливающиеся за выслугу лет, Z. И из этих трех вещей будет состоять доход. Это про перспективу и надежность. А когда работаешь как консультант — это скорее про деньги здесь и сейчас. Но в итоге получается, что я ноунейм. В фильмах, когда идут титры, вспоминают каскадёров, автора идеи. Они всегда в конце отдельным списком — и консультант идет так же.

С точки зрения карьеры работая консультантом я делаю себе плохо. Должность — это лычечка, потому что люди понимают, что ты идёшь дальше по карьерной лестнице. Для чего должности нужны? Чтобы обеспечить себе безбедное существование в определённой перспективе, потому что одно дело — писать код в 20 лет, другое дело — писать код в 30, третье — писать в 40 и совсем четвёртое — в 50.

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

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

Второе — это соблюдение work-life balance. Не стоит пытаться переделать все дела в мире, всегда появляются только новые и самые приоритетные. Нужно пытаться контролировать своё время: не забивать на то же хобби. У меня всегда есть баланс между спортом, хобби, работой и прочим. Иногда он сбивается, особенно когда есть сложная интересная задача, где нужно сделать сейчас больше, чем хочется. Но потом я возвращаюсь к балансу.

Хотя, наверное, нет такого человека, который бы проработал 10 лет в IT и не задумывался о том, а не уйти ли ему из сферы вообще. Все, с кем я говорил на эту тему, хоть раз размышляли: «А что дальше?». Кто-то не видит, куда развиваться, кому-то кажется, что он будет просто сидеть и делать одно и то же.

Предполагаю, через пять лет случится одно из трех.

1. Первое — я буду всё ещё на коне бежать туда, куда сейчас бегу. Это бесконечный путь, как у самурая: нет цели, только путь. Ты просто бежишь, и один за другим появляются новые клиенты, более масштабные, международные. Я со столькими компаниями познакомился и поработал, а раньше и предположить не мог, что меня когда-то к ним подпустят.
2. Либо я всё-таки приму предложение какой-нибудь из компаний и зависну там делать крутой продукт. Мне кажется, это может случиться, если это будет продукт, в который я буду искренне верить, буду убежден, что он действительно крутой, что то, что я делаю, — это миссия.
3. И третий вариант, очевидно, просто уйти из IТ и заняться чем-то прикольным другим. Мне всегда нравился ресторанный бизнес. Но это сложная сфера.

«На IT-рынке действует закон Дикого Запада». О том, почему разработчики получают и будут получать больше, чем заслуживают

Современный IT-рынок у нас регулируется искусственным спросом и предложением. Под искусственным я подразумеваю, что на рынке и вообще в IТ нет evaluation-специалистов. Нет такого, что посмотрел на CV, где указаны звездочки напротив скилов, и это были те звёздочки, которые есть на самом деле. В итоге получается, пока не поговорил со специалистом, неизвестно, что он из себя представляет.

Плюс к этому — идет волна спроса из-за коронавируса. Есть общая тенденция: в кризис нужно либо вкладывать, либо выжидать. Те, кто вкладывают, имеют конкурентное преимущество. Поэтому многие начали трансформации в кризис, а это означает еще больший спрос на кадры. У нас коронавирус даже позитивно сыграл для айтишников. Но людей-то больше не становится. Волатильность появления нового человека в IТ — это год, он не может просто взяться за месяц. Поэтому начинают прочесывать весь рынок. И у многих создается ощущение, что, наверное, все эти специалисты суперуспешные, что всем платят по 7–10 тысяч долларов. Это не всегда так. Хотя у нас на рынке действует закон Дикого Запада. Чистый закон спроса-предложения. Любую зарплату, которую бы не назвали — 10, 12, 15 — я верю, что найдется тот, кто её попросит, и найдётся тот, кто даст.

Компании будут вынуждены давать неадекватные зарплаты. В абсолютных цифрах это пик, которого еще не было. И я не думаю, что со временем эти зарплаты будут понижать. Они останутся такими, но будут люди, несправедливо получающие много денег. Ты можешь попасть к человеку, который действительно адекватно оценит и даст те деньги, которых специалист стоит. А будет ситуация, когда кому-то нужно будет закрыть очередной горящий проект, и им не важно, сколько денег дать, потому что эти расходы спишутся на клиента. Они просто объяснят стоимость ситуацией на рынке. Я видел, насколько неграмотно проводят собеседования во многих компаниях, где берут тех, чей уровень недостаточен для занимаемой позиции. Но дальше такой специалист уже отталкивается от своей зарплаты и создает на рынке хайп. Если он получил 7К, теперь вряд ли в следующей компании будет выставлять рейт ниже.

Но по меркам Штатов это все равно ничто. Нанимать здесь человека на 7К с учетом 5% налога — смешно. Можно еще до десятки спокойно поднимать. Сейчас заграничные компании решили напрямую нанимать людей в Украине. Из-за этого уже появились прослоечки — люди, которые оформляют сотрудника напрямую или помогают в этом. Они тоже добавили плюс к стоимости специалиста.

👉🏼Подписчики нашего YouTube смотрели это интервью ещё в начале сентября. Предлагаем подписаться и вам