В чем особенности расчета внешнего рейта для проектов по Fixed Price и T&M? Как рассчитать оверхед и распределить его между сотрудниками?

Как разбить часы разработчиков разных грейдов в одном проекте и не ошибиться с рентабельностью?

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

Его команда начинала работать с рейтами от $1k/h, а со временем вышла на 1,5 – 2k/h.

Обратите также внимание на другие материалы Kraftblick.Media по теме:

Как поднять рейт разработчиков до $50+/h. Опыт Redwerk.
Опыт SECL Group: почему важно считать прибыль с каждого девелопера, а не гоняться за высокими рейтами.
Как мы удерживаем клиентов 3+ года при рейтах $45/h. Опыт Surf.
Все о внешних рейтах: как отслеживать тенденции, когда соглашаться на низкий рейт, как поднять цену для старого клиента.

В этой статье вы прочитаете:

• Что нужно учитывать при расчете внутреннего рейта
• Как оценить рентабельность проекта
• Как считать рейт для разных типов контракта

Что нужно учитывать при расчете внутреннего рейта

Как правильно и точно высчитать рейт — не первая мысль, которая приходит в голову CEO IT компании, но одна из базовых.

Обычно новообразовавшиеся компании начинают работать с разработчиками по договору с фиксированной стоимостью.

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

Давайте разберемся, какие факторы при этом надо учитывать.

ЗП, налоги, отпуска, выходные

Допустим, в компании 12 разработчиков: 6 джунов, 4 мидла, 2 сеньора. У каждого свой рейт.

Часть из них может быть ИП/ФЛП, остальные оформлены по трудовому договору. Но при расчете юнит-экономики зарплату все равно нужно закладывать вчистую, т.е. считаются налоги по ТК.

Так внешняя ставка гораздо выше, но это дает ориентиры для продаж.

Если считать зарплату без налогов, получите невысокий внешний рейт, будете продавать его на рынке — получите развал экономики.

Например, есть разработчик Frontend Middle с зарплатой $1,3k, налог будет около $400, косвенные налоги около $580.

Вычитаем 160 часов отпуска, пару дней на больничный и праздничные дни (около $2,3k). Остается 247 рабочих дней, 151 рабочий час/месяц.

Оверхед

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

Кроме того, между разрабами нужно разделить еще все расходы, не связанные с производством: размещение вакансий, покупка рекламных интеграций, платные сервисы (Jira, Bitbucket, Slack) и т.д.

Формула оверхеда: все затраты / непроизводственные затраты.

У маленькой компании будет выходить около $2k в месяц. Если, как в нашем примере, программистов 12, получается, каждый из них должен заработать еще $200 сверху.

Помимо косвенных расходов на разработчиков ложатся и зарплата административного отдела: CEO, бухгалтер, HR и PR-специалисты и т.п.

Складываем зарплаты всех сотрудников. Пускай будет $6k.

Итого: $8k (т.е.$6k+$2k) /12 (человек). Получается около $667 на каждого программиста.

Что еще входит в оверхед?

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

Часть их заработка тоже являются общими затратами и попадает в расчет оверхеда.

В больших IT компаниях это могут быть тимлиды. 80% времени они работают на проектах, другие 20% — мотивируют команду или разбираются с техническими решениями.

И даже в маленьких командах тот же технический директор может 50% времени участвовать в разработке, а остальные 50% занимается наймом и мотивацией.

Получается, половина его зарплаты попадает в расчет производственных ресурсов (их сумма делится на 13,5 программистов), а другая половина — в общие затраты.

Как разделить эту сумму между разработчиками?

Есть несколько подходов.

• Соотносить зарплату и оклад.

Например, есть 3 разработчика, которые зарабатывают $ 2,3k-2,8k, поэтому им можно отдать большую часть затрат.

• Распределять оверхед поровну.

Т.к. все работают в равных условиях, делим все поровну. Т.е. каждый получает 1/15 административных затрат.

Как оценить рентабельность проекта

Чаще всего IT компании ориентируются на ставку рентабельности в 20-25%. Это, понятное дело, в среднем.

Зависит от типа договора, точности ТЗ, насколько были просчитаны риски. Рассмотрим пример.

Допустим, компания получила заказ на разработку мобильного приложения. Через какое-то время клиент приходит с просьбой модернизировать дизайн.

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

И по факту рентабельность проекта снизилась на 15%. Это риски, которые нужно учитывать.

Пример для более крупных компаний.

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

Но рентабельность рассчитывалась исходя из внутреннего рейта, а не внешнего, и в итоге снизилась на 5-8%.

Потому что формула внешнего рейта выглядит так: внутренний рейт * желаемая рентабельность.

Как считать рейт для разных типов контракта

Fixed Price

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

Все это уменьшает риски.

Если вы не уверены в проекте в целом, можете вынимать какие-то куски и делать их по Fixed Price.

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

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

В Fixed Price многие IT компании используют такую практику: называют заказчику большее количество часов, таким образом уменьшая внешний рейт. Зачем это делать?Представьте ситуацию: вы оцениваете проект в 100 часов с внутренним рейтом $39/h, целый проект стоит $3,9k.

Заказчик согласен с итоговым чеком, но говорит, что $39 за час разработчика — это слишком дорого.

Тогда вы пересчитываете ставку и увеличиваете количество часов, уменьшая внешний рейт. Т.е. оцениваете работу в 150 часов по рейту $26. На выходе будет такая же стоимость.

Еще немного о том, чем хорош контракт с фиксированной стоимостью. В нем уровень специалистов не так важен.

В проект по Fixed Price вы можете взять несколько программистов уровня мидл+ и сеньор и добавить к ним несколько джуниоров. Последним вы даете небольшой объем задач (10-20%).

Таким образом новички набираются опыта, но при этому проект подстраховывают опытные разрабы.

Как рассчитать часы проекта при наличие специалистов разного уровня?

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

Если проект не очень сложный, рассчитывайте на уровень мидл-специалистов. По ходу можно будет внести изменения. Например, если команда не справляется, добавляете свободного сеньора.

Кто-то оценивает рентабельность других проектов, на которых работал программист. Например, где-то она оказалась на 20% выше, чем была заложена. Тогда вы можете увеличить рейт специалиста.

Time & Material и выкуп

При этом типе контракта желательно следить за тем, чтобы горизонт проекта был 3-4 месяца.

Потому что если при Fix у вас есть четкое планирование ресурсов (проект на 4 месяца — разработчик будет занят на 4 месяца), то при T&M вы можете сделать этот же проект за 2 месяца, а потом думать, куда пристроить разраба.

Что касается рейтов.

Чем больше времени клиент выкупает у вас, тем дешевле стоит специалист. Так работает Time & Material и аутстаффинг.

Получается, внешняя ставка уменьшается в соответствии с количеством эффективности, потому что в отличие от Fixed Price, клиент выкупает разработчика на 12 месяцев, а не на 11 (1 месяц — отпуск разработчика). И ему неважно, кто именно будет работать над проектом.

Допустим, внутренняя ставка разработчика Frontend Middle будет $19/h. По Fixed Price: $17/h, по T&M — 16/h при полном выкупе.

Расчет максимальной зарплаты идет от внешнего рейта. Если вы продаете разработчика за $40, то нужно обратно рассчитать внутренний рейт и максимальную зарплату.

Если вы видите, что специалисту пора поднимать рейт (выросла квалификация), то разговариваете с клиентом о повышении ставки. Потому что тут два варианта: либо вы потеряете разработчика, либо клиента.

Стоит увеличить ставку разработчика хотя бы на $4, чтобы сохранить равновесие.

Outside-разработка

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

Например, вы специализируетесь на back-end-е мобильных приложений, а вам заказывают front-end для сайта.

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

Тогда считается иначе.

Берете ставку, по которой вам продают разработчика, высчитываете его зарплату (без налогов) и умножаете на количество часов, которые он должен у вас отработать.

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

Вычитаем налоги, отпускные, сервисы, которые которыми он не пользуется.

Например, купили разработчика по ставке $25, добавили около $4 косвенных расходов, плюс маржу $7. Получилось $36. Этот рейт называете клиенту.

Также нужно учитывать, что вы продаете таких разработчиков полностью, т.е. не домножаете на коэффициент эффективности.

Потому что это должно быть заложено во внешнюю ставку на стороне подрядчика.