Клуб Enterprise лидов с Ирой Цумаревой 

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

В этих и других аспектах юнит-экономики нам помог разобраться 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. Этот рейт называете клиенту.

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

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

Сообщение Как IT компании рассчитать внешний рейт при работе с Fixed Price, T&M и аутстаффинге появились сначала на Kraftblick.Media.

Кто решает, о чем писать в блоге IT компании? Какие статьи набирают больше всего просмотров? Зачем иногда ориентироваться на более узкую аудиторию?

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

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

Рекомендуем и другие статьи Kraftblick.Media по теме:

Как блог Daxx получает 40,000 пользователей в месяц. Упор на информационные запросы, линк-магниты и 3 цепочки писем.
Как сервисной IT компании вести блог, чтобы на сайт заходили потенциальные клиенты уровня мидсайз.
Как из спора с клиентом сделать статью для блога, а затем активно использовать ее в пресейлах [кейс Datacrafts].
Почему без персоны покупателя блог IT компании приносит на 80% меньше лидов.

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

• На решение каких вопросов работает контент
• Кто может писать статьи и как это поощрять
• Как классифицировать материалы по источнику и автору идеи
• Какие тематические направления можно выбрать при подготовке статей

На решение каких вопросов работает контент

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

Тут все зависит от стратегии и возможностей: готовить материалы может как один сотрудник, так и целая редакция.

Вторая задача, которая чаще появляется с масштабированием бизнеса — поиск новых сотрудников, а точнее повышение brand awareness.

Допустим, компания работает сразу на двух рынках: клиентском и рынке труда, но они разнесены географически. Клиенты, например, живут в англоязычном пространстве, а потенциальные сотрудники — в русскоязычном.

Как тогда готовить контент? Кто этим должен заниматься?

В таких случаях обычно контент-менеджеры/редакторы работают автономно, ориентируясь на свои потребности (компании международного рынка обычно представлены сразу в нескольких регионах).

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

Узнавайте о новых статьях на Kraftblick.Media!

Сообщение Как готовить контент для блога: материалы от коллег, переупаковка докладов, исследования, спецпроекты, новости появились сначала на Kraftblick.Media.

Как лучше структурировать резюме разработчика для продажи по модели аутстаффа? Что указывать в графе “опыт работы”, если у человека за плечами только несколько проектов? Стоит ли расписывать все навыки сотрудника или ограничиться потенциально необходимыми?

Об этом поговорили с техническим директором одной российской студии веб-разработки, которая работает в том числе и по модели аутстаффа.

Рекомендуем также другие материалы Kraftblick.Media:

Пример резюме Алены Сабитовой, Route-to-Market Success Manager в VMware.

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

Ниаршоринг в Латинской Америке: как нанимать местных разработчиков для североамериканских клиентов.

Как поднять рейт разработчиков до $50+/h. Опыт Redwerk.

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

• • Проанализируйте ожидания клиента
  • Правила идеального резюме
  • Высшее образование
  • Как устанавливать рейт и отбирать специалистов по уровню
  • Почему IT компании уходят от аутстаффа

Проанализируйте ожидания клиента

Первое, что нужно сделать при рассмотрении кандидата для работы на аутстаффе, — понять, чего хочет клиент, считает наш спикер.

А дальше алгоритм тот же, что и в продажах: определяем, есть ли у нас специалист, соответствующий запросу.

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

Для этого компании стоит выделить ментора — опытного Senior-developer из команды.

Правила идеального резюме

Резюме должно быть хорошо структурировано. В нем должны быть следующие разделы:

1. Личные данные.
2. Опыт работы.
3. Личные проекты.
4. Места работы, не связанные с нынешней профессией.
5. Ключевые навыки.
6. Образование и языки.
7. “О себе”.
8. Фотография.

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

Итак, рассмотрим подробно каждый блок.

Личные данные

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

Узнавайте о новых статьях на Kraftblick.Media!

Сообщение Каким должно быть резюме разработчика, чтобы с большей вероятностью продать его по аутстаффу? появились сначала на Kraftblick.Media.