# Доказывают ли четыре цифры сокращение инженерных расходов? > Убедительный кейс о сокращении инженерных расходов требует четырех цифр: базовых расходов на зарплаты, затрат на переход, результативности релизов и нагрузки от инцидентов. Большинство историй об экономии на инженерной разработке не проходят одну простую проверку: в них показывают более дешевую команду и не рассказывают о работе, которую эта команда перестала выполнять, отложила или перенесла в очередь инцидентов. Прежде чем принять любое утверждение о том, что инженерная организация стала дешевле, основатель должен потребовать четыре цифры: базовые расходы на зарплаты, затраты на переход, результативность релизов и нагрузку от инцидентов. Эти цифры не сделают каждое решение простым. Зато они вынесут утверждение на открытое обсуждение. Член совета директоров, инвестор или операционный руководитель сможет увидеть компромиссы, а не просто похвалить график численности. Я видел, как команды радовались сокращению расходов на зарплаты в одном квартале, а следующие два квартала тратили деньги на подрядчиков, которые разбирали накопившийся долг, нанимали старших специалистов по завышенной ставке и объясняли, почему релизы стали менее предсказуемыми. Изначальная таблица не была ложной. Она была неполной, а это хуже, потому что выглядела убедительно. ## Более низкие расходы на зарплаты - только начало Базовые расходы на зарплаты показывают, сколько организация действительно стоила до изменений. Это знаменатель для всех последующих утверждений, и в слабых кейсах его обычно занижают. Начните с людей, чья работа существенно изменится. Это могут быть штатные инженеры, engineering managers, подрядчики, специалисты по QA, DevOps и технические специалисты по продукту, если они участвуют в выпуске продукта. Не исключайте подрядчиков только потому, что их счета проходят по другой бюджетной статье. Не исключайте основателя, который тратит половину недели на технические решения, которыми раньше занимался штатный старший инженер. Базовая зарплата не равна расходам на зарплаты. Для компании, работающей в США, практический операционный показатель обычно включает налоги на фонд оплаты труда, льготы, бонусы, оборудование, расходы на найм, распределенные на ожидаемый срок работы сотрудника, лицензии на программное обеспечение и управленческие расходы. Ложная точность не нужна. Нужна единая формула, которую можно применить и к старой, и к новой команде. Полезная базовая таблица может выглядеть так: | Категория расходов | База за месяц | Примечания | | --- | ---: | --- | | Вознаграждение штатных инженеров | $180,000 | Зарплаты, налоги, льготы, начисление бонусов | | Подрядчики и агентства | $42,000 | Включая регулярную помощь специалистов | | Доля расходов на управление инженерией | $18,000 | Время на управление разработкой и операциями | | Найм и резерв на замещение сотрудников | $9,000 | Используйте явно заданное месячное допущение | | Инструменты и инфраструктура инженерной команды | $31,000 | Отдельно укажите расходы, которые сохранятся после изменений | | **Общая операционная база** | **$280,000** | Позже используйте те же категории | Приведенные цифры - пример рабочего листа, а не ориентир для сравнения. Ваши показатели могут быть совсем другими. Важно, чтобы компания позже могла объяснить, почему изменилась каждая строка. Есть еще одно различие, которое постоянно размывают: **расходы на зарплаты команды** - это не **операционные расходы инженерии**. Зарплатные расходы показывают, сколько стоят люди. Операционные расходы инженерии показывают, сколько стоит создавать и запускать программный продукт. Компания может сократить зарплаты и одновременно увеличить операционные расходы из-за подрядчиков, лишних облачных затрат, нагрузки на поддержку, вмешательства руководителей или роста числа дефектов. Если в кейсе заявлено сокращение расходов на зарплаты на 60%, спросите, что именно имеется в виду: базовая зарплата, полная стоимость сотрудников или все операционные расходы инженерии. Это три разных утверждения. Если считать их взаимозаменяемыми, красиво выглядящая цифра легко переживает проверку. ### Зафиксируйте базу до любых изменений Не составляйте базу после сокращений, внедрения AI или реорганизации. После ухода людей исчезает доступ к системам, меняется классификация времени, а воспоминания о прежнем процессе начинают поддерживать уже принятое решение. Выгрузите данные за последние три-шесть месяцев по зарплатам, счетам подрядчиков и релевантным расходам на инструменты. Отдельно отметьте регулярные и разовые расходы. Запишите, кто отвечает за таблицу. Затем сохраните копию, которую нельзя переписывать каждый раз, когда кому-то нужно сделать новый план привлекательнее. Достаточно простой формулы: ```text Месячная операционная база = полная стоимость штатных сотрудников + регулярные расходы на подрядчиков + распределенные расходы на управление + регулярные инженерные инструменты + регулярная инженерная инфраструктура ``` Не включайте в эту базу выручку, оценку компании или расплывчатые оценки производительности. Они могут быть важны для решения, но не относятся к расчету расходов. Если смешать их, появится возможность объявить победу до измерения операционного результата. ## От затрат на переход зависит, наступит ли экономия вообще Затраты на переход - это деньги и производственная мощность, которые уходят на переход от текущей команды к новой модели. Именно здесь многие предложения по сокращению расходов незаметно перестают считать. Переход от команды из 10 человек к меньшей группе с поддержкой AI может потребовать внешней помощи, новых инструментов, восстановления документации, работы над CI/CD, миграции хрупких систем, проверки безопасности, временного совмещения сотрудников, выходных пособий и нескольких месяцев внимания руководства. Это не делает план плохим. Но если притворяться, что переход ничего не стоит, бизнес-кейс становится нечестным. Обычно советуют назвать такие расходы «разовыми» и двигаться дальше. Для бухгалтерии такая отметка полезна, но она не делает расходы несущественными. Компании все равно нужны деньги, чтобы их оплатить, и производственная мощность, чтобы их выдержать. Правильный вопрос звучит так: приемлем ли срок окупаемости после учета этих расходов, а не подходят ли они под удобную категорию. Разбейте затраты на переход на четыре группы: 1. **Расходы на людей:** выходные пособия, удерживающие выплаты, найм, подрядчики для закрытия пробелов и параллельное комплектование команды на время передачи дел. 2. **Работа по изменениям:** рефакторинг, стабилизация тестов, документация, автоматизация развертывания, очистка доступов и интеграция, необходимые для безопасной передачи системы меньшей команде. 3. **Инструменты и обучение:** подписки на AI, среды разработки, использование моделей, средства безопасности, обучение и время старших специалистов на формирование рабочих привычек. 4. **Мощность руководства:** время основателя, CTO и менеджеров на принятие решений, разрешение конфликтов, проверку архитектуры и устранение сбоев в процессах. Четвертую группу часто оставляют пустой, потому что ее трудно оценить. Все равно оцените. Если CEO тратит десять часов в неделю на роль экстренного продакт-менеджера, технического ревьюера и координатора инцидентов, работа не исчезла. Она перешла к самому дорогому сотруднику компании. Рассмотрим упрощенный пример. Месячная операционная база инженерии составляет $280,000. После изменений новая модель будет стоить $150,000 в месяц, то есть заявленная месячная экономия равна $130,000. Переход требует $390,000 разовых расходов и добавляет $20,000 регулярных расходов на AI-инструменты, специализированную проверку и поддержку. Чистая месячная экономия составляет не $130,000, а $110,000. ```text Чистая месячная экономия = старая месячная операционная база - новые месячные операционные расходы - новые регулярные расходы, не учтенные в первом сравнении = $280,000 - $150,000 - $20,000 = $110,000 Срок окупаемости = затраты на переход / чистая месячная экономия = $390,000 / $110,000 = 3.55 месяца ``` Это все еще может быть сильным обоснованием. Но убедительным оно становится только тогда, когда компания также показывает, что происходило с разработкой и надежностью в эти месяцы. ### Отделяйте трансформацию от отложенного обслуживания Меньшая команда часто обнаруживает работу, которую большая команда выполняла неформально: недокументированные релизы, ручные изменения базы данных, обновления зависимостей, отложенные на годы, и процесс поддержки, основанный на памяти одного сотрудника. Не складывайте все эти расходы в трансформацию и не называйте новую модель дорогой. Часть работы уже была накопленным обязательством. Но и делать вид, что она ничего не стоит, нельзя. Покажите отдельную строку: отложенное обслуживание, выполненное во время перехода. Так читатели увидят реальную стоимость трансформации и стоимость очистки, которой компания наконец решила заняться. Это важно на обсуждениях с советом директоров. Если переход выявил $150,000 просроченной работы по инфраструктуре, руководство должно сказать об этом прямо. Убедительному кейсу не нужна безупречная история. Нужны цифры, происхождение которых можно проследить. ## Результативность релизов должна описывать работу, которую получили клиенты Результативность релизов показывает, сохранила ли компания способность поставлять продукт, одновременно снижая расходы. Одного подсчета активности в коде недостаточно. Я видел, как руководители использовали коммиты, pull request, story points и количество сгенерированных строк кода как доказательство успеха нового процесса. Для локальной диагностики эти показатели могут быть полезны. Для утверждения об изменении операционной модели они служат слабым доказательством: команда способна увеличить все четыре показателя и при этом выпустить меньше полезного программного обеспечения. Измеряйте результат ближе к клиенту. Выберите небольшой набор показателей, которые компания уже понимает, и заранее зафиксируйте их определения до и после изменений. Для SaaS-продукта это могут быть релизы в production, выполненные обязательства перед клиентами, медианное время цикла от утвержденной задачи до production и доля запланированной работы, которая попала в production в запланированный период. Используйте запись о релизе с достаточным контекстом, чтобы избежать манипуляций: ```text ID релиза: 2026-07-18.3 Объем для клиента: фильтрация экспорта в режиме самообслуживания Дата выхода в production: 2026-07-18 Время поставки: 11 календарных дней от утвержденной спецификации Запланированный или внеплановый: запланированный Потребовался откат: нет Инцидент в течение семи дней: нет Ответственный: product engineering ``` Формат намеренно простой. Он создает след, который основатель может проверить, не споря о том, равны ли двадцать небольших pull request одному содержательному релизу. Более частые релизы могут говорить о здоровой работе команды, но сама частота ничего не доказывает. Ежедневное изменение конфигурации не означает, что команда стала лучше выпускать сложные функции. Сопоставляйте количество релизов с их объемом и временем цикла. ### Не сравнивайте разные периоды продукта как одинаковые Кейс о расходах становится ненадежным, когда в базовый период попал крупный запуск продукта, а новый период оказался спокойной фазой обслуживания. Новая команда может выглядеть продуктивнее только потому, что спрос снизился. Или она может выглядеть медленнее, потому что унаследовала сложную работу после того, как простые задачи уже были выпущены. Четко указывайте существенный контекст. Если компания поставила на паузу крупное направление функций, скажите об этом. Если в базовый период крупный клиент потребовал индивидуальной разработки, тоже скажите. Если после перехода началась миграция платформы, укажите и это. Контекст не оправдывает отказ от измерений. Он не дает делать ложные сравнения. Лучше всего, когда это возможно, сравнивать одинаковую работу. Например, сопоставьте время выпуска пяти похожих запросов клиентов в двух периодах, а затем добавьте более широкую историю релизов. В стартапе невозможно провести идеальный контролируемый эксперимент. Но можно избежать очевидных нелепостей. ### Очередь работы показывает скрытую потерю результата Очередь разработки часто показывает ущерб раньше, чем квартальная метрика релизов. При потере мощности команда может сохранять заметные релизы, откладывая тесты, обновления, исправления для поддержки и внутренние улучшения. Календарь релизов выглядит нормально, пока накопившаяся работа не приводит к сбою или остановке дорожной карты. Отслеживайте возраст и состав очереди. Большой отчет не нужен. Следите за растущей группой дефектов, обновлений безопасности, эскалаций клиентов и операционных задач, которые остаются открытыми, потому что каждый доступный сотрудник занят следующей заметной функцией. Если новая команда выпускает столько же продуктовых релизов, но объем нерешенной операционной работы удваивается, компания не доказала, что нашла более дешевый способ разработки. Она доказала лишь, что какое-то время может откладывать работу. ## Нагрузка от инцидентов выявляет экономию, которая превращается в операционный долг Нагрузка от инцидентов показывает, сохранила ли организация способность поддерживать выпущенный продукт. Ей место рядом с расходами на зарплаты, потому что надежность требует реального времени инженеров, доверия клиентов и внимания руководства. Считайте не только крупные сбои. Зрелая проверка включает инциденты, затронувшие клиентов, серьезность, время обнаружения, время восстановления, ночные вызовы, повторные инциденты и часы, потраченные на реагирование и устранение причин. Используйте одно и то же определение инцидента до и после изменений. Если после реорганизации ранее зарегистрированные события начинают называться «тикетами поддержки», вы изменили измерение, а не улучшили операционную работу. Таблица инцидентов может оставаться компактной: | Показатель | Базовый период | Новый период | Что изменилось? | | --- | ---: | ---: | --- | | Инциденты, затронувшие клиентов | 8 | 11 | Больше дефектов, связанных с релизами | | Общее время восстановления | 19 | 37 | Два медленных восстановления базы данных | | Ночные вызовы | 14 | 24 | В дежурстве участвует меньше людей | | Повторные инциденты | 2 | 5 | Исправления устраняли симптомы, а не причины | | Часы инженеров на устранение последствий | 46 | 91 | Включает расследование и постоянные исправления | И здесь цифры приведены только для примера. Важна закономерность. Компания может экономить $100,000 в месяц на зарплатах и все равно терять значительную часть этой суммы, если новая операционная модель удваивает экстренную работу и заставляет старших специалистов постоянно отвлекаться. Плохой аргумент часто звучит так: новой команде нужно время, чтобы освоиться. Иногда это действительно так. Дайте ей время, но зафиксируйте стоимость периода адаптации. Если после стабилизации команды нагрузка от инцидентов снизится, кейс станет сильнее. Если она останется высокой, у руководства появятся данные для исправления модели. ### Мощность дежурств входит в общую мощность команды У команды из пяти человек не бывает пяти сотрудников, полностью доступных для работы над функциями. Люди уходят в отпуск, болеют, отвечают на вопросы клиентов, проверяют работу и реагируют на инциденты. Небольшая команда может хорошо работать, если системы просты, автоматизированы и понятны. Она не справится, если каждый критический вопрос требует участия каждого человека. Задайте практический вопрос: если два самых компетентных специалиста недоступны неделю, кто сможет выполнить развертывание, расследовать проблему в production, одобрить рискованное изменение и ответить на эскалацию клиента? Если ответ звучит как «нам придется подождать», команда, возможно, достаточно мала для экономии, но слишком мала для безопасной эксплуатации продукта. Именно здесь многие планы AI-трансформации становятся безответственными. AI может ускорить реализацию, генерацию тестов, расследования и документацию. Он не отменяет необходимость ответственного владельца во время инцидента. Более того, ускорение создания кода повышает требования к дисциплинированной проверке и ясному распределению операционной ответственности. ## Для четырех цифр нужны единый период и стабильные определения Метод четырех цифр работает только тогда, когда каждая цифра относится к сопоставимому периоду. Сравнивать месячный снимок расходов на зарплаты с годовым итогом по инцидентам - не анализ. Это слайд, собранный для победы в споре. Выберите базовый период, достаточно длинный для учета обычных колебаний. Для многих стартапов три месяца - минимально полезная отправная точка, а шесть месяцев дают более честную картину, если релизы продукта выходят неравномерно. После завершения перехода используйте такой же период для новой операционной модели. Отдельно выделите переходный период, чтобы временные сбои не скрывались внутри одной из сторон сравнения. Определите каждый показатель одним предложением и назначьте ответственного: | Показатель | Определение | Источник | Ответственный | | --- | --- | --- | --- | | Базовые расходы на зарплаты | Месячная полная стоимость ролей, связанных с разработкой и эксплуатацией | Зарплатные данные и счета | Руководитель финансового направления | | Затраты на переход | Деньги и внутренняя мощность, использованные для перехода к новой модели | Финансы, записи проекта | Руководитель трансформации | | Результативность релизов | Работа для клиентов, выпущенная по стабильному определению | Записи о релизах | Руководитель продукта | | Нагрузка от инцидентов | Операционная работа в production и работа, затрагивающая клиентов | Система инцидентов и записи дежурств | Руководитель инженерии | Это менее эффектно, чем презентация об AI-трансформации. Зато такая система выдержит первый серьезный вопрос скептически настроенного инвестора. Не позволяйте одному человеку владеть всеми цифрами и всеми объяснениями. Финансовая команда должна уметь сверить расходы на зарплаты. Руководитель инженерии должен объяснить классификацию инцидентов. Руководитель продукта должен защищать определение выпущенной работы. Когда все четыре цифры исходят от одного автора презентации, компания создает узкое место в отчетности и стимул сглаживать противоречия. ## Самая опасная экономия - работа, исчезнувшая из учета Заявленная экономия может быть математически правильной и операционно бесполезной, если работа просто переехала в другое место. Она переходит к основателю, customer success, sales engineers, внешним агентствам, неоплачиваемым сверхурочным или клиентам, которые теперь вручную обходят пробелы продукта. Следите за пятью переносами, которые должны стать поводом для проверки: - Старшие руководители тратят больше времени на решение технических проблем поставки. - Команды customer success занимаются обходными решениями, которые раньше исправляла инженерия. - Подрядчики возвращаются на «короткие» проекты, которые становятся постоянными. - Продакт-менеджеры пишут подробные инструкции по реализации, потому что команда потеряла технический контекст. - Клиенты дольше ждут ответа поддержки или сталкиваются с большим числом ручных процессов. Это не аргументы против небольших команд. Это признаки того, что таблица зарплат не отражает всей операционной картины. Один сценарий неудачи повторяется часто. Компания сокращает инженеров, оставляет дорожную карту без изменений и ожидает, что AI-инструменты сразу закроют пробел. Оставшиеся старшие специалисты становятся ревьюерами, реагирующими на инциденты, переводчиками между продуктом и техникой и специалистами по интеграции. Несколько месяцев они сохраняют видимость прежней дорожной карты за счет более долгой работы и откладывания очистки. Затем сложный релиз выходит из строя, команда останавливает разработку функций, а руководство возвращает подрядчиков, которые берут больше денег, потому что приходят в перегруженную систему со слабой документацией. Первоначальная экономия на зарплатах остается в финансовом отчете. Одновременно бизнес получает расходы на подрядчиков, отложенную работу, приносящую выручку, повышенную нагрузку на поддержку и более хрупкую команду. Презентация для совета директоров, в которой указаны только зарплаты, формально не лжет. Она не показывает последствия решения. ### Не принимайте отложенный найм за экономию Отложенный найм не всегда означает экономию. Это может быть разумным решением, особенно если инженеры с AI способны справляться с текущим объемом работы. Но называйте это отложенным наймом до тех пор, пока команда не докажет, что может поддерживать работу без роста времени цикла и нагрузки от инцидентов. То же относится к незаполненной должности после увольнения сотрудника. Если работа действительно исчезла, экономия реальна. Если работа осталась, а команда поглощает ее за счет сверхурочных или роста очереди, организация не снизила спрос на инженерию. Она лишь отложила расходы. ## Убедительный кейс показывает арифметику и последствия Лучший кейс о сокращении инженерных расходов не похож на победный отчет. В нем показаны исходное состояние, операционные изменения, стоимость изменений, выполненная работа и результат по надежности. В нем также сказано, где переход оказался болезненным. Используйте эту структуру при внутренней проверке или внешней публикации утверждения: 1. Укажите базовый период и полные месячные операционные расходы инженерии. 2. Перечислите затраты на переход и отделите их от регулярных расходов после перехода. 3. Покажите результативность релизов по определению, связанному с работой для клиентов. 4. Покажите нагрузку от инцидентов и операционные часы, необходимые для ее устранения. 5. Объясните существенные изменения в объеме продукта, составе команды, спросе клиентов и сложности системы. Затем сформулируйте вывод одним простым абзацем. Например: компания сократила месячные операционные расходы инженерии на $110,000 после учета новых регулярных затрат; вернула $390,000 затрат на переход примерно за четыре месяца; сохранила результативность релизов в прежнем диапазоне для сопоставимой работы; нагрузка на реагирование сначала выросла, а затем вернулась к исходному уровню после восстановления автоматизации развертывания. Такое утверждение дает читателю материал для проверки. Если результативность релизов снизилась или нагрузка от инцидентов выросла, скажите об этом. Изменение все равно может быть оправдано, если компания осознанно обменяла скорость на запас времени или приняла временный рост риска для исправления сломанной операционной модели. Основатели идут на компромиссы. Ошибка заключается в том, чтобы делать вид, будто компромисса не было. ## AI меняет кривую расходов, но не отменяет необходимость доказательств Разработка с помощью AI может сократить объем рутинной реализации, который компании приходится покупать за счет найма. Одновременно она способна быстрее выявить плохие тесты, слабую архитектуру, расплывчатые требования к продукту и отсутствие ответственных. Инструмент не решает, какой из этих результатов получит компания. Важен не вопрос, быстрее ли AI-инструмент сгенерировал код. Спросите, может ли команда длительное время выпускать и поддерживать продукт меньшим числом людей, сохраняя согласованный уровень результата и надежности. Это возвращает обсуждение к четырем цифрам. Серьезная трансформация обычно меняет обязанности раньше, чем численность. Старшие инженеры переключаются на архитектуру, проверку, проектирование систем, предотвращение инцидентов и обучение рабочему процессу. Менее опытные инженеры могут взять на себя больше реализации, но только если кодовая база, тесты, путь развертывания и стандарты проверки создают для них безопасные условия. Пропустить такую перестройку и просто купить больше доступа к моделям - дорогая импровизация. Если ваша компания не может подготовить картину из четырех цифр, Team & AI Audit поможет определить базу до решения о численности команды. Первый полезный результат - не обещание насчет AI. Это понятная картина расходов и операционной работы, которую руководство может проверить без лозунгов. Требуйте базовые расходы на зарплаты. Требуйте затраты на переход. Требуйте доказательства того, что релизы по-прежнему доходят до клиентов. Требуйте историю инцидентов. Любая заявленная экономия, которая не выдерживает проверки этими четырьмя цифрами, - это изменение бюджета, а не инженерный результат.