Культура героизма: почему команда, спасающая проекты по ночам, работает плохо

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

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

Аврал как часть плана

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

Когда все привыкают, что команда всегда готова подключиться овертайм, лишь бы спасти проект, пропадает стимул закладывать доработки в планирование. Даже когда меняются требования к проекту, дедлайны никто не переносит — разработчики ведь уже не раз показывали, что способны собраться и «дожать». Возникает иллюзия высокой эффективности: релиз проходит успешно и в срок, а руководство получает очередное подтверждение, что план был реалистичным. Хотя реалистичным он не был: просто команда потратила личное время, чтобы закрыть разницу между планом и действительностью.

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

Культура супергероев

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

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

Последствия для команды и продукта

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

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

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

Причины героизма

Важно понимать, что работа по ночам — это симптом, а не сама болезнь, поэтому недостаточно запретить сотрудникам работать после 19:00. Если не наладить процессы и не устранить причину, кризисы никуда не исчезнут — вы лишь потеряете привычный способ справляться с ними .

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

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

Как перестроить процессы

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

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

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