Деплой как зеркало организации: что ваши релизы говорят о процессах

Одним из прокси-показателей качества процессов команды (а иногда и всей организации) является «боль» от деплоев. Авторы книги «Accelerate» в ходе своего исследования выявили значимую корреляцию между трудностями, возникающими в процессе релиза ПО (и после него), и производительностью IT-команд.

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

⭐️ Слабая поставка == кошмарная работа

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

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

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

⭐️ Как DevOps влияет на процессы

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

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

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

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

// А какой уровень боли от деплоев в вашей команде?

В этом посте были ссылки, но мы их удалили по правилам Сетки