Статья Юлия Гольдберга: "Ваши ставки, господа..."
Допускаю, для многих читателей было бы интереснее узнать что-то новое про то, как правильно делать ставки в казино или на бегах, но в этой статье я решил сфокусироваться немного на другом – на ставках на работу специалистов, часовых, дневных тарифах, которые используются для оценки стоимости работ. Конечно, ставки есть почти во всех профессиях, где речь идет о “покупке” экспертизы или рук для решения определенных проблем, например, у адвокатов, врачей, официантов, сантехников и пр. В этой статье остановимся на ставках в ИТ-отрасли. Обычно они сводятся к ставкам за человеко-час или человеко-день на привлечение разработчиков, аналитиков, тестировщиков, руководителей проекта. Сами по себе ставки кажутся довольно простой темой, но именно они в значительной степени определяют итоговую цену ИТ-услуг для клиента, а правильное определение цены – это как минимум половина успеха в борьбе за заказ.
Я работаю в компании GlowByte, а в целом в ИТ-сфере – более 20 лет. В последние годы в основном занимаюсь проектами и решениями в области данных, BI, аналитики, но приходилось иметь дело с большим списком разнообразных ИТ-услуг и форм взаимодействия заказчиков и подрядчиков. По роду деятельности мне приходится много заниматься вопросами ценообразования на ИТ-услуги, определением/изменением ставок, согласованием их с клиентами компании. Знаю, что многие считают себя специалистами в этом вопросе. Это почти как в воспитании детей или в медицине, где вроде бы есть профессиональная экспертиза, но тем не менее почти каждый считает себя специалистом, способным самостоятельно решить любую проблему.
Тем не менее я ежедневно наблюдаю множество не всегда очевидных нюансов в деле определения и согласования ставок. Их стоит учитывать при формировании оптимальных предложений и поисках компромиссов с клиентом. Поэтому хотел бы в настоящей статье немного структурировать и систематизировать тему. Надеюсь, что кому-то это принесет реальную пользу на извилистом пути, который обычно пролегает точно “между Сциллой и Харибдой”.
Я работаю в компании GlowByte, а в целом в ИТ-сфере – более 20 лет. В последние годы в основном занимаюсь проектами и решениями в области данных, BI, аналитики, но приходилось иметь дело с большим списком разнообразных ИТ-услуг и форм взаимодействия заказчиков и подрядчиков. По роду деятельности мне приходится много заниматься вопросами ценообразования на ИТ-услуги, определением/изменением ставок, согласованием их с клиентами компании. Знаю, что многие считают себя специалистами в этом вопросе. Это почти как в воспитании детей или в медицине, где вроде бы есть профессиональная экспертиза, но тем не менее почти каждый считает себя специалистом, способным самостоятельно решить любую проблему.
Тем не менее я ежедневно наблюдаю множество не всегда очевидных нюансов в деле определения и согласования ставок. Их стоит учитывать при формировании оптимальных предложений и поисках компромиссов с клиентом. Поэтому хотел бы в настоящей статье немного структурировать и систематизировать тему. Надеюсь, что кому-то это принесет реальную пользу на извилистом пути, который обычно пролегает точно “между Сциллой и Харибдой”.
Фикс или T&M – вот в чем вопрос
Когда мы говорим о ставках – тарифах на работу специалистов, важно учитывать, что существует два принципиально разных подхода к расчету стоимости услуг для клиента. Первый – фиксированная цена за проект (или какой-то его этап) под ключ. Второй – Time&Materials (T&M), когда стоимость рассчитывается на основе объема трудозатрат, потраченных на оказание услуги.
В случае с fix price ставки являются скорее одним из внутренних факторов, которыми оперирует подрядчик, определяя итоговую цену проекта, – наряду со структурой проектной команды, прогнозируемым сроком выполнения работ, заложенными рисками, принятыми допущениями, плановой маржинальностью. В большинстве случаев при таком подходе заказчика волнует итоговая цена и именно ее он сравнивает с ценой конкурентов или со своим согласованным бюджетом. Ставки при этом могут вообще не показываться заказчику, а если и показываются, то носят скорее информативный характер. Поэтому в данной статье не буду подробно углубляться в ценообразование для проектов с фиксированной ценой, потому что это скорее не про ставки, а наша цель покопаться именно в них.
Вот где ставки выходят на первый план, так это в T&M. При этом подходе расчет стоимости оказанных услуг выполняется в конечном итоге на основе фактических понесенных трудозатрат. Тут тоже, как и в “фикс прайс”-проектах, можно планировать бюджет на будущее с учетом прогнозируемой потребности в ресурсах. Но все равно окончательный расчет будет проводиться по факту отработанных командой подрядчика и принятых заказчиком человеко-часов или дней. Конечно, в T&M-подходе итоговая цифра зависит не только от ставки и отработанного времени. Например, для нас в “ГлоуБайт” важный фактор – кто берет на себя риск простоев и, соответственно, их оплату.
Когда услуги оказываются в рамках аутстаф-модели, то есть заказчик фактически привлекает внешних специалистов, расширяя ими собственный штат, управление привлеченными сотрудниками обычно полностью на его стороне. Соответственно, все простои и некомпетентности в управлении командой тоже в зоне ответственности заказчика, который должен оплатить подрядчику все то время, которое внешняя команда работала на него. Практически так, как в случае, когда он выплачивает зарплату собственному сотруднику, даже если тот временно не задействован в работе по причине отсутствия для него задач. Единственный серьезный рычаг для заказчика в управлении затратами при такой модели – это возможность замены неэффективного сотрудника подрядчика. Если кто-то из команды подрядчика не нравится заказчику, недостаточно эффективен, не вписывается в коллектив, часто болеет и т. п., то можно требовать его замены и подрядчик, скорее всего, будет вынужден пойти навстречу.
Когда же мы говорим о передаче заказчиком привлеченному подрядчику какого-либо направления, бизнес-процесса или задачи целиком на аутсорс, то, даже если оплата производится по схеме T&M, риски простоев и прочих подобных проблем во многих случаях могут быть перенесены на подрядчика или же распределены между сторонами каким-то образом, с учетом той зоны ответственности и полномочий, которые переданы команде подрядчика. В таком случае определение и согласование с заказчиком ставок – более сложное упражнение, чем для аутстафа, поскольку должно учитывать все потенциальные огрехи управления команды подрядчика, задействованной у заказчика, и смежных процессов, которые могут серьезно влиять на работу этой команды.
Когда мы говорим о ставках – тарифах на работу специалистов, важно учитывать, что существует два принципиально разных подхода к расчету стоимости услуг для клиента. Первый – фиксированная цена за проект (или какой-то его этап) под ключ. Второй – Time&Materials (T&M), когда стоимость рассчитывается на основе объема трудозатрат, потраченных на оказание услуги.
В случае с fix price ставки являются скорее одним из внутренних факторов, которыми оперирует подрядчик, определяя итоговую цену проекта, – наряду со структурой проектной команды, прогнозируемым сроком выполнения работ, заложенными рисками, принятыми допущениями, плановой маржинальностью. В большинстве случаев при таком подходе заказчика волнует итоговая цена и именно ее он сравнивает с ценой конкурентов или со своим согласованным бюджетом. Ставки при этом могут вообще не показываться заказчику, а если и показываются, то носят скорее информативный характер. Поэтому в данной статье не буду подробно углубляться в ценообразование для проектов с фиксированной ценой, потому что это скорее не про ставки, а наша цель покопаться именно в них.
Вот где ставки выходят на первый план, так это в T&M. При этом подходе расчет стоимости оказанных услуг выполняется в конечном итоге на основе фактических понесенных трудозатрат. Тут тоже, как и в “фикс прайс”-проектах, можно планировать бюджет на будущее с учетом прогнозируемой потребности в ресурсах. Но все равно окончательный расчет будет проводиться по факту отработанных командой подрядчика и принятых заказчиком человеко-часов или дней. Конечно, в T&M-подходе итоговая цифра зависит не только от ставки и отработанного времени. Например, для нас в “ГлоуБайт” важный фактор – кто берет на себя риск простоев и, соответственно, их оплату.
Когда услуги оказываются в рамках аутстаф-модели, то есть заказчик фактически привлекает внешних специалистов, расширяя ими собственный штат, управление привлеченными сотрудниками обычно полностью на его стороне. Соответственно, все простои и некомпетентности в управлении командой тоже в зоне ответственности заказчика, который должен оплатить подрядчику все то время, которое внешняя команда работала на него. Практически так, как в случае, когда он выплачивает зарплату собственному сотруднику, даже если тот временно не задействован в работе по причине отсутствия для него задач. Единственный серьезный рычаг для заказчика в управлении затратами при такой модели – это возможность замены неэффективного сотрудника подрядчика. Если кто-то из команды подрядчика не нравится заказчику, недостаточно эффективен, не вписывается в коллектив, часто болеет и т. п., то можно требовать его замены и подрядчик, скорее всего, будет вынужден пойти навстречу.
Когда же мы говорим о передаче заказчиком привлеченному подрядчику какого-либо направления, бизнес-процесса или задачи целиком на аутсорс, то, даже если оплата производится по схеме T&M, риски простоев и прочих подобных проблем во многих случаях могут быть перенесены на подрядчика или же распределены между сторонами каким-то образом, с учетом той зоны ответственности и полномочий, которые переданы команде подрядчика. В таком случае определение и согласование с заказчиком ставок – более сложное упражнение, чем для аутстафа, поскольку должно учитывать все потенциальные огрехи управления команды подрядчика, задействованной у заказчика, и смежных процессов, которые могут серьезно влиять на работу этой команды.
Себестоимость важна, но не только она
Чтобы заработать на оказании услуг, а не просто сделать доброе дело клиенту, используемая ставка должна покрывать себестоимость услуги для компании подрядчика. Сразу хочу оговориться, что неравенство “ставка больше себестоимости”, хотя и кажется логичным, работает далеко не всегда и не по всем ставкам на клиенте. Зачастую, ради входа в нового перспективного клиента или, наоборот, для того, чтобы не дать войти конкуренту, компании готовы пойти на инвестирование в клиента собственных средств, то есть подать ставку, которая не только не дает получить прибыль, но и вообще оказывается планово убыточной.
Другой пример, иногда ставка за работу тимлида не покрывает себестоимость дорогого специалиста, но зато прибыль от работы пяти-шести рядовых специалистов, которые трудятся на проекте у заказчика под его началом, покрывает и затраты на всю команду целиком.
Понятно, что для того, чтобы правильно учитывать себестоимость при расчете ставки для клиента, требуется уметь ее корректно посчитать. Сейчас не те времена, чтобы клиент покупал ресурсы втридорога. Конкуренция практически во всех областях ИТ-услуг высокая, и клиенту не требуется много усилий, чтобы получить как минимум несколько (а иногда и несколько десятков) релевантных предложений от подрядчиков, которые могут предоставить специалистов нужной квалификации и с нужным опытом. Поэтому сильно задрать маржинальность, чтобы она покрыла все неточности расчета себестоимости, с большой вероятностью не получится. Следовательно, приходится глубоко вникать во все затраты – не только прямые (зарплаты, премии, отпускные, больничные, налоги на персонал), но и косвенные, ведь нужно оплачивать работу администратора, аккаунт-менеджера, руководителей отделов и топ-менеджеров, офисные помещения и т. п. Поиск сотрудников, наём, первоначальное обучение, курирование в процессе вливания в коллектив и пр. тоже обходятся недешево. И все это составляющие себестоимости, которую в идеале должна покрыть ставка. Иначе платить придется кому-то другому, на проекте с другим клиентом, но там тоже вряд ли будут рады “раздутой” цене на услуги.
Хотя риски простоев по своей вине в аутстаф-контрактах берет на себя заказчик, он точно не возьмет на себя простои по вине исполнителя, больничные, отпуска и пр. Платить подрядчику он будет только за те часы или дни, которые реально отработаны. Если ваш VPN-канал до клиента, на котором сидят ваши сотрудники, периодически отваливается, то это будет простой по вашей вине. Если вы затеяли тимбилдинг или обучение для своих сотрудников, то это, конечно, полезно и приятно, но клиент за это тоже не заплатит. Поэтому при расчете себестоимости приходится прогнозировать как можно точнее все эти будущие возможные события по всей команде. Задача – понять сколько дней (за месяц, за период оказания услуг) будет реализовано “на клиенте”, будет оплачено по согласованной с ним ставке. Ведь получите деньги вы за те часы/дни, которые были приняты клиентом, а зарплату сотрудникам придется в любом случае выплатить целиком. Да и премии, надбавки и прочие выплаты тоже не получится снизить, если сокращение отработанных на проекте с клиентом ЧД произошло не по прямой вине конкретного сотрудника.
Если клиент привлекает вашу команду на длительный срок, если есть накопленная история взаимодействия, то удобно прикинуть сколько ЧД команда отработает в год, в разрезе конкретных членов этой команды. Намного проще и точнее делать это на основе статистики за прошлые годы, если таковая имеется.
На мой взгляд, 220 дней, отработанных и принятых клиентом за год при примерно 250 рабочих днях, – отличная реализация. Конечно, бывают уникумы, которые и 260 дней могут отработать, работая без отпусков и беря по выходным задачи на переработки, но таких героев не так много, зато много людей, которые сами болеют или вынуждены сидеть с заболевшими детьми, у которых реализация опускается ниже 200 или даже 190 дней в году, а расходы на них при этом не становятся сильно меньше. Поэтому для себестоимости для расчета ставки, если нет четкой статистики, можно взять 200-210 дней реализации в год (1600-1680 часов), и делить все годовые затраты на сотрудника на это число, чтобы получить дневную себестоимость человека. И клиенту довольно легко показать, что это справедливая оценка оплачиваемых дней в году, если до таких обоснований дойдет дело.
28 календарных дней отпуска, пару больничных в год по три-четыре дня исключать нельзя, пара дней отгулов с большой вероятностью понадобится, ведь кого‑то обязательно зальют соседи, а кто‑то должен будет сидеть с ребенком, пока садик закрыли из‑за подозрительного звонка, обучение на два‑три дня — это святое, ведь если не давать людям развиваться, то они поищут себе другого работодателя, а пару обязательных корпоративных мероприятий тоже не пропустить. Для вас, как подрядчика, важно показать вариант, отражающий реальную картину, чтобы у заказчика складывалось правильное понимание о реальном бюджете, который потребует запрошенная им команда. Ведь расчет по простой формуле «количество рабочих дней на ставку» дает сильно завышенный результат.
Чтобы заработать на оказании услуг, а не просто сделать доброе дело клиенту, используемая ставка должна покрывать себестоимость услуги для компании подрядчика. Сразу хочу оговориться, что неравенство “ставка больше себестоимости”, хотя и кажется логичным, работает далеко не всегда и не по всем ставкам на клиенте. Зачастую, ради входа в нового перспективного клиента или, наоборот, для того, чтобы не дать войти конкуренту, компании готовы пойти на инвестирование в клиента собственных средств, то есть подать ставку, которая не только не дает получить прибыль, но и вообще оказывается планово убыточной.
Другой пример, иногда ставка за работу тимлида не покрывает себестоимость дорогого специалиста, но зато прибыль от работы пяти-шести рядовых специалистов, которые трудятся на проекте у заказчика под его началом, покрывает и затраты на всю команду целиком.
Понятно, что для того, чтобы правильно учитывать себестоимость при расчете ставки для клиента, требуется уметь ее корректно посчитать. Сейчас не те времена, чтобы клиент покупал ресурсы втридорога. Конкуренция практически во всех областях ИТ-услуг высокая, и клиенту не требуется много усилий, чтобы получить как минимум несколько (а иногда и несколько десятков) релевантных предложений от подрядчиков, которые могут предоставить специалистов нужной квалификации и с нужным опытом. Поэтому сильно задрать маржинальность, чтобы она покрыла все неточности расчета себестоимости, с большой вероятностью не получится. Следовательно, приходится глубоко вникать во все затраты – не только прямые (зарплаты, премии, отпускные, больничные, налоги на персонал), но и косвенные, ведь нужно оплачивать работу администратора, аккаунт-менеджера, руководителей отделов и топ-менеджеров, офисные помещения и т. п. Поиск сотрудников, наём, первоначальное обучение, курирование в процессе вливания в коллектив и пр. тоже обходятся недешево. И все это составляющие себестоимости, которую в идеале должна покрыть ставка. Иначе платить придется кому-то другому, на проекте с другим клиентом, но там тоже вряд ли будут рады “раздутой” цене на услуги.
Хотя риски простоев по своей вине в аутстаф-контрактах берет на себя заказчик, он точно не возьмет на себя простои по вине исполнителя, больничные, отпуска и пр. Платить подрядчику он будет только за те часы или дни, которые реально отработаны. Если ваш VPN-канал до клиента, на котором сидят ваши сотрудники, периодически отваливается, то это будет простой по вашей вине. Если вы затеяли тимбилдинг или обучение для своих сотрудников, то это, конечно, полезно и приятно, но клиент за это тоже не заплатит. Поэтому при расчете себестоимости приходится прогнозировать как можно точнее все эти будущие возможные события по всей команде. Задача – понять сколько дней (за месяц, за период оказания услуг) будет реализовано “на клиенте”, будет оплачено по согласованной с ним ставке. Ведь получите деньги вы за те часы/дни, которые были приняты клиентом, а зарплату сотрудникам придется в любом случае выплатить целиком. Да и премии, надбавки и прочие выплаты тоже не получится снизить, если сокращение отработанных на проекте с клиентом ЧД произошло не по прямой вине конкретного сотрудника.
Если клиент привлекает вашу команду на длительный срок, если есть накопленная история взаимодействия, то удобно прикинуть сколько ЧД команда отработает в год, в разрезе конкретных членов этой команды. Намного проще и точнее делать это на основе статистики за прошлые годы, если таковая имеется.
На мой взгляд, 220 дней, отработанных и принятых клиентом за год при примерно 250 рабочих днях, – отличная реализация. Конечно, бывают уникумы, которые и 260 дней могут отработать, работая без отпусков и беря по выходным задачи на переработки, но таких героев не так много, зато много людей, которые сами болеют или вынуждены сидеть с заболевшими детьми, у которых реализация опускается ниже 200 или даже 190 дней в году, а расходы на них при этом не становятся сильно меньше. Поэтому для себестоимости для расчета ставки, если нет четкой статистики, можно взять 200-210 дней реализации в год (1600-1680 часов), и делить все годовые затраты на сотрудника на это число, чтобы получить дневную себестоимость человека. И клиенту довольно легко показать, что это справедливая оценка оплачиваемых дней в году, если до таких обоснований дойдет дело.
28 календарных дней отпуска, пару больничных в год по три-четыре дня исключать нельзя, пара дней отгулов с большой вероятностью понадобится, ведь кого‑то обязательно зальют соседи, а кто‑то должен будет сидеть с ребенком, пока садик закрыли из‑за подозрительного звонка, обучение на два‑три дня — это святое, ведь если не давать людям развиваться, то они поищут себе другого работодателя, а пару обязательных корпоративных мероприятий тоже не пропустить. Для вас, как подрядчика, важно показать вариант, отражающий реальную картину, чтобы у заказчика складывалось правильное понимание о реальном бюджете, который потребует запрошенная им команда. Ведь расчет по простой формуле «количество рабочих дней на ставку» дает сильно завышенный результат.
Маржинальность: тактика или стратегия?
Себестоимость дня (часа) – это важный фактор для расчета ставки, но помимо компенсации затрат хочется и прибыль получить. Представления о приемлемой маржинальности у каждой компании свои. Ведь маржа, тем более плановая, далеко не всегда равна прибыли. В наше неспокойное время какие-то форс-мажоры возникают на каждом шагу. Риски отмены проектов, переноса сроков и т. п. реализуются с завидной регулярностью, и потери от реализации этих рисков нужно как-то компенсировать. Например, на одном из проектов “ГлоуБайт” заказчик решил резко сократить команду, потому что сверху “спустили” команду урезать бюджет. Да, по договору он должен был предупредить вас о высвобождении людей за два месяца, чтобы вы успели подыскать им новый проект. Но на практике он просит вас отозвать их через две недели и предупреждает, что, к большому сожалению, не сможет оплатить ни дня больше. Не пойдете же вы из-за этого в суд? Скорее всего, нет. Люди будут простаивать, хорошо если только месяц, а платить за это придется из кармана подрядчика, где трудоустроены эти специалисты.
Другой пример, эксперт из вашей команды, который очень нравился заказчику, вдруг решил уволиться (и такое случается: предложили в полтора раза больше денег). Лояльный заказчик расстроен, но готов к замене. Только просит вас на период онбординга нового человека не выставлять за него счет, потому что проблема возникала по вашей вине. А платить зарплату человеку все время этого онбординга нужно. Онбординг на сложных проектах требует месяца или больше, чтобы новый человек смог на приемлемом уровне разобраться и начать работать с достаточной эффективностью, чтобы за него готовы были платить в полном объеме.
Учесть все эти многочисленные риски и заложить их в себестоимость нереально, да и нет смысла. По-хорошему, их должна покрывать маржа. Кто-то в рамках своей стратегии считает, ничего очень уж нехорошего произойти не может и закладывает относительно скромную маржу – и если неожиданный риск случается, пытается по-максимуму компенсировать дополнительные затраты за счет клиента. Это может существенно влиять на качество сервиса и его удобство для заказчика. Кто-то, наоборот, старается заложить в ставку достаточную маржу, чтобы можно было не травмировать клиента в случае возникновения неожиданных проблем (часть из которых все равно неизбежно случится), а компенсировать эти расходы за счет собственного “жирка”.
В любом случае на сверхприбыль на рынке аутстаф- или аутсорс-услуг рассчитывать не приходится. Жадность подрядчика в большинстве случаев сталкивается с прижимистостью заказчика, помноженной на высокую конкуренцию на рынке практически во всех сферах и направлениях. Более высокая маржинальность возможна только в ряде особых случаев – предоставление специалистов с уникальными компетенциями, срочный вывод команды (например, когда проект у заказчика под угрозой срыва), глубокая привязка заказчика к команде подрядчика (в силу большой сложности ее замены).
Себестоимость дня (часа) – это важный фактор для расчета ставки, но помимо компенсации затрат хочется и прибыль получить. Представления о приемлемой маржинальности у каждой компании свои. Ведь маржа, тем более плановая, далеко не всегда равна прибыли. В наше неспокойное время какие-то форс-мажоры возникают на каждом шагу. Риски отмены проектов, переноса сроков и т. п. реализуются с завидной регулярностью, и потери от реализации этих рисков нужно как-то компенсировать. Например, на одном из проектов “ГлоуБайт” заказчик решил резко сократить команду, потому что сверху “спустили” команду урезать бюджет. Да, по договору он должен был предупредить вас о высвобождении людей за два месяца, чтобы вы успели подыскать им новый проект. Но на практике он просит вас отозвать их через две недели и предупреждает, что, к большому сожалению, не сможет оплатить ни дня больше. Не пойдете же вы из-за этого в суд? Скорее всего, нет. Люди будут простаивать, хорошо если только месяц, а платить за это придется из кармана подрядчика, где трудоустроены эти специалисты.
Другой пример, эксперт из вашей команды, который очень нравился заказчику, вдруг решил уволиться (и такое случается: предложили в полтора раза больше денег). Лояльный заказчик расстроен, но готов к замене. Только просит вас на период онбординга нового человека не выставлять за него счет, потому что проблема возникала по вашей вине. А платить зарплату человеку все время этого онбординга нужно. Онбординг на сложных проектах требует месяца или больше, чтобы новый человек смог на приемлемом уровне разобраться и начать работать с достаточной эффективностью, чтобы за него готовы были платить в полном объеме.
Учесть все эти многочисленные риски и заложить их в себестоимость нереально, да и нет смысла. По-хорошему, их должна покрывать маржа. Кто-то в рамках своей стратегии считает, ничего очень уж нехорошего произойти не может и закладывает относительно скромную маржу – и если неожиданный риск случается, пытается по-максимуму компенсировать дополнительные затраты за счет клиента. Это может существенно влиять на качество сервиса и его удобство для заказчика. Кто-то, наоборот, старается заложить в ставку достаточную маржу, чтобы можно было не травмировать клиента в случае возникновения неожиданных проблем (часть из которых все равно неизбежно случится), а компенсировать эти расходы за счет собственного “жирка”.
В любом случае на сверхприбыль на рынке аутстаф- или аутсорс-услуг рассчитывать не приходится. Жадность подрядчика в большинстве случаев сталкивается с прижимистостью заказчика, помноженной на высокую конкуренцию на рынке практически во всех сферах и направлениях. Более высокая маржинальность возможна только в ряде особых случаев – предоставление специалистов с уникальными компетенциями, срочный вывод команды (например, когда проект у заказчика под угрозой срыва), глубокая привязка заказчика к команде подрядчика (в силу большой сложности ее замены).
Объемы. Больше – дешевле
Хорошая практика, когда заказчик сразу, на этапе запроса предложения, обозначает потенциальный объем задачи, на которую планируется привлечение подрядчиков. Это могут быть два отдельных показателя – гарантированный и опциональный. В первом варианте речь о том, что определенное количество человеко-дней заказчик планирует выбрать и оплатить точно. Во-втором – объем возможно будет, а может быть и нет, в зависимости от каких-то факторов, которые прояснятся только в будущем.
В ряде случаев обозначается срок привлечения и примерный состав команды, которую требуется вывести, что в совокупности и дает подрядчикам представление о потенциальных объемах.
Срок привлечения – сам по себе важный фактор принятия решения по ставкам для подрядчика, особенно в наше турбулентное время. Если ИТ-компания понимает, что сможет на пару лет, например, гарантированно разместить команду у заказчика и получать стабильный доход, то она точно сможет пожертвовать частью маржи ради такой стабильности.
Некоторые клиенты не могут обозначить сроки и состав команды, поскольку задача еще недостаточно проработана или же на стороне клиента нет необходимых специалистов, чтобы это оценить. При этом готовы выдать ТЗ с каким-то уровнем проработки задачи или собранные требования на планируемый проект. Этих артефактов часто достаточно, чтобы опытный подрядчик смог понять, что требуется сделать, и дальше уже сам прикинул, какой потребуется объем ресурсов.
Как правило, бюджет заказчика на привлечение внешнего ресурса ограничен какой-то величиной. Она может быть строго рассчитана на основании прогноза трудозатрат и рыночных ставок. Может быть просто определена как некое дополнение к уже выделенному ранее бюджету проекта, который выполняется заказчиком своими силами в виде процента от уже выделенных средств. Но если бюджет на привлечение внешних ресурсов значительный и заказчик готов в той или иной форме показать потенциальным подрядчикам этот лимит, он может рассчитывать на экономию за счет скидки на объем. Подрядчик будет готов к сокращению своей маржи, поскольку сможет занять бОльшую команду на более длительный срок, что снизит как минимум затраты на пресейлы, онбординг и прочее.
Хорошая практика, когда заказчик сразу, на этапе запроса предложения, обозначает потенциальный объем задачи, на которую планируется привлечение подрядчиков. Это могут быть два отдельных показателя – гарантированный и опциональный. В первом варианте речь о том, что определенное количество человеко-дней заказчик планирует выбрать и оплатить точно. Во-втором – объем возможно будет, а может быть и нет, в зависимости от каких-то факторов, которые прояснятся только в будущем.
В ряде случаев обозначается срок привлечения и примерный состав команды, которую требуется вывести, что в совокупности и дает подрядчикам представление о потенциальных объемах.
Срок привлечения – сам по себе важный фактор принятия решения по ставкам для подрядчика, особенно в наше турбулентное время. Если ИТ-компания понимает, что сможет на пару лет, например, гарантированно разместить команду у заказчика и получать стабильный доход, то она точно сможет пожертвовать частью маржи ради такой стабильности.
Некоторые клиенты не могут обозначить сроки и состав команды, поскольку задача еще недостаточно проработана или же на стороне клиента нет необходимых специалистов, чтобы это оценить. При этом готовы выдать ТЗ с каким-то уровнем проработки задачи или собранные требования на планируемый проект. Этих артефактов часто достаточно, чтобы опытный подрядчик смог понять, что требуется сделать, и дальше уже сам прикинул, какой потребуется объем ресурсов.
Как правило, бюджет заказчика на привлечение внешнего ресурса ограничен какой-то величиной. Она может быть строго рассчитана на основании прогноза трудозатрат и рыночных ставок. Может быть просто определена как некое дополнение к уже выделенному ранее бюджету проекта, который выполняется заказчиком своими силами в виде процента от уже выделенных средств. Но если бюджет на привлечение внешних ресурсов значительный и заказчик готов в той или иной форме показать потенциальным подрядчикам этот лимит, он может рассчитывать на экономию за счет скидки на объем. Подрядчик будет готов к сокращению своей маржи, поскольку сможет занять бОльшую команду на более длительный срок, что снизит как минимум затраты на пресейлы, онбординг и прочее.
Рис. 1. Заказчику нужен один человек на неделю, но он хочет получить ставки, как-будто берет двадцать человек на год
Обратная ситуация, не очень приятная для подрядчиков, – заказчик хочет получить одного специалиста на неделю, а ставку желает увидеть такую, как будто привлекает 20 человек на год. Это можно принять, в случае если есть перспективы получить на проекте с этим заказчиком большой объем после того, как хорошо покажет себя на маленьком. В этом случае можно воспринимать низкомаржинальный небольшой контракт как хорошую возможность провести платный пресейл. Но перспективы расширения обычно далеко не стопроцентные. Особенно в части услуг аутстаф, где экспертиза и контроль проекта остаются полностью на стороне заказчика и поменять одного подрядчика на другого проще, чем в случае с реализацией проекта под ключ.
Но самая неприятная ситуация, на мой взгляд, когда заказчик просит дать ставки, вообще не обозначая при этом потенциальный объем привлечения ресурсов. Если это происходит в рамках предварительного исследования заказчиком рынка, то обычно еще можно как-то поговорить с клиентом, пояснить ему, что объем – очень важный фактор ценообразования. Параллельно в ходе обсуждений понять хотя бы примерно, что требуется от команды подрядчика и какой объем работ ожидается.
Но если запрос заказчика пришел уже в рамках официального тендера, то зачастую выяснить эту информацию уже не получается. В этом случае каждый подрядчик будет думать про потенциальный объем работ что-то свое – и заказчик в итоге станет сравнивать яблоки с апельсинами. Ведь подрядчик, который предложил низкую ставку, возможно, исходил из того, что работ будет много. В итоге, когда он обнаружит, что потребуется на порядок меньше ЧД, чем он ожидал, то он либо просто потеряет интерес к заказчику, либо станет предпринимать различные действия, чтобы снизить свои потери.
В таком случае заказчик будет получать предложения по специалистам с более низкой квалификацией, чем он ожидал, растянутся сроки подбора нужных людей (вместо штатных, подрядчик пойдет искать кого-то подешевле на рынке) или вообще будет объявлено о том, что, к сожалению, в моменте все нужные специалисты заняты. Резюмируя, стоит сказать, что предоставление реальной информации об объемах привлечения в интересах не только подрядчиков, но и заказчика. Скрывая ее, можно получить более низкую цену проекта – и прямо противоположный эффект.
Но самая неприятная ситуация, на мой взгляд, когда заказчик просит дать ставки, вообще не обозначая при этом потенциальный объем привлечения ресурсов. Если это происходит в рамках предварительного исследования заказчиком рынка, то обычно еще можно как-то поговорить с клиентом, пояснить ему, что объем – очень важный фактор ценообразования. Параллельно в ходе обсуждений понять хотя бы примерно, что требуется от команды подрядчика и какой объем работ ожидается.
Но если запрос заказчика пришел уже в рамках официального тендера, то зачастую выяснить эту информацию уже не получается. В этом случае каждый подрядчик будет думать про потенциальный объем работ что-то свое – и заказчик в итоге станет сравнивать яблоки с апельсинами. Ведь подрядчик, который предложил низкую ставку, возможно, исходил из того, что работ будет много. В итоге, когда он обнаружит, что потребуется на порядок меньше ЧД, чем он ожидал, то он либо просто потеряет интерес к заказчику, либо станет предпринимать различные действия, чтобы снизить свои потери.
В таком случае заказчик будет получать предложения по специалистам с более низкой квалификацией, чем он ожидал, растянутся сроки подбора нужных людей (вместо штатных, подрядчик пойдет искать кого-то подешевле на рынке) или вообще будет объявлено о том, что, к сожалению, в моменте все нужные специалисты заняты. Резюмируя, стоит сказать, что предоставление реальной информации об объемах привлечения в интересах не только подрядчиков, но и заказчика. Скрывая ее, можно получить более низкую цену проекта – и прямо противоположный эффект.
Роли. Иногда стоит пройтись бритвой Оккама
Хорошо иметь дело с профессионалами-универсалами, которые и с бизнесом на одном языке могут поговорить, и ТЗ написать, и код на Питоне или SQL, и архитектуру ХД правильно подобрать, и убедить всех, что все должно быть именно так, как было предложено, а не иначе. Универсалы в командах подрядчиков есть, но это “штучные” специалисты и, говоря про типовой аутстаф- или аутсорс-проект, трудно рассчитывать, что какие-то подрядчики смогут предоставить именно такого эксперта, а если и смогут, то вряд ли их будет больше одного.
В большинстве же случаев заказчик у подрядчиков запрашивает специалистов не на одну роль, а на несколько, иногда на десятки разных ролей, если это общекорпоративный запрос. Но тут, кажется, стоит всегда разделять запрос ролей и запрос ставок. Ролей может быть много, для каждой заказчик в идеальной ситуации присылает подробное описание требований к опыту, квалификации, стеку. Разработчик Java, разработчик JS, разработчик ETL, BI-аналитик, ХД-аналитик, 1С-аналитик и т. п. Но совсем не обязательно, чтобы на каждую из десятков ролей была установлена своя индивидуальная ставка. Мое мнение, что сильно мельчить в запросе ставок и в дифференциации ставок нет практического смысла. Если проводить тонкое статистическое исследование, то можно, конечно, посчитать свою себестоимость для каждой отдельной роли – для системного аналитика, для бизнес-аналитика по финансовому направлению, по направлению CRM, для разработчика на Java и для разработчика на Go и так до бесконечности.
Статистически сложившиеся в компании отличия по ЗП для ролей, безусловно, есть. Но так ли они значимы, чтобы иметь для них отдельные ставки. Двадцать рублей туда или сюда большой роли не играют. Но запросы на десятки ставок для десятков ролей – это значительное усложнение всех процедур, а зачастую и прямой путь к злоупотреблениям в конкурсах, о чем пойдет речь далее. По-моему, достаточно двух основных ролей – аналитик и разработчик, ставки по которым устанавливаются в разрезе грейдов (см. далее). Ну, если принципиально, то из основных можно еще добавить тестировщика.
Все вышесказанное справедливо для типовых ролей. Но есть позиции, которые находятся в моменте на пике интереса со стороны клиентов, спрос по ним превышает предложение, поэтому ставки по ним могут быть существенно выше, чем по прочим, и позиционировать их корректнее отдельно. К таким ролям можно отнести, например, в контексте услуг “ГлоуБайт”, которая в основном занимается данными и аналитикой, – ИИ-инженеров, разработчиков AI-агентов, DevSecOps-инженеров. Тут разница с “обычными” аналитиками и разработчиками может быть 20-30% для тех же грейдов, поэтому отдельные ставки оправданы.
Дополнительные роли, которые редко оказывают существенное влияние на стоимость проекта, – это DevOps-специалисты, архитекторы и руководители проекта. Цена на этих специалистов может быть довольно высокой. Но если конкретные персоналии заинтересуют заказчика, то он вполне может согласиться заплатить и в два раза дороже, чем за аналитика, например. Из-за того, что трудозатраты таких специалистов составляют относительно небольшой процент от общих затрат по проекту, их влияние на бюджет несущественно, поэтому решения о приемлемости более высоких ставок принимаются легче.
В целом для расчета сметы любого ИТ-проекта можно обойтись всего несколькими ролями. А значит, лишние ставки ни в запросе, ни в КП плодить по-хорошему не нужно.
Еще интересный момент – соотношение ставок основных ролей. Почему, скажем, аналитик должен стоить для заказчика дороже разработчика? Или почему ставка руководителя проекта должна быть выше ставки аналитика? Только потому, что в вашей компании сложилась такая статистика по ЗП? Представляется, что даже единое значение ставки на аналитика, разработчика, руководителя проекта может быть вполне жизнеспособно, будет понятно для заказчика и позволит упростить все сметные прогнозы и расчеты. Я не спорю, что вариации ставок разных ролей возможны, но, как мне кажется, не несут глубокого смысла.
Приходится периодически сталкиваться с тем, что компании пытаются устанавливать на некоторые роли относительно дешевые ставки, иногда даже заведомо убыточные для подрядчика. Делается это для того, чтобы через такой демпинг войти в проект с новым клиентом. При этом похожие, но другие роли (например, разработчик ETL и дата-инженер) подают существенно дороже, предполагая на них заработать. Если клиент выбирает только одного подрядчика, то это, конечно, может сработать. Но, как правило, все же подрядчиков на аутстаф бывает несколько, и тогда такая уловка может в итоге сработать против того, кто ее применяет. В целом склонен считать, что чрезмерно широкий спектр разных ставок по похожим ролям – это следствие какой-то схемы или просто избыточность, которую вполне можно упростить без каких-либо потерь.
Хорошо иметь дело с профессионалами-универсалами, которые и с бизнесом на одном языке могут поговорить, и ТЗ написать, и код на Питоне или SQL, и архитектуру ХД правильно подобрать, и убедить всех, что все должно быть именно так, как было предложено, а не иначе. Универсалы в командах подрядчиков есть, но это “штучные” специалисты и, говоря про типовой аутстаф- или аутсорс-проект, трудно рассчитывать, что какие-то подрядчики смогут предоставить именно такого эксперта, а если и смогут, то вряд ли их будет больше одного.
В большинстве же случаев заказчик у подрядчиков запрашивает специалистов не на одну роль, а на несколько, иногда на десятки разных ролей, если это общекорпоративный запрос. Но тут, кажется, стоит всегда разделять запрос ролей и запрос ставок. Ролей может быть много, для каждой заказчик в идеальной ситуации присылает подробное описание требований к опыту, квалификации, стеку. Разработчик Java, разработчик JS, разработчик ETL, BI-аналитик, ХД-аналитик, 1С-аналитик и т. п. Но совсем не обязательно, чтобы на каждую из десятков ролей была установлена своя индивидуальная ставка. Мое мнение, что сильно мельчить в запросе ставок и в дифференциации ставок нет практического смысла. Если проводить тонкое статистическое исследование, то можно, конечно, посчитать свою себестоимость для каждой отдельной роли – для системного аналитика, для бизнес-аналитика по финансовому направлению, по направлению CRM, для разработчика на Java и для разработчика на Go и так до бесконечности.
Статистически сложившиеся в компании отличия по ЗП для ролей, безусловно, есть. Но так ли они значимы, чтобы иметь для них отдельные ставки. Двадцать рублей туда или сюда большой роли не играют. Но запросы на десятки ставок для десятков ролей – это значительное усложнение всех процедур, а зачастую и прямой путь к злоупотреблениям в конкурсах, о чем пойдет речь далее. По-моему, достаточно двух основных ролей – аналитик и разработчик, ставки по которым устанавливаются в разрезе грейдов (см. далее). Ну, если принципиально, то из основных можно еще добавить тестировщика.
Все вышесказанное справедливо для типовых ролей. Но есть позиции, которые находятся в моменте на пике интереса со стороны клиентов, спрос по ним превышает предложение, поэтому ставки по ним могут быть существенно выше, чем по прочим, и позиционировать их корректнее отдельно. К таким ролям можно отнести, например, в контексте услуг “ГлоуБайт”, которая в основном занимается данными и аналитикой, – ИИ-инженеров, разработчиков AI-агентов, DevSecOps-инженеров. Тут разница с “обычными” аналитиками и разработчиками может быть 20-30% для тех же грейдов, поэтому отдельные ставки оправданы.
Дополнительные роли, которые редко оказывают существенное влияние на стоимость проекта, – это DevOps-специалисты, архитекторы и руководители проекта. Цена на этих специалистов может быть довольно высокой. Но если конкретные персоналии заинтересуют заказчика, то он вполне может согласиться заплатить и в два раза дороже, чем за аналитика, например. Из-за того, что трудозатраты таких специалистов составляют относительно небольшой процент от общих затрат по проекту, их влияние на бюджет несущественно, поэтому решения о приемлемости более высоких ставок принимаются легче.
В целом для расчета сметы любого ИТ-проекта можно обойтись всего несколькими ролями. А значит, лишние ставки ни в запросе, ни в КП плодить по-хорошему не нужно.
Еще интересный момент – соотношение ставок основных ролей. Почему, скажем, аналитик должен стоить для заказчика дороже разработчика? Или почему ставка руководителя проекта должна быть выше ставки аналитика? Только потому, что в вашей компании сложилась такая статистика по ЗП? Представляется, что даже единое значение ставки на аналитика, разработчика, руководителя проекта может быть вполне жизнеспособно, будет понятно для заказчика и позволит упростить все сметные прогнозы и расчеты. Я не спорю, что вариации ставок разных ролей возможны, но, как мне кажется, не несут глубокого смысла.
Приходится периодически сталкиваться с тем, что компании пытаются устанавливать на некоторые роли относительно дешевые ставки, иногда даже заведомо убыточные для подрядчика. Делается это для того, чтобы через такой демпинг войти в проект с новым клиентом. При этом похожие, но другие роли (например, разработчик ETL и дата-инженер) подают существенно дороже, предполагая на них заработать. Если клиент выбирает только одного подрядчика, то это, конечно, может сработать. Но, как правило, все же подрядчиков на аутстаф бывает несколько, и тогда такая уловка может в итоге сработать против того, кто ее применяет. В целом склонен считать, что чрезмерно широкий спектр разных ставок по похожим ролям – это следствие какой-то схемы или просто избыточность, которую вполне можно упростить без каких-либо потерь.
Грейды. Движение вверх всегда хорошо… если это не про деньги заказчика
Поход по карьерной лестнице любого айтишника стартует с позиции джуна. Не важно, занимается ли человек разработкой, аналитикой, поддержкой, тестированием или чем-то еще. Затем, года через два, человек переходит на позицию мидла, потом еще года через три становится старшим специалистом, потом тимлидом, руководителем направления и далее все выше и выше к звездам. Руководители, они на то и руководители, чтобы управлять коллективом, а не пахать на аутстаф-проектах у заказчика, поэтому никто их обычно в аутстаф не берет и не предлагает.
Поход по карьерной лестнице любого айтишника стартует с позиции джуна. Не важно, занимается ли человек разработкой, аналитикой, поддержкой, тестированием или чем-то еще. Затем, года через два, человек переходит на позицию мидла, потом еще года через три становится старшим специалистом, потом тимлидом, руководителем направления и далее все выше и выше к звездам. Руководители, они на то и руководители, чтобы управлять коллективом, а не пахать на аутстаф-проектах у заказчика, поэтому никто их обычно в аутстаф не берет и не предлагает.
Рис. 2. Джунов обычно мало кто берет в аутстаф, а уникальные эксперты высших грейдов могут стоить любых денег, если они сильно нужны заказчику
Таким образом, в T&M реально интересны ставки только 3-4 грейдов. С поправкой на то, что редко кому нужны в T&M не только большие боссы, но и джуны (с ними ведь много забот по постоянному мониторингу и корректировке результатов, а выхлоп небольшой даже при относительно невысоких ставках). В итоге получается, что ставки в стандартном для аутстаф-/аутсорс-запросе просят на мидлов, старших специалистов и тимлидов.
Первую проблему можем поймать уже в самом начале, при попытке идентификации запрашиваемых грейдов и мэппировании названий грейдов заказчика на грейды подрядчика. Уровней квалификации ведь может быть разное количество и называться они могут совершенно по-разному в разных компаниях. Где-то младший, специалист, старший, тимлид; где-то – джун, джун+, мидл, мидл+, сеньор, принципал; где-то – базовый, средний, старший, высший, архитектор. А где-то и совсем просто: первый, второй, третий и т. д.
Хорошо, если заказчик четко обозначает свои требования к каждому грейду в годах опыта, числе проектов, наличии конкретных знаний. Но часто, кроме названий грейдов и краткого описания задач, ничего “на вход” подрядчику не поступает. А подрядчик, который хочет продать свою простаивающую команду, посмотрев такие требования, может легко сказать, что его джуны уже через три месяца все это умеют. Может быть, он даже где-то будет прав. И проблема вскроется только на собеседовании или вообще уже после того, как этот джун с месяцами опыта окажется в самостоятельном плавании – в непростой организационной и технологической ситуации между бизнесом, ИТ, проектным офисом заказчика, которому нужен результат, и молодой специалист для него, возможно, – не более чем внешний ресурс.
Я бы на месте руководителя менеджера подрядчика, который подбирает команду для заказчика, подумал, стоит ли идти по пути наименьшего сопротивления (или пути получения наибольшей прибыли), продавая джунов как мидлов и т. п. Для начала хорошо бы разобраться в том, как понимает грейды заказчик, что он реально хочет, чтобы умели предоставляемые ему специалисты, какие наиболее сложные задачи каждому грейду придется решать.
Кстати, тут есть и обратная задача, которая в реальности встречается не так уже редко, – когда сеньор-специалиста ставят на задачи мидла. Если человек у подрядчика простаивает, например, а ставка мидла вполне приятная и обеспечивает при выводе на позицию данного сотрудника нормальную маржу. Но сможет ли старший специалист, переросший мидловые задачи, долго на них сидеть? Вопрос открытый, поскольку сильно зависит собственно от характера и стремлений человека, атмосферы у заказчика и многого другого. Но это уже скорее вопрос не ставок, а управления командой, который подробно разбирать тут не планировалось.
Вторая важная проблема ценообразования, связанная с грейдами, – поиск правильного соотношения ставок джуна, мидла, старшего, тимлида. С одной стороны, любая компания хотя бы как-то понимает себестоимость своих специалистов разных уровней, у нее есть статистика, на сколько в среднем больше ЗП у мидла, чем у джуна и т. д. Разница между ЗП по грейдам может быть 30-50% в среднем, а между крайними значениями и все 100-150%.
Представьте себе лицо вашего заказчика, когда вы говорите ему, что ваш мидл, которого вы вывели на проект полгода назад, стал старшим и поэтому теперь будет стоить для заказчика на 40% дороже (при том, что скоуп задач его может остаться почти таким же, как и раньше). Размер компенсации обычно растет плавно, ежегодно. Вряд ли кто-то в рамках одной компании может рассчитывать, что ему единоразово повысят зарплату в два раза. Поэтому, хотя разница между ставками младших и средних специалистов может достигать 30-50%, вводятся промежуточные позиции типа джун+, чтобы сократить разрыв и приблизить значение роста ставки к росту затрат компании на сотрудника. А вот при переходе от средних грейдов к старшим рост ставки зачастую скромнее – 15-25%. Обычно это ниже уровня роста ЗП, что, как мне кажется, отражает попытку найти баланс между себестоимостью специалистов и хорошими отношениями с заказчиком.
При этом ставки старших специалистов редко оказывают принципиальное влияние на общую стоимость команды подрядчика. Соотношение между числом старших и мидлов в команде крупного проекта (не важно, по “фиксу” он делается или по T&M) обычно один к четырем-пяти и даже более. Другое дело – проекты типа обследования, ИТ-аудита, разработки ИТ-стратегии, где часто команда целиком состоит из старших специалистов. Но такие проекты, во-первых, в основном делаются по модели “фикс прайс” (в силу большого уровня неопределенности и желания заказчика ограничить свои риски), а во-вторых, даже если кто-то и берет команды на обследования в режиме T&M, сами по себе такие проекты относительно нересурсоемкие. Поэтому удар по бюджету заказчика, даже если вам удалось согласовать с ним ставки старших специалистов на 40% выше ставок мидлов, будет не очень большой.
Есть еще пласт суперквалифицированных экспертов уровня принципал, главных специалистов, визионеров по определенным направлениям, архитекторов в различных областях, которые фактически являются “штучными” специалистами и которых у любого подрядчика единицы. Этих специалистов тоже периодически берут “в аренду”. Но ставки по ним не стоит мерить в процентах от средних и старших специалистов. Они могут быть любыми, из серии “на сколько договоритесь” (может быть, и в три, и более раза дороже среднего специалиста). Тут речь уже идет обычно не о конкурентном сравнении по цене, а о наличии доступного специалиста у подрядчика и желании заказчика получить его в рамках имеющегося бюджета. Часто даже бюджет в такой ситуации не является проблемой. Если специалист уникальный и задача, под которую его хотят взять, важна для клиента, то финансирование в достаточном объеме найдется, чтобы обеспечить эксперту возможность добиться поставленной цели.
Первую проблему можем поймать уже в самом начале, при попытке идентификации запрашиваемых грейдов и мэппировании названий грейдов заказчика на грейды подрядчика. Уровней квалификации ведь может быть разное количество и называться они могут совершенно по-разному в разных компаниях. Где-то младший, специалист, старший, тимлид; где-то – джун, джун+, мидл, мидл+, сеньор, принципал; где-то – базовый, средний, старший, высший, архитектор. А где-то и совсем просто: первый, второй, третий и т. д.
Хорошо, если заказчик четко обозначает свои требования к каждому грейду в годах опыта, числе проектов, наличии конкретных знаний. Но часто, кроме названий грейдов и краткого описания задач, ничего “на вход” подрядчику не поступает. А подрядчик, который хочет продать свою простаивающую команду, посмотрев такие требования, может легко сказать, что его джуны уже через три месяца все это умеют. Может быть, он даже где-то будет прав. И проблема вскроется только на собеседовании или вообще уже после того, как этот джун с месяцами опыта окажется в самостоятельном плавании – в непростой организационной и технологической ситуации между бизнесом, ИТ, проектным офисом заказчика, которому нужен результат, и молодой специалист для него, возможно, – не более чем внешний ресурс.
Я бы на месте руководителя менеджера подрядчика, который подбирает команду для заказчика, подумал, стоит ли идти по пути наименьшего сопротивления (или пути получения наибольшей прибыли), продавая джунов как мидлов и т. п. Для начала хорошо бы разобраться в том, как понимает грейды заказчик, что он реально хочет, чтобы умели предоставляемые ему специалисты, какие наиболее сложные задачи каждому грейду придется решать.
Кстати, тут есть и обратная задача, которая в реальности встречается не так уже редко, – когда сеньор-специалиста ставят на задачи мидла. Если человек у подрядчика простаивает, например, а ставка мидла вполне приятная и обеспечивает при выводе на позицию данного сотрудника нормальную маржу. Но сможет ли старший специалист, переросший мидловые задачи, долго на них сидеть? Вопрос открытый, поскольку сильно зависит собственно от характера и стремлений человека, атмосферы у заказчика и многого другого. Но это уже скорее вопрос не ставок, а управления командой, который подробно разбирать тут не планировалось.
Вторая важная проблема ценообразования, связанная с грейдами, – поиск правильного соотношения ставок джуна, мидла, старшего, тимлида. С одной стороны, любая компания хотя бы как-то понимает себестоимость своих специалистов разных уровней, у нее есть статистика, на сколько в среднем больше ЗП у мидла, чем у джуна и т. д. Разница между ЗП по грейдам может быть 30-50% в среднем, а между крайними значениями и все 100-150%.
Представьте себе лицо вашего заказчика, когда вы говорите ему, что ваш мидл, которого вы вывели на проект полгода назад, стал старшим и поэтому теперь будет стоить для заказчика на 40% дороже (при том, что скоуп задач его может остаться почти таким же, как и раньше). Размер компенсации обычно растет плавно, ежегодно. Вряд ли кто-то в рамках одной компании может рассчитывать, что ему единоразово повысят зарплату в два раза. Поэтому, хотя разница между ставками младших и средних специалистов может достигать 30-50%, вводятся промежуточные позиции типа джун+, чтобы сократить разрыв и приблизить значение роста ставки к росту затрат компании на сотрудника. А вот при переходе от средних грейдов к старшим рост ставки зачастую скромнее – 15-25%. Обычно это ниже уровня роста ЗП, что, как мне кажется, отражает попытку найти баланс между себестоимостью специалистов и хорошими отношениями с заказчиком.
При этом ставки старших специалистов редко оказывают принципиальное влияние на общую стоимость команды подрядчика. Соотношение между числом старших и мидлов в команде крупного проекта (не важно, по “фиксу” он делается или по T&M) обычно один к четырем-пяти и даже более. Другое дело – проекты типа обследования, ИТ-аудита, разработки ИТ-стратегии, где часто команда целиком состоит из старших специалистов. Но такие проекты, во-первых, в основном делаются по модели “фикс прайс” (в силу большого уровня неопределенности и желания заказчика ограничить свои риски), а во-вторых, даже если кто-то и берет команды на обследования в режиме T&M, сами по себе такие проекты относительно нересурсоемкие. Поэтому удар по бюджету заказчика, даже если вам удалось согласовать с ним ставки старших специалистов на 40% выше ставок мидлов, будет не очень большой.
Есть еще пласт суперквалифицированных экспертов уровня принципал, главных специалистов, визионеров по определенным направлениям, архитекторов в различных областях, которые фактически являются “штучными” специалистами и которых у любого подрядчика единицы. Этих специалистов тоже периодически берут “в аренду”. Но ставки по ним не стоит мерить в процентах от средних и старших специалистов. Они могут быть любыми, из серии “на сколько договоритесь” (может быть, и в три, и более раза дороже среднего специалиста). Тут речь уже идет обычно не о конкурентном сравнении по цене, а о наличии доступного специалиста у подрядчика и желании заказчика получить его в рамках имеющегося бюджета. Часто даже бюджет в такой ситуации не является проблемой. Если специалист уникальный и задача, под которую его хотят взять, важна для клиента, то финансирование в достаточном объеме найдется, чтобы обеспечить эксперту возможность добиться поставленной цели.
Встать на сторону клиента. Как выглядят ставки с его стороны
Принятие клиентом решения по выбору подрядчика – обычная задача, которую ежегодно решает бесчисленное количество компаний. Крупные опытные компании придерживаются понятной и подрядчикам, и заказчикам схемы выбора: сравнение разных подрядчиков между собой для определения наиболее подходящих. Сначала по стоп-факторам (опыт, квалификация, наличие ресурсов, скорость вывода сотрудников и разные доп. условия), чтобы не допустить до этапа ценового сравнения откровенно маргинальные варианты. Затем уже проводится сравнение по цене и определение победителя (победителей). Тут можно увидеть разные вариации подходов, которые в том числе описаны в разделе “Тендеры”, по части из которых трудно прогнозировать хороший результат.
Но, помимо вышеприведенного стандартного подхода, часто приходится сталкиваться с тем, что клиент пытается сравнивать предлагаемые подрядчиками ставки со своими расходами на персонал. Многим наверняка приходилось слышать такую фразу: “Да я за эти деньги…”. Эмоции в ряде случаев зашкаливают, а все потому, что клиент и подрядчик говорят о разном на разных языках. Особенно характерно это для случаев, когда клиент впервые привлекает внешних специалистов или же просто ответственный сотрудник заказчика не имеет необходимого опыта в этом. Например, заказчик часто полагает, что реализация (число оплачиваемых дней в месяц) специалистов на его проекте будет равна числу рабочих дней в месяце, что, допустим, составляет 23 дня. В реальности, с учетом отпусков, больничных, отгулов, внутренних обучений и пр. уважительных отвлечений, скорее всего оплачиваемых будет не более 17 дней в месяц. То есть клиенту фактически нужно будет платить на 25% меньше, чем он думал, просто посмотрев на ставку в час!
Другой вопрос, учитывает ли клиент, когда сравнивает ставки с зарплатами своих сотрудников, косвенные расходы – на наём, онбординг, курирование, обучение, переключение между проектами и пр. Понимает ли, что будет делать с сотрудниками, нанятыми в штат, после завершения проекта. Ведь увольнение, помимо психологических затрат, несет вполне конкретные расходы для компании и часто не маленькие.
Принятие клиентом решения по выбору подрядчика – обычная задача, которую ежегодно решает бесчисленное количество компаний. Крупные опытные компании придерживаются понятной и подрядчикам, и заказчикам схемы выбора: сравнение разных подрядчиков между собой для определения наиболее подходящих. Сначала по стоп-факторам (опыт, квалификация, наличие ресурсов, скорость вывода сотрудников и разные доп. условия), чтобы не допустить до этапа ценового сравнения откровенно маргинальные варианты. Затем уже проводится сравнение по цене и определение победителя (победителей). Тут можно увидеть разные вариации подходов, которые в том числе описаны в разделе “Тендеры”, по части из которых трудно прогнозировать хороший результат.
Но, помимо вышеприведенного стандартного подхода, часто приходится сталкиваться с тем, что клиент пытается сравнивать предлагаемые подрядчиками ставки со своими расходами на персонал. Многим наверняка приходилось слышать такую фразу: “Да я за эти деньги…”. Эмоции в ряде случаев зашкаливают, а все потому, что клиент и подрядчик говорят о разном на разных языках. Особенно характерно это для случаев, когда клиент впервые привлекает внешних специалистов или же просто ответственный сотрудник заказчика не имеет необходимого опыта в этом. Например, заказчик часто полагает, что реализация (число оплачиваемых дней в месяц) специалистов на его проекте будет равна числу рабочих дней в месяце, что, допустим, составляет 23 дня. В реальности, с учетом отпусков, больничных, отгулов, внутренних обучений и пр. уважительных отвлечений, скорее всего оплачиваемых будет не более 17 дней в месяц. То есть клиенту фактически нужно будет платить на 25% меньше, чем он думал, просто посмотрев на ставку в час!
Другой вопрос, учитывает ли клиент, когда сравнивает ставки с зарплатами своих сотрудников, косвенные расходы – на наём, онбординг, курирование, обучение, переключение между проектами и пр. Понимает ли, что будет делать с сотрудниками, нанятыми в штат, после завершения проекта. Ведь увольнение, помимо психологических затрат, несет вполне конкретные расходы для компании и часто не маленькие.
Рис.3. Как и во многих других вещах, мнения заказчика и подрядчика на оптимальную ставку могут не совпадать. И часто просто потому, что принимают в расчет совершенно разные факты
Еще один пример несовпадения ожиданий и действительности: довольно часто клиент полагает, что может направить заявку и вывести внешнюю команду на проект буквально через несколько дней после запроса. Иногда приходится даже видеть в таких запросах желаемые даты вывода (“через два дня”), а бывает, что и задним числом. Конечно, мгновенный вывод теоретически возможен, если так совпало, что именно в этот момент все нужные заказчику люди находятся в простое и готовы сразу выйти на новую задачу (при этом если подрядчик настолько уверен в заказчике, что готов вывести людей под честное слово, без договора и прочих формальностей. Да еще если учетные записи и доступы для команды будут сделаны за считанные часы). Но в жизни все обычно происходит иначе, и заказчику в конце концов придется в этом убедиться и принять эти реалии во внимание.
У эффективного подрядчика, который предлагает релевантные ставки, простои минимальны. По факту при поступлении запроса от клиента, ему часто предлагают резюме сотрудников, которые в данный момент работают на других проектах. В обычной ситуации никто не станет запускать процесс мобилизации команды с других проектов до того, как заказчик проведет необходимые собеседования, подтвердит готовность брать команду в согласованном составе и на согласованный срок, подтвердит наличие бюджета и готовность потратить его именно на эту команду. Не секрет, что на вывод сотрудника с проекта обычно требуется никак не меньше двух недель, а часто и больше месяца. Согласно правилам хорошего тона, человек сначала должен завершить и сдать работы, которые ему поручены, и только потом спокойно уходить с проекта, без криков и испорченных отношений между людьми и компаниями.
Подписание договора, предоставление доступов – все это тоже требует недель и месяцев, но никак не дней. Поэтому, даже если заказчик пишет в своем запросе, что готов стартовать работу команды с завтрашнего дня, в 95% случаев будет хорошо, если она реально сможет приступить к работе через несколько недель. И отнюдь не из-за задержки на стороне ИТ-компании. Лучше бы это сразу понимать и заказчику, и подрядчику, чтобы не было неоправданных ожиданий и некорректных обещаний.
У эффективного подрядчика, который предлагает релевантные ставки, простои минимальны. По факту при поступлении запроса от клиента, ему часто предлагают резюме сотрудников, которые в данный момент работают на других проектах. В обычной ситуации никто не станет запускать процесс мобилизации команды с других проектов до того, как заказчик проведет необходимые собеседования, подтвердит готовность брать команду в согласованном составе и на согласованный срок, подтвердит наличие бюджета и готовность потратить его именно на эту команду. Не секрет, что на вывод сотрудника с проекта обычно требуется никак не меньше двух недель, а часто и больше месяца. Согласно правилам хорошего тона, человек сначала должен завершить и сдать работы, которые ему поручены, и только потом спокойно уходить с проекта, без криков и испорченных отношений между людьми и компаниями.
Подписание договора, предоставление доступов – все это тоже требует недель и месяцев, но никак не дней. Поэтому, даже если заказчик пишет в своем запросе, что готов стартовать работу команды с завтрашнего дня, в 95% случаев будет хорошо, если она реально сможет приступить к работе через несколько недель. И отнюдь не из-за задержки на стороне ИТ-компании. Лучше бы это сразу понимать и заказчику, и подрядчику, чтобы не было неоправданных ожиданий и некорректных обещаний.
Тендеры. Военные хитрости в мирное время
Казалось бы, что может быть более типовой процедурой, чем тендеры на ИТ-услуги. Более того, тендеры на ставки, привлечение сотрудников подрядчика по T&M-модели в рамках аутстафа или аутсорса, по сути своей, гораздо проще и для заказчика, и для подрядчика, чем конкурсы на реализацию проекта под ключ по фиксированной цене. Тем не менее и тут существует множество вариаций, и если не понимать их нюансы, то, могу сказать по собственному печальному опыту, можно получить серьезные проблемы.
Чаще всего тендеры проводятся на заключение рамочного соглашения по широкому перечню (буквально десяткам) различных ролей и грейдов. В некоторых тендерах могут быть ограничения по количеству победителей, тогда заказчик ограничивается, например, тремя или четырьмя подрядчиками, которые предоставили наиболее релевантный опыт и наиболее подходящие ставки, и только с ними будет заключен договор. Причем иногда заказчик даже сразу оговаривает, что победитель получит, к примеру, 50% объема работ, второе место – 30%, а третье – 20%. Для заказчика это хорошо, поскольку он диверсифицирует свои риски, не ограничиваясь одним поставщиком, а для подрядчиков повышает шанс попасть в обойму, даже и не с самым идеальным предложением.
Бывает, заказчик не обозначает, выберет ли он одного подрядчика, какое-то ограниченное их количество или готов заключить рамку и работать со всеми, кто в какой-то степени удовлетворяет базовым требованиям. В случае последнего варианта (его часто называют аккредитацией) договоры могут быть в итоге заключены с 40 или даже 50 компаниями. Ставки фиксируются в рамочном договоре с каждой конкретной компанией, и уже потом под конкретную задачу заказчик просит всех прошедших аккредитацию предоставить конкретные предложения по составу запрошенных команд с резюме. То есть в такой ситуации конкурс фактически двухэтапный и растянутый во времени.
Сначала служба закупок проводит первый этап конкурса – просто для фиксации ставок (обычно на срок в пару лет), часто без обозначения конкретных задач и объемов, без глубокого вовлечения в процедуру собственно бизнес-заказчиков. Сопровождается эта процедура, как и полагается у возглавляемого службой закупок процесса, переторжками и прочими видами утрясания подрядчиков для минимизации цен (хотя реально в таком конкурсе цена не сильно влияет на согласие подписать с вами договор, если она, конечно, не запредельная).
Затем, в каждом конкретном запросе ресурсов, уже с привлечением бизнеса, фактически выбирается локальный победитель – тот, кто будет поставлять команду специалистов для решения определенной задачи. Тут ценовой фактор играет значимую роль: потенциальных подрядчиков на конкретный запрос может быть много, и каждый предлагает свои резюме, но большее влияние оказывает качество предоставленных специалистов и готовность вывести их в ожидаемый срок. Кроме того, никто не мешает (при большом желании победить) снизить ставки от зафиксированного в рамке уровня. Выше ставку показать нельзя, меньше – пожалуйста.
Считается, что такой двухэтапный конкурс позволяет сократить время на выбор подрядчика и принятие решения по конкретному запросу. Но на практике, к сожалению, это не всегда работает так. Сроки принятия решения и по одному конкретному запросу, даже при наличии подписанного рамочного договора, тоже могут измеряться месяцами, особенно если задача большая, а потенциальных подрядчиков много.
Каким бы простым ни казался конкурс на ставки, но выбор критериев принятия решения в таких тендерах иногда может сильно удивить. Речь ведь обычно идет не об одной ставке, а о целой тарифной матрице в разрезе ролей и грейдов, как было сказано выше. Живой пример из опыта “ГлоуБайт”, один из не так уже редко применяемых показателей для оценки предложений – это средняя ставка (на практике смысл такого показателя максимально близок к средней температуре по больнице).
Допустим, в конкурсе подается предложение на 27 различных ставок (девять ролей в разрезе трех грейдов). Для расчета показателя все поданные подрядчиком ставки суммируются и делятся на 27. Итоговое значение используется для сравнения предложений участников. Математически вроде бы неплохая идея. Но в реальности она несет множество проблем. Во-первых, все роли и грейды имеют разный потенциальный объем привлечения. А при использовании среднего значения это никак не учитывается. Ставка по роли, которая потребуется на три дня, будет влиять на итоговый результат так же, как и по роли, которая потребуется на 1000 дней.
В большинстве конкурсов на ставки на подрядчика не накладывается жестких обязательств по выводу запрошенных специалистов к заказчику. Поэтому в конкурсах по средней ставке подрядчики устанавливают реальные ставки только по тем ролям и грейдам, которые реально собираются предоставлять. По остальным случается “театр абсурда”, и можно встретить ставки и 12 тыс. рублей в день, а порой даже 8.
Понятно, что позиции не планируется закрывать по таким ставкам, они подаются только с целью снижения целевого показателя конкурса. Более того, сам показатель средней ставки подразумевает, что все подрядчики должны подать предложение на все запрошенные роли и грейды, даже если их у подрядчика реально нет. Таким образом, сам критерий оценки, без ввода должных ограничителей (штрафов и черных списков за непредоставление людей в срок), толкает подрядчиков на предоставление некорректных данных. Думаю, что такой критерий не оправдывает своего применения и не позволяет заказчику реально оценить и сравнить поданные предложения подрядчиков. Но если уж вы столкнулись с подобным критерием в реальном конкурсе, то без “читерской” стратегии вряд ли сможете рассчитывать на победу. В целом средневзвешенная ставка (с учетом объемов потенциального привлечения по каждой позиции и грейду, важности данной роли для проекта) была бы гораздо более справедливым критерием, чем средняя. Но считать ее сложнее, а также заказчику в этом случае нужно поделиться с подрядчиками дополнительными вводными, поэтому и имеем то, что имеем.
Ряд заказчиков пытается защититься (с переменным успехом) от занижения подрядчиками ставок или от подачи ими в конкурс позиций, по которым у интегратора реально отсутствуют ресурсы, устанавливая различные наказания за непредоставление их в жесткие сроки. Например, если заказчик направляет запрос, то подрядчик обязан в течение трех дней направить подходящие CV-сотрудников, работающих в штате у подрядчика. Если заказчик соглашается, то будь добр в течение недели направить сотрудников на собеседование. Если и тут специалисты понравились, то через две недели обязан вывести людей на работу. Иначе штраф, включение в черный список, разрыв договора и т. п.
На наличие этих условий нужно в обязательном порядке проверять тендерную документацию. Если они есть, то стоит скорректировать подход к формированию ставок – если действовать по-честному, то нужно закладывать наличие резерва людей на случай внезапного запроса клиента. Но и определение позиций, на которые вы хотите претендовать, в таком случае тоже отдельное сложное решение – например, по “штучным”, уникальным позициям риски возрастают, поскольку быстро найти свободного человека при наличии всего нескольких таких специалистов в компании может быть затруднительно.
Итого, если не принять во внимание дополнительные риски таких мер со стороны заказчика, то, когда они случатся с большой долей вероятности, они не только съедят маржу, но и приведут к потере репутации, что часто оказывается во много раз больнее, особенно если клиент – крупная и известная всему рынку компания.
Рассмотрим еще один интересный вариант. Иногда конкурс тоже двухэтапный, первый этап играется на ставки, как было описано выше, но в ходе последующих запросов, уже на конкретные работы, предусматривается получение от подрядчиков предложений и реализация проектов (этапов проекта) по фиксированной цене. Если это оговаривается заказчиком в конкурсной документации сразу, то уже на первом этапе можно увидеть сильно заниженные ставки. Конечно, только в том случае, если первый этап отсекающий, с выбором одного или нескольких победителей. “Грамотные” подрядчики понимают, что при такой схеме смогут потом относительно легко “раздуть” трудозатраты в своих оценках конкретных работ и заработать хорошую прибыль даже при низких, заведомо убыточных ставках.
Довольно часто в таких конкурсах информация о том, как будут потом играться и реализовываться конкретные задачи – по фиксированной цене или по T&M, прямо не раскрывается, клиент как бы старается “напустить туман”, объясняя это желанием получить максимально выгодные предложения. Тут уже ваш выбор – рискнуть в надежде, что потом получится заработать за счет контрактов с “фикс прайс”, или не делать этого. В случае выигрыша, при нехорошем раскладе, результат может быть печальнее, чем в случае проигрыша. Правильнее попытаться узнать, как была выстроена работа у этого клиента раньше и надеяться, что и в рамках нового конкурса все будет реализовываться как прежде.
Казалось бы, что может быть более типовой процедурой, чем тендеры на ИТ-услуги. Более того, тендеры на ставки, привлечение сотрудников подрядчика по T&M-модели в рамках аутстафа или аутсорса, по сути своей, гораздо проще и для заказчика, и для подрядчика, чем конкурсы на реализацию проекта под ключ по фиксированной цене. Тем не менее и тут существует множество вариаций, и если не понимать их нюансы, то, могу сказать по собственному печальному опыту, можно получить серьезные проблемы.
Чаще всего тендеры проводятся на заключение рамочного соглашения по широкому перечню (буквально десяткам) различных ролей и грейдов. В некоторых тендерах могут быть ограничения по количеству победителей, тогда заказчик ограничивается, например, тремя или четырьмя подрядчиками, которые предоставили наиболее релевантный опыт и наиболее подходящие ставки, и только с ними будет заключен договор. Причем иногда заказчик даже сразу оговаривает, что победитель получит, к примеру, 50% объема работ, второе место – 30%, а третье – 20%. Для заказчика это хорошо, поскольку он диверсифицирует свои риски, не ограничиваясь одним поставщиком, а для подрядчиков повышает шанс попасть в обойму, даже и не с самым идеальным предложением.
Бывает, заказчик не обозначает, выберет ли он одного подрядчика, какое-то ограниченное их количество или готов заключить рамку и работать со всеми, кто в какой-то степени удовлетворяет базовым требованиям. В случае последнего варианта (его часто называют аккредитацией) договоры могут быть в итоге заключены с 40 или даже 50 компаниями. Ставки фиксируются в рамочном договоре с каждой конкретной компанией, и уже потом под конкретную задачу заказчик просит всех прошедших аккредитацию предоставить конкретные предложения по составу запрошенных команд с резюме. То есть в такой ситуации конкурс фактически двухэтапный и растянутый во времени.
Сначала служба закупок проводит первый этап конкурса – просто для фиксации ставок (обычно на срок в пару лет), часто без обозначения конкретных задач и объемов, без глубокого вовлечения в процедуру собственно бизнес-заказчиков. Сопровождается эта процедура, как и полагается у возглавляемого службой закупок процесса, переторжками и прочими видами утрясания подрядчиков для минимизации цен (хотя реально в таком конкурсе цена не сильно влияет на согласие подписать с вами договор, если она, конечно, не запредельная).
Затем, в каждом конкретном запросе ресурсов, уже с привлечением бизнеса, фактически выбирается локальный победитель – тот, кто будет поставлять команду специалистов для решения определенной задачи. Тут ценовой фактор играет значимую роль: потенциальных подрядчиков на конкретный запрос может быть много, и каждый предлагает свои резюме, но большее влияние оказывает качество предоставленных специалистов и готовность вывести их в ожидаемый срок. Кроме того, никто не мешает (при большом желании победить) снизить ставки от зафиксированного в рамке уровня. Выше ставку показать нельзя, меньше – пожалуйста.
Считается, что такой двухэтапный конкурс позволяет сократить время на выбор подрядчика и принятие решения по конкретному запросу. Но на практике, к сожалению, это не всегда работает так. Сроки принятия решения и по одному конкретному запросу, даже при наличии подписанного рамочного договора, тоже могут измеряться месяцами, особенно если задача большая, а потенциальных подрядчиков много.
Каким бы простым ни казался конкурс на ставки, но выбор критериев принятия решения в таких тендерах иногда может сильно удивить. Речь ведь обычно идет не об одной ставке, а о целой тарифной матрице в разрезе ролей и грейдов, как было сказано выше. Живой пример из опыта “ГлоуБайт”, один из не так уже редко применяемых показателей для оценки предложений – это средняя ставка (на практике смысл такого показателя максимально близок к средней температуре по больнице).
Допустим, в конкурсе подается предложение на 27 различных ставок (девять ролей в разрезе трех грейдов). Для расчета показателя все поданные подрядчиком ставки суммируются и делятся на 27. Итоговое значение используется для сравнения предложений участников. Математически вроде бы неплохая идея. Но в реальности она несет множество проблем. Во-первых, все роли и грейды имеют разный потенциальный объем привлечения. А при использовании среднего значения это никак не учитывается. Ставка по роли, которая потребуется на три дня, будет влиять на итоговый результат так же, как и по роли, которая потребуется на 1000 дней.
В большинстве конкурсов на ставки на подрядчика не накладывается жестких обязательств по выводу запрошенных специалистов к заказчику. Поэтому в конкурсах по средней ставке подрядчики устанавливают реальные ставки только по тем ролям и грейдам, которые реально собираются предоставлять. По остальным случается “театр абсурда”, и можно встретить ставки и 12 тыс. рублей в день, а порой даже 8.
Понятно, что позиции не планируется закрывать по таким ставкам, они подаются только с целью снижения целевого показателя конкурса. Более того, сам показатель средней ставки подразумевает, что все подрядчики должны подать предложение на все запрошенные роли и грейды, даже если их у подрядчика реально нет. Таким образом, сам критерий оценки, без ввода должных ограничителей (штрафов и черных списков за непредоставление людей в срок), толкает подрядчиков на предоставление некорректных данных. Думаю, что такой критерий не оправдывает своего применения и не позволяет заказчику реально оценить и сравнить поданные предложения подрядчиков. Но если уж вы столкнулись с подобным критерием в реальном конкурсе, то без “читерской” стратегии вряд ли сможете рассчитывать на победу. В целом средневзвешенная ставка (с учетом объемов потенциального привлечения по каждой позиции и грейду, важности данной роли для проекта) была бы гораздо более справедливым критерием, чем средняя. Но считать ее сложнее, а также заказчику в этом случае нужно поделиться с подрядчиками дополнительными вводными, поэтому и имеем то, что имеем.
Ряд заказчиков пытается защититься (с переменным успехом) от занижения подрядчиками ставок или от подачи ими в конкурс позиций, по которым у интегратора реально отсутствуют ресурсы, устанавливая различные наказания за непредоставление их в жесткие сроки. Например, если заказчик направляет запрос, то подрядчик обязан в течение трех дней направить подходящие CV-сотрудников, работающих в штате у подрядчика. Если заказчик соглашается, то будь добр в течение недели направить сотрудников на собеседование. Если и тут специалисты понравились, то через две недели обязан вывести людей на работу. Иначе штраф, включение в черный список, разрыв договора и т. п.
На наличие этих условий нужно в обязательном порядке проверять тендерную документацию. Если они есть, то стоит скорректировать подход к формированию ставок – если действовать по-честному, то нужно закладывать наличие резерва людей на случай внезапного запроса клиента. Но и определение позиций, на которые вы хотите претендовать, в таком случае тоже отдельное сложное решение – например, по “штучным”, уникальным позициям риски возрастают, поскольку быстро найти свободного человека при наличии всего нескольких таких специалистов в компании может быть затруднительно.
Итого, если не принять во внимание дополнительные риски таких мер со стороны заказчика, то, когда они случатся с большой долей вероятности, они не только съедят маржу, но и приведут к потере репутации, что часто оказывается во много раз больнее, особенно если клиент – крупная и известная всему рынку компания.
Рассмотрим еще один интересный вариант. Иногда конкурс тоже двухэтапный, первый этап играется на ставки, как было описано выше, но в ходе последующих запросов, уже на конкретные работы, предусматривается получение от подрядчиков предложений и реализация проектов (этапов проекта) по фиксированной цене. Если это оговаривается заказчиком в конкурсной документации сразу, то уже на первом этапе можно увидеть сильно заниженные ставки. Конечно, только в том случае, если первый этап отсекающий, с выбором одного или нескольких победителей. “Грамотные” подрядчики понимают, что при такой схеме смогут потом относительно легко “раздуть” трудозатраты в своих оценках конкретных работ и заработать хорошую прибыль даже при низких, заведомо убыточных ставках.
Довольно часто в таких конкурсах информация о том, как будут потом играться и реализовываться конкретные задачи – по фиксированной цене или по T&M, прямо не раскрывается, клиент как бы старается “напустить туман”, объясняя это желанием получить максимально выгодные предложения. Тут уже ваш выбор – рискнуть в надежде, что потом получится заработать за счет контрактов с “фикс прайс”, или не делать этого. В случае выигрыша, при нехорошем раскладе, результат может быть печальнее, чем в случае проигрыша. Правильнее попытаться узнать, как была выстроена работа у этого клиента раньше и надеяться, что и в рамках нового конкурса все будет реализовываться как прежде.
Мои года – мое богатство, но не всегда. Изменение устаревающих ставок
Ставки согласованы, договор подписан, работы выполняются, клиент доволен — идиллия. Особенно приятно, если ставки позволяют обеспечить для команды хорошие условия компенсации и приемлемую маржу для компании. Но идиллия не может длиться долго. В стране довольно высокая инфляция, цены постоянно растут, и зарплаты ИТ-специалистов так или иначе участвуют в этой гонке. Ставки, которые были хороши год назад, сегодня могут оказаться уже не такими привлекательными, а иногда и вообще убыточными. А что уж говорить про то, как финансовая картина взаимодействия с клиентом будет выглядеть при тех же ставках через два-три года.
Ставки согласованы, договор подписан, работы выполняются, клиент доволен — идиллия. Особенно приятно, если ставки позволяют обеспечить для команды хорошие условия компенсации и приемлемую маржу для компании. Но идиллия не может длиться долго. В стране довольно высокая инфляция, цены постоянно растут, и зарплаты ИТ-специалистов так или иначе участвуют в этой гонке. Ставки, которые были хороши год назад, сегодня могут оказаться уже не такими привлекательными, а иногда и вообще убыточными. А что уж говорить про то, как финансовая картина взаимодействия с клиентом будет выглядеть при тех же ставках через два-три года.
Рис. 4. Инфляция не только съедает сбережения, но и по ставкам бьет больно
Есть два основных варианта достижения с клиентом компромисса по ставкам: тендер или переговоры. Тендеры, по результатам которых фиксируются ставки, играются сразу на два или три года. В большинстве случаев при подписании договора по результатам тендера ставки жестко фиксируются и не могут изменяться до истечения срока контракта. Поэтому модель сотрудничества с клиентом должна учитывать, что ставки с течением времени будут все менее и менее интересными. Например, можно стараться в первый год после подписания контракта максимизировать объем предоставляемых клиенту ресурсов, а по мере снижения маржинальности постепенно выводить людей на другие, более привлекательные по ставкам и условиям проекты.
Но на практике, особенно в случае с перспективными большими клиентами, так сделать получается далеко не всегда. Ведь всегда есть надежда, что через два-три года будет новый тендер и ставки снова станут нормальными. Выводя ресурсы и отпуская клиента в свободное плавание, мы теряем его лояльность, снижаем вероятность победы в новом тендере, даем преимущество конкурентам, которые в расчете на будущие дивиденды могут не только удовлетвориться минимальной маржой, но даже проинвестировать – “высадить” на проекте нужную клиенту команду и заменить вас частично или полностью. Поэтому крупные компании, у которых есть запас прочности, зачастую готовы держать большие команды “на клиенте” и удовлетворять его потребности в специалистах даже на третий год после тендера, когда старые ставки уже совсем не радуют.
Другой распространенный вариант удержания маржинальности на приемлемом уровне – это снижение затрат за счет снижения квалификации специалистов, работающих на проекте у клиента, постепенная замена более дорогих людей на менее затратных, оставаясь в рамках тех же грейдов. Этот способ хорош, если не учитывать, что ротация людей подрядчика зачастую сама по себе является сильным раздражителем для менеджеров со стороны клиента и не добавляет им лояльности. А если еще и квалификация этих людей зримо снижается, то, даже если этой квалификации и достаточно для работы в рамках грамотно выстроенных подрядчиком процессов, все равно можно “нарваться” на раздражение.
Иной подход, когда ставки устанавливаются не по результатам тендера, а просто в ходе проведения с клиентом переговоров и фиксируются в специализированном соглашении. Такое не редкость, если вы уже работаете с заказчиком, хорошо себя зарекомендовали, и менять вас на другого подрядчика для заказчика нет большого смысла, за исключением ситуации, когда ваши аппетиты перестанут влезать в бюджет. При таком раскладе обычно получается договориться с клиентом о более гибких условиях. Например, о ежегодном пересмотре ставок с учетом официальной инфляции. Или же о фиксированном ежегодном увеличении ставок на определенный согласованный процент. Тут тоже есть подводные камни.
Например, официальная инфляция в большинстве случаев ниже, чем рост затрат ИТ-компании на персонал. Можно спорить, почему так происходит, но от этого не станет легче. Факт остается фактом, что, допустим, при официальной инфляции за 2025 год в 5,66% зарплаты в среднем в ИТ-отрасли выросли на 15%. Разница больше чем в два раза, и ситуация превышения затрат над инфляцией по ЦБ РФ сохраняется уже несколько лет. Поэтому, если вы даже договорились о росте ставок на уровень официальной инфляции, это лишь отчасти подсластит пилюлю: снижение маржинальности, если не предпринимать других мер, неизбежно.
Если клиент понимает ценность вашей компании и склонен к сотрудничеству, то в динамичных условиях нашего рынка часто лучшее решение вообще не фиксировать ставки надолго. Договориться о ежегодном пересмотре по итогам переговоров, прописать процесс запуска этих переговоров, установить ограничители роста сверху, чтобы заказчик не беспокоился, что подрядчик попытается “выкрутить ему руки”.
Конечно, отсутствие длинного договора вносит определенный риск, что впоследствии договориться о нормальных условиях не получится. Но плюс в том, что у вас будет возможность, показав реальные аргументы изменения ваших затрат, убедить клиента в необходимости поднять ставки больше, чем на процент инфляции по ЦБ, – при условии, что заказчик удовлетворен качеством вашего сервиса и предоставляемых ему специалистов.
В целом, как показывает практика, вопрос аргументации в таких переговорах всегда крайне важен. Понятно, что если другие ИТ-подрядчики согласны увеличить свои ставки только на 10%, а вы без каких-либо серьезных обоснований утверждаете, что без 20%-ного увеличения уйдете в минус, то шансов договориться будет немного. Но если у вас на проекте с клиентом работают сильные специалисты, которых он не захочет терять, это может стать настоящим сильным аргументом. Например, к независимым исследованиям по росту ЗП в отрасли или по росту иных ИТ-затрат (оборудование, ПО).
Иногда хорошо показать полный расчет маржинальности, основанный на статистике прошлых лет с учетом реальной утилизации и реализации людей на проекте, учитывающий больничные, отпуска, простои по вине клиента (если они на нем), бесплатные грейс‑периоды на онбординг и тому подобное Важно, чтобы клиент не думал, что у вас и так 70% маржа и поэтому «пощипать» вас — святое дело, тогда ему будет проще пойти на разумный и регулярный рост ставок раз в год и принять компромисс.
Но на практике, особенно в случае с перспективными большими клиентами, так сделать получается далеко не всегда. Ведь всегда есть надежда, что через два-три года будет новый тендер и ставки снова станут нормальными. Выводя ресурсы и отпуская клиента в свободное плавание, мы теряем его лояльность, снижаем вероятность победы в новом тендере, даем преимущество конкурентам, которые в расчете на будущие дивиденды могут не только удовлетвориться минимальной маржой, но даже проинвестировать – “высадить” на проекте нужную клиенту команду и заменить вас частично или полностью. Поэтому крупные компании, у которых есть запас прочности, зачастую готовы держать большие команды “на клиенте” и удовлетворять его потребности в специалистах даже на третий год после тендера, когда старые ставки уже совсем не радуют.
Другой распространенный вариант удержания маржинальности на приемлемом уровне – это снижение затрат за счет снижения квалификации специалистов, работающих на проекте у клиента, постепенная замена более дорогих людей на менее затратных, оставаясь в рамках тех же грейдов. Этот способ хорош, если не учитывать, что ротация людей подрядчика зачастую сама по себе является сильным раздражителем для менеджеров со стороны клиента и не добавляет им лояльности. А если еще и квалификация этих людей зримо снижается, то, даже если этой квалификации и достаточно для работы в рамках грамотно выстроенных подрядчиком процессов, все равно можно “нарваться” на раздражение.
Иной подход, когда ставки устанавливаются не по результатам тендера, а просто в ходе проведения с клиентом переговоров и фиксируются в специализированном соглашении. Такое не редкость, если вы уже работаете с заказчиком, хорошо себя зарекомендовали, и менять вас на другого подрядчика для заказчика нет большого смысла, за исключением ситуации, когда ваши аппетиты перестанут влезать в бюджет. При таком раскладе обычно получается договориться с клиентом о более гибких условиях. Например, о ежегодном пересмотре ставок с учетом официальной инфляции. Или же о фиксированном ежегодном увеличении ставок на определенный согласованный процент. Тут тоже есть подводные камни.
Например, официальная инфляция в большинстве случаев ниже, чем рост затрат ИТ-компании на персонал. Можно спорить, почему так происходит, но от этого не станет легче. Факт остается фактом, что, допустим, при официальной инфляции за 2025 год в 5,66% зарплаты в среднем в ИТ-отрасли выросли на 15%. Разница больше чем в два раза, и ситуация превышения затрат над инфляцией по ЦБ РФ сохраняется уже несколько лет. Поэтому, если вы даже договорились о росте ставок на уровень официальной инфляции, это лишь отчасти подсластит пилюлю: снижение маржинальности, если не предпринимать других мер, неизбежно.
Если клиент понимает ценность вашей компании и склонен к сотрудничеству, то в динамичных условиях нашего рынка часто лучшее решение вообще не фиксировать ставки надолго. Договориться о ежегодном пересмотре по итогам переговоров, прописать процесс запуска этих переговоров, установить ограничители роста сверху, чтобы заказчик не беспокоился, что подрядчик попытается “выкрутить ему руки”.
Конечно, отсутствие длинного договора вносит определенный риск, что впоследствии договориться о нормальных условиях не получится. Но плюс в том, что у вас будет возможность, показав реальные аргументы изменения ваших затрат, убедить клиента в необходимости поднять ставки больше, чем на процент инфляции по ЦБ, – при условии, что заказчик удовлетворен качеством вашего сервиса и предоставляемых ему специалистов.
В целом, как показывает практика, вопрос аргументации в таких переговорах всегда крайне важен. Понятно, что если другие ИТ-подрядчики согласны увеличить свои ставки только на 10%, а вы без каких-либо серьезных обоснований утверждаете, что без 20%-ного увеличения уйдете в минус, то шансов договориться будет немного. Но если у вас на проекте с клиентом работают сильные специалисты, которых он не захочет терять, это может стать настоящим сильным аргументом. Например, к независимым исследованиям по росту ЗП в отрасли или по росту иных ИТ-затрат (оборудование, ПО).
Иногда хорошо показать полный расчет маржинальности, основанный на статистике прошлых лет с учетом реальной утилизации и реализации людей на проекте, учитывающий больничные, отпуска, простои по вине клиента (если они на нем), бесплатные грейс‑периоды на онбординг и тому подобное Важно, чтобы клиент не думал, что у вас и так 70% маржа и поэтому «пощипать» вас — святое дело, тогда ему будет проще пойти на разумный и регулярный рост ставок раз в год и принять компромисс.
Заключение
Я знаю, что большинство моих коллег полагает, что прекрасно разбирается в том, как формировать ставки для клиента. Ни в коем случае не стану с этим спорить и, более того, уверен, что каждый читатель смог бы предложить множество важных дополнений, которые тут не были учтены. И наоборот, многие могут сказать, что то, что я написал выше, – это банальные и понятные вещи, которые не стоят электричества, потраченного на то, чтобы их напечатать. Но я все же постарался выделить и структурировать те аспекты, которые важны при принятии решения о ставках и которые, по моему опыту, учитываются далеко не всегда.
Надеюсь, что в каком-то очередном конкурсе вам улыбнется удача, и не потому, что у вас просто самые низкие ставки, а потому, что эта статья помогла вам о чем-то задуматься, лучше понять, что хочет заказчик, что будут делать конкуренты, и в итоге вы сформируете оптимальное предложение, которое нельзя будет не принять.
Я знаю, что большинство моих коллег полагает, что прекрасно разбирается в том, как формировать ставки для клиента. Ни в коем случае не стану с этим спорить и, более того, уверен, что каждый читатель смог бы предложить множество важных дополнений, которые тут не были учтены. И наоборот, многие могут сказать, что то, что я написал выше, – это банальные и понятные вещи, которые не стоят электричества, потраченного на то, чтобы их напечатать. Но я все же постарался выделить и структурировать те аспекты, которые важны при принятии решения о ставках и которые, по моему опыту, учитываются далеко не всегда.
Надеюсь, что в каком-то очередном конкурсе вам улыбнется удача, и не потому, что у вас просто самые низкие ставки, а потому, что эта статья помогла вам о чем-то задуматься, лучше понять, что хочет заказчик, что будут делать конкуренты, и в итоге вы сформируете оптимальное предложение, которое нельзя будет не принять.