В производстве простой — это плохо. Когда простаивают станки, фабрика недовырабатывает продукцию, амортизация оборудования происходит медленно и т.п.

В сервисной индустрии простой — параметр, требующий баланса. Когда у официантов или продавцов есть свободное время (они простаивают), они могут быстро обслужить клиента (уменьшаем простой клиента). Это стоит дороже для бизнеса, но можно найти правильный параметр загрузки персонала.

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

В разработке IT-продуктов простой тоже на каждом шагу.

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

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

• Ожидание внутри процесса — например, завершения билдов у программистов.
• Ожидание внутри функции — когда прогеры ждут друг друга.
• Ожидания внутриорганизационные — когда прогеры ждут прояснения требований от продактов, одобрения руководством и т.п.
• Внешние — разного рода аппрувалы, SEO и т.п.

Не все эти простои можно убрать. Системы слишком сложные, особенно, организационно-человеческие.

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

На помощь приходит стоицизм.

Стоики сделали бы инвентаризацию простоев и разбили список на три категории.

1. То, что мы можем контролировать — автоматизировать, оптимизировать и т.п. Системы CI/CD, разного рода скрипты и т.п. Сложно, но можно.
2. То, что мы не можем контролировать — смириться и делать эти задачи асинхронно. Просто делаем, результат будет когда-нибудь потом. Ну не можем мы повлиять на скорость индексации поисковиками...
3. То, что находится в серой зоне — искать процессы, снижающие простой. Хочешь, чтобы продакты отвечали разработчикам быстро? Посади их в одну комнату. Хочешь, чтобы прогеры быстрее друг друга разблокировали? Снизь на них нагрузку, они будут быстрее отвечать (как в сервисной индустрии, это называется "slack"). Разного рода процессные истории, вроде agile, тоже в этой категории. Это бесконечная, постоянно эволюционирующая оптимизация.

Приятных вам простоев.