Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
ПЕРЕСТАТЬ ОПРАВДЫВАТЬСЯ И НАЧАТЬ ДЕЙСТВОВАТЬ
Вначале путешествие American Airlines по DevOps выросло из серии вопросов. Первый из них был простым: “Что такое DevOps?
“Мы действительно начинали с самых низов, с самого начала”, – сказала Майя Лейбман, исполнительный вице-президент и главный информационный директор American Airlines.
Чтобы начать, команда провела исследование, но самое главное – перестала оправдываться. В самом начале развития DevOps несколько лет назад большинство примеров было связано с компаниями, ориентированными на цифровые технологии, такими как Netflix и Spotify. Команде было легко сбрасывать со счетов их достижения – в конце концов, они родились в облаке. Но когда более традиционные предприятия, такие компании, как Target, Nordstrom и Starbucks, встали на ноги, American Airlines поняла, что у них не осталось никаких оправданий.
Чтобы начать работу, они сделали следующее:
- поставили конкретные цели
- формализовали цепочку инструментов
- привлекли тренеров и наставников извне компании
- экспериментировали и автоматизировали
- проводили иммерсивные практические тренинги (чтобы учиться в процессе работы).
Но все это было связано с их конечной целью – быстрее создавать ценности.
Было много случаев, когда коллеги по бизнесу приносили новую идею, но руководство говорило: “О, это то, что мы хотим сделать, но ИТ-отделу потребуется шесть месяцев или год, чтобы это реализовать”. И этот опыт просто убивал меня. Так что толчком к этому послужил вопрос: “Как нам не быть длинным шестом для палатки”. Мы знали, что есть лучший способ работы, который поможет нам достичь этого”, – Майя Лейбман.
Следующим шагом стало решение о том, какие результаты они собираются измерять. Они начали со следующего:
- частота развертывания
- время цикла развертывания
- частота отказов изменений
- время цикла разработки
- количество инцидентов
- среднее время восстановления (MTTR)
Первые успехи в картировании потока создания ценности помогли членам команды лучше понять сквозные процессы системы и придали им мотивацию. На основе этих успехов они накопили энергию для того, чтобы атаковать систему и сделать ее лучше. Они также проводили погружение в процесс обучения в рамках всего ИТ.
ФИНАНСЫ – ДРУГ ИЛИ ВРАГ?
Эти первые успехи, изучение DevOps и начало практического применения некоторых его элементов привели их ко второму большому вопросу на пути DevOps: Финансы – друг или враг?
Текущий процесс утверждения финансов был громоздким и длительным, с многомесячными циклами утверждения. “Раньше я описывала этот процесс как процесс, созданный для того, чтобы заставить вас сдаться”, – говорит Майя Лейбман.
Процесс выглядел следующим образом:
- Ни один проект не утверждался без участия финансов.
- Проекты утверждались, но для их выполнения не добавлялась численность персонала (и не останавливались другие приоритеты).
- Запросы рассматривались одинаково тщательно, независимо от размера или риска.
- Запросы рассматривались одинаково тщательно, даже если это был высший корпоративный приоритет и не было сомнений в том, что он будет выполнен.
- Проекты часто завершались до их утверждения.
Хотя даже финансисты понимали, что процесс необходимо изменить, отсутствие доверия между финансами и ИТ привело к блокировке. Чтобы пролить свет на то, куда тратятся деньги, и укрепить доверие с финансами, они провели анализ затрат и определили все расходы на свои продукты, включая расходы на их эксплуатацию.
ИТ-команда смогла лучше понять, куда на самом деле вкладываются деньги, и усомниться в том, что они используются наилучшим образом. Финансисты смогли получить необходимую информацию, чтобы убедиться в отсутствии больших потерь.
Благодаря этой видимости они получили доверие к экспериментам. Они взяли четыре продуктовые команды и выделили им определенный бюджет на год. Команды определили OKRs и использовали бюджет на самые приоритетные задачи, которые, по их мнению, соответствовали этим OKRs. Это позволило команде провести тестирование перед внедрением и сосредоточиться на подотчетности и результатах, а финансы смогли получить еще большую видимость.
Этот успех позволил им масштабировать новую модель на все свои продукты и определить новый процесс финансирования для всего отдела. “Это был огромный ускоритель в нашем путешествии”, – говорит Майя Лейбман.
КАКОВ СЧЕТ?
Когда финансы были на борту, а новые процессы были внедрены, компания America Airlines столкнулась с третьим вопросом на своем пути DevOps: Как узнать, каков результат? Добиваясь небольших успехов, они хотели лучше понять, как идут дела в целом. Каков был результат? Закончили ли они?
- Для команды American Airlines первый год их пути DevOps был сфокусирован на исходных данных: изучение Agile/DevOps, фокусировка на продуктах, облаке, безопасности и т. д.
- На втором году пути они стали больше думать о результатах, включая показатели, которые они начали измерять, такие как частота развертывания и среднее время восстановления.
- Третий год стал моментом, когда они начали фокусироваться не только на входах и выходах, но и на результатах. “В конце концов, что мы действительно хотим сделать”, – сказал Лейбман.
Они пришли к следующим результатам. Мы хотим:
- зарабатывать деньги
- улучшить операционную деятельность
- увеличить LTR
- снизить затраты
В первый год одна из наших целей заключалась в том, что X% людей пойдут на тренинг по Agile. Это действительно представляет собой входные данные. На второй год, когда мы стали больше фокусироваться на результатах, цели как бы изменились на X% команд, которые повысят уровень зрелости Agile с этого уровня до этого. А когда мы перешли к третьему году, agile уже не был целью. Мы поняли, что входы и выходы – это здорово, мы должны их измерять, но в конечном итоге мы должны быть сосредоточены на результате.
ЧТО ТАКОЕ ПРОДУКТ?
Это, наконец, привело к четвертому вопросу в их путешествии по DevOps: Что такое продукт? Пришло время уточнить таксономию. Это оказалось одним из самых сложных моментов на их пути. Было много мнений и не было единственно правильного ответа. В конце концов, они решили просто начать, изложить что-то на бумаге, организовать все вокруг и исправлять по мере накопления опыта. И в конечном итоге все это привело их к пятому вопросу: Чувствуете ли вы, что это нечто большее, чем DevOps?
КАК МАСШТАБИРОВАТЬ DEVOPS НА ВЕСЬ БИЗНЕС
Следующей задачей стало масштабирование этих новых методов работы на весь бизнес, чтобы ускорить и продолжить реализацию преобразований и полученных знаний.
Они привлекли Росса Клэнтона в качестве управляющего директора, главного архитектора по трансформации технологий, чтобы он помог им перейти на новый уровень.
Для того чтобы подтолкнуть к разговору всю организацию, они сосредоточились на двух вещах:
- почему: создание конкурентного преимущества
- как: бизнес и ИТ-команды работают вместе, чтобы максимизировать ценность бизнеса.
Чтобы расширить видение, сформулированное в ИТ, – “быстрее создавать ценности”, – они разработали план преобразований, основанный на следующей структуре из четырех ключевых столпов:
- совершенство доставки: как мы работаем (практика, мышление продукта)
- операционное совершенство: как мы структурированы (таксономия продуктов, модель финансирования, операционная модель, расстановка приоритетов)
- совершенство персонала: рост талантов и культуры (включая эволюцию поведения лидеров)
- технологическое превосходство: модернизация (инфраструктура и технологическая база, автоматизация, переход к облачным технологиям и т.д.)
МАСШТАБИРОВАНИЕ КУЛЬТУРЫ
После разработки стратегии масштабирования трансформации необходимо было сосредоточиться на масштабировании культуры в рамках всего бизнеса, чтобы продолжить движение вперед.
Чтобы расширить культуру, они сосредоточились на трех ключевых атрибутах:
- Страсть: команды сосредоточены на том, чтобы радовать клиентов, быть лучшими, становиться лучше, принимать неудачи и становиться сильнее благодаря им.
- Бескорыстие: сотрудничество и обмен знаниями и кодом в рамках всей организации, иннерсорсинг, создание пространства для голоса других и помощь другим в победе.
- Подотчетность: отвечать за результаты, даже если они трудны, – то, как вы что-то делаете, так же важно, как и то, что вы делаете.
Сосредоточившись на этих трех культурных столпах, команды American Airlines теперь “наделены полномочиями и делают все возможное, чтобы наделить полномочиями других”, по словам Клэнтона.
Когда в 2020 году разразилась глобальная пандемия, компания American Airlines сосредоточилась на следующих ценностях, чтобы их команды смогли добиться успеха и результатов даже в условиях глобальных перемен. Они ценили:
- действовать и делать, а не анализировать
- сотрудничество вместо замкнутости
- ясность миссии вместо попыток сделать все
- расширение прав и возможностей, а не личное клеймо на каждой попытке (установите цели и дайте командам возможность достичь их)
- получение чего-то результата (MVP) в сравнении с получением чего-то совершенного
- “Мы можем это сделать” против иерархии (сотрудничество через организационные границы)
- завершение против начала (ограничение WIP и концентрация на главных приоритетах)
НОВЫЙ СПОСОБ РАБОТЫ
Как же они теперь работают? Вместо того чтобы перебрасываться требованиями, у них теперь есть команда заинтересованных сторон из бизнеса, ИТ, дизайна и т.д. Они изменили свою модель планирования, чтобы лидеры определяли четкие результаты, а команды могли решать, как они будут достигать этих результатов.
Команды добиваются результата, концентрируясь на небольших задачах, которые добавляют ценность постепенно. Благодаря тому, что задачи небольшие, команды могут быстро завершать работу (быстрее создавая ценность) и концентрироваться на завершении, а не на начале.
Чтобы обеспечить все эти изменения, руководству необходимо было также изменить свои методы работы. Лидеры переключились на обслуживание команд, устраняя препятствия и ограничения, которые мешают командам создавать ценности. Вместо совещаний по статусу руководство посещает встречи по воспроизведению (демонстрации), чтобы увидеть, что делают команды, и дать рекомендации в данный момент.
С этой целью они также поняли, что для изменения мышления лидеров и приведения всех в соответствие с принципами agile/DevOps им необходимо предоставить новый словарный запас. Ниже приведена таблица некоторых способов, с помощью которых они помогли повернуть разговор в нужное русло.
По словам Дуга Паркера, генерального директора American Airlines, преобразования, которые предприняла компания American Airlines, “делают нас более эффективными, мы быстрее выполняем проекты, проекты разрабатываются с учетом потребностей пользователей… Это уже вносит огромные изменения в управление проектами в American Airlines… Больше всего я горжусь тем, что чемпионом по преобразованию процесса доставки является уже не ИТ, а бизнес-лидеры, которые приняли его. Они видят, насколько быстрее они выполняют работу, и распространяют эту идею повсюду. И это сильно меняет ситуацию”.
БЕСКОНТАКТНЫЕ КИОСКИ
В связи с пандемией возникла необходимость в бесконтактной регистрации. Хотя в мобильном приложении American Airlines была предусмотрена бесконтактная регистрация, если клиент проверял сумку, все равно необходимо было подойти к киоску и получить бирку для сумки.
Сначала руководство поставило четкую цель (OKR): стимулировать своих клиентов к путешествиям, обеспечив полностью бесконтактную регистрацию, даже при проверке сумок.
Затем команды приступили к работе над тем, как это сделать. В ходе быстрых сессий проектного мышления команды изучили три возможных решения. Затем они остановились на MVP и приступили к работе. Лидеры ушли с дороги, и команды смогли не только выполнить, но и превзойти установленные OKR. Их первоначальная цель состояла в том, чтобы на 25% увеличить количество сканирований посадочных талонов для начала работы киоска и на 25% увеличить использование функции предоплаченной сумки в мобильном приложении. Они достигли 145% увеличения количества сканирований посадочных талонов и 57% увеличения использования функции предоплаченной сумки. За шесть недель они сократили среднее время сеанса в киоске на 17 секунд в 2 100 киосках в 230 аэропортах.
AA.COM
Команда dot com собралась вместе, чтобы приступить к совершенствованию ката. В то время они поставили перед собой цель – когда разработчик подает запрос на исправление, его код будет в продакшене в течение часа, и каждый шаг будет автоматизирован, никто не будет трогать код после запроса на исправление.
“В то время эта цель была смехотворной. Буквально все люди в той комнате смеялись вслух. Они годами шли по пути преобразований, добились значительных улучшений в скорости, но все еще оставалось множество технических интеграций, передач… множество барьеров и препятствий, которые нужно было преодолеть, чтобы достичь цели, и в то время это казалось невозможным”, – говорит Росс Клэнтон.
Далее начался путь постоянного совершенствования, они устраняли по одному препятствию за раз. Они преодолевали процессные барьеры, интегрированный QA silo, автоматизацию тестирования, перешли на Kubernetes и т.д. В конце концов, год спустя они достигли своей цели, сократив время внесения изменений в среду с трех недель до одного часа. Благодаря этому успеху они смогли избавиться от календаря релизов. Больше никаких пакетных релизов.
LEGACY COTS
Практика DevOps не ограничивается цифровыми технологиями. Их можно применять и к устаревшим COTS. В компании American Airlines продукт для постоянных клиентов работает на платформе Seibel. AA перевела его в гибридную облачную модель, а затем инвестировала в конвейеры CI/CD для автоматизации доставки и инфраструктуры продукта лояльности. После этого команда стала развертывать продукт чаще, всего за несколько месяцев было выполнено более пятидесяти автоматизированных развертываний, в 2 раза увеличилось время отклика веб-службы лояльности и на 32% сократились расходы на облако.
Более того, после этого перехода изменился разговор между бизнесом и ИТ. Вместо того чтобы бизнес ждал изменений от ИТ, команды получили возможность внедрять изменения чаще и бесперебойнее, чем бизнес готов их утвердить и принять. Теперь продуктовые команды в партнерстве с бизнес-командами и ИТ-отделами ищут способы оптимизации всего процесса для достижения более высокой частоты развертывания.
