# Состояния ожидания в инженерной работе и их стоимость для фонда оплаты труда

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

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

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

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

## Состояния ожидания - это оплачиваемый простой с последствиями для бизнеса

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

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

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

На практике удобно выделить четыре категории:

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

Пятую категорию, «другая внешняя зависимость», используйте только временно. Если она становится распространенной, разделите ее. Категория, в которую попадает все подряд, ничему не учит.

Видимый симптом - инженер пишет в чате: «Кто-нибудь может посмотреть?» Фактическая стоимость начинается раньше. Работа распадается, когда человек бросает задачу и ищет другую. Когда ответ приходит, приходится заново восстанавливать контекст. Срок релиза сдвигается. Затем инженер должен вспомнить, почему решение было важно и не изменился ли код вокруг него.

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

## Отделяйте заблокированное время от календарного

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

Pull request, который ждал ревью 30 часов, не обязательно потребовал 30 оплаченных инженерных часов. Автор мог перейти к другой задаче. Но задержка в 30 часов все равно влияет на то, когда изменение можно объединить, протестировать, развернуть и показать клиенту. Она также создает дополнительные затраты на восстановление контекста, когда автор возвращается к работе.

Для каждого существенного ожидания фиксируйте три поля:

1. **Начало блокировки:** момент, когда инженер больше не мог сделать осмысленное изменение вперед.
2. **Конец блокировки:** момент, когда пришли недостающее решение, ревью, доступ или информация.
3. **Последствия блокировки:** люди и события бизнеса, зависевшие от этой работы.

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

Запись может быть совсем короткой:

```text
Work item: Billing retry rules
Blocked at: 2026-07-22 10:15
Category: Founder approval
Waiting on: Product founder
Question: Can retries continue after an account is marked past due?
People blocked: 1 engineer
Dependent event: Enterprise prospect needs confirmation before Friday demo
Unblocked at: 2026-07-23 14:40
```

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

Частое возражение звучит так: команда не может записывать каждое прерывание. И не должна. Фиксируйте ожидания, которые меняют план работы, задерживают релиз, вынуждают переключить задачу или блокируют больше одного человека. Цель - показать повторяющиеся источники задержек, а не провести идеальное исследование каждого движения.

Короткие, но повторяющиеся ожидания тоже важны. Ежедневные 15 минут на поиск доступа кажутся слишком мелкими для отчета. За месяц для четырех инженеров это превращается в регулярную потерю и показывает, что модель доступа сломана. Люди игнорируют такие случаи, потому что каждый по отдельности выглядит безобидно.

## Сначала оцените стоимость ожидания по фонду оплаты труда

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

Используйте формулу:

```text
Direct wait cost = blocked person-hours × loaded hourly cost × displacement factor
```

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

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

Предположим, полная внутренняя стоимость часа инженера составляет 150 долларов. Жесткая блокировка на четыре часа стоит 600 долларов, еще до учета отложенной выручки, упущенного обучения и дополнительной координации. Если инженер два часа занимается несвязанной работой и теряет темп, коэффициент вытеснения 0,5 дает прямую стоимость 300 долларов. Это все равно не бесплатно.

Не превращайте расчет в фиктивный счет, выставленный конкретным людям. Это инструмент для принятия решений. Он помогает руководству сравнить стоимость исправления рабочего процесса со стоимостью сохранения проблемы.

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

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

## Согласования у основателя требуют границ решений, а не более быстрых напоминаний

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

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

Решение не в том, чтобы требовать от основателя быстрее отвечать на каждое сообщение. Так вы лишь превратите его в более эффективное узкое место. Определите, какие решения требуют суждения основателя, а какие нет.

Полезная запись о решении состоит из пяти частей:

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

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

Вариант по умолчанию важен. Без него молчание означает остановку. С ним команда выбирает известный обратимый путь и фиксирует его. Некоторые основатели сопротивляются вариантам по умолчанию, потому что боятся плохих решений. Такой страх оправдан, когда решение необратимо. Но он создает лишние потери, если речь идет об обратимой детали интерфейса, поле логов или эксперименте, который можно откатить.

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

## Очереди код-ревью дважды наказывают небольшие команды

Очередь задерживает автора, но одновременно отнимает время проверяющего в неподходящий момент. Автор уже переключился на другое и должен заново восстановить детали изменения. Проверяющий видит больший diff, менее свежий контекст и множество несвязанных коммитов вокруг. За ожидание платят оба.

Измеряйте ревью по четырем временным отметкам: pull request открыт, отмечен как готовый, проведено первое содержательное ревью, изменение объединено. Промежуток от готовности до первого содержательного ревью и есть очередь. Одобрение от человека, который не читал изменение, содержательным ревью не считается. Автоматическое уведомление тоже.

Команды часто смотрят на длительность ревью, потому что она заметна. Обычно большая проблема - очередь. Проверяющий может внимательно изучить изменение за 20 минут, но автор будет ждать эти 20 минут два дня.

Не отвечайте простым правилом: каждый pull request должен получить ревью в течение часа. Такое правило создает давление на прерывания и поверхностные проверки. Лучше установить норматив первого ответа в зависимости от типа работы. Исправления в продакшене могут требовать немедленного внимания. Для обычных изменений первый ответ может быть нужен в тот же рабочий день. Крупные архитектурные изменения стоит обсуждать в запланированном слоте до того, как вокруг нерешенного выбора появятся сотни строк кода.

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

- Более глубокая проверка нужна для прав доступа, движения денег, удаления данных и изменений публичного API.
- Для обычных изменений кода достаточно одного квалифицированного проверяющего.
- Правила владения должны направлять изменения к людям, которые действительно могут их оценить.
- Изменения должны быть достаточно небольшими, чтобы проверяющий мог понять их смысл за один подход.

Очередь ревью также показывает неудобную кадровую правду: если один человек должен проверять все, он становится единственной точкой отказа. ИИ может помочь подготовить тесты, кратко описать diff и найти очевидные пропуски, но он не заменит ответственного проверяющего, у которого нет времени или знания системы. Сначала исправьте распределение ответственности и расписание.

## Доступ к окружению - это мощность поставки, а не администрация

Если инженер не может открыть лог, воспроизвести проблему клиента, использовать тестовый аккаунт или развернуть одобренное изменение, у компании меньше мощности, чем ей кажется. Название «запрос в IT» не меняет последствия для поставки.

Доступ к окружению особенно часто создает неприятные задержки, потому что пересекает границы команд. Инженер обращается к менеджеру, менеджер - к безопасности или эксплуатации, кто-то обнаруживает устаревшую группу, а затем запрос задерживается еще сильнее, потому что никто не может объяснить, какое именно разрешение нужно. Тем временем инженер начинает гадать.

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

Для каждого окружения определите:

```text
Role: Application engineer on incident rotation
Can read: service logs, traces, error reports, sanitized production records
Can change: feature flags and approved deployment settings
Cannot change: customer billing records, user roles, raw secret values
Access duration: expires after incident rotation unless renewed
Approval owner: engineering operations lead
```

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

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

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

## Неясные требования дороги, потому что работа продолжает двигаться

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

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

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

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

Команда, которая начинает писать код до получения этих ответов, не движется быстрее. Она переносит неопределенность в код, где ее дороже обнаруживать и исправлять.

Используйте блок требований, если неоднозначность влияет на поставку:

```text
Outcome: The system retries temporary payment failures automatically.
Owner: Product lead
Acceptance test: A temporary provider failure creates a visible pending state and retries under the documented policy.
Decision still open: Whether past-due accounts keep full access during the retry window.
Default by Thursday 3:00 PM: Keep access, log the exception, and flag the account for support review.
Non-goal: Changing plan pricing or collection policy.
```

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

## Сравнивайте стоимость задержек с фондом оплаты труда честно

Фонд оплаты труда отвечает на вопрос: «Сколько мы платим за команду?» Стоимость задержек отвечает на другой: «Что команда не выпускает, пока работа ждет?» Полезный операционный обзор показывает оба числа рядом, не создавая видимость точности до доллара.

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

| Категория ожидания | Заблокированные человеко-часы | Прямая стоимость | Задержанное событие | Допущение о влиянии на бизнес |
| --- | ---: | ---: | --- | --- |
| Согласование у основателя | 42 | $3,150 | Эксперимент с ценой начался поздно | Обучение задержалось на неделю |
| Очередь ревью | 58 | $4,350 | Релиз перенесен | Исправление для поддержки дошло до клиентов на два дня позже |
| Доступ к окружению | 25 | $3,750 | Диагностика инцидента замедлилась | Дежурство продлилось |
| Неясные требования | 46 | $3,450 | Переделка платежного сценария | Запланированная функция отложена |

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

Теперь сопоставьте прямую стоимость ожидания с фондом оплаты труда, который вы пытаетесь оптимизировать. Предположим, полностью загруженная годовая стоимость команды из пяти человек составляет 1,2 миллиона долларов. Если документированные внешние ожидания дают консервативную прямую стоимость 15 000 долларов в месяц, это 180 000 долларов в год, еще до учета задержек бизнеса. Команде не обязательно нужен шестой инженер, чтобы вернуть эту мощность. Возможно, ей нужны более четкое делегирование, покрытие ревью и удобные маршруты доступа.

Такое сравнение меняет решения о найме. Основатель может решить, что инженерия работает медленно, и одобрить еще один найм. Если текущая команда значительную часть времени ждет одних и тех же двух людей, новый сотрудник попадет в те же очереди. Фонд оплаты труда вырастет, а пропускная способность почти не изменится.

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

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

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

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

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

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

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

Team & AI Audit помогает увидеть эти данные в более широком контексте: численности команды, потока поставки и инженерной работы с поддержкой ИИ. Полезный результат - список ограничений с оценкой стоимости и рабочие изменения, которые их устраняют, а не общий балл продуктивности.

В следующий разговор о бюджете добавьте к фонду оплаты труда один вопрос: где команда ждала в прошлом месяце, кто отвечал за каждую очередь и что именно задержало это ожидание? Если никто не может ответить, не считайте стоимость небольшой. Считайте, что вы ее пока не измерили.