Как «поженить» классический ITSM и гибкие методики разработки? И как уберечься от огульного внедрения новомодного DevOps? Ответы на эти вопросы пытались найти участники практической конференции «Agile, DevOps и ITIL – инструменты цифровизации», проведенной в конце сентября издательством «Открытые системы».
Можно услышать мнение, что традиционный ITSM – это вчерашний день, пора переходить к DevOps, причем срочно. Однако не стоит противопоставлять эти методики, на самом деле у них много общего, они лишь требуют здравого подхода.
«В ITIL действительно многое не так. Во-первых, это несовершенный продукт; во-вторых, его неправильно используют, и отсюда большинство проблем», — констатирует Роман Журавлев, менеджер компании Axelos по развитию продуктов ITSM.
Библиотека ITIL устаревает – последнее обновление было много лет назад. Кроме того, у нее неоптимальный формат – тысячи страниц текста, и это плохо воспринимается современными специалистами. В ней есть ошибки, которые трудно исправить. Наконец, широко распространено ее некорректное позиционирование в качестве панацеи, способной решить все проблемы.
По признанию Журавлева, рынок консалтинга и обучения практикам ITSM также болен. Он ориентирован на коммерческий успех интеграторов, а не на пользу заказчиков, и это влияет на имидж продукта. В качестве экспертов порой выступают недостаточно компетентные люди, которые не читали ITIL «в подлиннике» и к тому же не являются практикующими специалистами. Однако по-прежнему есть топ-менеджеры, готовые за это платить и на самом деле озабоченные не повышением эффективности, а личным комфортом.
Крупные тоже хотят быть гибкими
По мнению Антона Исанина, руководителя центра качества «Альфа-банка», DevOps дает ответы на вопросы, про которые молчит ITIL: как быстро давать клиенту то, что он хочет, и как понять, за что клиент готов платить.
«DevOps позволяет быть ближе к клиенту, а если мы понимаем клиента, то понимаем, как заработать деньги, и это уже половина успеха. Вторая половина – удовлетворить эти потребности», — подчеркнул он.
Как известно, главная проблема водопадной модели – процессы проходят ужасно медленно. Это порождает множество недопониманий между участниками, и конечный результат ухудшается. В случае Agile изменения происходят по-прежнему медленно – они занимают пусть и не месяцы, но все равно десятки дней. А главное – команда не чувствует рынок, остаются «стены» между владельцем продукта и разработчиками. Сочетание подходов Agile и DevOps позволяет обеспечить максимальную чувствительность к рынку и минимизировать путь удовлетворения потребностей клиента, в некоторых случаях до пяти дней.
В российской экономике масса ниш не занята, и возможностей для развития бизнеса очень много, главное – быстро их реализовать. На это и нацелена модель гибкого бизнеса (business-agility), к которой сейчас стремятся все бизнес-гиганты.
В «Ростелекоме» с этой целью создали бимодальную структуру бизнеса, включающую «горячий» и «холодный» полюсы. Как рассказал Олег Егоркин, директор проектов «Ростелекома», такой подход позволяет сочетать мощь обычного, классического телекома, умеющего реализовывать крупные проекты, и цифровой составляющей бизнеса, работающей максимально близко к клиенту.
.jpg) |
| Николай Кныш: «Каждый DevOps – свой, надо использовать лучшее из всех подходов» |
Для работы на современном рынке необходим максимально простой запуск цифровых проектов, и такая возможность была обеспечена. После первых успехов под них выделяется финансирование и запускается пилотный проект с ограниченным функционалом в одном из макрорегионов. В дальнейшем происходит охват всего бизнеса. В этой гибридной модели совмещаются две культуры: быстрые проверки гипотез в «цифровой песочнице», осуществляемые по гибким методикам, и понятное бизнесу масштабирование продуктов.
Михаил Громов, директор департамента качества «Сбербанк-Технологии», рассказал о применении подходов DevOps при работе с унаследованными системами. Про agile-трансформацию в Сбербанке, начатую в 2016 году, слышали очень многие. А с марта 2017 года началась ее вторая стадия — переход на DevOps. С августа этот подход охватил 80% систем: бизнес, разработчики, тестировщики и поддержка работают в единой команде.
Как выяснилось, проблемы унаследованных систем оказались вполне решаемыми с помощью архитектурных изменений и роботизации. Ключевым вопросом стало изменение культуры, и этот процесс актуален для всех без исключения организаций, решившихся на радикальные перемены в работе ИТ.
Стирая барьеры
«Традиции – тяжелая ноша. Люди работают так, как привыкли, их способность к творчеству приходится пробуждать», — заявил Олег Скрынник, управляющий партнер Cleverics. Конечно, здравый скепсис – это неплохо: как минимум, все инструменты и практики надо сначала примерять на себя. Но за упертость и косность, убежден Скрынник, надо наказывать.
«Ни один фреймворк ‘с улицы’ нельзя применить на крупном предприятии без доработки. Каждый DevOps – свой, надо использовать лучшее из всех подходов», — согласился Николай Кныш, директор по развитию ИТ-продуктов «Райффайзенбанка». Типовые решения – хорошо, но не следует бездумно копировать чужой опыт.
DevOps – это в первую очередь расширение зоны ответственности, стирание ее границ. Традиционные команды не могут работать в такой парадигме, приходится их доучивать и трансформировать культуру.
Как подчеркнул Алексей Дерюшкин, управляющий партнер ScrumTrek, главные «грабли» в таких проектах – отсутствие обучения. Нельзя оставлять тему на самостоятельное изучение наиболее продвинутыми сотрудниками, чтобы они затем распространяли ее в массы. Второй проблемой становится сохранение прежней структуры организации. Культура, о трансформации которой говорят все, не изменится сама собой, она складывается в рамках определенной оргструктуры. Необходимы кроссфункциональные команды, причем не только в рамках ИТ.
Как отметила Алсу Увакина, руководитель программы проектов банка «Открытие», для постоянного развития какого-либо продукта нужна выделенная команда, реализующая процесс непрерывной поставки ПО. При этом важно отсутствие в команде иерархии – только так возможна настоящая эффективная работа.
В рамках команд, придерживающихся Agile, роль ИТ-лидера должна смещаться в сторону коуча. Кроме того, радикально изменяется роль владельца продукта, причем окончательно его функции не ясны. Как минимум, он берет на себя четыре роли: бизнес-аналитика, ИТ-лидера, менеджера проекта и менеджера продукта. Если все это удается совместить в одном человеке, используемый подход будет эффективным. В противном случае получится гибридный подход с неочевидной ценностью.
Каким же должно быть ИТ-подразделение цифровой эпохи? По мнению Скрынника, уже в ближайшей перспективе вообще не будет ИТ-департаментов в нынешнем виде – они «расплывутся» по всей организации.
«Все идет к тому, что исчезнет граница между ИТ и бизнесом. Барьеры, существующие сейчас, будут стираться – не стирать их нельзя», — сказал он.
Как некоторое время назад отметил Герман Греф, банк завтрашнего дня – это не банк с ИТ-департаментом, а ИТ-компания с банковской лицензией. По словам Кныша, наблюдающееся сейчас соревнование очевидно: с одной стороны – банк, который хорошо знает бизнес и обладает необходимой инфраструктурой, но медленно внедряет новые продукты. С другой – инноватор, который быстро внедряет продукт, но не знает банковского бизнеса. Все просто: кто первым научится делать работу соседа, тот и победит.
