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

Другая задача сформулирована Майклом Рембеци, который помог провести DevOps-преобразования в 2009 г. Тогда он работал в компании Etsy директором по производству. Он заметил: «Мы должны подбирать проекты преобразования осторожно, потому что, находясь в процессе поиска и устранения неисправностей, мы ограничены в средствах. Поэтому нужно тщательно выбрать объекты, усовершенствование которых сильнее всего улучшит состояние всей организации».

Давайте проанализируем, как команда компании Nordstrom начала свои преобразования DevOps в 2013 г. Кортни Кисслер, вице-президент по электронной коммерции и технологиям хранения, описала этот опыт на конференциях DevOps Enterprise Summit, прошедших в 2014 и 2015 гг.

Основанная в 1901 г. Nordstrom была ведущим продавцом модной одежды, нацеленным на создание положительных впечатлений у своих клиентов от процесса покупки. В 2015 г. компания имела годовой доход в размере 13,5 миллиарда долларов.

Отправной точкой для DevOps-преобразований было, скорее всего, ежегодное заседание совета директоров в 2011 году. В том году одним из стратегических вопросов было обсуждение необходимости роста прибыли от онлайн-продаж. Совет изучил бедственное положение компаний Blockbusters, Borders и Barnes & Nobles, продемонстрировавших плачевные последствия того, что организации традиционной розничной торговли слишком поздно создают конкурентоспособные интернет-подразделения. Такие организации явно рисковали потерять позиции на рынке или даже полностью уйти из бизнеса.

В то время Кортни Кисслер была старшим директором по системам доставки и технологиям продаж, ответственным за значительную часть технологической организации работы, включая системы в обычных магазинах и веб-узле электронной коммерции. Как позже описывала Кисслер, «в 2011 г. технология организации работы Nordstrom была оптимизирована для экономии расходов, мы передали на аутсорсинг многие технологические функции, у нас был ежегодный цикл планирования с большими заданиями “каскадного” выпуска ПО. И хотя планы выполнялись на 97 % по показателям сроков выпуска, бюджета и достижения целей, мы были недостаточно оснащены для достижения целей пятилетней бизнес-стратегии, потребовавшейся от нас, после того как компания Nordstrom начала оптимизировать скорость работы, а не расходы».

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

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

Мобильное приложение Nordstrom при запуске потерпело неудачу. Как сказала Кисслер, «наши клиенты были крайне разочарованы продуктом, и когда мы запустили его в App Store, то получили много одинаковых отрицательных отзывов. Что еще хуже, существующие структуры и процессы (то есть “система”) были разработаны так, что обновления выпускались два раза в год». Другими словами, любые исправления попадали к клиенту спустя несколько месяцев.

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

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

Во второй области действий основное внимание было уделено системам поддержки расположенных в магазинах ресторанов под маркой Café Bistro. В отличие от потока создания ценности мобильного приложения, где необходимо было сократить время выхода на рынок и увеличить скорость разработки новых функциональных возможностей, здесь бизнес нуждался в уменьшении расходов и повышении качества. В 2013 г. компания Nordstrom завершила разработку 11 «концепций изменений в ресторанах», потребовавших изменений в работе соответствующих торговых точек, в результате чего увеличилось число жалоб клиентов. Вызывало тревогу, что на 2014 г. было запланировано внедрение 44 подобных концепций — в четыре раза больше, чем в предыдущем.

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

Команда смогла определить проблемные области — сбор информации и развертывание — и сосредоточила на них усилия по улучшению. Она смогла сократить время развертывания кода на 60 % и число ошибок, требующих вмешательства вручную, на 60–90 %.

Эти успехи дали группе уверенность: используемые принципы и методы DevOps могут быть применены к широкому кругу потоков создания ценности. Кисслер получила повышение — должность вице-президента по электронной коммерции и технологиям хранения в 2014 г.

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

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

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

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

Мы часто категоризируем программные услуги или продукты как «чистые» (greenfield, «гринфилд») или как «нечистые» (brownfield, «браунфилд»). Эти обозначения первоначально использовались при планировании городов и строительных объектов. «Чистое» строительство ведется на неосвоенных землях. «Нечистым» называется такое, которое ведется на земле, ранее использовавшейся для промышленных целей, потенциально зараженной опасными отходами или загрязнениями. При застройке городов многие факторы могут сделать реализацию «чистых» проектов более простой, чем «нечистых», — нет конструкций, которые прежде необходимо демонтировать, и нет токсичных материалов, которые предварительно требуется вывезти.

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

«Чистые» DevOps-проекты часто используются в качестве пилотных, демонстрируя осуществимость публичного или частного облака, экспериментальной автоматизации развертывания и аналогичных инструментов. Пример такого проекта — Hosted LabView, разработанный в 2009 г. в компании National Instruments, существующей 30 лет, имеющей 5000 сотрудников и миллиард долларов годового дохода. Чтобы быстро вывести продукт на рынок, была создана новая команда разработчиков. Ей было разрешено не соблюдать существующие процессы и поручено изучить возможность использования публичных облаков. Первоначально в состав входили архитектор приложений, системный архитектор, два разработчика, разработчик системы автоматизации, руководитель команды и два специалиста из офшорного подразделения. Используя методы DevOps, они смогли вывести Hosted LabView на рынок за половину времени, обычно нужного для разработки продукта.

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

Хотя многие считают, что DevOps предназначен в первую очередь для «чистых» проектов, он использовался и для успешного преобразования различного рода «нечистых» проектов. Фактически свыше 60 % проектов трансформации, о которых шла речь на конференции DevOps Enterprise Summit в 2014 г., были второго типа. В этих случаях существовал большой разрыв между потребностями клиентов и тем, что организации фактически давали. И DevOps-преобразования принесли огромные преимущества для бизнеса.

По сути, один из выводов доклада 2015 State of DevOps Report (о состоянии DevOps) подтвердил, что по возрасту приложения сложно предсказать его производительность. Для такого предсказания надо определить, было ли оно спроектировано (или перепроектировано) для обеспечения удобства тестирования и развертывания.

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

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

Можно привести следующие примеры успешных преобразований браунфилд-проектов.

• Компания CSG (2013 г.). В 2013 г. компания CSG International получила 747 миллионов долларов дохода и имела более 3500 сотрудников, более 90 тысяч агентов службы поддержки клиентов для выставления счетов и обслуживания более чем 50 миллионов клиентов, пользующихся услугами видео- и голосовой связи и передачи данных. Каждый месяц выполнялось более шести миллиардов операций, печатались и рассылались по почте более 70 миллионов бумажных счетов. Первоначально улучшения должны были охватить печать документов, одно из их главных занятий, использующее приложение для мейнфреймов, написанное на языке COBOL и связанное с двадцатью технологическими платформами. В качестве составной части трансформации компания приступила к выполнению ежедневных развертывания в среде, близкой к производственной, и в два раза чаще стала выпускать обновленные версии для клиентов, — не два, а четыре раза в год. В результате была значительно увеличена надежность приложения, а время развертывания кода сократилось с двух недель до менее чем одного дня.

• Компания Etsy (2009 г.). В 2009 г. компания Etsy имела 35 сотрудников и приносила доход в размере 87 миллионов долларов, но, после того как она едва выжила в сезон предрождественских распродаж, она начала преобразования практически по каждому направлению деятельности, в итоге превратившись в одну из наиболее уважаемых компаний, использующих DevOps, и создала условия для успешного размещения своих акций на бирже в 2015 г.

Исследовательская компания Gartner недавно популяризировала понятие «двухуровневые IT», ссылаясь на широкий спектр услуг, которые поддерживает типичное крупное предприятие. В рамках двухуровневого IT существуют системы записей, подобные ERP. Благодаря им функционирует наш бизнес (например, MRP, HR, системы финансовой отчетности), где корректность транзакций и данных имеет первостепенное значение, и системы совместной работы, включающие работу с клиентами и с сотрудниками (системы электронной торговли и приложения, обеспечивающие высокую производительность).

Системы записей обычно меняются медленнее и нередко должны соответствовать нормативным требованиям (например, закону Сарбейнза — Оксли). Компания Gartner называет такие системы «тип 1»; организации, их использующие, уделяют основное внимание установке «делать правильно».

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

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

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

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

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

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

Рис. 9. Кривая внедрения технологий (источник: Мур и Маккена. Преодоление пропасти. Маркетинг и продажа хайтек-товаров массовому потребителю, Crossing The Chasm, 15)

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

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

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

Генерируя успехи, мы получаем право расширить масштабы инициативы DevOps. Мы хотим продвигаться по безопасной последовательности, повышающей уровень доверия к нам, степень нашего влияния и получаемой поддержки. Приведенный ниже список позаимствован из курса лекций доктора Роберто Фернандеса, адаптированного Уильямом Паундсом, профессором менеджмента Массачусетского технологического института. Здесь описаны идеальные фазы, применяемые, чтобы побуждать ответственных лиц создавать и расширять коалиции и обеспечивать базу поддержки преобразований.

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

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

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

Расширение DevOps на всю организацию — непростая задача. Оно может вызвать нежелательные последствия для отдельных сотрудников, отделов и даже для организации в целом. Но, как говорит Рон Ван Кеменад, директор по информационным технологиям компании ING, преобразовавший свою компанию в одну из наиболее популярных организаций в области технологий, «лидерство в изменениях требует мужества, особенно в корпоративных средах, где сотрудники боятся изменений и будут противостоять им. Но если вы начнете с малого, то вам действительно нечего бояться. Любой лидер должен быть достаточно смел, чтобы выделить команды на решение задач, связанных с риском, хотя и предусмотренным».

Питер Друкер, лидер в области разработки методов обучения менеджменту, отмечал: «Маленькая рыбка учится быть крупной в маленьких прудах». Тщательно выбирая, где и как начать, мы смогли определить в организации участки, создающие продукт и не затрагивающие при этом деятельность остальных частей организации. Поступая таким образом, мы создаем себе базу поддержки, зарабатываем право расширить использование DevOps и получаем признание и благодарность заинтересованных лиц (сотрудников, клиентов и т. п.).