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

Перемены начались с массового перехода на Agile-разработку, а продолжились внедрением принципов DevOps и DesignOps. В современной компании ИТ — это сфера коллективной ответственности. Хотя профессионалы с обширными техническими познаниями по-прежнему необходимы, нужно фокусировать внимание на том, как организовать эффективную совместную работу представителей всех специальностей.

Технологии на вторых ролях

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

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

Вместе с ПК появилось еще одно новшество — пакеты офисных приложений: текстовые процессоры, электронные таблицы и т. п. Благодаря макросам, встроенным средствам программирования и механизмам интеграции такие пакеты стали мощной платформой, на которой бизнес-пользователи сами начали создавать сложные решения. Одним из главных стимулов, побуждающих бизнес к этому, стала негибкость созданных отделами ИТ процессов, что отбивало охоту к взаимодействию, хотя в реальности требовалось более тесное сотрудничество. Постепенно создание автоматизированных систем вне отдела ИТ стало настолько распространенной практикой, что для них даже придумали название — «теневые ИТ», которые, с одной стороны, способствуют улучшению взаимодействия, а с другой, обходятся недешево. Согласно результатам исследований, на теневые ИТ может тратиться от 30 до 50% общего ИТ-бюджета организации, а кроме того, они создают значительный риск для бизнеса [1].

Технологии становятся бизнесом

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

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

Эволюция роли ИТ на предприятии: во многих компаниях технологии сами стали бизнесом

 

В глазах компаний, где к отделу ИТ стали относиться как к партнеру, преобладавший тогда проектный подход к разработке ПО проявил свои недостатки [2], и в некоторых организациях начали экспериментировать с другими подходами, которые в 2001 году были обобщены в «Манифесте скорой разработки ПО».

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

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

Длительность цикла — ключевой фактор

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

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

Методы Agile-разработки основаны на взаимодействии и вводят короткие циклы обратной связи на многих этапах проекта. Выпуская релиз ПО, который еще не завершен, но уже пригоден для применения, вы получаете отзывы от реальных пользователей и клиентов. Эти отзывы используются разработчиками, что позволяет увеличить надежность готового продукта. Пропускная способность тоже повышается, поскольку не тратятся усилия на реализацию ненужных функций. Эту концепцию нередко называют минимизацией отходов, используя термин, позаимствованный из бережливого производства [3].

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

Больше чем Agile-разработка

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

Онлайн-стартапы, часть из которых уже выросли в гигантов рынка, научили тому, что нужно переходить от проектной ориентации к ориентации на продукт. Жизненный цикл ПО уже не делится на четко очерченные этапы, за каждый из которых отвечает отдельная группа: границы групп изменились, одна и та же группа несет ответственность за непрерывную эволюцию ПО и его эксплуатацию. Вернер Фогельс, директор по технологиям Amazon, обобщил этот принцип так: запускайте сразу после сборки. Кросс-функциональные группы обычно компактны (8–12 участников), что позволяет им сохранять фокус на конкретном аспекте создаваемого продукта. Одной из первых компаний, внедривших эти концепции и взявшихся за поиск стратегий их масштабирования, стала Spotify.

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

DevOps и DesignOps

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

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

Средства DevOps, а именно набор методов и инструментов непрерывной поставки ПО, помогли расчистить путь к промышленной эксплуатации. В лучших случаях отдельные блоки функциональности, описанные в «пользовательских историях», можно разработать и ввести в рабочую эксплуатацию всего за день-два, а не за недели и месяцы. Сегодня обширные отделы ИТ, состоящие из многих продуктовых групп, способны каждую неделю запускать в рабочую эксплуатацию сотни релизов связанных элементов программных систем. Возможность радикального сокращения длительности цикла побудила многие организации к внедрению DevOps. Например, в отчете State of DevOps 2014 года приводятся данные, подтверждающие, что высокая производительность отдела ИТ коррелирует с высокой результативностью бизнеса.

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

Практически параллельно с DevOps появилось еще одно движение, связанное с тестированием пользовательских интерфейсов непосредственно в отделах ИТ с расчетом на то, чтобы пользовательские истории отражали реальные потребности бизнеса. Специалисты по интерфейсам привнесли новые концепции, в том числе дизайн-мышление и исследования потребительской аудитории, благодаря которым число циклов обратной связи дополнительно увеличилось. Кроме того, они внедрили принцип записи гипотез о функциях и их проверки с помощью данных, собранных в процессе реального использования системы, — этот метод назвали «разработкой с опорой на гипотезы» (hypothesis-driven development).

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

Опорные методы и технологии

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

Принципы экстремального программирования, особенно разработка с ориентацией на тестирование (test-driven development), придали группам разработки уверенность, необходимую для частого выпуска релизов ПО, а отсутствие непредсказуемых объединений повысило надежность процесса.

Сервисная архитектура, которая позднее сменилась концепцией микросервисов, предоставляет возможность независимого развития компонентов. При использовании такой архитектуры небольшие кросс-функциональные группы могут работать независимо друг от друга над своей частью общего ИТ-решения. Методы тестирования контрактов (consumer-driven-contract testing) и микрофронтендов (micro frontends) позволяют запускать сервисы в рабочую эксплуатацию вообще без тестирования в среде интеграции. На самом деле у организаций, которые выпускают ПО по многу раз в день, просто нет возможности выполнять обстоятельное интеграционное тестирование в отдельной среде.

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

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

***

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

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

Литература

  1. P. Bendor-Samuel. How to Eliminate Enterprise Shadow IT. CIO Magazine.— 11 Apr. 2017. URL: https://www.cio.com/article/3188726/it-industry/how-to-eliminate-enterprise-shadow-it.html (дата обращения: 21.11.2018).
  2. S. Narayan. Agile IT Organization Design: For Digital Transformation and Continuous Delivery. — Addison-Wesley, 2015. — Ch. 8 and 9.
  3. M. Poppendieck, T. Poppendieck. Implementing Lean Software Development: From Concept to Cash. — Addison-Wesley, 2006. — Ch. 4.

Эрик Дерненбург (erik@thoughtworks.com) — директор по технологиям, компания ThoughtWorks.

Erik Dornenburg, The Path to DevOps. IEEE Software, September/October 2018, IEEE Software. All rights reserved. Reprinted with permission.