Вся правда о зарплатах на рынке ИТ
Всем привет! Меня зовут Татьяна Мельничук. Я — основатель и руководитель IT-рекрутингового агентства Lucky Hunter. К нам обращаются разные клиенты, но всех их объединяет одно: не имея достаточных in-house-ресурсов, клиенты передают задачу по подбору ИТ-профессионалов на аутсорс.
Казалось бы, мы отлично знаем IT-рынок, уже много лет общаемся с кандидатами, понимаем специфику каждой вакансии. Несмотря на это, в момент, когда мы озвучиваем вилку по вакансии, мы сталкиваемся с недоверием со стороны клиентов.
Заказчики ссылаются на аналитики заработных плат из открытых источников, полагая, что мы заведомо повышаем стоимость специалистов, и все для того, чтобы получить более высокое вознаграждение за услугу.
Чтобы уладить сложившееся недоразумение, я бы хотела рассказать вам, почему не стоит ориентироваться на публичные данные о зарплатах на рынке и поделюсь нашими реальными целями в работе.
В чем проблема публично доступной аналитики?
В первую очередь, публичные данные о зарплатах показывают нам среднюю температуру по больнице. Часто не учитывается бэкграунд специалиста, особенности компании, предыдущий опыт и тот факт, что специалисты с рынка всегда стоят дороже, чем внутренние кадры.
Во-вторых, открытые источники не учитывают изменения на рынке. IT-сфера постоянно меняется, и данные из сети не успевают обновляться с такой скоростью. К примеру, за последние полгода отмечаются такие перемены:
- Зарплата в регионах постепенно приравнялась к зарплатам в мегаполисах. Искать специалиста из небольшого города на удаленку на зарплату, меньшую чем в Москве или Петербурге в сегодняшних условиях уже неактуально.
- IT-специалисты неохотно рассматривают предложения от российских компаний. Европа и США всегда привлекали многих IT-специалистов, но сегодня это условие стало таким же топовым, как когда-то удаленная работа.
- Кандидаты, в целом, стали менее открыты к новым предложениям: пандемия заставила пересмотреть приоритеты, и теперь одно из ключевых требований — стабильность и уверенность в завтрашнем дне.
- Особенно трудно переманивать кандидатов в начинающие стартапы, а также в неизвестные компании.
- Востребованность некоторых IT-специалистов значительно выросла, и, следовательно, выросли и зарплатные ожидания. К примеру, это касается Golang и мобильных разработчиков.
И, наконец, в третьих, подумайте, существовали бы специальные исследовательские центры? Предоставляли бы агентства отдельную услугу по HR-аналитике, если бы все было так просто? Нам кажется, что нет.
Что будет, если все-таки довериться аналитике?
- Компания неправильно сформирует профиль кандидата;
- Усложнятся процессы рекрутинга;
- Увеличится срок закрытия вакансии (и, скорее всего ее удастся закрыть только с понижением требований к специалисту).
Мы понимаем, что не каждая компания может позволить себе специалиста за условные 300 тысяч рублей в месяц. Но рекрутинговые компании работают, отталкиваясь от реалий рынка: мы не сможем удовлетворить нереалистичные задачи клиента.
Немного цифр
Я сделала для вас несколько скринов, чтобы наглядно показать, какие зарплаты предлагают открытые источники.
Это скрин взят с «Хабр. Карьеры.» Как мы видим, он показывает, что средняя зарплата Senior Golang разработчика составляет 211 000 рублей. Это не совсем релевантные данные. Golang позиция сейчас у нас самая популярная, и найти хорошего Senior-специалиста, который согласится на зарплату ниже 300 000 рублей, довольно трудно (учитывая, что минимальная вилка, которую мы сообщаем клиенту — 240 000 рублей).
Другой пример — Senior Python разработчик.
Средняя зарплата Python-разработчиков сегодня другая и стартует от 220 000 рублей.
Стоит отметить и выборку: согласно скринам, команде Habr удалось опросить 60 Golang и 57 Python разработчиков. Это совсем небольшое количество анкет, поэтому анализ вряд ли можно назвать точным.
Важно и то, что на сбор данных в среднем уходит полгода, и когда информацию публикуют в открытых источниках, она к этому моменту перестает быть актуальной (в силу специфики и изменчивости IT-рынка).
Несмотря на это, у «Хабр.Карьеры» есть и преимущество: специалисты сами указывают свои зарплаты, и на основании этих данных портал формирует значения.
Другие примеры
Портал Visasam.ru в своей статье о зарплатах программистов предоставил такую таблицу:
Разрыв с реальными цифрами выше и составляет в среднем от 70 000 — 100 000 рублей (для Middle-Senior позиций). Зарплаты на позицию тимлидов значительно дальше от рыночных значений.
Еще один пример: статья Rusbase. Начинается она так:
Эти цифры также не соответствуют рыночным значениям, поэтому на них не следует ориентироваться.
И напоследок — сайт trud.com. На запрос «PHP-программист» в разделе «Зарплаты» сайт показал среднюю зарплату в размере 66 903 рублей. (Аналитика Trud.com очень усреднённая и не позволяет настроить фильтры)
Вывод
Публично доступная аналитика заработных плат не всегда корректно отражает реальность. Не рекомендуем ориентироваться на нее, принимая решения о зарплате.
Будет более полезно, если вы спросите кандидатов напрямую, сколько они хотели бы получать или, если есть возможность, закажите аналитику зарплат в исследовательской компании.
Несколько слов о том, почему стоит доверять IT-рекрутинговым компаниям
Для нас важнее всего — партнерство с клиентом, долгосрочные отношения, построенные на взаимном доверии и уважении. Этот принцип идет вразрез с ведением нечестной политики в отношении клиентов и кандидатов.
По этим причинам мы всегда сообщаем клиенту только актуальную информацию по зарплате, не завышая (и не занижая) рыночные значения.
Буду рада вашим комментариям.
Комментарий недоступен
Сомнительно, но то, что платить _после_ придётся - это понятно. Обычно _после_ появляются деньги на рефакторинг.
Часто после сеньора за 100к проще выкинуть код и написать заново.
Комментарий недоступен
Опыт поколений показал, что взять и переписать приводит к фейлу проекта почти всегда.
А вот изолировать старый код, новые фичи писать отдельно и постепенно переносить старый код, срабатывает почти всегда.
Комментарий недоступен
А мой опыт вполне очевидный: если код писали за 40к в месяц, с вероятностью в 95% его можно выкидывать, если писали за 200к, то с вероятностью 95% код либо вполне хороший, либо идеальный
Как код коррелирует с деньгами. Что-то новое.
Вам не кажется, что есть корреляция между зарплатой и уровнем специалистов и , соответственно, качеством создаваемого ими продукта?
Хотя не всегда, слишком много говорящих голов, но все равно.
Не не кажется. Я считаю код зависит только от скиллов. А уж кто как себя там продает это дело десятое. Видел слабеньких миддлов которые вполне себе говнокодили в крупных компаниях за зп раза в 4 больше чем у головостых сеньеров из регионов.
Я скептически отношусь к идее непризнанных гениев, которые сидят в регионах на копеечной зарплате.
Многие люди не выкупают, что они могут претендовать на куда большую зарплату. А многие по случайности начинают получать выше рынка и начинают считать это нормой. Ну как с зарплатами по 200к.
Так про-то и речь. Просто многие джуны вайтишники уверены что IT это как в армии. Наседел 10000 жопа часов получи лычку pre-middle и 20% к окладу.
зря.
а уж несправедливость оплаты - это не когда непризнанный гений, а когда скажем более талантливый получает 180 а менее талантливый 300 - встречается сплошь и рядом.
проблема в том что измерить талант сложно, нужны активные действия самого специалиста по демонстрации таланта.
Говорили про корреляцию денег и кода, короче слив защитан.
То что вы один раз увидели не значит что так происходит всегда.
Так происходит всегда, на удаленку с регионов ищут дешевых работников, в обратном случае проще нанять человека на месте в офис.
Нет
Плохое качесвто это большой круг. И все низкие з\п внутри него на 99%. 1% оставляем на растущего таланта новичка, но с потенциалом. А вот большая з\п на половину также в дерьмовом коде. 50 на 50 что и из огромные бабки будет черти что.
Ровным счётом - никак. И суперпрофи может создать эпичное говно.
а вот мой опыт говорит о том что если код писали за любую сумму то через год его с вероятностью 95% можно выкидывать:)
т.к. рынок не стоит блин на месте а развивается..
Я работал на проекте который стартовал 6 лет назад, и начинался на .Net Framework 4.5, недавно его успешно на .Net Core перенесли
сочувствую:)
Через пару лет его хочется отрефакторить да времени никак не найдется. А выкидываются варианты не дошедшие до прода бывает. Если дошло то только рефактор без потерь данных делать.
да и из прода выкидывают часто. бизнес процесс поменяли и опа. стал код не нужен и опа.
в таких случаях как раз экономия начальных вложений является выгодной. типа сделали говнокод задешево но т.к. знали что его долго тянуть не надо а просто потом выкинуть - то и норм.
Вы значит не работали в действительно больших проектах
Комментарий недоступен
Мне тоже интересно. Постоянно спрашивают на собесах "какой ваш самый сложный проект". Блядь какая нахуй разница если что в сайте-визитке, что в сбере контроллеры и вьюхи одни и те же.
Все, что вы назвали это вершина айсберга и там в принципе не может быть проблем у любого студента кто хоть раз прочитал хоть один туториал.
Понятие "бизнес требование" для вас наверное ничего не говорящий термин. А проблемы в корпоративных системах как раз в том, что их количество настолько велико, а иногда и качество оставляет желать лучшего. Наложите на это кучу разработчиков которые правили один и тот же код и выйдет, что зачастую ни один разработчик не может быть уверен, что плоправив конкретный ты вы не поставите на непроходимый нехилый счётчик пару тысяч ипотечников которое потом пойдут в суды. Вот поэтому вы не можете выкинуть даже кусочек кода просто так, не то что целую подсистему.
Этим и отличаются сеньеры за 300к рублей которые понимают, что все не так здесь просто, от джунов 30к которые видят только контроллер/вьюху и готовы сейчас же выкинуть все нахрен быстренько переписать все "как надо" и поставить весь сбер раком.
Пока вы будете на вопрос о самом большом проекте рассказывать про контроллер. Дорога к зарплатам в 300к вам увы закрыта.
Я это не рассказываю. Но хз как правильно отвечать на этот вопрос. И я в курсе про принцип Открытости-Закратости и понимаю что выпиливать ничего не надо 100 раз не проверив.)) Для меня эти проекты не сложные потому что я понимаю архитектуру и как их делать, что применять, как тестировать, как разворачивать, словом весь фуллстек. Конечно вопрос в человекочасах, будь они, я бы один и аналог гугла запилил попутно читая книжки. Только вот собеседующие думают что там какая-то магия и супер всё сложно.
ну раз не сложно . вот тебе 30тыс рублей в месяц
Давай, на биткоин переведёшь?
Но вы то явно не за 300K разработчик с такими речами даже на 50шку не тянете. То есть у признаете что для вас норма гад обдежкты изменения пары строк в которых развалят всю систему, а про юнит тесты я так понимаю вы даже не слышали. Короче джун раздувает щечки.
Возьмите к примеру проект на примерно 120 человеколет потраченных на него ресурсов (5 лет на 25 человек). Таких проектов в корпоративной разработке хоть отбавляй. Вы там мало, что сможете выкинуть.
*хитро улыбнулся. Разработка, длившаяся 5 лет - была выкинута целиком и полностью. Чуть поменьше людей, да. Сути не меняет.
Такое тоже бывает. Но по опыту это обычно следствие закрытия/реорганизации бизнес направления и соответственно отказ или переработка каких-то процессов со стороны бизнеса для которых эта система больше не нужна или не подходит по чисто их внутренним причинам никак не связанным с разработкой.
Выкинуть целую бизнес подсистему по решению только ИТ департамента просто потому, что разработчики увидели там плохой код это что-то из параллельной реальности. На своем опыте сталкивался только с ситуациями когда строили новую платформу при параллельном использовании старой при этом старая активно дорабатывалась. Отказывались постепенно от кусков старой. Бизнесу поверьте тоже не просто даются такие перескоки - как минимум переобучение людей это довольно затратная процедура.
Комментарий недоступен
он имеет ввиду что в проекте такого размера очень часто бывает что видишь сходу очевидную дурь, полную. типа выкинуть и все. начинаешь разбираться - оказывается это следствие двух противоречивых бизнес требований которые никак нельзя разрулить а программисты вынуждены были сделать и ни выкинуть ни рефакторить нельзя.
наверное есть и проекты где есть откровенно плохие моменты которые бесспорно можно выкинуть, но я вот проектов первого вида (как выше описал) встречал больше чем второго.
Ну как минимум от 10 разработчиков, 2 пары тестировщиков, дев опс и тд
Комментарий недоступен
там два момента есть.
1 это конечно как вы сказали невозможность оценить разницу между плохим и хорошим спецом (любой владелец бизнеса скажет ну что он в 5 что ли раз хуже) ну и конечно невозможность в принципе измерить скилл. типа а что такое скилл вообще, что такое хороший код, одному хороший одному плохой. я ни разу не видел кода который бы все программисты назвали хорошим. то есть это даже для разработчиков сложная задача отличить хорошего от плохого а так то вообще лучше забыть.
2. более тонкий момент с точки зрения бизнеса такой что продукт надо делать как можно дешевле т.к. потом его может вообще придется выкинуть, а вот если он будет денег приносить то можно и денег потратить на его переделку. я такие решения принимал - типа сознательно делал проект в виде прототипа т.к. нужен был дешевый а если он не пойдет так и все равно выкидывать.
то есть для бизнеса деньги имеют разную стоимость. деньги потраченные на непонятно работающий ли проект изначально стоят больше чем деньги, потраченные на переделку этого проекта взятые из его прибыли. даже если вторые деньги в цифрах в 10 раз больше.
ну вот как пример.
100 тысяч долларов для цукерберга на разработку фейсбук в 2004 году были деньгами с большой буквы. а в 2020 на поддержку фейсбука 100 тыс долларов это наверное бюджет одной минуты работы.
в случае фейсбука получается окупился бы любой говнокод т.к. после того как он стал успешным его и так наверное раз 10 переписали уже полностью.
то есть до того как продукт выстрелил и принес прибыль деньги потраченные на него это стоят нам дорого т.к. мы их потенциально выкидываем в помойку (не знаем еще как все будет). это "плохие" расходы.
а деньги, потраченные из прибыли уже выстрелившего проекта это вложения в работающий прибыльный продукт чтобы он лучше работал - это для нас понятные и "хорошие" расходы.
поэтому на стадии проверки гипотезы продукта на нем можно экономить, а когда он прибыльный тратить бОльшую сумму на устранение технического долга.
хотя с точки зрения бухгалтерии выгоднее было бы вложить больше денег изначально, тогда на технический долг не пришлось бы тратить в 10 раз больше. (но для этого нужна уверенность, что проект пойдет).
На апворке это вечная история освоили бюджеты и ничерта не сделали, процентов 90% таких "стартапов"
Как туда трудоустроиться? :)
в гугле upwork наберите и устраивайтесь
Регистрируйтесь и работайте,я там 5 лет работаю, ни разу не пожалел
Комментарий недоступен
первый год было непросто, дальше уже проще