DataOps (акроним от data и operations) — это новая методология, предполагающая совместную работу объединенных команд разработки и эксплуатации ИТ-систем (DevOps), инженеров по подготовке данных (data engineer) и исследователей данных (data scientist) для создания инструментов, процессов и организационных структур, необходимых предприятию, опирающемуся в работе на данные.

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

Принципы DataOps

Подобно DevOps, DataOps опирается на принципы скорой (agile) разработки. В рамках DataOps приоритетами являются непрерывная доставка аналитических знаний и ориентация на удовлетворенность клиента.

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

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

Для чего годится DataOps

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

Кроме того, DataOps хорошо сочетается с архитектурами на основе микросервисов.

DataOps на практике

Новые технологии требуют от предприятий перемен, способностей работать с большими объемами данных и оперативно реагировать на события.

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

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

Эксперты подчеркивают: чтобы группа DataOps стала максимально эффективной, в ней должны быть специалисты по исследованию данных.

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

При этом не требуется, чтобы специалисты в области Data Science работали в группе DataOps на постоянной основе: обычно исследователя данных включают в команду на определенное время, впоследствии он может перейти в другую команду, а его роль в группе берет на себя другой участник, например инженер по подготовке данных, иными словами, происходит постоянная ротация.

Как сформировать команду DataOps

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

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

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

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

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

Участники круглого стола обсудили новые тенденции в бизнесе, связанные с развитием информационных технологий. Мероприятие было организовано компанией Comindware при поддержке Союза ИТ-директоров и Высшей школы бизнес-информатики НИУ ВШЭ.

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

Задачами бизнеса, опирающегося на инновации, становятся цифровые клиенты, использование ботов вместо офисного персонала, роботизация производства и быстрая реакция на изменения. Однако в реальности все еще широко распространены бумажные процессы, поддержка зоопарка унаследованных ИТ-систем, требующая больших трат, и негибкое финансовое планирование. Чем выше темп изменений в бизнесе, тем дороже поддерживать старые системы в актуальном состоянии: очередь доработок выстраивается на годы вперед. Тем временем происходят новые изменения, под которые снова надо подстраиваться. А запросы пользователей возрастают. Никого не интересует, как работают интернет-технологии, всем важен результат.

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

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

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

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

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

Все тиражные сервисы будут замещены индивидуальными, считает Славин. Бизнес в привычном смысле слова исчезнет, останутся только отношения между людьми, которые станут «коллективным интеллектом».

Таким образом, цифровая трансформация не есть просто внедрение технологий, цифровая трансформация – это ответ на возникающие потребности людей, подвел итог эксперт.

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

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

Итак, десятка прогнозов IDC для индустрии ИТ.

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

2. К 2020 году на 60% всех предприятий будут создавать технологическую основу общекорпоративной платформы цифровой трансформации. Такую платформу в IDC определяют как новую корпоративную архитектуру ИТ на основе API и данных, которая обеспечит возможность быстрого создания цифровых продуктов и услуг и обеспечит радикальную модернизацию интеллектуального ядра компании.

3. В 2020 году затраты предприятий на облачные сервисы и инфраструктуру превысят 530 млрд долл., причем более 90% всех компаний будут пользоваться сразу многими сервисами и платформами. Облачная среда также распространится до периферии — больше половины компаний в отраслях, ориентированных на потребителей, будут активно инвестировать в развитие граничных облачных сервисов.

4. К 2019 году в рамках 40% инициатив цифровой трансформации будут использоваться сервисы искусственного интеллекта, а к 2021 году он будет применяться в 75% коммерческих приложений для предприятий. Цифровые сервисы и приложения без искусственного интеллекта быстро отстанут от общих темпов прогресса.

5. К 2021 году корпоративные приложения будут переведены на «гиперскорые» (hyper-agile) архитектуры: 90% их компонентов будут работать в облачных PaaS-платформ с использованием микросервисов и бессерверных вычислений, при этом свыше 95% новых микросервисов будет развертываться в контейнерах. Новые базовые технологии и появление узкоспециализированных вертикальных решений разработки обеспечат десятикратный рост количества приложений и микросервисов.

6. К 2020 году интерфейсы человек-компьютер станут более разнообразными: 25% выездных технических специалистов и информационных работников будут пользоваться дополненной реальностью, и почти в половине новых мобильных приложений основным интерфейсом станет голосовой. В частности, техникам дополненная реальность предложит изображения, наложенные на реальный мир, доступ к свежей информации и визуальную связь с руководством и консультантами.

7. К 2021 году не меньше 25% компаний из рейтинга Global 2000 начнут широко использовать сервисы блокчейна для обеспечения цифрового доверия. В IDC предвидят, что распределенные реестры и связи на основе блокчейна в предстоящие три года будут развиваться медленно, но верно. Ранние адепты блокчейна смогут получить очень крепкие позиции в новой экосистеме, но и у поздних впоследствии будет возможность освоиться, изучив подходящие применения.

8. К 2020 году 90% крупных предприятий будут получать доход от данных, предоставляемых в виде сервиса. Способность компаний извлекать выгоду из какой-то части собственных данных быстро станет важным показателем оценочной стоимости предприятия, а наличие достаточного объема внешних источников данных — необхдоимым ингредиентом любых сервисов и решений на основе искусственного интеллекта.

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

10. К 2021 году более чем у половины участников рейтинга Global 2000 в среднем треть взаимодействий с цифровыми сервисами будет проходить через собственные открытые API компании, тогда как сейчас соответствующий показатель практически на нуле. Создание открытых API и экосистем разработки позволит предприятиям значительно ускорить распространение их цифровых платформ и сервисов. В следующие три года лидеры цифровой трансформации начнут активно развивать экосистемы и сети дистрибуции на основе открытых API. А компании, в которых не этого не сделают, быстро окажутся маргинализированными в условиях цифровой экономики.

«Тема будущего – не блокчейн, а искусственный интеллект, вот что взорвет рынок. Данные о клиенте, которыми обладает банк, скоро станут гораздо более ценными, чем размещенные им депозиты», — заявил Алгирдас Шакманас, вице-президент «Промсвязьбанка» и руководитель блока «Цифровой бизнес», на пресс-конференции, посвященной освоению банком цифрового пространства. Уже в ближайшем будущем пойдет речь о бизнесе не на транзакциях клиента, а на его интересах и потребностях. Разумеется, подобное пристальное наблюдение может нервировать, но надо понимать, что за счет этого банк сможет выступать в роли «хорошего официанта», угадывая желания и потребности клиента. Согласно внутренним прогнозам банка, к концу следующего года примерно 50% продаж физическим лицам будет происходить с участием искусственного интеллекта.

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

По словам Ивана Паткина, директора «Промсвязьбанка» по электронному бизнесу в СМБ, сейчас самая горячая сфера для банка – именно сегмент юридических лиц. Цифровизация банковского ретейла уже состоялась, а вот корпоративные клиенты начали активно переходить в онлайн лишь сейчас, и этой тенденции приходится уделять повышенное внимание. Борьба за клиента в значительной степени происходит именно здесь.

«Мы активно привлекаем новых клиентов в сегменте СМБ – более 10 тыс. юрлиц в месяц, около 98% из них сразу подключают интернет-банк. Дальнейшую свою стратегию мы видим именно в цифровизации всех наших процессов и выводе продуктов в онлайн-каналы», — рассказал Паткин. В планах на ближайшую перспективу – по возможности максимальный переход в «цифру» при работе с юридическими лицами, как с небольшими предприятиями, так и в корпоративном сегменте.

Однако сервисам нужна не только привлекательная оболочка, но и мощный «мотор»: кузов «Феррари» на двигателе от «Запорожца» далеко не уедет. Важную роль в цифровизации процессов будет играть искусственный интеллект – роботы должны завладеть бизнес-процессами. Парадокс заключается в том, что именно благодаря роботам банк способен стать более человечным, предоставляя персонифицированные сервисы.

Тем не менее первое решение, основанное на искусственном интеллекте, в банке появилось в области безопасности: была внедрена система по борьбе с мошенничеством на основе модели поведения человека, сформированной с помощью анализа Больших Данных.

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

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

Agile заставляет «пылесосить»

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

«Мы весь год ‘пылесосили’ рынок талантов, штат серьезно увеличился», — подчеркнул Андрей Овсянников, вице-президент по ИТ Промсвязьбанка. В настоящее время внутренний ИТ-персонал выполняет почти 80% работ для бизнеса.

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

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

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

Как «поженить» классический ITSM и гибкие методики разработки? И как уберечься от огульного внедрения новомодного DevOps? Ответы на эти вопросы пытались найти участники практической конференции «Agile, DevOps и ITIL – инструменты цифровизации», проведенной в конце сентября издательством «Открытые системы».

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

«В ITIL действительно многое не так. Во-первых, это несовершенный продукт; во-вторых, его неправильно используют, и отсюда большинство проблем», — констатирует Роман Журавлев, менеджер компании Axelos по развитию продуктов ITSM.

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

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

Крупные тоже хотят быть гибкими

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

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

Как известно, главная проблема водопадной модели – процессы проходят ужасно медленно. Это порождает множество недопониманий между участниками, и конечный результат ухудшается. В случае Agile изменения происходят по-прежнему медленно – они занимают пусть и не месяцы, но все равно десятки дней. А главное – команда не чувствует рынок, остаются «стены» между владельцем продукта и разработчиками. Сочетание подходов Agile и DevOps позволяет обеспечить максимальную чувствительность к рынку и минимизировать путь удовлетворения потребностей клиента, в некоторых случаях до пяти дней.

В российской экономике масса ниш не занята, и возможностей для развития бизнеса очень много, главное – быстро их реализовать. На это и нацелена модель гибкого бизнеса (business-agility), к которой сейчас стремятся все бизнес-гиганты.

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

Николай Кныш: «Каждый DevOps – свой, надо использовать лучшее из всех подходов»

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

Михаил Громов, директор департамента качества «Сбербанк-Технологии», рассказал о применении подходов DevOps при работе с унаследованными системами. Про agile-трансформацию в Сбербанке, начатую в 2016 году, слышали очень многие. А с марта 2017 года началась ее вторая стадия — переход на DevOps. С августа этот подход охватил 80% систем: бизнес, разработчики, тестировщики и поддержка работают в единой команде.

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

Стирая барьеры

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

«Ни один фреймворк ‘с улицы’ нельзя применить на крупном предприятии без доработки. Каждый DevOps – свой, надо использовать лучшее из всех подходов», — согласился Николай Кныш, директор по развитию ИТ-продуктов «Райффайзенбанка». Типовые решения – хорошо, но не следует бездумно копировать чужой опыт.

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

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

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

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

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

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

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

26 сентября издательство «Открытые системы» организовало в Москве конференцию «Agile,DevOps и ITIL – инструменты цифровизации».

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

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

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

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

В программе конференции — более полутора десятков докладов от руководителей процессов цифровизации в корпорациях, директоров департаментов качества, аналитиков и консультантов из таких организаций, как «Ростелеком», «Сбербанк-Технологии», ВТБ, Райффайзенбанк, AXELOS, Ernst&Young, Альфа-банк, использующих инструменты Agile, культуру DevOps и опыт ITIL для проведения безболезненной цифровой трансформации. Большое внимание на конференции было уделено обсуждению конкретного опыта выполнения проектов построения «цифровых фабрик» в банковской отрасли, телекоме и страховом бизнесе, анализу практики применения методов Agile, DevOps и других подходов к непрерывному развитию корпоративных информационных систем без нарушения работы критических для бизнеса унаследованных систем.

В компаниях сегодня применяется множество инструментов управления проектами разработки ПО, как на базе классических каскадных моделей, Kanban, Agile, так и разнообразные доморощенные методики. Однако для цифровой трансформации предприятий требуется не автоматизация разрозненных процессов, а их выстраивание заново. В этом уверены участники тематической сессии «Agile/DevOps на практике», проведенной в рамках традиционного ежегодного форума IT Management Forum, уже в 14-й раз организованного издательством «Открытые системы».

«Перестаньте внедрять Agile. Будьте Agile!», — призвал в своем докладе Николай Кныш, директор по развитию ИТ-продуктов «Райффайзенбанка». Для успеха в цифровой трансформации необходимо продвигать в направлении Agile всю компанию, а не только подразделения, отвечающие за ИТ. Адаптация подобных практик означает масштабную трансформацию. Это сложное и длительное «путешествие», многие моменты которого лежат за пределами ИТ, и, как и всякое путешествие, оно должно быть тщательно подготовлено. Но главное, став Agile, можно охватить весь жизненный цикл выпуска продуктов или услуг, составляющих бизнес компании. За редким исключением, в массе своей российские организации неспособны собрать воедино разрозненные команды, чтобы быстро реализовать в программной системе нужный функционал и выпускать ее новые версии с частотой, требуемой бизнесу. Неспособны они и работать в тесной связке с другими подразделениями, например с отделом маркетинга, которому надо быть готовым с той же частотой оповещать клиентов о новом функционале, обновлять пресс-релизы и выполнить другую работу, необходимую для ввода нового сервиса в эксплуатацию.

Алгоритмы с жесткими связями нежизнеспособны, а в цифровую эпоху и подавно, однако по-прежнему, как подтверждают доклады форума, каждое подразделение или филиал компании стремится к обособлению. «Организации, проектирующие системы, неизбежно воплощают в них свою собственную структуру», а «культура ест стратегию на завтрак» — с этих цитат из Мела Конвея и Питера Друкера начал свое выступление Иван Евтухович, управляющий партнер компании «Экспресс 42». В цифровую эпоху новые бизнес-возможности для предприятия возникают непрерывно, однако способно ли ИТ-подразделение обеспечить их поддержку, своевременно разработав новые сервисы и приложения или изменив уже имеющиеся? Как организовать деятельность разработчиков таким образом, чтобы при неизменном качестве можно было существенно увеличить скорость изменений?

Для процессов с разным уровнем рисков и потенциальной прибыльностью может быть предпочтительна как система Kanban, позволяющая хорошо управлять потоком заявок командам разного уровня, так и Agile. Методы быстрой разработки позволяют быстро обнаружить ошибку и исправить ее. «Ошибись как можно раньше, зафиксируй качество, быстро выпусти версию с реализацией критичного для заказчика функционала, отбрось до поры второстепенный функционал» – вот основные принципы Scrum. Однако для проектов, в которых задействованы большие группы, подходы в стиле Agile уже не годятся: хорошо решая сиюминутные потребности проекта, при росте масштабов следование Scrum грозит целостности архитектуры.

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

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

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

Для того чтобы способствовать цифровой трансформации бизнеса, корпоративные ИТ-структуры должны изменить и свой подход к работе, и методы взаимодействия с внутренним заказчиком. О том, как ИТ-службам начать трансформацию с себя, рассказывает Олег Скрынник, управляющий партнер компании Cleverics, одного из партнеров предстоящего форума IT Management Forum 2017, который издательство «Открытые системы» проведет 25 мая.

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

Безусловно, изменения в управлении информационными технологиями необходимы, чтобы поддержать бизнес-трансформацию. Одно из средств для этого — набор практик DevOps. Еще буквально год-два назад у большинства ИТ-специалистов и менеджеров не было четкого понимания, что же это такое и зачем нужно. При том что само движение зародилось лет пять-шесть назад, только сейчас этот набор практик находит свое применение. В 2016-2017 годах в вопросе «Что такое DevOps?» наконец наступает ясность. Ограниченные точки зрения, например: DevOps — это про автоматизацию конвейера поставки ПО, сменяются более общей концепцией: DevOps — логическое развитие идей гибкой разработки ПО и бережливого производства, примененное к полной цепочке создания ценности и позволяющее добиваться большего от современных информационных технологий посредством культурных, организационных и инструментальных изменений.

Надо признать, что большинство идей DevOps не новы. DevOps объединяет, впитывает в себя практики Agile и других течений, привнося новое именно на стыке разработки и эксплуатации.

- Почему идеи DevOps стали популярны именно сейчас?

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

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

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

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

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

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

- Но мы пока говорим только про изменения в работе ИТ-подразделения?

Существенные изменения в ИТ-отделах, как правило, не делаются ради самих ИТ-отделов. ИТ работают для бизнеса.

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

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

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

На качественном уровне бизнес получает новые инструменты взаимодействия с клиентами, маркетинга, продаж, предоставления услуг и монетизации. На количественном уровне бизнес получает ИТ-продукты, создаваемые со скоростью движения бизнеса (необходимый бизнесу и очень быстрый time-to-market), а также ИТ-продукты, обладающие большей стабильностью и доступностью по сравнению с традиционными системами.

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

- Есть ли сопротивление «трансформации через DevOps» со стороны бизнес-подразделений?

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

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

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

- Ваша компания будет одним из партнеров IT Management Forum 2017. О чем вы собираетесь рассказать участникам форума, какие из заявленных тем кажутся вам наиболее интересными, о чем бы вы хотели сами услышать на форуме?

Собственно, ровно по обсуждаемой теме мы проведем демонстрационную деловую игру «Проект Феникс – DevOps на практике». Это совершенно новая бизнес-симуляция, разработанная в прошлом году голландской компанией GamingWorks. Ее сюжет основан на популярной книге «Проект Феникс», а на самой игре участники могут на своем опыте изучить и опробовать основные идеи, техники и практики DevOps, такие как поток создания ценности, визуализация задач, минимальный рабочий продукт, быстрое устранение препятствий, ранняя обратная связь, непрерывное улучшение и др.