Рентабельність проєктів для студій: повний гайд
Рентабельність проєкту — це скільки він реально заробив, а не скільки грошей на рахунку в кінці кварталу.
Студія зайнята, команда працює, проєкти здаються вчасно — а прибуток усе одно незрозумілий. Причина майже завжди одна: ніхто точно не знає, скільки приносить кожний конкретний проєкт. Цей гайд розбирає всі частини рівняння — виручку, вартість, утилізацію, ціноутворення та понаднормові — і показує, як вони пов'язані між собою. Кожний розділ посилається на окремий гайд з деталями; тут — загальна картина.
Чому рентабельність невидима
Виручка зрозуміла — вона в рахунку. З витратами складніше: вони ховаються в зарплатах, податках, понаднормових і годинах, які ніхто не записав. Коли рахувати незручно, зазвичай не рахують — і тоді дивляться на банківський залишок.
Проблема в тому, що залишок на рахунку — це агрегат. Він не показує розбивку по проєктах. Прибуткові перекривають збиткові, і студія виглядає здоровою — доки прибуткових вистачає. Варто втратити одного сильного клієнта або взяти ще один проєкт на кшталт Б — і картина різко змінюється.
| Проєкт | Виручка | Витрати | Маржа | Маржа % |
|---|---|---|---|---|
| А — Корп. сайт | $32,000 | $19,600 | +$12,400 | 39% |
| Б — Підтримка | $18,000 | $19,500 | −$1,500 | −8% |
| В — Редизайн | $25,000 | $17,000 | +$8,000 | 32% |
| Разом | $75,000 | $56,100 | +$18,900 | 25% |
Зверни увагу: сукупна маржа 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.
Подивіться реальну маржу в реальному часі
AltOrbit рахує її за вас, поки команда логує час. У розробці — приєднуйтесь до раннього доступу.
Відкрити ранній доступ