Скільки насправді приносить розробник: правда про маржу на аутстафі

«Я був упевнений, що заробляю 40% на кожному розробнику. Коли ми вперше зробили розкладку по людині, вийшло 11%. Різницю зʼїдав бенч, про який я просто не думав як про витрату».

Це слова власника аутстаф-студії на 14 інженерів. Історія знайома майже кожному, хто здає команду в години: рейт клієнту мінус зарплата розробника здається прибутком. Насправді між цими двома числами ховається ще пів компанії — і поки ви не рознесете витрати по людині, ви керуєте виручкою, а не маржею.

Чому «рейт мінус зарплата» бреше

Візьмемо типового мідла. Клієнту виставляєте $35 за годину, розробнику на руки з податками виходить близько $3000 на місяць. У голові власника це $35 проти умовних $20 — маржа під 43%. Красиво, і саме на цю цифру спираються, коли вирішують наймати ще, давати знижку чи піднімати зарплату.

Проблема в тому, що розробник не приносить 160 оплачуваних годин на місяць. Між проєктами він на бенчі. На онбординг нового клієнта йде тиждень, поки людина вникає в чужий код і процеси. Плюс мітинги, код-рев'ю, навчання, лікарняні, відпустки. Реальна утилізація — частка годин, за які реально платить клієнт — навіть у здорових студіях рідко вища за 75%. І кожен неоплачуваний відсоток ви фінансуєте із власної кишені.

Розкладка на одну людину

Порахуймо чесно, з тими самими цифрами.

43% на папері перетворилися на 12% у житті. І це ще нормальний сценарій. Варто утилізації впасти до 60% через один порожній місяць — і той самий розробник іде в мінус, хоча зарплату ви платите так само.

Порахуймо на цілий рік

Місячна цифра оманлива, бо бенч не рівномірний. Візьмемо того самого мідла за рік. Десять місяців він завантажений на 80%, один місяць — на 40% (проєкт закінчився, новий ще не стартував), один тиждень сумарно — лікарняні й навчання. За рік клієнт оплатив приблизно 1250 годин замість теоретичних 1920. Дохід: близько $43 750. Зарплата з податками: $36 000. Overhead на людину: $8 400. Річний прибуток із розробника: близько −$650. Той самий інженер, який «дає 43% маржі», за рік вийшов у легкий мінус — і все через один порожній місяць та кілька неоплачуваних тижнів, розмазаних по році.

«Бенч не показується в жодному інвойсі, тому його не бачать. А він з'їдає більше, ніж будь-яка знижка клієнту».

Три витрати, які завжди недооцінюють

Перша — бенч. Час між проєктами оплачуєте ви, а не клієнт. Один порожній тиждень на місяць — це мінус 25% доходу з людини при тій самій зарплаті. У студії на 14 людей навіть 10% середнього бенчу — це як утримувати півтора інженери, які нічого не приносять.

Друга — неоплачувані години всередині проєкту. Щоденні стендапи, синки з клієнтом, рев'ю, дослідження, переписування після зміни вимог. Клієнт платить за 6 годин, а зайнято 8. Ці дві години щодня — теж ваша витрата, просто невидима.

Третя — overhead на управління. Кожні пʼять-шість інженерів потребують проджект-менеджера, а рекрутинг і заміна людини коштують як місяць її зарплати, плюс місяці, поки новачок вийде на повну швидкість. Ці гроші не прив'язані до жодного інвойсу, тому їх легко не помічати — доки не порахуєш прибуток на людину після overhead.

Як це виглядає в житті

Проблему чути в típових фразах усередині студії. «У нас багато проєктів, а прибутку мало». «Ми виросли до 20 людей, а власник заробляє як на 12». «Клієнт відвалився — переживемо, посадимо людину на внутрішній проєкт» (тобто на повний бенч за ваш кошт). «Дамо цьому клієнту знижку 10%, він великий» — при тому, що маржа на цьому акаунті й так була 12%, і знижка робить його збитковим.

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

Як побачити маржу по кожному розробнику

Щоб керувати цим, потрібно бачити дохід і витрати в розрізі людини або проєкту, а не одним казаном. У Finmap ви заводите проєкти та напрями, розносите дохід від клієнта й прямі витрати на виконавця — і бачите валову маржу по кожному інженеру та по студії загалом. Бенч перестає бути невидимим: порожній місяць одразу видно у звіті, а не за півроку в загальному «щось прибуток просів». Так само видно, який клієнт приносить нормальну маржу, а який лише завантажує людей майже задарма.

Дотично — чим управлінський облік відрізняється від бухгалтерії в IT і як рахувати утилізацію команди.

Що з цим робити

• Тримайте цільову утилізацію та слідкуйте за нею щотижня, а не раз на квартал. Порожній тиждень, помічений вчасно, ще можна закрити продажем.
• Закладайте бенч у ціну: рейт має покривати не лише зайняті години, а й неминучі порожні. Якщо цільова утилізація 75%, рейт рахується від неї, а не від 100%.
• Рахуйте прибуток на людину після overhead, а не валову різницю рейт-зарплата. Тільки перша цифра каже правду.
• Дивіться на маржу по клієнтах: великий клієнт зі знижкою часто приносить менше, ніж дрібний за повним рейтом.
• Плануйте заміни й найм від завантаження, а не «про запас». Кожна людина «на виріст» без проєкту — це чистий бенч за ваш кошт.

Аутстаф здається простим бізнесом, поки не почнеш рахувати по-людині. Щойно почнеш — стає видно, хто реально заробляє, хто сидить на бенчі й де маржа витікає крізь неоплачувані години. І тоді рішення про найм, знижку чи новий проєкт ухвалюються на цифрах, а не на відчутті, що «людей багато, отже все добре».

Money Doesn't Disappear. You Just Don't See It.

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