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

Остаток на счёте в конце квартала говорит, что студия выжила. Он не говорит, какие проекты оплатили остальные. Маржа проекта — то число, которое говорит. И её можно знать по каждому проекту в реальном времени, а не восстанавливать спустя месяцы.

Что такое маржа проекта на самом деле

Маржа — это то, что остаётся после оплаты времени, ушедшего на проект.

Выручка — это то, что платит клиент: фикс-цена или часы × ставка. Стоимость команды — реальная стоимость каждого часа, который твои люди потратили на проект. Разрыв между ними — единственная цифра, которая говорит, стоило ли браться.

Важный момент: маржа проекта — это не прибыль студии. Это валовая маржа конкретного проекта, из которой потом вычитаются накладные, аренда, маркетинг. Но именно с неё всё начинается. Если у проекта нет маржи, всё остальное — уже не важно.

Почему ставка клиента — это не себестоимость

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

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

Что входит в стоимость команды

Большинство студий ошибается именно здесь. Они берут оклад — и на этом останавливаются. Но это не стоимость, это только её часть. Считать нужно так:

• Каждый оплачиваемый зарплатой час — на проекте по его полной себестоимости, не по ставке клиента. Полная стоимость включает оклад, налоги и взносы работодателя, и долю накладных расходов. Разница — обычно 30–50%. Чем ниже утилизация команды (доля оплачиваемых часов от доступных), тем выше стоимость каждого часа при том же окладе.
• Овертайм. Тихий убийца маржи. Часы были, деньги стоили, в смету не попали. Разработчик переработал 20 часов — если они не учтены в стоимости, маржа завышена.
• Все, кто касался проекта — PM, дизайн, QA, а не только разработчики. Час PM на созвоне с клиентом стоит денег. Ревью кода, тест QA — тоже. Если их нет в расчёте, маржа — фикция.

Как маржа проекта меняется от типа контракта

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

При фикс-прайсе всё иначе. Цена названа заранее, а реальная стоимость станет понятна только в конце. Любые переработки, неучтённые задачи, расширение скоупа снижают маржу — и студия об этом узнаёт последней. Поэтому по фикс-прайсу маржу нужно контролировать не после сдачи, а в процессе. Сколько ты реально зарабатываешь на час при фикс-прайсе — твоя эффективная ставка — это отдельная тема.

Разобранный пример

Редизайн сайта по фикс-цене:

Теперь прогони тот же проект на 360 часах из-за неоплаченного овертайма — стоимость вырастет примерно до $26 700, а маржа упадёт примерно до $5 300 (17%). Тот же счёт — меньше половины прибыли.

Этот сдвиг не виден, пока не посчитаешь часы честно.

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

Какая маржа проекта считается нормальной

Ориентиры для дев-студий и агентств:

• Ниже 20% — тревожная зона. Любой перерасход по часам или скоуп-крип уводит проект в ноль или минус.
• 20–35% — рабочий диапазон для большинства студий. Даёт буфер на переработки и покрывает накладные.
• 35%+ — хорошо. Обычно это значит, что ставки выставлены правильно, а проект оценён с запасом.

Но важен не только средний показатель — важен разброс. Нужно видеть маржу по каждому проекту отдельно.

Почему Excel в конце квартала проваливается

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

Вот что происходит на практике. Проект ушёл в минус на шестой неделе — но это видно только через полтора месяца. Всё это время команда продолжает работать, овертайм накапливается, PM думает, что укладывается.

Проблема не в таблице. Проблема в том, что таблица обновляется раз в месяц. Маржа постфактум ничего уже не исправит.

Маржа — не итог, а инструмент

Зачем считать маржу не в конце, а в процессе?

Чтобы принимать решения, пока они ещё имеют смысл. Если маржа падает ниже нормы на третьей неделе — можно пересмотреть скоуп или поговорить с клиентом. Если проект систематически выходит с маржой 10% вместо целевых 30% — это сигнал пересмотреть ценообразование. Без этого числа управление студией — управление по ощущениям.

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

Как начать считать: минимальный набор

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

• Шаг 1 — Определи полную стоимость часа для каждого сотрудника. Оклад + налоги + доля накладных, делённые на реально оплачиваемые часы. Без этого числа всё остальное — угадайка.
• Шаг 2 — Зафиксируй время по проекту. Все участники, включая PM и QA. Без честного учёта часов формула не работает.
• Шаг 3 — Считай маржу в процессе, не в конце. Хотя бы раз в неделю. Это покажет, где ты находишься сейчас.
• Шаг 4 — Реагируй на отклонения. Маржа упала ниже порога — это сигнал разобраться, а не просто факт в отчёте.

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

AltOrbit считает маржу за тебя, пока команда фиксирует время — смотри как это работает. В разработке — присоединяйся к раннему доступу.