Agile эпохи трансформации
Agile эпохи трансформации

Максим Григорьев полагает, что цифровая трансформация уже в ближайшие годы радикально повысит востребованность Agile и DevOps


09:40 02.11.2018   |  Дмитрий Гапотченко |  Computerworld Россия

Рубрика Предприятие |   1403 прочтения



Цифровая трансформация требует новых подходов к развитию корпоративных информационных систем.

 

Практическая конференция Agile.DevOps.ITSM 2018, проведенная издательством «Открытые системы», собрала более 200 участников из разных сфер экономики и госуправления. Ее основными темами, кроме собственно опыта развития деловых информационных систем и соответствующих методик и инструментария, стали цифровая трансформация, специфике применения Agile при работе с государственными заказчиками и кадровые вопросы.

Трансформация и Agile

С рассказа о цифровой трансформации и началась конференция. Максим Григорьев, управляющий партнер Gartner, до относительно недавнего времени — начальник Центра финансовых технологий Банка России, показав, что меняет трансформация в продуктовой линейке (появляются новые продукты), каналах взаимодействия с покупателем (взаимодействия они становятся омниканальными и «мгновенными») и на производстве (оно становится «цифровым»).

Меняется и ИТ-система — она становится трехслойной. «Внизу», в основе всего, лежат маломеняющиеся монолитные транзакционные системы, «вверху» — быстроразрабатываемые сервисы. А между ними — промежуточный слой, который должен состыковать две столь разные модели разработки. И если на «монолит» в 2016 году приходилось 90% ИТ-бюджета, а на инновации — 1%, то уже в 2020-м, как полагают в Gartner — 50% и 15% (траты на промежуточный слой тоже вырастут — с 9% до 35%).

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

Как сделать государство гибче?

Государство у нас — один из крупнейших заказчиков, в том числе — в области ИТ. Об особенности работы с ним рассказали Дмитрий Матвеев, до недавнего времени возглавлявший развитие портала госуслуг, и Сергей Добриднюк из компании «Диасофт» (она провела в апреле-июне работы по переводу на «Перспективную платежную систему России» Центробанка и всех 480 банков страны).

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

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

Agile в бизнесе

Николай Кныш («Райффайзенбанк»), рассказывая об опыте трансформации компании отметил, что первые три года, с 2013-го по 2016-й, прошли практически впустую. Эксперименты с внедрением методологий Scrum и Kanban шли хаотически, глава банка в процессе не участвовал, в результате 95% организации остались на старых методах разработки.

В 2016-2017 годах CEO стал играть роль «владельца продукта», были созданы кроссфункциональные команды, процесс внедрения новых методов был упорядочен и в результате начали свою работу более двух десятков команд.

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

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

DevOps и его команда. Как ее создать?

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

Одна из причин, как отметил Олег Скрынник (компания Cleverics), все участники процесса разработки програмного обеспечения (аналитики, тестировщики и разработчики) — считают себя умнее коллег по ИТ-цеху и уж конечно умнее сотрудников бизнес-подразделений.

Для того, чтобы заставить их работать вместе, необходимо ломать административные барьеры и заставлять их сидеть и работать вместе, учить разговаривать друг с другом, «слушать и слышать».

Задача эта лежит на наставниках, scrum-мастерах. «А их нет», — резюмировал Скрынник. И откуда брать, непонятно, поскольку рынок труда в этом сегменте и перегрет («кандидаты в мастера» требуют больших зарплат) и пуст (результата дорогие специалисты зачастую не дают).

Выращивать в своем коллективе — но из кого? Менеджеры проектов в scrum-мастеров «перековываются» плохо. Они остаются менеджерами, которые привыкли не «зажигать глаза» у своих сотрудников, а «поджигать под ними стулья».

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

Идея эта многим показалась интересной, однако «девочка-психолог из HR» уже стала именем нарицательным в мире ИТ, так что реакция программистов на scrum-мастера из психологов может быть неоднозначной.

Олег Егоркин («Ростелеком») предложил создавать внутри компаний, особенно территориально распределенных, гильдии — профессиональные сообщества, объединяющие специалистов из разных филиалов, работающих над одним продуктом. Это даст возможность сотрудникам обмениваться знаниями о продуктах, повышать их квалификацию, создавать кадровый резерв.

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

В интернет-магазине Wildberries к кадровой проблеме подошли с другой стороны. Там классифицировали сотрудников «по Афанасьеву». Она заключается в том, что личность «разбивается» на «эмоции», «логику», «физику» и «волю», их «порядок» и определяет личность. Скажем ИТ-специалисты — это ЛВФЭ (Лао-цзы) или ЛВЭФ (Энштейн), а управленцы — ВЛЭФ (Сократ) или ВЛФЭ (Ленин).

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


Теги: показывать на главной Самое интересное ITSM DevOps Agile Gartner AgileDevOpsITSM2018
На ту же тему: