Три дня на согласования ради задачи, которую разработчик пишет за три-четыре дня, и счёт за облака от $5 тыс. в месяц, где часть расходов уже никто не может внятно объяснить, — так выглядят скрытые потери в IT-разработке не в теории, а в обычной рабочей неделе. Для российских команд это знакомый сюжет: релизы выходят, Jira заполнена, CI/CD работает, а скорость и маржа всё равно утекают в щели между процессами.
Об этом сообщает Habr / Карьера со ссылкой на материал Сергея Прощаева, Tech Lead и руководителя направления Java/Kotlin-разработки в FinTech и e-commerce, который описал три типовых контура потерь: лишние согласования, ожидание между этапами и раздувающиеся расходы на облака и SaaS. Гайд адресован COO, фаундерам и техническим руководителям компаний с IT-отделом от 15 до 150 человек, где уже есть таск-трекер, Git, CI/CD и хотя бы базовая отчётность по инфраструктурным затратам.
Ключевой тезис статьи неприятен именно тем, что в нём мало драмы и много правды: команда может работать дисциплинированно и всё равно терять деньги. В пример автор приводит аутсорсинговый проект с командой из 12 человек и двумя стримами, где задача по интеграции с банковским API оценивалась в три дня разработки и ещё день тестов. На практике перед кодом запускались три круга согласований — архитектурный комитет, безопасность и продакт. Первый цикл занял три календарных дня, хотя сам код был готов через два дня и просто лежал в ветке без движения. После замены документов и презентаций на короткий чек-лист в Jira со схемой интеграции, перечнем логируемых данных и acceptance criteria время согласования сократилось до четырёх часов.
Это автор называет информационным налогом — неформальной, но вполне измеримой нагрузкой, когда инженеры тратят часы не на разработку, тестирование и ревью, а на сбор данных, отчётность, статусы, синки и согласования. В качестве рабочей эвристики предлагается делить суммарные часы на всю эту координацию на часы полезной инженерной работы. Если коэффициент выше 0,6, это уже сигнал, что процесс обслуживает сам себя. Практические рецепты довольно приземлённые: убрать обязательные документы, которые никто не читает, заменить часть синхронных статусов асинхронными апдейтами, использовать шаблоны для типовых решений и не делать Jira единственным священным источником истины, особенно если половина полей в тикете заполняется только ради галочки.
Второй источник потерь — ожидание между этапами. Здесь статья попадает в боль почти любой зрелой команды: задача формально в работе, но реального движения нет. Она ждёт старта, ответа смежников, код-ревью, окна на деплой или ручного подтверждения. В одном из проектов из практики автора среднее время от создания задачи до первого коммита составляло 2,5 дня. Для бизнеса это выглядит как «разработка идёт», для разработчика — как обычный фон, а для операционной экономики это чистый простой, который редко кто считает в деньгах. Проблема в том, что такие паузы размазаны по процессу и не вызывают тревоги по отдельности, хотя в сумме удлиняют цикл поставки сильнее, чем один крупный инцидент.
Третий контур потерь — облака и SaaS. Это особенно чувствительная тема для компаний, которые уже прошли этап хаотического роста и успели подключить всё полезное, а потом забыли отключить половину. По логике статьи, тут срабатывает тот же управленческий шаблон, что и в процессах разработки: расходы легализуются привычкой. Инстансы продолжают жить после экспериментов, подписки дублируют друг друга, а ежемесячный платёж воспринимается как погодное явление. Автор предлагает не начинать с большой оптимизационной кампании, а пройти короткий цикл: сначала замерить, потом выбрать два-три улучшения с низкой трудоёмкостью и высоким эффектом, внедрить по одному исправлению в каждом контуре, а через неделю-две повторить замеры и масштабировать то, что реально сработало.
Важная оговорка в материале — речь именно про operational efficiency, а не про product discovery. Иными словами, можно идеально ускорить delivery и всё равно сжечь бюджет на функциях, которые рынку не нужны. Для русскоязычной IT-аудитории здесь, пожалуй, самая полезная мысль в том, что скрытые потери в IT-разработке почти никогда не маскируются под катастрофу. Они маскируются под «ну у нас так принято», «безопасники должны посмотреть», «подождём релизное окно», «счёт за SaaS не такой уж большой». Из-за этого компании режут найм, спорят о производительности команд и внедряют новые регламенты, хотя часть денег можно вернуть более скучным способом: сократить ненужные артефакты, убрать лишние ожидания и наконец-то разобрать инфраструктурный мусор.
Похоже, следующий этап зрелости для многих продуктовых и аутсорсинговых команд — не ещё один модный фреймворк управления, а привычка смотреть на разработку как на систему очередей, согласований и регулярных платежей. Там, где руководитель видит не только velocity и число релизов, но и стоимость ожидания, разговор о «нехватке людей» иногда заканчивается совсем не наймом.