Як рахувати маржу проєкту в студії

Залишок на рахунку наприкінці кварталу каже, що студія вижила. Він не каже, які проєкти оплатили решту. Маржа проєкту — те число, яке каже. І її можна знати по кожному проєкту в реальному часі, а не відновлювати через місяці.

Що таке маржа проєкту насправді

Маржа — це те, що залишається після оплати часу, витраченого на проєкт.

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

Важливий момент: маржа проєкту — це не прибуток студії. Це валова маржа конкретного проєкту, з якої потім вираховуються накладні, оренда, маркетинг. Але саме з неї все починається. Якщо у проєкту немає маржі, решта вже не має значення.

Чому ставка клієнта — це не собівартість

Ставка, за якою ти виставляєш рахунок клієнту, — це виручка, а не вартість. Вартість години визначається зарплатами, а не рахунками, і майже завжди нижча за твою ставку — саме звідси береться маржа.

Звучить очевидно. Але на практиці багато студій при оцінці проєктів використовують ставку клієнта як орієнтир собівартості, а потім дивуються, чому цифри не сходяться. Зробити це правильно — окрема тема: див. гайд скільки насправді коштує година розробника.

Що входить до вартості команди

Більшість студій помиляється саме тут. Беруть оклад — і на цьому зупиняються. Але це не вартість, це лише її частина. Рахувати треба так:

• Кожна оплачувана зарплатою година у проєкті за її повною собівартістю — не за ставкою клієнта. Повна вартість включає оклад, податки та нарахування роботодавця, і частку накладних витрат. Різниця — зазвичай 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 рахує маржу за тебе, поки команда фіксує час — дивись як це працює. В розробці — приєднуйся до раннього доступу.