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

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

Я Tech Lead и руководитель направления Java | Kotlin разработки в FinTech & E‑commerce, также преподаю на курсах разработки и архитектуры в OTUS. За последние пять лет я видел десятки команд: от стартапов с тремя джунами до enterprise‑компаний с сотнями сервисов. И везде повторяется одна и та же картина — ресурсы уходят туда, куда никто не смотрит.

Для кого этот гайд (исходные условия)

Гайд рассчитан на COO, фаундера или технического руководителя в SaaS или аутсорсинговой компании с численностью IT‑отдела от 15 до 150 человек. У вас уже есть налаженные процессы (Jira, Git, CI/CD) и ежемесячный облачный счёт от $5 тыс. Если вы стартап на первой стадии или корпорация с бюрократией выше крыши — некоторые решения придётся адаптировать (об этом в конце).

Исходные ограничения, которые мы берём за точку отсчёта:

• Команда использует таск‑трекер (Jira/YouTrack/Linear).

• Код хранится в Git, есть CI/CD (GitHub Actions, GitLab CI, Jenkins).

• Облачная инфраструктура (AWS, GCP, Azure) или хотя бы виртуализация.

• Есть хотя бы один ежемесячный отчёт по затратам на облака и подписки.

Если чего‑то из этого нет — сначала добейтесь базового порядка, потом возвращайтесь к гайду.

Важное различие: эффективность (efficiency) vs результативность (effectiveness)

Эта статья в основном про efficiency — как быстрее и дешевле доставлять то, что вы уже делаете. Но senior‑аудитория знает: локальная эффективность бессмысленна, если команда поставляет ненужные функции или решает не ту проблему. Ускорение delivery не спасает, если product discovery сломан.

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

Общий пошаговый маршрут (5 шагов за месяц)

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

Шаг 1 (Неделя 1 — Аудит)
Замерьте все три вида потерь по формулам и чек‑листам ниже. Не пытайтесь ничего исправлять — только цифры.

Шаг 2 (Неделя 2 — Приоритизация)
Оцените влияние каждой потери на скорость прохождения задач через систему и стоимость координации. Выберите 2–3 задачи с low effort / high impact (мало усилий — много эффекта).

Шаг 3 (Неделя 3 — Быстрые победы)
Внедрите по одному исправлению в каждом контуре:

• Уберите один вид согласования (информационный налог).

• Автоматизируйте одно ожидание (ревью/деплой).

• Отключите неиспользуемые инстансы и дублирующиеся SaaS.

Шаг 4 (Неделя 4 — Измерение)
Повторите замеры. Сравните с исходными. Зафиксируйте изменения.

Шаг 5 (Масштабирование)
Перенесите удачные решения на другие команды/проекты. Повторите цикл с новыми контурами.

Теперь пройдём каждый контур детально — внутри я буду ссылаться на эти общие шаги.

Контур 1. Информационный налог — когда согласование длиннее разработки

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

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

Кейс: как мы сократили время согласования с трёх дней до четырёх часов

Перед написанием кода нужно было пройти три согласования:

• Архитектурный комитет (предоставить схему последовательности и описание интеграции).

• Безопасность (проверить, не сливаем ли мы PII в логи).

• Продакт‑менеджер (убедиться, что поведение при ошибках соответствует бизнес‑правилам).

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

Я тогда ввёл простое правило: вместо долгих документов — короткий чек‑лист в Jira с тремя пунктами:

1. Схема интеграции в Mermaid (вставляется прямо в описание задачи).

2. Перечень логируемых данных (подтверждение от security в комментарии).

3. Три acceptance criteria от продакта.

После этого время согласования упало до четырёх часов. А объём правок по итогам код‑ревью не вырос — потому что разработчики перестали гадать, что именно нужно сделать.

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

Что такое информационный налог? (эвристика для быстрой диагностики)

Вот практический индикатор, который я использую (это не индустриальный стандарт, а рабочая эвристика для оценки операционной нагрузки):

(Суммарные часы всех участников на сбор данных, отчётность, согласования, заполнение трекеров, синхронизации) / часы на полезную работу (разработка, тестирование, ревью)

Если коэффициент > 0,6 — это зона внимания. В здоровых командах обычно < 0,3.

Как быстро снизить информационный налог (ваш первый чек‑лист)

1. Уберите обязательные документы, которые никто не читает. В одном проекте мы обнаружили, что 200-страничная спецификация на Confluence не открывалась последние два спринта. Заменили на wiki‑страницу с пятью разделами.

2. Рассмотрите возможность асинхронных апдейтов. Для части команд асинхронные апдейты могут заменить ежедневные синхронизации, если команда уже достаточно автономна. Например, утренний комментарий в Slack: «Что сделано, что блокирует, план».

3. Внедрите шаблоны для часто повторяемых артефактов. Чек‑лист для ревью архитектуры, таблица выбора технологий, стандартная структура ADR (Architecture Decision Record).

4. Автоматизируйте сбор метрик. Вместо того чтобы разработчики вручную заполняли статусы в Jira, настройте автоматический экспорт из Git (коммиты, PR, время ревью).

Я бы предпочёл не использовать Jira как единственный источник истины — часто она сама становится генератором налогов. Но если Jira уже стала центральным инструментом управления, хотя бы уберите кастомные поля, которые никто не заполняет.

Контур 2. Стоимость ожидания — когда задача лежит мёртвым грузом

Могу себе представить, как вы сейчас подумали: «Ну, ожидание — это же неизбежно, код‑ревью, деплой, ответы смежников». Да, но цена этого ожидания почти всегда недооценена.

В одном из моих предыдущих проектов (FinTech, команда 40 разработчиков) я замерил такие метрики:

Время от создания задачи до первого коммита (Time to First Commit) = в среднем 2,5 дня.

А чистое время активной работы над задачей — около 6 часов. Остальное — waiting time.

Разница — это Waiting Time: уточнения требований, доступа к данным, ревью и завершения CI/CD pipeline. Это не прямой простой (разработчик обычно параллелит задачи), а стоимость замедленного потока: переключения контекста, потери фокуса, увеличения времени цикла.

Теперь про DORA metrics. Одна из них — Lead Time for Changes (время от коммита до продакшена). Согласно DORA‑метрикам, высокоэффективные команды обычно минимизируют время между коммитом и деплоем в продакшен, но абсолютные значения сильно зависят от домена, требований к compliance и архитектуры системы.

Где искать скрытое ожидание

Я составил для себя список из пяти мест, куда смотрю в первую очередь:

Что с этим делать на практике?

Мой вариант — раз в две недели брать случайную завершённую задачу и реконструировать её временную линию. Где были длинные паузы? Почему? Можно было их избежать?

В одной команде мы обнаружили, что задача лежала несколько дней в статусе «тестирование», потому что тестировщик ждал, пока разработчик выкатит стенд. Автоматический деплой в shared dev environment после прохождения CI pipeline сократил время передачи задачи в тестирование с нескольких дней до нескольких часов.

Контур 3. Скрытые потери в SaaS и облаках — невидимый пожиратель бюджета

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

Я как‑то пришёл в проект, где ежемесячный счёт за облака составлял $35 000. Команда жаловалась на нехватку ресурсов. Мы провели аудит за два дня и нашли:

• 14 неиспользуемых инстансов БД (остались от предыдущего релиза). Экономия — $2800/мес.

• Удвоенные лицензии на CI/CD (GitHub Actions + Jenkins + TeamCity, хотя использовали только GitHub Actions). Экономия — $1200/мес.

• Overprovisioned Kubernetes‑кластер — requests и limits были настроены существенно выше реального p95 потребления. Экономия — $4000/мес.

• Неотключенные аккаунты в Datadog, New Relic и Sentry — часть систем дублировала друг друга по функциональности без понятных operational requirements. Экономия — $3500/мес.

Итого — $11 500 в месяц только на очевидных вещах. Это почти 140 тысяч долларов в год.

Ваш чек‑лист по SaaS‑оптимизации (2026 edition)

1. Раз в квартал проводите FinOps‑ревью. Соберите все подписки: облака, CI/CD, мониторинг, логи, артефакторы, БД как сервис, AI/ML‑тулы.

2. Проверьте реальное потребление. В AWS — Cost Explorer с Rightsizing Recommendations, в GCP — Recommender, в Azure — Advisor.

3. Удалите дублирующиеся инструменты (или хотя бы обоснуйте, зачем вам два решения для одной задачи).

4. Используйте committed use discounts (Reserved Instances, Savings Plans), если нагрузка стабильна.

5. Автоматизируйте остановку неиспользуемых окружений на ночь и выходные (до 30% экономии для dev/stage).

Практический пример команды для аудита AWS:

# Найти остановленные инстансы
aws ec2 describe-instances --filters "Name=instance-state-name,Values=stopped" --query 'Reservations[*].Instances[*].[InstanceId,InstanceType,State.Name]' --output table

# Найти неиспользуемые volumes
aws ec2 describe-volumes --filters "Name=status,Values=available" --query 'Volumes[*].VolumeId' --output text

Практический пример аудита ресурсов в Kubernetes

# Найти поды в состоянии Failed
kubectl get pods --all-namespaces \
  --field-selector=status.phase=Failed

# Найти неиспользуемые Persistent Volume
kubectl get pv

# Проверить requests/limits по namespace
kubectl describe resourcequota -A

Полезно также регулярно сравнивать фактическое потребление CPU и памяти с настроенными requests/limits. На практике именно завышенные лимиты часто становятся причиной избыточных затрат на инфраструктуру.

Важное предупреждение: перед удалением любых ресурсов убедитесь, что они не используются в DR‑сценариях, политиках резервного копирования или временных окружениях. Неиспользуемый том или остановленный сервис ещё не всегда означает лишний ресурс. Для облачных платформ (Yandex Cloud, VK Cloud и других) доступны собственные инструменты анализа потребления и рекомендации по оптимизации. Главное — проводить такие проверки регулярно и фиксировать результаты в рамках FinOps‑практики.

Диагностика и алгоритм изменений

Прежде чем что‑то исправлять, нужно понять, где именно теряются ресурсы. Ниже — схема, которая сводит три контура потерь в единую картину. Посмотрите, как информационный налог, ожидание и SaaS‑расходы связаны с конечным результатом (рис. 2).

Большинство потерь в разработке лежит не в зарплатах или «плохих» сотрудниках, а в трёх системных зонах: информационный налог (согласования, отчёты), стоимость ожидания (ревью, CI/CD, зависимости) и избыточные SaaS‑расходы. Каждый контур измеряется и даёт измеримый результат — снижение времени согласования и увеличение flow efficiency (скорости прохождения задач). Главная мысль: начните с любого контура — улучшения придут быстрее, чем вы думаете.

А теперь — пошаговый план, который я проверил на реальных проектах. Он не требует долгой подготовки. Просто берите и делайте по неделям. Ключевой принцип: сначала быстрые победы, потом масштабирование (рис. 3).

За четыре недели можно пройти полный цикл: аудит, приоритизация быстрых побед, внедрение, измерение, масштабирование. Ключевая идея — не пытаться исправить всё сразу, а выбрать 3–4 задачи с low effort / high impact (мало усилий — много эффекта). После первой итерации цикл повторяется для следующего контура. Это практичный, а не теоретический подход.

Когда этот гайд не поможет (и что тогда делать)

Гайд не панацея. Вот ситуации, где решение не сработает:

1. Жёстко регулируемая отрасль (банки, госсектор, медицина). Вы не сможете убрать весь информационный налог, потому что обязательные документы продиктованы регуляторами.
   
   Что делать: сократить налог на 30% за счёт шаблонов и автоматизации отчётности — это реально.

2. Нет базового CI/CD или таск‑трекера. Если вы работаете «на энтузиазме» без автоматизации, сначала внедрите хотя бы минимальный порядок.
   
   Что делать: потратьте месяц на настройку Git + CI (GitHub Actions бесплатен для малых команд).

3. Размер команды менее 5 разработчиков. Ваши потери в абсолютных цифрах могут быть меньше, чем усилия на их поиск.
   
   Что делать: сфокусируйтесь только на одном контуре (например, SaaS‑подписки) — там почти всегда есть мёртвые лицензии.

4. Компания уже в кризисе и нужно спасать продажи. Гайд про операционную эффективность, а не про рост выручки.
   
   Что делать: закройте сначала sales‑воронку, потом возвращайтесь к потерям внутри разработки.

Как понять, что вы всё сделали правильно (финальная проверка результата)

Через месяц после внедрения по нашему алгоритму проведите контрольные замеры:

• Информационный налог (коэффициент) заметно снизился по сравнению с исходным (например, с 0,8 до 0,5 или ниже).

• Lead Time for Changes сократился (насколько — зависит от вашего домена; главное — устойчивая тенденция к снижению).

• Ежемесячный счёт за облака уменьшился на 15–20% без потери производительности (проверьте метрики CPU/память/латентность).

Если вы увидели улучшения хотя бы по двум направлениям — вы на правильном пути. Если нет — вернитесь к шагу 1 (аудит) и проверьте, где вы срезали угол.

Итог: что делать прямо завтра?

Как и предполагал в начале, ресурсы уже утекают. Вопрос только в том, заметите ли вы это до того, как CFO начнёт задавать неудобные вопросы.

Вот три действия, которые я рекомендую выполнить в ближайшие 48 часов:

1. Проведите часовой аудит информационного налога. Выберите три задачи, выполненные на прошлой неделе. Посчитайте, сколько часов ушло на согласования, переписки, созвоны, обновление документов. Оцените эту нагрузку (хотя бы как индикатор).

2. Замерьте Lead Time for Changes. Посмотрите в Git или CI/CD, сколько времени проходит от коммита до продакшена. Сравните с DORA‑бенчмарками для вашего домена.

3. Скачайте выгрузку всех облачных подписок (AWS Cost Explorer, Google Cloud Billing, Azure Cost Management). Отсортируйте по услугам, которые не использовались последние 30 дней. Прежде чем удалять — убедитесь, что они не нужны для DR или бэкапов.

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

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

• 4 июня, 20:00. «Операционная эффективность в ИТ: как находить скрытую прибыль в процессах разработки». Записаться

• 18 июня, 20:00. «Операционный директор в ИТ: компетенции, которые превращают хаос в систему». Записаться

Больше бесплатных открытых уроков июня — в дайджесте OTUS.