Как одна команда перестала тушить пожары и что из этого вышло

В одной средней компании, работающей в сфере IT-услуг, годами царила атмосфера, которую сотрудники окрестили «режимом пожарной команды». Каждый день приносил новый инцидент. Каждый спринт — новый аврал. Прод падал с завидной регулярностью. Клиенты жаловались на одни и те же проблемы. Разработчики, выбиваясь из сил, героически всё чинили, получали похвалу за скорость реакции — и на следующий день всё повторялось заново.

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

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

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

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

Как именно перестроили работу с инцидентами

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

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

И только на пятом уровне команда выходила на системную причину: отсутствие автоматизированного процесса обновления и неполная документация. Если бы остановились на первом ответе «переполнилась память», то просто увеличили бы память и забыли. А так стало ясно: нужно автоматизировать обновление и переписать инструкцию.

Вторым шагом стало введение правила «одного владельца» для каждого инцидента. Раньше, когда что-то падало, кто-то быстро чинил и забывал. Теперь каждый инцидент получал владельца, который был ответственен не за то, чтобы «починить быстро», а за то, чтобы довести разбор до системного решения. Владелец не имел права закрыть задачу, пока не ответил на вопрос: «Что мы меняем в системе, чтобы эта проблема больше не возникла?» Если ответ был «ничего», задачу не закрывали.

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

Четвёртым шагом, вызвавшим, пожалуй, самое большое сопротивление, стало правило выделять время на системные улучшения. Раньше, когда команда работала «в режиме пожаров», на улучшения не оставалось ни минуты. Теперь в каждом спринте резервировали 20% времени на задачи, которые не приносят немедленной пользы, но снижают вероятность будущих проблем. Это могли быть: переписывание документации, автоматизация рутинных действий, написание тестов, рефакторинг проблемных мест.

Сопротивление, как водится, исходило от менеджеров продуктов: «Мы тратим время на то, что не даёт фич!» Пришлось объяснять, что это инвестиция, а не расход. Каждый час, потраченный на системное улучшение, экономит три часа будущих пожаров. И привели расчёты: за последний год команда потратила 400 часов на тушение повторяющихся проблем. Если бы они вложили 80 часов в системные решения, эти 400 часов превратились бы в 50.

С какими трудностями столкнулись на этом пути

Первая трудность, предсказуемая, но оттого не менее болезненная, — культура героизма. В команде были люди, которые гордились своей способностью «спасать» проекты в последний момент. Для них новое правило «не допускать пожаров» означало потерю идентичности. «Я тушильщик, я герой, а что я буду делать без пожаров?» — примерно так звучали их внутренние монологи.

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

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

Третья трудность, на первый взгляд парадоксальная, — сотрудники привыкли к драме. Оказывается, многим нравится быть в центре событий, когда всё горит, все бегают, а ты — главный герой. Тишина и спокойствие воспринимались как скука. Пришлось объяснять, что спокойствие — это не скука, а свобода заниматься интересными задачами, а не бесконечными переделками. Потребовалось несколько месяцев, чтобы это осознание пришло.

Какие результаты получили через год

Цифры, как это часто бывает, говорят сами за себя. Количество инцидентов в месяц сократилось на шестьдесят процентов. Если раньше команда фиксировала в среднем пятнадцать серьёзных проблем в месяц, то теперь их стало шесть. Время, затрачиваемое на устранение инцидентов, сократилось на семьдесят процентов — не потому, что команда стала медленнее, а потому что самих инцидентов стало меньше, и те, что случались, были менее серьёзными.

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

Но главный результат, пожалуй, лежал в области человеческих отношений. Команда перестала жить в режиме пожарной команды. Ушло чувство хронической усталости, возникавшее от бесконечных «авралов». Ушло ощущение, что ты постоянно должен кого-то спасать. Вместо этого появилось чувство контроля над своей работой — предсказуемость, устойчивость, возможность планировать.

Один из разработчиков, помнится, сказал на ретроспективе: «Раньше я просыпался с мыслью "что сегодня упадёт". Теперь я просыпаюсь с мыслью "что я сегодня улучшу". Разница колоссальная».

Что из этой истории можно взять уже завтра

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

Шаг для завтра:
когда вы в следующий раз столкнётесь с проблемой, требующей решения, остановитесь на мгновение. Вместо того чтобы думать «как это починить быстро», спросите себя: «Почему это произошло? И что нужно изменить в системе, чтобы это больше не повторилось?» Запишите ответ. И если ответ требует больше десяти минут работы — заведите отдельную задачу, не смешивая её с текущим решением.

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

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

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

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