Экономика внедрения CI/CD в проекте на платформе 1С: как посчитать эффект и обосновать заказчику

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

🧱 Скрытые издержки ручных релизов

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

• Простой бизнеса. Пока идёт выкатка, бухгалтерия не закрывает период, менеджеры не видят остатки, склад не отгружает. Час простоя списывается на «издержки автоматизации».
• Ручные операции. Выгрузка, перенос, обновление и проверка занимают часы квалифицированного специалиста. Это работа, которую автоматизируют первой.
• Ошибки переноса. Забытый объект, не та версия расширения, незалитые права - каждая такая ошибка требует разбора и повторной выкатки.
• Отсутствие воспроизводимости. Порядок действий держится в голове у одного человека. Его отпуск или уход превращает релиз в лотерею.
• Накопление версий. Несколько конфигураций обмена, расширения и внешние обработки переносятся по отдельности, и состав релиза каждый раз собирается заново.

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

🧮 Из чего складывается расчёт

Расчёт держится на четырёх величинах, и все они берутся из истории заказчика.

Стоимость одного ручного релиза

Стоимость релиза = время релиза в часах * ставка часа

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

Стоимость инцидентов на продуктиве

Стоимость инцидентов = число инцидентов * (часы разбора * ставка + упущенная выгода)

Упущенная выгода - оценка заказчика: сколько стоит час остановки конкретного процесса. Если оценку дать не могут, в расчёт идут только часы разбора.

Затраты на внедрение

Затраты = часы на настройку и скрипты + часы на автотесты + часы на обучение

Примерный состав работ: сервер сборки, скрипты выгрузки и загрузки конфигурации, связка с системой контроля версий, базовые автотесты на критические сценарии, обучение команды.

Срок окупаемости

Срок окупаемости = затраты на внедрение / экономия в месяц

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

💰 Условный пример расчёта

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

Исходные данные

Текущие издержки в месяц

Релизы:    4 * 5 * 2 500 = 50 000 руб.
Инциденты: 3 * (4 * 2 500 + 30 000) = 3 * 40 000 = 120 000 руб.
Итого:     170 000 руб. в месяц

Затраты на внедрение

Настройка сервера и скриптов:        200 часов * 2 500 = 500 000 руб.
Автотесты на критические сценарии:   100 часов * 2 500 = 250 000 руб.
Обучение и переходный период:         50 часов * 2 500 = 125 000 руб.
Итого: 875 000 руб.

Экономия после внедрения

Сокращение времени релиза на 80%:      50 000 * 0,8 = 40 000 руб. в месяц
Снижение числа инцидентов на 70%:     120 000 * 0,7 = 84 000 руб. в месяц
Итого: 124 000 руб. в месяц

Срок окупаемости: 875 000 / 124 000 ≈ 7 месяцев. Проценты сокращения (80% и 70%) в примере взяты как ориентир на первый год: их подтверждает сама команда после двух-трёх автоматизированных релизов, а до этого в расчёт лучше ставить четверть и половину.

📋 Что запросить у заказчика

Расчёт начинается с выгрузки фактов. Оценка на глаз даёт числа, которые заказчик оспорит на первой же встрече. Запросите данные за последние 3-6 месяцев:

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

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

🚧 Границы расчёта

• Эффект ускорения вывода функций в расчёт не входит: он зависит от того, насколько быстро бизнес готов принимать изменения. Считать его деньгами без данных заказчика нельзя.
• Стоимость адаптации новых сотрудников оценивается по времени входа в проект, а оно измеряется только по факту, когда новичок уже вышел.
• Качественные эффекты - прозрачность состава релиза, возможность отката, воспроизводимость сборки - в цифры не переводятся. Их стоит назвать отдельным списком и не смешивать с экономией.
• Числа из обзоров в расчёт не годятся: ставки, проценты и «сокращение в несколько раз» зависят от конфигурации, команды и зрелости процесса. Расчёт строится на данных заказчика, и это его главное преимущество перед презентацией из интернета.

🤝 Четыре возражения и ответы

«У нас маленькая команда, нам это не нужно». Риск ручного переноса есть и при одном разработчике: те же ошибки переноса, та же зависимость от знаний одного человека. Стоимость внедрения при этом растёт вместе с объёмом конфигурации. Для одной конфигурации объём работ меньше, чем в примере: начинать стоит с автоматизации сборки и выкатки на тестовый контур.

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

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

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

🧰 Порядок внедрения

Этапы идут в этом порядке, потому что каждый следующий опирается на предыдущий.

1. Хранилище и контроль версий. Разработка переводится на хранилище конфигурации, история изменений - в систему контроля версий. Результат: видно, кто и что менял.
2. Сборка и выкатка на тест. Сервер сборки, скрипты выгрузки и загрузки, автоматическая выкатка на тестовый контур. Результат: сборка и развёртывание одной командой.
3. Проверка синтаксиса в конвейере. Синтаксический контроль и отчёт о результатах при каждом изменении. Результат: ошибка видна до выкатки.
4. Автотесты. Критические сценарии - проведение документов, формирование отчётов - проверяются автоматически. Результат: обратная связь по качеству в течение минут после изменения.
5. Выкатка на продуктив с откатом. Процедура выкатки, уведомления о статусе, обучение команды. Результат: предсказуемое окно выкатки вместо аврала.

📈 Что отслеживать после внедрения

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

Первые два показателя проверяют сам расчёт: если время релиза и число инцидентов не двигаются, значит исходные данные были оценены неверно, и расчёт стоит пересобрать на новых фактах.

🏁 Итог

Обоснование внедрения CI/CD держится на данных заказчика: стоимость ручных релизов, стоимость инцидентов, затраты на внедрение и срок окупаемости считаются по четырём формулам, а проценты сокращения берутся консервативно. Условный пример в статье даёт формат таблиц, числа подставляются свои. Разговор с заказчиком идёт о его издержках, и тогда вопрос цены переходит в вопрос срока окупаемости.

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

📦 Файл к статье

Архив к статье (05.4-companion.zip) лежит в блоке «Файлы» под текстом публикации. Что внутри:

• kalkulyator-okupaemosti.csv - таблица-калькулятор с формулами: подставьте свои часы и ставку, итог и срок окупаемости пересчитаются;
• voprosy-zakazchiku.md - список вопросов для сбора исходных данных и место для ответов;
• vozrazheniya-i-otvety.md - четыре возражения с заготовками ответов;
• plan-vnedreniya.md - пять этапов с результатом каждого и признаком готовности.

Все суммы в примерах условные. Расчёт не заменяет замер на своей истории: исходные данные собираются у заказчика.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 28 технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S