Рентабельность проектов для студий: полный гайд

Студия занята, команда работает, проекты сдаются в срок — а прибыль всё равно непонятна. Причина почти всегда одна: никто точно не знает, сколько приносит каждый конкретный проект. Этот гайд разбирает все части уравнения — выручку, стоимость, утилизацию, ценообразование и переработки — и показывает, как они связаны. Каждый раздел ссылается на отдельный гайд с деталями; здесь — картина целиком.

Почему рентабельность невидима

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

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

Обрати внимание: совокупная маржа 25% выглядит нормально. Но она скрывает убыток на поддержке. Продли этот контракт ещё на год или возьми похожий — и убыток удвоится, а агрегированный показатель лишь немного ухудшится. Студии, которые смотрят только на итог, узнают о проблеме слишком поздно.

Два числа, которые решают всё

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

Маржа в процентах важнее абсолютного числа: она позволяет сравнивать проекты разного масштаба. Проект на $10 000 с маржой 40% выгоднее проекта на $50 000 с маржой 8% — отдача на вложенные ресурсы выше. Как именно считать, что входит в стоимость, разобранный пример — в гайде как рассчитать маржу проекта.

Как найти реальную стоимость часа

Возьми оклад + налоги работодателя + накладные и подели не на календарные, а на реально оплачиваемые часы. Разница между этой цифрой и привычным «оклад ÷ часы» — обычно 30–50%, и именно она незаметно съедает маржу.

Разберём на примере. Разработчик с окладом $5 000 в месяц: казалось бы, $5 000 ÷ 160 часов = $31 в час. Добавь налоги работодателя (~20%): +$1 000. Накладные на сотрудника (офис, инструменты, HR, менеджмент) — ещё $800. Итого затраты: $6 800 в месяц. И это ещё не финал.

Из 160 рабочих часов в месяц реально оплачивается клиентами примерно 130 — остаток уходит на планёрки, онбординг, административку и внутренние задачи. Делим $6 800 на 130 оплачиваемых часов: $52 в час. Это в 1,7 раза больше, чем кажется по окладу. $21 с каждого оплачиваемого часа просто выпадают из сметы — когда считаешь от оклада, а не от реальных затрат.

Как посчитать это точно для своей команды — в реальная стоимость часа разработчика.

Утилизация: множитель

Если из 160 рабочих часов в месяц оплачиваемы 120, твоя стоимость часа выросла на треть — при том же окладе. Поэтому утилизацию надо считать, а не угадывать.

Утилизация = оплачиваемые часы ÷ доступные часы. Здоровый диапазон для большинства студий — 70–80%. Ниже — ты переплачиваешь за простаивающую ёмкость. Выше — команда не успевает ни продавать, ни учиться, ни восстанавливаться.

Ловушка 100% особенно опасна: студия без буфера не справляется ни с одним отклонением от плана — заболел человек, клиент добавил задачи, проект затянулся. Любое событие становится кризисом, потому что лишней ёмкости нет.

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

Ценообразование: почасово или фиксом

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

Разница между моделями — в том, кто несёт риск. При почасовой оплате клиент видит каждый час и может остановить работу. При фикс-цене ты берёшь на себя всю неопределённость: если объём вырос на 30% — платишь ты, а не клиент.

Ни одна модель не лучше другой в абстракте. Почасовая работает плохо там, где клиент хочет предсказуемый бюджет. Фикс-цена разрушительна там, где требования размыты или заказчик склонен расширять скоуп на ходу. Простое правило: фикс-цена уместна, когда объём работ можно описать исчерпывающе до начала. Если нет — почасовая честнее для обеих сторон.

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

Переработки: тихая утечка

Вернись к таблице выше: те же три проекта, но команда залогировала 360 часов вместо 264 — счёт клиенту тот же, а стоимость выросла. Проект А теряет половину прибыли, Б уходит глубже в минус.

Переработки у сотрудника на окладе кажутся бесплатными. Это иллюзия с конкретной ценой. Если человек на фикс-проекте работает 360 часов вместо 264, ты заплатил $52 × 96 дополнительных часов = $4 992, которых нет в смете. Плюс скрытая цена: выгоревший сотрудник в следующем месяце работает медленнее, хуже удерживается, чаще болеет.

Ещё одна ловушка: переработки часто не видны, пока проект не завершён. К тому моменту менять цену уже поздно. Именно поэтому нужен учёт часов в реальном времени — чтобы видеть перерасход на второй неделе, а не после закрытия.

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

Видеть это в реальном времени — без слежки

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

Команда сама отмечает время с однострочной заметкой — что делали, на какой проект. Это занимает меньше минуты и даёт контекст, которого нет ни у одного счётчика кликов: разработчик знает, что из двух часов один ушёл на фичу, а другой — на баг заказчика. Автоматический трекер этого не различит.

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

Простой рабочий ритм

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

Когда это работает, меняется характер разговора: вместо «сколько мы заработали в этом квартале?» ты спрашиваешь «какой проект проседает прямо сейчас?». Это другая скорость реакции и другое качество решений. Сделай это — и вопрос «рентабельны ли мы?» перестанет быть квартальной головоломкой. Он становится числом, которое видно сегодня. Именно для этого сделан AltOrbit.