Сколько на самом деле приносит разработчик: правда о марже на аутстаффе

«Я был уверен, что зарабатываю 40% на каждом разработчике. Когда мы впервые сделали разбивку по человеку, вышло 11%. Разницу съедал бенч, о котором я просто не думал как о расходе».

Это слова владельца аутстафф-студии на 14 инженеров. История знакома почти каждому, кто сдаёт команду в часы: рейт клиенту минус зарплата разработчика кажется прибылью. На деле между этими двумя числами прячется ещё полкомпании — и пока вы не разнесёте расходы по человеку, вы управляете выручкой, а не маржой.

Почему «рейт минус зарплата» врёт

Возьмём типичного мидла. Клиенту выставляете $35 в час, разработчику на руки с налогами выходит около $3000 в месяц. В голове владельца это $35 против условных $20 — маржа под 43%. Выглядит красиво, и именно на эту цифру опираются, когда решают нанимать ещё, давать скидку или поднимать зарплату.

Проблема в том, что разработчик не приносит 160 оплачиваемых часов в месяц. Между проектами он на бенче. На онбординг нового клиента уходит неделя, пока человек вникает в чужой код и процессы. Плюс митинги, код-ревью, обучение, больничные, отпуска. Реальная утилизация — доля часов, за которые реально платит клиент — даже в здоровых студиях редко выше 75%. И каждый неоплачиваемый процент вы финансируете из собственного кармана.

Разбивка на одного человека

Посчитаем честно, с теми же цифрами.

43% на бумаге превратились в 12% в жизни. И это ещё нормальный сценарий. Стоит утилизации упасть до 60% из-за одного пустого месяца — и тот же разработчик уходит в минус, хотя зарплату вы платите так же.

Посчитаем на целый год

Месячная цифра обманчива, потому что бенч неравномерный. Возьмём того же мидла за год. Десять месяцев он загружен на 80%, один месяц — на 40% (проект закончился, новый ещё не стартовал), одна неделя суммарно — больничные и обучение. За год клиент оплатил примерно 1250 часов вместо теоретических 1920. Доход: около $43 750. Зарплата с налогами: $36 000. Overhead на человека: $8 400. Годовая прибыль с разработчика: около −$650. Тот же инженер, который «даёт 43% маржи», за год вышел в лёгкий минус — и всё из-за одного пустого месяца и нескольких неоплачиваемых недель, размазанных по году.

«Бенч не показывается ни в одном инвойсе, поэтому его не видят. А он съедает больше, чем любая скидка клиенту».

Три расхода, которые всегда недооценивают

Первый — бенч. Время между проектами оплачиваете вы, а не клиент. Одна пустая неделя в месяц — это минус 25% дохода с человека при той же зарплате. В студии на 14 человек даже 10% среднего бенча — это как содержать полтора инженера, которые ничего не приносят.

Второй — неоплачиваемые часы внутри проекта. Ежедневные стендапы, синки с клиентом, ревью, исследование, переписывание после изменения требований. Клиент платит за 6 часов, а занято 8. Эти два часа ежедневно — тоже ваш расход, просто невидимый.

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

Как это выглядит в жизни

Проблему слышно в типичных фразах внутри студии. «У нас много проектов, а прибыли мало». «Мы выросли до 20 человек, а владелец зарабатывает как на 12». «Клиент отвалился — переживём, посадим человека на внутренний проект» (то есть на полный бенч за ваш счёт). «Дадим этому клиенту скидку 10%, он большой» — при том, что маржа на этом аккаунте и так была 12%, и скидка делает его убыточным.

Всё это — симптомы одного: студия считает разницу рейт-зарплата и не считает прибыль на человека после бенча и overhead. Выручка большая, а владелец удивляется, куда девается прибыль.

Как увидеть маржу по каждому разработчику

Чтобы управлять этим, нужно видеть доход и расходы в разрезе человека или проекта, а не одним котлом. В Finmap вы заводите проекты и направления, разносите доход от клиента и прямые расходы на исполнителя — и видите валовую маржу по каждому инженеру и по студии в целом. Бенч перестаёт быть невидимым: пустой месяц сразу видно в отчёте, а не через полгода в общем «что-то прибыль просела». Так же видно, какой клиент приносит нормальную маржу, а какой лишь загружает людей почти даром.

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

Что с этим делать

• Держите целевую утилизацию и следите за ней еженедельно, а не раз в квартал. Пустую неделю, замеченную вовремя, ещё можно закрыть продажей.
• Закладывайте бенч в цену: рейт должен покрывать не только занятые часы, но и неизбежные пустые. Если целевая утилизация 75%, рейт считается от неё, а не от 100%.
• Считайте прибыль на человека после overhead, а не валовую разницу рейт-зарплата. Только первая цифра говорит правду.
• Смотрите на маржу по клиентам: большой клиент со скидкой часто приносит меньше, чем мелкий по полному рейту.
• Планируйте замены и найм от загрузки, а не «про запас». Каждый человек «на вырост» без проекта — это чистый бенч за ваш счёт.

Аутстафф кажется простым бизнесом, пока не начнёшь считать по-человеку. Как только начнёшь — становится видно, кто реально зарабатывает, кто сидит на бенче и где маржа утекает сквозь неоплачиваемые часы. И тогда решения о найме, скидке или новом проекте принимаются на цифрах, а не на ощущении, что «людей много, значит всё хорошо».

Money Doesn't Disappear. You Just Don't See It.

Попробуйте Finmap бесплатно 14 дней и увидьте маржу по каждому разработчику и проекту уже в этом месяце — без ручной сборки табличек.