Переработки - не героизм, а сигнал, что процесс пора чинить

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

Решение находили привычное: «Ребят, тут еще немного, давайте сегодня задержимся».

Сначала это выглядело как временная мера. Потом стало частью рабочего процесса. Релизы сдвигались, объем задач рос, а авралы повторялись снова и снова. 😵‍💫

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

И качество тоже начало страдать.

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

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

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

Что можно сделать вместо этого? - Фиксировать объем релиза и договоренности. Если появляются новые задачи, обсуждать, что из запланированного переносится. Дополнительная работа не должна автоматически становиться дополнительной нагрузкой. - Расставлять приоритеты. Разделять действительно критичные задачи и те, которые могут подождать. Не все, что срочно для заказчика, одинаково важно для продукта. - Планировать с учетом реальных ресурсов. У команды есть определенная пропускная способность. И если она уже загружена, это нужно учитывать при принятии новых обязательств. - Управлять ожиданиями заказчика. Иногда задача лида - не найти способ выполнить все любой ценой, а объяснить последствия: что мы успеем, чем рискуем и какие решения нужно принять.

И был у меня показательный случай. Команда решила больше не компенсировать проблемы планирования регулярными переработками.

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

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

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