Перейти до основного вмісту
All guides/Повний гайд
Повний гайд

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

Рентабельність проєкту — це скільки він реально заробив, а не скільки грошей на рахунку в кінці кварталу.

AltOrbitGuide9 хв читання

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

Чому рентабельність невидима

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

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

ПроєктВиручкаВитратиМаржаМаржа %
А — Корп. сайт$32,000$19,600+$12,40039%
Б — Підтримка$18,000$19,500−$1,500−8%
В — Редизайн$25,000$17,000+$8,00032%
Разом$75,000$56,100+$18,90025%
На рахунку все добре: +$18 900. Але проєкт Б збитковий — його приховують А і В. Без розрахунку по кожному проєкту ти цього не бачиш.

Зверни увагу: сукупна маржа 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 рахує її за вас, поки команда логує час. У розробці — приєднуйтесь до раннього доступу.

Відкрити ранній доступ