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

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

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

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

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

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

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

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

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

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

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

Разберём на примере. Разработчик с окладом $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% — платишь ты, а не клиент.

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

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

Овертайм: тихая утечка

Вернись к таблице выше и возьми проект А. Допустим, его оценили в 264 часа, а команда залогировала 360. Счёт клиенту тот же, стоимость выросла примерно на $7 100 — и А потерял больше половины прибыли: осталось около $5 300 вместо $12 400.

Овертайм у сотрудника на окладе кажется бесплатным. Это иллюзия с конкретной ценой. На проекте А час команды стоит около $74 ($19 600 ÷ 264), так что эти 96 дополнительных часов — примерно $7 100, которых нет в смете: ты платишь их либо как овертайм, либо ёмкостью, которая могла уйти на работу, выставляемую клиенту, в другом проекте. Плюс скрытая цена: выгоревший сотрудник в следующем месяце работает медленнее, хуже удерживается, чаще болеет.

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

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

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

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

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

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

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

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

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