# Аудит инженерных расходов: какие факты собрать за пять дней

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

## Почему сокращение команды может сорвать обещания клиентам

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

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

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

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

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

До обсуждения штата соберите короткий список фактов:

- Обязательства перед клиентами, даты и назначенные владельцы
- Задачи, ожидающие выполнения, поддержки и ревью
- Дежурства, история инцидентов и зависимости от одного человека
- Повторяющиеся ручные задачи и время, которое они занимают
- Расходы на облако, поставщиков и ПО с реальным владельцем

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

## Сначала определите границы аудита

Аудит провалится, если начать с простой инструкции «найдите экономию». В одну таблицу смешаются срочная работа для клиентов, старые договоры, эксперименты и мнения. Сначала определите границы, чтобы у каждого числа был понятный смысл.

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

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

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

- Даты запусков клиентов и договорные даты поставки
- Покрытие поддержки, целевые сроки ответа и дежурства
- Работы по безопасности, соответствию требованиям и надежности с фиксированными сроками
- Задачи, связанные с выручкой, обещанные клиентам или партнерам
- Проекты, которые другая команда не может завершить без участия инженеров

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

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

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

## Сопоставьте очереди поставки с обязательствами перед клиентами

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

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

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

Разделите задачи на четыре практические категории:

- Обязательства перед клиентами с фиксированной датой или риском продления
- Работа по безопасности, надежности и инцидентам
- Задачи для выручки или продукта без фиксированного обещания
- Внутренние запросы, эксперименты и старые задачи бэклога

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

Компания может увидеть 40 открытых задач и решить, что ей нужен каждый инженер. Аудит покажет, что 18 задач ждут уточнений от продукта, девять ожидают отзывов клиентов, а семь стоят в очереди на ревью кода. Только шесть готовы к разработке. Это меняет разговор о штате.

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

## Измерьте регулярную рутину и ручную работу

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

Запись должна быть простой. «Исправил сломанный импорт, 45 минут, три раза за неделю» рассказывает больше, чем общее недовольство постоянными отвлечениями. Включайте работу вне запланированных задач, поскольку скрытые расходы часто находятся именно там.

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

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

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

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

Для каждой задачи спросите: «Что произойдет, если никто не будет делать это две недели?» Ответ отделит защиту клиентов от работы, которую нужно автоматизировать, передать другой функции или остановить.

## Свяжите расходы на облако с продуктами и владельцами

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

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

Проверка расходов на облако часто выявляет затраты, исчезновение которых клиент не заметит:

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

Сравните расходы за последние три-шесть месяцев с датами релизов, трафиком и активностью клиентов. Рост на 40% после запуска продукта может быть оправдан. Такой же рост при неизменном трафике требует объяснения. Попросите владельца связать каждый скачок с реальным событием, например новым клиентом, увеличением числа запросов или релизом, добавившим повторную обработку.

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

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

## Найдите дублирование у поставщиков и неиспользуемые лицензии

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

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

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

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

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

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

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

## Проверьте возможности ревью и узкие места

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

Используйте данные по pull request за последние четыре-восемь недель. Измерьте время от открытия до первого ревью, финального одобрения и слияния. По возможности отделите небольшие исправления от крупных изменений. Заявки, ожидающие ревью больше дня, требуют внимания, если от них зависит релиз.

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

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

В стартапе может быть восемь разработчиков, но каждый инфраструктурный change request проверяет один staff engineer. Увольнение разработчика с меньшей производительностью мало поможет, если именно он выполняет первичное ревью и освобождает staff engineer для работы в продакшене. Очередь ревью вырастет, а релизы начнут задерживаться.

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

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

## Следуйте плану сбора фактов за пять дней

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

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

- **День 1:** Определите границы, обязательства и владельцев, соберите расходы на зарплаты, условия работы с подрядчиками, активные проекты, историю инцидентов, счета за облако и подписки.
- **Дни 2-3:** Соберите данные по очередям, примеры повторяющейся ручной работы, использование облака по продуктам или окружениям и количество лицензий поставщиков. Используйте выгрузки, задачи, счета и логи доступа.
- **День 4:** Проверьте выводы с руководителями команд. Неиспользуемая на вид подписка может поддерживать запланированный запуск. Медленная очередь ревью может быть следствием временного отсутствия.
- **День 5:** Расставьте действия по приоритету с учетом экономии, риска для поставки и усилий. Пометьте каждое действие как безопасное сейчас, требующее проверки или откладываемое до завершения обязательства перед клиентом.

Таблица содержит факты, но не является окончательным ответом. Руководители команд объяснят, важна ли еще тестовая среда и меняет ли срок отмены договора подходящий момент для действий.

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

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

## Защитите запуск и сократите потери

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

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

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

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

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

## Избегайте ошибок, искажающих цифры

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

Количество задач также скрывает неравномерность работы. Одна задача может менять подпись на кнопке. Другая потребует недели расследования, проверки безопасности и аккуратного релиза. Изучайте выборку вместе с обязательством перед клиентом, ожидаемым результатом и затраченным временем.

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

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

Добавьте в аудит два столбца: «возможность» и «подтвержденная экономия». Отмена лицензии не дает экономии, пока владелец не подтвердит, что она не нужна, договор разрешает сокращение и известна дата продления. Экономия на облаке реальна только после изменения нагрузки, проверки влияния на клиентов и появления меньшей суммы в счете.

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

## Превратите факты в следующие шаги

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

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

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

Назначьте одного человека на каждое действие и установите дату проверки. «Отменить неиспользуемые лицензии» звучит расплывчато. «Финансы отменяют 18 неактивных лицензий до продления и подтверждают, что следующий счет уменьшится на $4,320» можно проверить.

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

Внешний аудит Team & AI Audit от Oleg Sotnikov стоит $5,000 и занимает пять рабочих дней. Он охватывает работу команды, использование ИИ и операционные расходы. Гарантируется выявление экономии минимум на $50,000 в год, иначе аудит проводится бесплатно. В результате вы получите приоритетный план: что остановить, что автоматизировать, кому поручить каждое изменение и какие обязательства перед клиентами нужно защитить.