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

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

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

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

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

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

Антон Исанин: «DevOps позволяет быть ближе к клиенту, а если мы понимаем клиента, то понимаем, как заработать деньги, и это уже половина успеха»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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