Кейсы

5 мин

02.07.2026

20 разработчиков, ставка и никакого понимания, сколько реально дал проект

Алексей Базюра

Финансовый эксперт Finmap

«Я знала почасовую ставку каждого разработчика. Я знала контрактную ставку клиента. Вычитала одно из другого и думала, что понимаю маржу. Потом я построила P&L по каждому проекту — и поняла, что четыре года вела бизнес на основе вымысла.»

Основательница сервисно-аутстафф IT-компании — 20 разработчиков, 36 млн ₴ годовой выручки, семь активных клиентов — рассказала об упражнении, которое изменило её подход к ценообразованию и найму.

Четыре года она вела бизнес так, как это делают все в отрасли: считала по почасовой ставке. У каждого разработчика была себестоимость часа (в среднем 550 ₴/час). У каждого клиента — контрактная ставка (в среднем 950 ₴/час по всем клиентам). Простое вычитание давало 400 ₴/час валовой маржи на разработчика, около 42%. В масштабе всей команды картина выглядела комфортной, прибыльной, растущей.

Потом она провела это упражнение. Взяла один проект. Не цифру «мы выставили клиенту ₴X за час», а реальный P&L проекта. Выручка от клиента за месяц. Все затраты, напрямую относимые на этот проект. Все косвенные затраты. Что остаётся.

Маржа по ключевому клиенту за предыдущие 12 месяцев: 14%. Не 42%.

Двадцать восемь процентных пунктов маржи растворились в статьях затрат, которых почасовая математика просто не замечала.

Что на самом деле скрывает почасовая математика

Почасовая ставка предполагает, что разработчик загружен проектом на 100%, продуктивен всё это время и проект потребляет только его труд. Ни одно из этих допущений не верно ни в одном реальном сервисном бизнесе. Where the 28 points went — vector waterfall. Left: HOURLY MATH MARGIN 42%. Six drops: BENCH & RAMP-DOWN −5pt, PTO & SICK LEAVE −4pt, INTERNAL MEETINGS & PROCESS −6pt, TOOLS & LICENSES −2pt, RECRUITER & MANAGEMENT OVERHEAD −7pt, DISCOUNT & OVERTIME UNBILLED −4pt. Right: REAL PROJECT MARGIN 14%. Brand teal accent on management overhead drop (largest). Скамейка и переходный период (−5 пунктов). Когда проект завершается или клиент берёт паузу, разработчик простаивает, но продолжает получать зарплату. В среднем две недели в год на разработчика. Не тарифицируется. Съедает маржу.

Отпуска и больничные (−4 пункта). Штатные разработчики получают оплачиваемый отпуск и больничные. Контрактная ставка выставляется только за рабочее время. Разрыв незаметен, пока его не посчитаешь.

Внутренние встречи, процессы, собеседования (−6 пунктов). Стендапы, ретроспективы, планирования, интервью с кандидатами, внутренние синки. Всё оплачивается, ничего не тарифицируется. В среднем 4–6 часов на разработчика в неделю.

Инструменты и лицензии (−2 пункта). Лицензии на IDE, облачная инфраструктура для внутренних окружений, инструменты управления проектами, мониторинг, коммуникационные платформы. Немного на единицу — ощутимо в сумме.

Затраты на рекрутинг и управление (−7 пунктов). HR, delivery-менеджеры, проджект-менеджеры, личное время основательницы. Всё это оплачивается. Почти никогда не тарифицируется. Это была крупнейшая единичная утечка.

Скидки и неоплаченные переработки (−4 пункта). При продлении контракта клиент добился скидки в 8%. Авральная работа по выходным не всегда фиксировалась. Перерасход по блокам с фиксированным объёмом работ поглощался самостоятельно.

Двадцать восемь пунктов, шесть категорий — ни одна из них в почасовой математике не фигурировала.

Перестройка — фреймворк P&L по проектам

За выходные основательница построила P&L по каждому проекту. Он стал самым важным документом в её бизнесе. Фреймворк применим к любой сервисной компании. Первое — Выручка по проекту. Оплаченные часы за месяц × контрактная ставка клиента. Не обещанные продажи — фактически выставленные счета.

Второе — Прямые затраты на разработчиков в полном исчислении. Зарплата + налоги + льготы + амортизация оборудования + оплачиваемые отпуска, делённые на оплачиваемые часы (не календарные). Если разработчик тарифицируется 65% времени, его полная себестоимость часа = зарплата / (часы × 0,65).

Третье — Распределённые затраты на управление проектами, delivery-менеджмент и рекрутинг. Примерная доля по размеру проекта или выручке. Не обязательно идеально точно. Главное — последовательно.

Четвёртое — Инструменты и лицензии, относимые на проект.

Пятое — Распределение затрат на скамейку. Общие затраты на скамейку за год, распределённые по активным проектам.

Шестое — Распределение внутренних встреч и процессов. Доля оплачиваемых часов, уходящих на работу вне проекта × распределённые затраты.

Результат — Реальная маржа проекта. По ключевому клиенту: 14%. По двум небольшим клиентам: 21% и 8%. По одному клиенту, которого она считала лучшим: 3%.

Что она сделала с правдой

С клиентом на 3% состоялся разговор о повышении ставки. Прошёл успешно — маржа выросла до 12%. У клиента на 8% были проблемы с дисциплиной скоупа (избыточный сервис), которые поддавались исправлению — маржа поднялась до 15%. Условия оплаты рекрутинга пересмотрели: вместо гонорара за каждый найм ввели фиксированный ежемесячный ретейнер. Провели аудит внутренних встреч — три еженедельных повторяющихся встречи упразднили. Загрузка двух старших разработчиков выросла с 58% до 72% за счёт перевода их с внутренних задач, генерирующих простой, на клиентские проекты. Общая маржа компании изменилась: с кажущихся 42% (вымысел) до реальных 19% (до перестройки) и реальных 27% (через шесть месяцев). Важнее цифры другое: теперь она точно знала, какой клиент действительно прибыльный, какой субсидирует скамейку и какой незаметно обходится ей в деньги.

Фреймворк — что отслеживать

Шесть показателей, ежемесячно, по каждому проекту:

Реальные оплачиваемые часы (не зафиксированные в договоре — фактические)
Полная себестоимость разработчиков по проекту
Распределённые управленческие расходы (время PM/DM/рекрутера/основательницы как % от месяца)
Распределение затрат на скамейку (затраты на скамейку в этом месяце × доля проекта в выручке)
Реальная маржа проекта (выручка − всё перечисленное выше)
Загрузка по каждому разработчику — отслеживается отдельно от маржи

Шесть показателей, один дашборд, ежемесячный разбор с руководителем delivery. Два часа в месяц — и вымысел не возвращается.

📌 Хотите проверить, насколько ваши проекты на самом деле прибыльны — а не только по почасовой математике? Пришлите данные о выставленных счетах за три месяца и разбивку затрат на команду — мы построим водопадный график реальной маржи по проектам и разберём его с вами за 15 минут. Запросить бесплатную диагностику Finmap →

Часто задаваемые вопросы

Разве утилизация — это просто KPI, а не драйвер маржи?

И то, и другое. Высокая утилизация напрямую увеличивает маржу с учётом полных затрат, поскольку стоимость разработчика распределяется на большее количество оплачиваемых часов. Низкая утилизация незаметно уничтожает маржу.

Что если разработчик работает над тремя проектами в месяц?

Распределите его время по фактически отработанным часам на каждом проекте. Его полные затраты делятся в том же соотношении. Именно поэтому учёт рабочего времени важен — даже в упрощённом виде.

Считать бенч по каждому разработчику или суммарно?

Суммарный подход подходит для небольших команд (до 30 разработчиков). При большем масштабе удобнее считать по каждому, поскольку простой senior-специалиста обходится значительно дороже, чем простой junior-специалиста.

Как это применяется к проектам с фиксированной ценой?

Та же математика, но выручка — это ежемесячно заработанная часть (стоимость контракта × % выполнения). Убыточные проекты выявляются таким образом значительно раньше, чем при кассовом методе учёта.

Клиент не принимает повышение ставки. Что делать?

Проверьте альтернативу: достаточно ли рентабелен проект, чтобы продолжать его по текущим ставкам? Если маржа отрицательная или ниже 10%, рассмотрите сокращение объёма работ, повышение эффективности или плавный выход из проекта.

Чем это отличается от того, что делает мой бухгалтер?

Бухгалтер формирует P&L на уровне компании. Здесь же речь идёт о P&L на уровне проекта, что требует аллокаций, для которых у бухгалтера, как правило, нет операционных данных.

Остались вопросы?

Мы готовы на них ответить.