Что CFO стоит ожидать от CTO в реальных цифрах

Почему финансы и инженерия часто говорят на разных языках

Финансы отслеживают деньги по месяцам. Инженерия отслеживает работу по backlog, инцидентам и рискам релиза. Они могут смотреть на одну и ту же проблему и описывать две разные реальности.

Хороший пример — счет за облако. Финансы видят, что операционные расходы растут, а валовая маржа сжимается. Инженерия видит всплеск трафика, поспешный запуск или систему, которую быстро собрали, а теперь нужно наводить порядок.

С наймом та же история. CFO спрашивает, вписываются ли еще два инженера в бюджет. CTO спрашивает, сможет ли команда попасть в срок релиза, удержать стабильный uptime и не выжечь людей. Эти вопросы связаны между собой. План найма, сроки релиза и расходы на инфраструктуру движутся как одно целое.

Представьте SaaS-команду, которая обещает новую enterprise-функцию к Q3. Чтобы выпустить ее вовремя, команда подключает поставщика, увеличивает облачные мощности и откладывает доработку платформы. Финансы видят рост расходов. Инженерия видит выполненный дедлайн. Через три месяца обе стороны получают один и тот же сюрприз: растет нагрузка на поддержку, падает маржа, а следующий релиз выглядит менее надежным.

CTO должен давать финансам не просто список выпущенных функций. Его задача — связать продуктовые решения с бизнес-результатами.

Такой общий взгляд обычно сводится к четырем показателям:

• стоимость инфраструктуры на одного клиента или на продуктовую линию
• зависимость от поставщиков и риск продления контрактов
• влияние инженерных решений на валовую маржу
• уровень уверенности в датах поставки

Когда CTO отчитывается только об объеме выполненной работы, доверие начинает таять. Финансы слышат о прогрессе, но не могут понять, становится ли этот прогресс дешевле в эксплуатации, безопаснее в поддержке и проще в прогнозировании. В итоге инженерам приходится защищать расходы по отдельности, что только тратит время и уводит обе команды в неправильный разговор.

Согласование начинается тогда, когда обе стороны используют одну и ту же операционную картину. Релиз — это событие продукта, событие расходов, событие маржи и событие планирования. Команды принимают лучшие решения, когда каждый месяц смотрят на него именно так.

Какие цифры сильный CTO должен показывать

Передать финансам один лишь счет за облако — это не контроль расходов. Хороший CTO показывает, как технические затраты меняются вместе с выручкой, использованием продукта и скоростью поставки.

Расходы на инфраструктуру гораздо понятнее смотреть как отношение, а не как отдельный счет. Если хостинг вырос с $40,000 до $60,000, сам по себе этот факт мало что говорит. Если за тот же период выручка выросла с $400,000 до $700,000, бизнес может стать более эффективным, а не менее.

Полезно также разбивать инженерные расходы на понятные категории: хостинг и облачные сервисы, инструменты и использование API, подрядчики или агентства, а также нагрузку на поддержку, связанную с инцидентами и запросами клиентов. Такое разделение показывает, откуда именно идет давление. Рост счета за поддержку после повторяющихся сбоев рассказывает совсем другую историю, чем более высокий счет за облако из-за здорового роста клиентов.

Особенно полезны удельные показатели. Для SaaS-продукта стоимость на активного клиента или на 1,000 транзакций говорит больше, чем общие расходы. Если одна продуктовая линия обходится в три раза дороже другой, финансы могут рано заметить проблему в ценообразовании или пакетах.

CTO должен объяснять и то, что происходит, когда использование растет быстрее выручки. Если активность в продукте выросла на 40%, а выручка — только на 15%, финансам нужен денежный эффект. Возможно, команда занизила цену для плана с высоким потреблением. Возможно, в инфраструктуре накопились потери. Возможно, использование AI API выросло без ограничений. Объяснение должно звучать так: «Если этот тренд продолжится еще один квартал, валовая маржа снизится с 72% до 66%».

Показатели поставки должны быть в том же отчете. Точность оценки и сдвиги сроков нужно называть прямо: «Мы оценили шесть недель и выпустили за семь» или «Три из восьми релизов сдвинулись более чем на пять рабочих дней». Это показывает CFO, достаточно ли надежен план для найма, ценообразования и решений по деньгам.

Когда каждый месяц появляются одни и те же несколько цифр, финансы перестают гадать, чем занимается инженерия.

Как расходы на инфраструктуру влияют на валовую маржу

Валовая маржа становится мутной, когда инфраструктура спрятана в одном большом счете за облако. Хороший CTO сразу делит этот счет на две части: базовую стоимость поддержания продукта в работе и стоимость, которая растет вместе с использованием клиентами.

Это различие важно, потому что фиксированные расходы платформы ведут себя не так, как расходы по использованию. Если команда тратит $20,000 в месяц на базовый стек и еще $15,000, которые растут вместе с трафиком, хранилищем или API-запросами, картина маржи меняется по мере роста объема. Финансы тогда видят, улучшает ли рост маржу или просто поднимает счет с той же скоростью.

Следующий шаг — отнести расходы туда, где им место. Хостинг продукта, базы данных, трафик и AI API с оплатой за использование обычно входят в себестоимость, потому что они ежедневно нужны для обслуживания клиента. Внутренние dev-инструменты, софт для найма и бэк-офисные системы обычно идут в операционные расходы, потому что они поддерживают компанию, но не масштабируются напрямую вместе с использованием продукта. Для общих инструментов нужен простой и понятный принцип распределения, а не догадки.

Когда расходы разложены по местам, проще заметить потери. Простаивающие серверы, слишком большие базы данных, старые бэкапы, которые никому не нужны, и сторонние API, вызываемые чаще, чем нужно, съедают маржу. CTO должен показывать самые большие утечки простыми цифрами: «Неиспользуемое хранилище стоит $3,200 в месяц» или «Дублирующий инструмент мониторинга добавляет $18,000 в год».

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

Сырые счета редко помогают CFO разобраться в этом. Гораздо лучше работают тренды. Стоимость на одного клиента, стоимость на транзакцию или доля инфраструктуры в выручке за последние шесть–двенадцать месяцев превращает шумный счет от поставщика в историю о марже.

Смысл простой: расходы должны поддерживать выручку или снижать риск так, чтобы это видел каждый. Если не происходит ни того ни другого, к ним стоит присмотреться.

Как на практике выглядит контроль поставщиков

Хороший CTO не относится к поставщикам как к куче несвязанных подписок. Он управляет ими как частью операционной модели.

Финансы должны уметь запросить один актуальный обзор всех инструментов, кто за них отвечает, сколько они стоят, когда продлеваются и может ли компания без них обойтись. Если такого списка нет, расходы быстро расползаются. Команды добавляют инструменты в загруженные кварталы, а потом никто их не убирает. Через полгода компания платит за два продукта мониторинга, три AI-инструмента для написания кода и контракт, который продлевается уже на следующей неделе.

Здоровая система скучна в лучшем смысле слова. CTO ведет реестр поставщиков и пересматривает его каждый месяц или каждый квартал. В этом реестре должны быть каждый поставщик и внутренний владелец, ежемесячные или годовые расходы, даты продления и уведомления, лимиты использования или ограничения по лицензиям, а также то, насколько сложно будет уйти на другое решение.

Последний пункт важнее, чем многие CFO ожидают. Дешевый инструмент становится дорогим, когда команда строит вокруг него половину своего процесса и не может уйти без долгой переделки. Поэтому важно заранее понимать: покупаете ли вы инструмент или встраиваете себя в его привычки.

Хороший контроль поставщиков также означает, что ограничения нужно ставить до того, как расходы резко вырастут. Правила согласования для новых лицензий, использования API, роста хранилища и премиальных дополнений не дают расходам ползти вверх без причины. Дублирующие инструменты нужно быстро убирать. Если инженерия использует один сервис для логов, другой для оповещений и третий для дашбордов, CTO должен объяснить, почему такое разделение стоит этих денег.

Иногда лучшим решением становится консолидация. В компактных командах стек, построенный вокруг GitLab CI/CD, Sentry и Grafana с Prometheus, может заменить несколько пересекающихся поставщиков. Это подходит не каждой компании, но логика проста: меньше инструментов, понятнее ответственность, меньше сюрпризов.

Сроки контрактов тоже важны. CTO должен проверять цены, использование и варианты выхода до наступления дедлайнов по продлению. Это оставляет достаточно времени, чтобы договориться о лучших условиях, снизить тариф или уйти.

Как предсказуемость поставки проявляется в планировании

Планирование быстро становится слабым, когда даты воспринимаются как обещания, а не как прогнозы. Хороший CTO дает диапазон дат, объясняет уровень уверенности и заранее обновляет его, когда реальность меняется.

Этот диапазон должен исходить из мощности команды, а не из оптимизма. Если в команде шесть инженеров, но около 35% времени уходит на тикеты поддержки, инциденты в продакшене и запросы клиентов, в дорожной карте остается только 65% времени. План, который игнорирует нагрузку на поддержку, может выглядеть аккуратно в таблице, но в течение месяца он разваливается.

Небольшие релизные партии помогают увидеть это раньше. Когда команда выпускает одну большую функцию через десять недель, все узнают о задержке слишком поздно. Когда ту же работу выпускают более мелкими частями каждые одну-две недели, финансы раньше замечают отклонение и могут скорректировать сроки выручки, найм или расходы на поставщиков до того, как квартал станет хаотичным.

CTO не обязан включать финансы в каждый тикет. Финансам нужен короткий апдейт: что сдвинулось, почему это сдвинулось и как это повлияло на расходы. Если релиз задержался на две недели из-за того, что команде пришлось исправлять ошибки в биллинге в продакшене, CFO должен услышать, ушло ли это в рабочее время команды, добавило ли $8,000 на подрядчиков или задержало выставление счетов.

Обычно несколько простых сигналов объясняют большинство сдвигов: сколько инженерного времени ушло на запланированную работу, а сколько — на прерывания, сколько задач было заблокировано и на сколько, сколько времени команда потратила на переделку, как часто проблемы в продакшене меняли график и насколько крупной была каждая партия релиза.

Эти цифры показывают, в чем настоящая проблема: плохой scope, нестабильные требования, задержки у поставщиков или продукт, которому нужно больше поддержки, чем ожидалось.

Предсказуемость не означает идеальную точность. Она означает, что сюрпризы становятся меньше, компромиссы — понятнее, а доверие между сторонами немного растет каждый месяц.

Как провести ежемесячный обзор CFO-CTO

Ежемесячный обзор не обязан быть долгим. Часто достаточно 45 минут, если формат остается одинаковым.

Начните с трех бизнес-показателей, которые уже важны: целевая выручка, целевая маржа и лимиты по деньгам. Так инженерные решения попадают в тот же контекст, которым CFO уже пользуется.

Используйте общий дашборд и сделайте его достаточно простым, чтобы пробежать глазами за две минуты. В большинстве компаний достаточно одной страницы: выручка против плана, тренд валовой маржи, расходы на облако и софт против бюджета, статус поставки на ближайшие 30–90 дней и короткая заметка о влиянии на деньги.

Затем проверьте три главных драйвера затрат. Во многих софтверных командах это использование облака, внешние поставщики и payroll, связанный с задержками поставки. Смысл не в том, чтобы разбирать каждый счет. Смысл в том, чтобы понять, что изменилось, почему это изменилось и помогло ли это выручке, марже или скорости поставки.

После этого рассмотрите три главных риска по поставке. Держите их конкретными. «Переписывание auth может сдвинуть enterprise-запуск на три недели» — полезно. «Инженерия занята» — нет. CFO нужно понимать, что может сдвинуться, сколько это может стоить и поможет ли дополнительный бюджет.

Правила принятия решений так же важны, как и отчетность. Если каждое изменение поставщика или покупка инфраструктуры требует согласования, CTO не сможет двигаться достаточно быстро. Если согласование не нужно вообще, финансы теряют контроль. Установите лимиты для размера контракта, изменений численности и непредвиденных расходов на облако выше определенного порога. Все остальное остается в зоне CTO.

SaaS-компания может договориться о простом разделении, например таком: CTO может утверждать изменения в инструментах в пределах месячного лимита, переносить нагрузку на более дешевый хостинг и заменять слабого поставщика без длинного совещания. CFO утверждает новые годовые контракты, изменения численности и любые расходы, которые могут опустить денежный запас ниже согласованного минимума.

Заканчивайте встречу владельцами, сроками и короткими заметками. Записывайте, кто что делает и к какому сроку, плюс любую цифру, которую нужно снова проверить в следующем месяце. Если одна и та же проблема всплывает на трех встречах подряд, записи обычно показывают, в чем дело: в исполнении, в планировании или в неверном предположении.

Такой ритм строит доверие, потому что обе стороны продолжают смотреть на одни и те же цифры, риски и решения.

Пример: SaaS-команда с растущими облачными расходами

SaaS-компания с 3,200 платящими аккаунтами увидела, как ее ежемесячный счет за облако вырос с $42,000 до $68,000 за шесть месяцев. Выручка при этом выросла всего на 11%. В то же время два запланированных релиза сдвинулись примерно на пять недель. CFO увидел одну проблему с двух сторон: расходы росли, а поставка все время отставала.

Старый отчет был почти бесполезным. Финансы получали один крупный счет с грубыми метками вроде app, data и other. Из-за этого расходы выглядели как фиксированные накладные затраты, хотя часть из них была связана с конкретными продуктовыми решениями.

CTO изменил представление и разбил расходы по использованию продукта: трафик основного приложения, хранилище и бэкапы, AI-задачи для одной премиальной функции и инженерные инструменты с тестовыми средами.

Это простое изменение показало настоящую проблему. Премиальную AI-функцию использовали только 14% клиентов, но она давала 31% инфраструктурных затрат, потому что работала на дорогой managed queue и чрезмерно больших вычислительных ресурсах в часы пик. Теперь CFO мог связать расходы с конкретной функцией и увидеть влияние на маржу, а не смотреть на один большой облачный счет.

Одно изменение поставщика, которое снизило расходы

Следующий шаг был простым. Компания перевела логи с дорогого hosted-сервиса на более дешевую схему с тем же сроком хранения, который команда реально использовала. Инженеры сохранили свои дашборды и оповещения. Поддержка не потеряла видимость инцидентов. Ежемесячный счет снизился на $7,500.

Это сработало, потому что команде не понадобились ни переписывание, ни новый процесс. Они просто перестали платить за функции, которыми почти не пользовались.

Один пересмотр roadmap, который наладил планирование

В roadmap было восемь обязательных пунктов на следующий квартал, хотя за последние три квартала команда выполняла только по четыре-пять пунктов. CTO сократил обязательный план до пяти пунктов, вынес остальное за пределы квартала и перестал назначать даты, пока у каждого пункта не было четкого владельца, дизайна и списка зависимостей.

В течение двух циклов планирования точность прогноза улучшилась примерно с 55% до 85%.

Это дало CFO гораздо более чистую картину бизнеса: какая функция разгоняет облачные расходы, где можно снизить затраты на поставщиков без потери результата, как риск поставки влияет на квартал и как контроль инфраструктуры связан с валовой маржой и уверенностью в планировании.

Ошибки, которые подрывают доверие

Доверие быстро ломается, когда финансы считают инженерию одной фиксированной статьей расходов. Некоторые затраты какое-то время действительно остаются относительно стабильными, но использование облака, нагрузка на поддержку, сторонние API и подрядчики часто меняются вместе со спросом на продукт и с продуктовыми решениями. CTO должен разделять затраты, которые масштабируются, затраты, которые в основном фиксированы, и затраты, которые команда может убрать.

Еще одна частая ошибка — резать расходы на облако изолированно. Более дешевая конфигурация может выглядеть хорошо один месяц, а потом падает скорость страниц, растет число ошибок, и enterprise-клиенты начинают задавать неприятные вопросы. Экономия $8,000 на инфраструктуре не помогает, если компания теряет продление на $40,000, потому что продукт кажется менее надежным.

Разрастание инструментов наносит тот же ущерб, только тише. Одна команда хочет новый инструмент для тестирования, другая — инструмент для данных, а третья — отдельный стек мониторинга. Если никто не спрашивает, какую бизнес-проблему решает каждый инструмент, компания платит за дублирование, дополнительное обучение и путаные передачи между командами.

Сроки релизов тоже могут превратить доверие в театр. Если приоритеты продукта меняются каждую неделю, точные даты релиза — это фикция. CTO все равно должен обещать диапазоны, компромиссы и уровень уверенности. Когда CFO слышит жесткую дату, которая потом сдвигается, настоящая проблема часто не в скорости инженерии. Часто проблема в том, что никто не защитил входные данные.

Время бюджета важнее, чем готовы признать многие команды. Если все ждут годового планирования, чтобы убрать очевидные потери, мелкие утечки становятся нормой. Ненужный инструмент продлевается. Большой инстанс продолжает работать уже после падения трафика. Дублирующий поставщик остается в расходах, потому что его отключение кажется мелочью. Через полгода такие мелкие решения складываются в большую сумму.

Более здоровый подход довольно прост. Каждый месяц пересматривайте изменения в расходах, связывайте планы экономии с уровнем сервиса и влиянием на клиентов, утверждайте новые инструменты только с реальным кейсом использования и владельцем, прогнозируйте поставку диапазонами, пока требования еще меняются, и убирайте потери сразу, как только команда их находит.

Финансам не нужна от инженерии идеальная уверенность. Им нужна честная отчетность, быстрое исправление курса и цифры, которые совпадают с реальностью. CTO тоже не нужна полная свобода. Ему нужно пространство, чтобы объяснять, почему одна экономия улучшает маржу, а другая вредит продукту.

Краткая проверка перед следующим бюджетным совещанием

Бюджетные встречи проходят быстрее, когда обе стороны проверяют несколько фактов вместо того, чтобы спорить по наитию.

Начните с ясности по расходам. CTO должен уметь назвать три главных драйвера затрат простыми словами, с примерными процентами и короткой причиной для каждого. Если большая часть денег уходит на облачные вычисления, базы данных, observability или время подрядчиков, финансы должны услышать это за одну минуту, а не после десяти слайдов.

Быстрый тест обычно показывает, работает ли сотрудничество:

• Может ли CTO объяснить три главных драйвера затрат без технического жаргона?
• Может ли финансы назвать поставщиков, которых будет больно или дорого заменить?
• Могут ли обе стороны показать, как текущие расходы меняют валовую маржу в следующем квартале?
• Показывает ли дорожная карта диапазоны уверенности вместо жестких дат с ложной определенностью?
• Заканчивается ли встреча решениями, владельцами и датой следующего шага?

Один слабый ответ еще не значит, что у команды проблемы. Несколько слабых ответов обычно означают, что финансы и инженерия все еще работают по разным картам.

Риски поставщиков заслуживают особого внимания, потому что они прячутся внутри обычной работы. Счет за облако сегодня может выглядеть приемлемым, но lock-in растет, когда один провайдер одновременно ведет вычисления, базы данных, очереди, идентификацию и аналитику. CTO не обязан убирать каждую зависимость. Его задача — сказать, какие из них легко заменить, какие дорого менять и почему.

Маржа должна оставаться на виду в течение всего разговора. Если инженерия просит еще $20,000 в месяц, финансам нужно понимать, защищает ли это выручку, сокращает ли время поставки или снижает ли расходы на поддержку. Если никто не может связать расходы с маржой, бюджет по-прежнему остается догадкой.

Roadmap тоже важен. Одни только даты создают ложную уверенность. Лучший план показывает вероятные окна поставки и допущения, на которых они основаны. Это дает CFO более чистый способ планировать деньги, найм и отчеты для совета директоров.

Если ежемесячный обзор заканчивается без журнала решений, тот же спор вернется в следующем месяце.

Что делать дальше

Начните с малого. CFO и CTO не нужен новый planning system, чтобы работать лучше вместе. Им нужен один общий дашборд и одна ежемесячная встреча с одними и теми же цифрами каждый раз.

Сделайте дашборд простым. Соберите в одном месте расходы на инфраструктуру, обязательства перед поставщиками и даты продления, тренд валовой маржи и точность поставки относительно плана. Когда эти цифры лежат на одной странице, финансы видят компромиссы заранее, а не после закрытия квартала.

В первый месяц исправьте две вещи, а не десять: одну понятную утечку расходов, например простаивающие облачные ресурсы, пересекающиеся инструменты или неиспользуемые лицензии, и одну привычку планирования, например сроки релизов без владельца или прогнозы, которые никогда не обновляются.

Потом на время оставьте стек инструментов в покое. Большинству команд не нужен еще один reporting app. Им нужны более чистые входные данные, меньше сюрпризов и одна привычка смотреть на одни и те же цифры каждый месяц.

Если в вашей команде есть сильные инженеры, но нет человека, который связывает архитектурные решения с маржой и деньгами, внешняя помощь может быстро закрыть этот разрыв. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями как fractional CTO и advisor, с фокусом на продуктовую архитектуру, контроль инфраструктурных расходов и AI-first operations. Такая поддержка особенно полезна, когда бизнесу нужны более ясные компромиссы без тяжелого процесса.

Стандарт здесь несложный: понятные цифры, честные компромиссы, меньше сюрпризов и план, который могут защитить и финансы, и инженерия.