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

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

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

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

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

Зверни увагу: сукупна маржа 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-денний пробний період.