Рассмотрим кейс.

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

Предположим также, что данная команда переносит наработки в среду эксплуатации через релизы (накопленные изменения) и имеет сложности с регулярностью и частотой релизов: много изменений собираются вместе, влияют друг на друга, разом тестируются через “регресс”, не все тесты проходят успешно, уходим на второй круг, снова куда-то ушли месяц или два. Есть и целый букет технических сложностей, связанных с выделением ИТ-ресурсов для разных сред, низкой степенью автоматизации выполняемых операций и действий, скромным количеством автотестов, ручным развёртыванием и другими неприятностями. В общем, всё как у всех.

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

В таком новом для себя режиме команда поработала примерно два месяца. Объективные данные, известные через набор заранее заданных метрик (и эти данные совпадают с субъективным ощущением и непосредственными наблюдениями), показали, что успешным является каждый второй релиз. То есть достигнуть цели “еженедельно” не вышло, а “раз в две недели” – стабильно получается.

Далее возможен один из следующих сценариев:

1. Раз в две недели – неплохо, особенно в сравнении с прошлым. Будем стараться и дальше, но в целом уже здорово.
2. Раз в две недели – хорошо, но ещё не то, что хотелось. Продолжаем активно “дожимать” и стараемся попасть в “еженедельно”.
3. Если стабильно получается раз в две недели, то такую частоту релизов и следует зафиксировать в качестве нового правила. По возможности будем делать внеплановые релизы.
4. Раз в две недели – совсем не предел, нужно применить более радикальные решения. Давайте выходить на ежедневные релизы.

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

Итак. Поделюсь своим мнением.

Первый сценарий заведомо нерабочий. Он не подразумевает активных действий по улучшению (намерение “будем стараться” к активным действиям относить не следует). Предоставленный сам себе, сложившийся процесс быстро или не очень деградирует, и даже двухнедельный цикл релизов будет разваливаться. Без продолжения системной работы по совершенствованию скорость страдает первой.

Второй сценарий вполне возможен. Раз договорились дойти до “еженедельно” – давайте смотреть почему не получается и задавать неудобные вопросы. Да, потребуется что-то менять, во что-то вложиться головой и трудом. Зато и скорость увеличим, и опыт приобретём, и цели достигнем.

Третий сценарий представляется наиболее ущербным. Корневые причины невозможности работать быстро не устранены, сейчас сняты лишь самые явные ограничения. Если зафиксировать новое нормальное состояние “раз в две недели”, то с довольно большой вероятностью будет снова получаться каждый второй релиз, а значит реальная частота сведётся к “раз в месяц”. Что в современном ИТ-менеджменте никак нельзя считать достижением. Разумеется, оговорка “по возможности сделаем внеплановый релиз” не повлияет на частоту (не умеем же так), но повлияет на мотивацию (ну мы же договорились, почему не получается?).

Четвёртый сценарий полностью вписывается в идеологию управленческого DevOps. Проблемные места нужно повторять как можно чаще, это лучший мотиватор найти и устранить, наконец, проблемы. Да, совершенно непонятно как этого достичь, но тем интереснее задача и ценнее получаемый опыт. Достигнув “раз в день” команда будет со снисхождением смотреть на тех, кто ещё живёт в парадигме “раз в неделю-две” или “когда-нибудь”. Это и есть переход к заветному “High Velocity IT”.

Теперь тем читателям, которые сразу же выбрали четвёртый сценарий как самый правильный и привлекательный, предлагается подумать над следующими непростыми вопросами:

1. Как объяснить всё это команде и договориться?
2. Как объяснить всё это владельцу продукта, который, разумеется, за скорость, но, тем не менее, считает третий сценарий самым лучшим?
3. Кто должен делать все эти объяснения? Может, стоит привлечь грамотного специалиста из-вне команды (консультанта, или самого главного в компании по качеству, или какого-нибудь руководителя)?
4. Какой набор детальных и предметных вопросов задать команде, чтобы выявить-таки корневую причину и понять как её устранить? Заодно убедившись, что причина одна (или нет), и что то, что выявленно, действительно негативно влияет на частоту (ведь слов “почему не можем быстрее” в любом случае будет сказано очень много).

Это был вполне реальный кейс – на мой взгляд, очень любопытный и поучительный. Такие кейсы и вопросы мы обсуждаем на учебном курсе “Основы DevOps”. Приглашаю, на ближайшем открытом курсе в мае ещё есть места.

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы