Что такое рейт в зарплате
Опубликовано: 17.09.2024
Пока есть вдохновение, еще пост про Штаты. На этот раз тема рейтов. Одна из самых интересных тем для обсуждения. В нашей поездке по Штатам в ноябре прошлого года мы получили много интересных инсайтов и лучше поняли, как именно покупают американцы. Думаю, многие знают, что в США на местном рынке рейты 100-150$ / час. на разработку. Модные технологии типа blockchain или machine learning могут стоить и выше, 150-250$ / час. Но на самом деле рынок намного сложнее и значительно более важный вопрос - по чем можем продавать именно вы.
На рейт влияют две группы факторов: внешние, которые не зависят от нас и внутренние, которые касаются компании.
Внешние факторы:
1. Сам рынок, это ключевой внешний фактор. США - огромная страна с разным уровнем развития и разными рейтами в каждом из штатов. Я прикрепил статистику зарплат с двух разных источников, которая отлично это иллюстрирует. Разница может быть в 2 раза (!) от самых богатых штатов к самым бедным. Но это еще не значит, что рейты в 2 раза отличаются) В Штатах очень развита трудовая миграция, поэтому девам ничего не мешает уехать с бедного штата в богатый. Получается, что зарплата девелопера в богатых штатах может доходить до 70-80 долл. в час. Накидываем сюда накладные расходы и маржу, вот и получаются рейты в 100-150$ / час.
2. Соседние страны. Это Мексика, Канада и Россия. С РФ все понятно, в свете последних события ситуация с российским рынком довольно сложная и с Россией не хотят работать. Это на уровне ментальности, поэтому россияне открывают компании в США. Но и тут все не просто у них, бывают отказы в регистрации, открытии счета, оплаты на российские счета. Потому Россию я вообще не буду учитывать. Мексика - рейты для США у них от 40$ / час и выше. Я общался с мексиканскими предпринимателями в Штатах лично. Все благодаря тому, что на севере Мексике достаточное количество девелоперов знают английский, один часовой пояс и местами схожая ментальность. Еще есть Канада, в которую очень активно аутсорсят многие американские компании. На местном рынке в Канаде рейты - 50-60$ долларов США в час. Опять же, я недавно был в Канаде и тоже лично общался с канадцами, да и вообще у меня там много друзей. То есть для американцев - Канада тоже ключевая аутсорс страна с рейтами в 2-3 раза меньше, чем на местном рынке, а также с отличным английским, одним часовым поясом, одинаковой ментальностью, кучей привилегий на законодательном уровне и т.д. Для американцев вообще есть США, Канада и весь остальной мир, они примерно так воспринимают все вокруг.
Еще есть ряд стран южнее Мексики, которые вроде не соседи, но тоже недалеко и там рейты чуть ниже, хотя с английским не очень хорошо.
3. Популярные аутсорс страны. Экономика Штатов огромная и аутсорсят они во многие страны. Очень хорошо себя чувствуют, например, Индия. Просто потому, что индусов в США сейчас море и они стараются притянуть своих в компании, в которых работают, в том числе подрядчиков. Если у клиента в команде появляется индус - это самый страшный сон, который может быть у наших аутсорсеров. И тут рейты могут быть в пределах 10-20 долл. в час. Ну а еще есть куча других очень дешевых стран.
Хорошо, что далеко не все американские клиенты готовы работать с Индией. Один американец мне в штуку сказал, что все компании в Штатах делятся на два типа: те, кто еще не работали с Индией и те, кто уже не работает :) Ну а если серьезно, в Индии тоже вполне есть хорошие компании. На нашем рынке сложилось такое негативное мнение, потому, что мы все переделывали что-то после дешевых индусов и не работали с нормальными. А в Штатах далеко не все думают про них негативно.
То есть кому отдать разработку у американцев есть. Я много раз слышал: "мы хотим продавать по 70-80$ / час в Штаты". Хорошо, это в теории возможно, но для этого нужно ответить на вопрос: "Чем моя компанию лучше канадских и мексиканских?". Потому, что мы дефолтно проигрываем: уровнем английского, часовым поясом, пониманием ментальности и кучей других факторов.
Внутренние факторы:
1. Экспертиза. Это ключевой фактор для высокого рейта. Если её не будет, то мы быстро сползаем в ценовую конкуренцию и также быстро проигрываем её индусам, африканцам, пакистанцам и т.д. Тут важны знания в определенной отрасли бизнеса, тематическое портфолио, свои наработки, сильные аналитики, профильные маркетологи, крутые сейлзы с тематическими знаниями и другие специалисты. Компания должна стать центром компетенции, а все её сотрудники понимать предметную отрасль. Как правило, у обычной компании нет всех специалистов и компетенций, которые я перечислил, но каждый из этих параметров прибавляет экспертизу в глазах клиентов. Одно только портфолио в какой-либо сфере может сильно помочь продажам и увеличить рейт.
2. Готовые продукты. Это продолжение темы экспертизы. У некоторых компаний может быть не только отраслевая экспертиза, но уже готовые продукты, которыми она торгует и их кастомизирует. Например, кастомизация для SAP имеет свои рейты, своих клиентов и вообще свой рынок. Чем уникальнее решение, тем выше рейт. Стоимость продукта может быть копеечная, а вот стоимость кастомизации очень даже большая. Эти решения могут быть, как собственного производства, так и от больших компаний. Самыми прибыльными будут собственные решения направленные на узкие рынки, так как большие корпорации, которые продвигают свои решения, заинтересованы в максимальном охвате и большом количестве партнеров, что быстро убивает высокий рейт.
4. География подрядчика. Тут, прежде всего, будет важен часовой пояс в котором находится команда. Чем дальше страна, тем неудобнее с ней работать, тем сильнее отличается ментальность и тем ниже рейт. И наоборот, если у вас есть команда разработчиков в США, вы можете продавать по местным рейтам. Именно по этой причине все чаще встречаются комбинированные команды, где часть девелоперов находится в Штатах, а часть в далеком аутсорс офисе и такие компании часто зарабатывают только на удаленной команде, а местные американские девы для компании выходят в ноль.
5. Вид работ и технология. Стоимость программирования, дизайна и маркетинга - разная, это не нужно объяснять. А вот по технологиям всегда есть простые и популярные, на них рейты будут низкими, а есть сложные и с ограниченным количество разработчиков, на них рейты могут быть в разы выше. Например, WordPress разработчик и Blockchain разработчик - это отличие рейтов во много раз. И чем заниматься - тоже важное внутреннее решение компании.
6. Уровень специалистов. Тут просто, есть джуны, мидлы, сеньеры. Рейт у всех в теории должен быть разный и многие аутсорс команды пытаются рассказывать, что их джуны - это сеньеры. Мы сами заказываем сейчас у партнеров разработку некоторых вещей, которые сами не успеваем, и я в 50% случаев с таким сталкиваюсь. Кстати, про это мне говорили немцы, когда мы были в Берлине, именно это им не нравится в работе с нашим рынком. Если они просят сеньера - им нужно давать сеньера, иначе вы просто навсегда потеряете этого клиента. Думаю, в других странах такое же мнение. Если у вас девелоперы высокого уровня - их можно продавать дорого, но при условии проработки всех остальных пунктов, которые я перечислил. А если они идеально подходят по тех. стеку, особенно в случае с аутстафингом, это вообще отличная основа :)
7. Маркетинговая обвертка. Тут огромное поле для фантазий! Все мы продаем часы наших специалистов, но все это делают по-разному. Одно дело просто продавать программистов и совсем другое продавать специализированную команду, которая, например, автоматизирует работу автомобильных заводов. Чувствуете разницу? Что быстрее продать какой-нибудь автомобильной компании?
На самом деле рейт зависит еще от многих вещей, я описал только основные параметры, над которыми надо работать. И высокий рейт - это очень долгий и сложный процесс для любой компании. Продажи в США не гарантируют высокий рейт вообще. Все, что выше 35$ / час - это уже заслуга самой компании, а не рынка. Так что продавать по 70-80$ / час возможно, но реально такой средний рейт получают единицы.
Ну а для тех, кто хочет углубиться в тему, мы уже завершаем набор группы на курс про продажам в США и кто еще не с нами, самое время написать мне и узнать какие еще темы про США мы раскроем уже в рамках закрытой тусовки единомышленников.
Метрики — они как фломастеры, каждому по вкусу свои. Без метрик существование прибыльного бизнеса как такового невозможно, они окружают нас постоянно, это неприятная, но аксиома. Для кого-то метрика — план продаж на месяц, кому-то — выполнение заказа до оговоренного дедлайна, а другим — количество отработанных часов.
Подходящей «Картинки Для Привлечения Внимания» на эту тему нет, так что держите котика
Почему-то слово «метрики» в IT-сфере плотно ассоциируются с такими «превосходными» по своей тупости практиками, как подсчет написанных строчек кода или закрытых тасков. С уверенностью можно сказать, что это — самые бесполезные и беззубые в управленческом плане «инструменты» контроля. По сути же, адекватные метрики бывают, весьма условно, но все же, только двух типов: метрики для проекта и/или работ, результат и время исполнения которых ясен и прогнозируем во времени, и напротив, метрики для проекта и/или работ, результат и время исполнения которых спрогнозировать физически невозможно. Для первого типа выставляются метрики результата, а для вторых — дистанции, сиречь отработанного времени.
Первый тип метрик «по результату»
Универсального рецепта для выставления метрик любому работнику нет — это всегда ситуационное явление. Метрика работника всегда формируется из одного простого ответа на следующий вопрос: можем ли мы четко предсказать конечный результат и, как следствие, время работ на малой или средней дистанции?
Давайте рассмотрим ситуацию на фрилансе. Чаще всего заказчики выстраивают взаимоотношения с исполнителями по принципу оплаты за выполненный объем работы. То есть существует бюджет на проект, и под этот бюджет уже в ходе переговоров согласуется редлайн и дедлайн его сдачи. Так работают дизайнеры, верстальщики, ряд разработчиков. Чаще всего бюджет не двигается с места, то есть подвижной частью является «время выполнения».
Но оно всегда плюс/минус прогнозируемо, то есть заказчик четко понимает, сколько «примерно» времени уйдет на исполнение его заказа. Отталкиваясь от этой цифры выделяется бюджет, после чего ищется подходящий по стоимости исполнитель.
Вообще во фриланс-среде четко проповедуется принцип «нам все равно, сколько времени вы потратите на выполнение заказа, просто сделайте хорошо и в сроки, которые для нас приемлемы». Таким образом снимается масса вопросов по контролю за работой наемного фрилансера или временного сотрудника, снимается необходимость платить ему три, четыре, десять раз «зарплату» и так далее. Есть транш предоплаты, есть закрытие итогового, заранее оговоренного счета.
Подобный подход просочился и в малый и средний бизнес, где люди работают вроде бы, и на фуллтайм, но компания живет в состоянии жесткой конкуренции и коротких дистанций, когда результат нужен в конкретные сроки. Приложив «безумные усилия» можно нарисовать вот такую грубую-грубую блок-схему, которой руководствуются при принятии решения:
А что насчет почасовых рейтов UpWork и прочих моделей фриланса по времени?
Возможно, этот вопрос родился у тебя, читатель, еще в начале статьи, но пришли к ответу на него мы только сейчас. Точнее, к ответам, потому что их несколько.
Первый: нанимающая компания привыкла к контролю, потому что почасовая ставка в 50% случаев подразумевает трекер, а в 100% — периодические отчеты с проведением ревизии выполненных работ. То есть заказчик перекладывает часть менеджерских функций на самого исполнителя, который отчитывается сам за себя.
Второй: компании нужен контроль за ходом разработки, потому что у нее есть только одна попытка. Если проект растягивается более, чем на несколько недель, заказчику нужно понимать, «на каком свете» находится работа. Чаще всего на такие массивные заказы бюджет выделяется один раз и попытка есть только одна. На самом деле на рынке когда-то были и компании, которые не требовали такой периодичной и временами жесткой отчетности от исполнителей на крупных проектах, но с ними случилось тоже самое, что и со слонами с маленькими ушами — они вымерли (слоны от перегрева, а компании — из-за сорванных сроков).
Второй тип метрик «по времени»
Но все становится намного, намного сложнее, если мы начинаем говорить о крупном проекте, сроки сдачи которого колеблются в диапазоне «от года до трех» и до «это вечная разработка».В случае «вечной разработки» спрогнозировать время получения конечного результата практически невозможно по следующим причинам:
- над проектом работает не то что один человек, а даже несколько команд;
- каждая команда «по направлениям» насчитывает от двух-трех, до нескольких десятков сотрудников;
- когда закончится работа над проектом никто не знает.
Самый простой и логичный пример работы «по времени» — это обычный офисный фулл-тайм в компаниях от 30-50 человек в отделе разработки. В этих условиях бизнес «на берегу» договаривается с потенциальным работником, то есть еще на этапе собеседования, не о моменте сдачи проекта, а о стоимости часа работы исходя из 40-часовой рабочей недели согласно ТК. Для нас это выглядит просто как размер заработной платы.
При этом надо четко понимать, что бизнес — не дураки. В размер ЗП (точнее в ее сокращение) закладываются личностные кризисы, шатания по офису, перекуры, лишние 20-30 минут на обед (то есть полтора часа, вместо часа) и просто прокрастинация на YouTube. Какие-то компании могут позволить себе эти издержки, так как из бизнес является в данный момент прибыльным и он может позволить себе «легкую» версию контроля через простое выставление краткосрочных задач с размытыми дедлайнами, которыми занимается менеджмент младшего и среднего звена.
Но если бизнес низкомаржинальный или существует в конкурентной легаси-среде, то все становится еще хуже. И вот тут начинается форменный ад, за который разработчики так не любят слово «метрики».
Реальная жесткая привязка к отработанному времени не является самостоятельной метрикой эффективности, тут нужны костыли
Если человеку платят не за результат, а за количество отработанного времени, то как оценить его эффективность? Этим вопросом постоянно задается бизнес. Тут есть несколько переменных:
- Привязка результативности команды к метрике «результат» на короткой дистанции.
- Использование более мелких метрик на уровне задач и спринтов.
- Выстраивание четкой структуры ответственности, сроков и приоритетов, называйте как хотите, например, «политика разработки».
Чаще всего происходит так, что менеджмент не способен четко проследить потребности бизнеса и работников одновременно, то есть выстроить систему и политику применения метрик, при которой обе стороны были бы довольны происходящим. Что имеется в виду: метрики должны одновременно выполнять интересы бизнеса и быть понятны и выполнимы работниками.
Тут мы сталкиваемся с другой проблемой: если при работе «на заказ» на коротких дистанциях задача, чаще всего, ясна и понятна всем сторонам, то при разработке крупного продукта вся структура находится в постоянном движении. Банально: конкуренты выпустили новый продукт или появился новый инструментарий и все планы, которые были любовно созданы менеджментом, пошли прахом.
В этот момент очень много зависит от менеджмента. Тут можно просто описать неадекватный и адекватный подходы к выставлению метрик.
Неадекватные метрики:
- количество строк кода и коммитов;
- количество закрытых тасков без учета сложности;
- лишение разработчика права голоса;
- игнорирование динамики и потребностей разработки в отчетный период (выполнение метрик превыше здравого смысла);
- длительный процесс пересмотра метрик, отсутствие гибкости, игнорирование мнения разработки.
Адекватные метрики:
- Учет сложности задачи;
- Возможность пересмотра метрики постфактум при возникновении проблем;
- Возможность комментирования задачи;
- Отсутствие жесткой привязки к количественным показателям строк кода/количества тасков;
- Игнорирование частичного несоблюдения метрик, если в этом была необходимость.
Кроме того, жесткая привязка к соблюдению метрик контр-продуктивна: если девелопер знает, что у него начнутся «проблемы» из-за того, что он закрыл 19 тасков за неделю вместо 20, то качество выполнения задачи уходит на задний план. И минимум последний, 20 таск, будет сделан на «отвали», с костылями и велосипедами вместо того, чтобы по-настоящему раз и навсегда решить поставленную задачу.
Обратная связь как неотъемлемая часть модели «покупки времени»
Фактически, качественно построенная модель разработки, привязанная ко времени работы, намного сложнее, чем может показаться на первый взгляд. Для эффективной работы по этой модели должна быть организована качественная обратная связь между исполнителями и руководителями, которые должны постоянно корректировать «политику партии» на всех уровнях. Ведь неадекватно поставленная задача, то есть сформулированная метрика — это проблема далеко не разработчиков, хотя эту проблему у нас принято спихивать именно на исполнителей. Неадекватно сформулированная метрика — это проблема, как раз менеджмента, который эту задачу поставил перед исполнителями при условии прозрачности работы обоих сторон.
Именно наличием обратной связи и ответственностью за принятые решения со стороны менеджмента отличается от компания, которая ведет детальный учет отработанного времени, от явной «галеры», где разработчики попадают в бессмысленную мясорубку.
Именно обратная связь позволяет бизнесу найти «узкие места» в разработке. Как часто вы сталкивались с ситуацией, когда сотрудники какого-либо отдела задыхались, работая на износ, но так и не получали «подкрепления» в виде пары новых специалистов, которые бы подставили плечо и забрали на себя часть нагрузки? Такие ситуации возникают сплошь и рядом именно из-за отсутствия качественной обратной связи между разработкой и менеджментом. Вместо четкого отслеживания эффективности команды и ее нагрузки, менеджер ковыряется в носу пальцем, а когда кто-то «ломается», не выдерживая такого ритма, все спихивает на оставшихся девелоперов. Не надо так.
Вместо вывода
Самое худшее, что может случиться в процессе организации рабочего процесса — «передергивание» механизмов, присущих одной модели в другую. Например, когда для долгосрочных проектов выставляются жесткие дедлайны без здравой оценки сложности и возможностей команды. Или когда на краткосрочные самодостаточные проекты и задачи надстраиваются такие формы контроля, которые впору применять в области ракетостроения, а речь идет всего-то о заказе на фрилансе.
Четкое понимание уместности тех или иных методов работы в различных по структуре и размеру компаниях поможет уберечь огромный кусок здоровья и нервной системы при поиске работы. И чем больше разработчиков, менеджеров и владельцев бизнеса будут понимать эти механизмы — тем лучше будет для всех участников IT-сегмента.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Какую модель работы предпочитаете лично вы?
- Блог компании Crossover
- Управление разработкой
- Фриланс
- Управление персоналом
- Карьера в IT-индустрии
- Скопировать ссылку
- ВКонтакте
- Telegram
Похожие публикации
- 2 ноября 2018 в 14:50
Прекратите нанимать «эффективных менеджеров». Они не только бесполезны, но и вредны
Неделя обратной связи в Crossover
Бесконкурентная борьба: как турниры Crossover изменились за свой первый год
AdBlock похитил этот баннер, но баннеры не зубы — отрастут
Вакансии компании Crossover
Комментарии 24
Свой вариант, что учитывать, я озвучивал пол года назад на Тостере.
Если коротко:
— число строк,
— время в офисе,
— выполнение задач,
— фикса в месяц.
1. Количество написанных строк обязательно должно оплачиваться деньгами, либо как основная оплата («сколько написал — столько получил, например 35 руб./строка»), либо в качестве поощрения («фикса 20 тыс. руб./месяц + 25 руб./строка»).
2. Новые строки кода должны разделяться на разные виды и оплачиваться по-разному:
1) абстракции (описание классов, структур, заголовки модулей, названия методов) и пустые строки — 0 руб. (т.е. не учитываются в оплате за строки кода)
2) рабочий код (тело методов, тело функций, тело процедур и т.п.) — 70 руб./строка*
3) определение констант, массивов, переменных вне тела методов — 10 руб./строка
4) комментарии (не более 10% от всего числа строк) и todo — 5 руб./строка
5) документация, changelog, bugfix-файлы — 20 руб./строка.
*Цена за рабочий код зависит от языка программирования, для низкоуровневых языков она должна быть меньше, для высокоуровневых — больше, например:
— Си — 50 руб.
— С++, Pascal, PHP — 60 руб.
— Ruby и Python — 70 руб.
Ну и так далее.
3. Измененные строки (не новые) должны оплачиваться в 30%-50% от новых.
4. Перенесенные строки (не изменялись, просто перенесены) — не оплачиваются.
Учёт строк должен проводиться по распечатанному «git diff» или специально написанными для этого утилитами.
Помимо оплаты за строки кода желательно оплачивать:
1) фикса в месяц — например, минимум 15 тыс. руб./мес. включающие оплату первых строк кода (т.е. напишет или не напишет на 15 тыщ, но всё равно получит, даже если весь месяц ни строчки не написал, или писал, но на 15 тыщ не написал). Это что-то типа подушки безопасности для новичков.
2) время, проведенное в офисе — например, 50 руб./час. Это не должно быть много, но должно стимулировать писать в офисе, а не из дома. Для работодателя, пишущий в офисе эффективнее, чем пишущий дома, т.к. он вживую общается с коллегами и больше пишет кода. К тому же присутствующий в офисе участвует в мозговых штурмах, совещаниях и тому подобном, что тоже положительно скажется на процессе. Чтобы не просыпали, первый утренний час сделать дороже, например 100 руб./час. Учёт входов и выходов вести турникетом по электронной карте или паролю номеронаберателя. Бюджетно — положить самозаполняемый журнал на тумбочку или бумажки, ручку и ящик с прорезью. Можно рядом повесть веб-камеру.
3) бонус за выполнение поставленной задачи. Работодатель перед раздачей заданий сотрудникам может оценить каждое из них, например:
— Написание GUI для ввода формы «Счета на оплату» — 3200 руб.
— Реализация сетевого обмена записями по подпискам — 7500 руб.
— Сохранение сообщений об ошибках в лог-файл — 1000 руб.
Ну и так далее. Бонус учитывает сложность и срочность выполнения с точки зрения работодателя.
При описанной мной системе программист будет мотивирован:
1) больше писать рабочего кода, меньше плодить абстракции и витать в облаках
2) стараться проводить больше времени в офисе
3) брать «горячие» задания и выполнять их как можно быстрее
4) не бояться остаться без денег (актуально для новичков).
Все цифры приведены примерно и должны подбираться экспериментально конкретно для вашей ситуации.
Дополнительно можно добавить метод Водянова, когда часть бюджета разработки (например 20%) распределяется самими разработчиками между собой.
К примеру в конце каждого месяца (или спринта) сотрудники садятся в одной комнате в круг, каждому даётся 3 фишки (красная-600р, зеленая-300р и синяя-200р), перед каждым ставится пустая коробочка, и по кругу разрабы скидывают свои фишки друг другу, на первом круге — красные, потом зеленые, а потом синие. При сбросе фишки, разраб говорит, за что он поощряет, например «за крутой рефакторинг сетевого модуля», «дал мне дельный совет», «носил всем вкусные печеньки», ну и так далее.
После собрания разраб со своей коробкой идет «обналичивать» премию (если ему накидали), в кассу или у начальника.
В этом случае с менеджмента частично снимается вина за «несправедливое» премирование, ну или по крайней мере, «несправедливое премирование» частично «выпрямляется» самими разрабами. Я также полагаю, что это может улучшать личные связи в команде.
Вижу три минуса подобного подхода:
- Исправление багов невыгодно. внесенные изменения будут оцениваться как минимум вдвое меньше, чем написание нового функционала.
- На исправление бага требуется время на поиск (минимальная ставка)
- При исправлении бага будет больше измененных строк чем новых (минимальная ставка)
- на С++ шаблоны не будут использоваться. Выгоднее сделать копию и поменять типы данных.
PS. Если разработчик найдет дублирующий код и удалит его, то будут ли его штрафовать за это? (например по 5 рублей за каждую удаленную строчку)
Интересно узнать, где Вы этого говна набрали, чтобы обходить людей и организации черпающие субстанцию из этого источника.
Следуя этой логики получается, что JS — 100 рублей строка. Мы чудесным образом приходим к тому, что чем менее профессиональный специалист, тем больше он получает.
П.С. Вдруг пришло осознание откуда появился Skype на электроне и почему всё больше в нашем мире говнософта с титаническими аппетитами на ресурсы.
Сколько стоят определенные навыки и сколько клиент реально готов за них заплатить – это вечные вопросы для всех фрилансеров, особенно новичков. Для начала, перешедшим на фриланс сложно установить свой первый рейт (почасовая ставка), потом его так же сложно корректировать при получении опыта.
Идеальной формулы для определения почасовой ставки нет. Но есть несколько приемов для новичков и их первого рейта. Существуют определенные признаки того, что пора поднимать оплату, и способы добиться повышения заработка на фриланс-бирже.
Подсказки, которые помогут определить свой первый рейт: 3 шага
![]()
Новым фрилансерам важно четко определить, что они будут предлагать клиенту, и изучить конкурентную среду в этой сфере. Уделите время изучению фрилансеров с навыками, как у вас: посмотрите, как они себя оценивают, прочитайте их профили, посмотрите на предыдущие проекты. После этого будет проще определится с первым рейтом.
Определите свои уникальные навыки
Кроме опыта на фрилансе для рейта не менее важны и профессиональные навыки. Если вы новичок на фриланс-бирже, но являетесь экспертом своего дела, то можете запрашивать и более высокую оплату, чем люди, только начинающие осваивать эту сферу. Если у вас есть уникальные навыки, обязательно делайте на них акцент, чтобы потребовать за них соответствующую оплату.
Для хорошей репутации крайне важны рекомендапции от прошлых клиентов. Не ждите, что клиент сам предложит написать вам рекомендацию — попросите его об этом. Часто клиент попросту забывает об этом, а еще чаще у них нет времени, поэтому не зазорно предложить клиенту написать отзыв вместо него. Потом, разумеется, вышлите текст на согласование. Скорее всего, клиент согласится на такой вариант.
Когда пора поднимать рейт: 5 сигналов
![]()
Вы поработали на фриланс-бирже некоторое время, набрались опыта и сомневаетесь, стоит ли поднимать рейт. А вдруг этим вы все испортите, отпугнете клиентов? Есть несколько сигналов, которые сообщат, пора ли.
Если вам начали поступать предложения по работе, это хороший знак: вас заметили. В таком случае можно немного поднять рейт, поскольку клиента уже привлекли ваши знания и опыт.
Слишком много работы
Звучит как очень приятная проблема. Если вам отдают большинство работ, на которые вы подаете заявку, и заказов у вас более чем достаточно, значит, пришло время повысит запросы. Среди клиентов найдутся те, кто готов заплатить вам больше за ваш опыт и экспертизу.
Вы готовы специализироваться
Поработав некоторое время, вы, скорее всего, найдете нишу, в которой вам комфортно работать и в которой вы спец. Поищите других фрилансеров с той же специализацией и посмотрите на их расценки, чтобы понять, есть ли у вас некий люфт, который позволяет продвинуться немного выше.
Обычно чем дольше вы работаете с клиентом, тем более ценным вы для него становитесь. Ваша роль в проекте за это время может стать намного более серьезной. Дождитесь какой-то круглой даты в ваших рабочих отношениях и обсудите с клиентом возможности увеличить вашу ставку.
Возможно ли повысить рейт и при этом не потерять клиентов
![]()
Подход фрилансеров к новым и существующим клиентам обычно отличается. И это правильно. Многие фрилансеры отмечают, что гораздо проще изменить цены для новых клиентов, нежели для уже существующих. Ведь со старыми клиентами цена выставлена, предложение принято, сделка в процессе. С новыми проще: можно поднять рейт, сразу озвучив более высокую стоимость услуг.
Перед тем, как обсуждать с клиентом вашу кандидатуру и оплату, изучите проблемы его компании и найдите их решения. Если опередить вопрос клиента об оплате, сначала предоставив ему анализ проблем компании и конкретное предложение с путями для улучшения, вы в результате можете получить согласие на любой рейт, в разумных рамках.
Когда вам удасться обзавестись достаточным количеством новых клиентов, готовых платить больше, можно объявить о повышении рейта и уже существующим, не опасаясь последствий. Ну а если рынок примет ваши новые требования, можете вскоре пробовать снова их повысить.
С новым клиентом можно также заранее договориться о том, что ваш рейт будет постепенно расти по мере достижения определенных этапов в рамках вашего с ним сотрудничества (так называемых “майлстоунов”). Для начала предложите более низкую «вступную» цену — это можно оговорить сразу, во время собеседования. Узнайте, подходит ли такой формат клиенту и согласен ли он платить вам больше.
Ведение переговоров о повышении рейта с существующими клиентами требует бОльшей осторожности. Сначала спросите, доволен ли он вашей работой и как вы могли бы улучшить свой клиентский сервис. Если вы проделали большую работу и уверены, что клиент доволен, можно обсудить повышение оплаты. Укажите на прямой результат вашей работы, например, повышение объемов продаж или увеличение трафика.
Другой способ повысить рейт у существующих клиентов: повышение нагрузки или расширение ваших полномочий. После успешного завершения проекта можете предложить дальнейшее сотрудничество, поделиться своими идеями о том, как сделать бизнес клиента еще более успешным.
Если вы видите, что клиент заинтересован, но пробует торговаться, стойте на своем. В крайних случаях можно пойти на уступку: поработать несколько недель с более низкой оплатой. Если клиент останется доволен вашими результатами в пробный период, повышайте ставку. Соглашайтесь работать дешевле, только если клиент готов в будущем пересмотреть рейт.
В первой части мы рассмотрели механизм распределения расходов сервисной компании и поговорили о средних рейтах разработчиков. Сегодня я расскажу о том, как формируются индивидуальные рейты сотрудников и какие есть способы для их увеличения.
Данные для статьи взяты из квартальных отчетов публичных компаний — EPAM, Luxoft, Geometric, Globant.
Как формируются зарплатные вилки
Попробуем смоделировать несколько примеров и посмотрим, какие факторы влияют на зарплату конкретного сотрудника. Например, у нас есть self-managed developer, он работает на проекте один, у него нет ни начальников, ни подчиненных, ни тимлидеров. Клиент платит за него деньги, а компания платит ему зарплату. Сколько компании платить такому сотруднику? Допустим, что в данной компании фонд оплаты труда — 60%, Billability — 70%, а клиент платит $35-45 в час в зависимости от квалификации. Тогда расчет по формуле Customer Rate * %Salary * Billability (подробней о формуле — в предыдущей статье) показывает эффективный для данной компании размер оплаты работы такого сотрудника: $35-45 * 60% * 70% = $14.7-18.9 в час.
Для self-managed QA Engineer этот диапазон составит $12.6-14.7 в час — при условии, что клиент платит $30-35 в час в зависимости от квалификации тестировщика.
Обратите внимание, что цифры приблизительные, я показываю принцип расчета и порядок величин.
Теперь давайте возьмем тимлидера, у которого есть парочка подчиненных. Например, такая команда из трех человек: синьор (он же тимлидер), миддл и джуниор. Тогда часть денег можно перераспределить таким образом, чтобы средняя зарплата по команде осталась неизменной. Тимлидер получит добавку за счет миддла и джуниора, что вполне справедливо, поскольку он, помимо основной работы, обучает и контролирует команду. Допустим, средний рейт заказчика для такой команды составляет $37.5 в час. Тогда средняя зарплата по команде составит $15.75/час. Если рейт миддла равен $15 в час, а рейт джуниора — $10 в час, то опытному тимлидеру можно платить $22.25 в час.
По такому же принципу рейт тимлидера команды из а точнее, верхняя его граница, может вырасти еще примерно на
Естественно, компании никогда не считают эти цифры по командам, но ориентируются на такие показатели в среднем по компании. То есть у тимлидера определенного уровня синьорности зарплата, скорее всего, будет в конкретном диапазоне, который в целом по компании считается разумным.
Как повлиять на рост своей зарплаты
Мы видим, что потолок зарплат всё же существует. Есть ли какие-то способы его «пробить»?
С точки зрения начинающего разработчика, самое естественное — стать хорошим специалистом в какой-то конкретной области программирования: специализация на языке, технологиях (front-end, back-end, мобильные приложения), фреймворках и т.д. Но нужно учитывать, что рано или поздно экстенсивный рост замедляется, и для дальнейшего роста зарплаты ваш рост должен опережать средний по индустрии, потому что в программировании, если не растешь, то деградируешь.
При достижении определенного уровня дальнейший профессиональный рост становится возможным за счет освоения смежных областей — новых языков программирования, платформ, фреймворков и т.д. Сотрудники, которые на одном проекте могут применять свои знания в разных областях, стоят больше. Хочу подчеркнуть, что я не говорю о фрилансе.
Следующий шаг в профессиональном развитии — это специализация на предметной области. Можно разобраться в специфике банковского дела, здравоохранении, инженерных задачах — за таких экспертов заказчики готовы платить существенно больше. Но есть и обратная сторона такой специализации: в таком случае ваша экспертиза будет применима в какой-либо узкой области, то есть при смене предметной области ваша зарплата может даже упасть.
Разумеется, есть множество других способов повышения своего дохода: смена места работы, переезд в другой город или страну, переход во фриланс и т.д. Этой теме посвящено множество статей.
Чем обусловлен рост зарплат с точки зрения компаний
С точки зрения компании рост уровня зарплат может быть обусловлен следующими факторами: ростом рейтов на стороне заказчика, ростом компании и attrition (замена одних сотрудников другими). Рассмотрим возможный вклад каждого из этих факторов.
Существует инфляция на стороне заказчика: через некоторое время работы над проектом компания вправе сказать клиенту, что у определенных сотрудников уровень вырос, и попросить прибавить несколько процентов к зарплате. Обычно такой запрос делается не чаще, чем раз в год. Кого-то продвинули в тимлидеры, кто-то стал миддлом, синьором — заказчик вполне в состоянии такие вещи воспринять, если он видит реальные результаты. У некоторых сотрудников уровень особо не меняется, с точки зрения клиента им делать прибавку нерационально. Таким образом, на круг по всей компании выходит прибавки.
Также существует эффект нового заказчика — обычно attrition клиентов составляет Это значит, что в течение года какие-то контракты заканчиваются, но появляются новые. Этим клиентам компании продают освобождающихся сотрудников, но стараются это сделать по несколько более высокому рейту. За счет такого естественного attrition можно получить еще в среднем по компании. В сумме такой рост рейтов дает увеличение доходов на 5%, часть которых можно пустить на прибавку к зарплатам пропорционально фонду оплаты труда.
Но зачастую зарплаты растут гораздо быстрее: за год зарплаты отдельных сотрудников могут вырасти на а джуниоров — на 50% и больше. Здесь самое время вспомнить про рост компаний и attrition. Средний рост IT отрасли в Украине составляет около 20% в год. Этот рост обеспечивается за счет джуниоров начального уровня, так как массового переезда опытных разработчиков в Украину пока не наблюдается. Конечно, есть переходы между компаниями, но основной источник роста по отрасли — это всё же джуниоры. Средний рейт по компаниям — $10-15 в час, а средний рейт найма — $10 в час. За счет этого эффекта можно накинуть к зарплате «ветеранов» порядка 5% с тем, чтобы средний рейт оставался более-менее на том же уровне. Естественно, эта прибавка зависит только от роста компании.
Теперь подробнее остановимся на attrition. Про негативную сторону говорить не буду, об этом все наслышаны. В каждой компании есть распределение между джуниорами, миддлами и синьорами. Обычно джуниоров может быть несколько больше трети, а синьоров несколько меньше. Допустим, attrition составляет это нормальные цифры по индустрии. Из каждой категории по разным причинам уходит приблизительно одинаковый процент: кто-то уезжает за границу, кто-то переходит в другую компанию, кого-то увольняют. Для того, чтобы восполнить рост, то есть attrition + рост компании нужно нанять 40% новых сотрудников. И приходят, в основном, джуниоры. Таким образом, за счет эффекта attrition — замены людей более опытных на менее опытных — можно добавить «ветеранам» еще порядка 5%. Естественно, нужно стараться не снижать уровень сервиса заказчику, но в данной статье мы рассматриваем только финансовый аспект.
Давайте сложим теперь всё, что даёт прирост к зарплате: «инфляционного» роста, рост компании и attrition. В сумме это означает, что зарплаты в среднем по компании могут вырасти на Но нужно понимать, что это не гарантирует роста зарплаты каждому сотруднику. У синьоров и экспертов зарплаты растут намного меньшими темпами, чем у быстро прогрессирующих джуниоров.
Что мы имеет на практике
Посмотрим теперь, подтверждается ли теория практикой. Согласно обзорам DOU, в 2014 году в Украине было 75 000 IT специалистов, а в 2015 стало 90 000, то есть рост составил 20%. При этом средняя зарплата упала на 5%. Страх и ужас, индустрия загибается, зарплаты падают! Но весь прирост по индустрии в целом идет за счет джуниоров, причем начинающих — студентов, выпускников и тех, кто переквалифицировался из других специальностей.
Attrition в целом по Украине — порядка 5%. Это люди, которые уезжают из страны или уходят из IT в другие отрасли. Attrition по Украине меньше, чем attrition в компаниях, потому что здесь не проявляются переходы между компаниями. Если мы эти факты учтем, то получим в сумме 25% «свежих» джуниоров, и увидим, что в действительности «ветераны» получили прибавку в 12,5%, что хорошо согласуется с нашими расчетами.
В заключительной статье цикла мы рассмотрим, пожалуй, самые «мифологизированные» вопросы — куда девается прибыль компаний и зачем компаниям нужен рост.
Недавно, мы искали (всё ещё ищем) программиста к себе в команду. Зарплатная вилка была достаточно большой — 70–200к рублей. Это вызывало у многих недоумение, поэтому мы пояснили этот момент: вы можете видеть наш ответ на скрине.
![]()
А сейчас мы предлагаем поговорить о том, как формируются зарплаты в IT, почему организации не указывают в вакансии чёткую сумму, если вообще указывают хоть что-то, и достаточно ли для получения з/п по верхней границе вилки «продавить» рекрутера.
Как работодатели определяют «зарплатную вилку»?
Во-первых, определимся с тем, что такое «зарплатная вилка». Это верхняя и нижняя граница оплаты труда. Соискателям она показывает, сколько компания готова платить за выполнение определенных задач, а нанимателям — сколько человек хочет получить за работу
Чтобы сформировать «вилку», компании анализируют рынок — изучают, какая зарплата считается конкурентоспособной в регионе, сколько получают сотрудники других фирм на аналогичных позициях и сколько просят соискатели. Ещё важно учитывать, сколько людей претендуют на должность в компании и сколько предложений от конкурентов на рынке.
Также зарплаты в IT зависят от целей нанимателя. Например, компания хочет создать команду из лучших разработчиков: с престижным образованием, большим портфолио и квалификацией выше средней. Тогда она, скорее всего, укажет более высокую зарплату. Или, наоборот, захочет набрать джуниоров, которых обучит «под себя» — тогда сумма будет меньше, зато будут более низкие требования и, возможно, бонусы, вроде корпоративного обучения.
Почему в вакансиях скрывают информацию о зарплате
![Кристина Гурочкина]()
Кристина Гурочкина
руководитель группы подбора персонала ИТ-компании «Рексофт»
27 мая в 18:30, Онлайн, Беcплатно
В компании действует политика неразглашения зарплат — это частая причина, исключающая демонстрацию зарплат на рынке.
Ещё одна причина может быть связана с тем, что компания избегает демотивации существующих сотрудников, когда в рамках одного отдела у сотрудников разные зарплаты в зависимости от квалификации. Так же бывает, когда работодатель понимает, что уровень зарплат по рынку вырос, но увеличить доход текущим сотрудникам пока нет возможности. В такой ситуации компания вынуждена нанять специалиста на более высокую зарплату и со временем выравнивать оклады других специалистов.
Компания хочет оценить уровень кандидатов, посмотреть и проанализировать — кто откликается на данную вакансию. Например, работодатель знает, что готов платить сотруднику от 50-80 тысяч рублей в месяц, в результате анализа он, например, понимает, что сейчас он может нанять начинающего специалиста за 50 тысяч рублей в месяц, и у него будет возможность по мере роста компетенции сотрудника поднимать ему зарплату. Другой вариант — работодатель, просмотрев большое количество соискателей, решает взять опытного специалиста и платить ему по верхнему уровню. Если в вакансии была бы указана, или только нижняя, или верхняя планка оклада, то компания теряла бы из поля зрения начинающих специалистов или опытных соискателей.
Ещё одна распространённая причина — компания скрывает данные от конкурентов. Это особенно актуально для конкурирующей IT среды.
Какие зарплаты у айтишников в России?
В этом году сервис Хабр Карьера провёл исследование. Аналитики собрали информацию о почти 8 тысячах реальных зарплат в IT. Медианная зарплата программистов в этом году — 108 тысяч рублей. При этом в Москве она примерно равна 150 тысячам, в Санкт-Петербурге — 120, а в регионах опускается в среднем до 80 тысяч.
![]()
Как видим, большие зарплаты — по 150–200 тысяч рублей — получают в крупных городах, и то далеко не во всех сферах.
Обычно программисты, которые зарабатывают такие суммы, находятся на уровне миддла: могут написать свой код и «пофиксить» чужой, а еще обучить стажера и провести презентацию. Важную роль также играют знание английского, навыки переговоров и управления персоналом и так далее.
Наконец, многие программисты, которые зарабатывают от 200 тысяч, часто сотрудничают с международными компаниями, готовыми платить большие гонорары в долларах и евро.
Читайте также:
