Кейс: увеличение частоты релизов в продуктовой команде

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

DevOps Основы DevOps

Популярный трёхдневный учебный курс
 

Проект Феникс — DevOps на практике

Новая полезная деловая игра
 

Цифровая трансформация: высокоскоростное ИТ-подразделение

Семинар на два часа для высших руководителей бизнеса и ИТ
 

Комментарии и мнения

  1. Леонид

    Неудовлетворительное время получения заказчиком требуемого функционала – вполне реальный кейс. Но при чем тут ежедневные релизы? В Вашей интерпретации, Олег, DevOps = ежедневные релизы. А если ежедневные релизы не нужны (нужны своевременные), то и DevOps не нужен?

    1. Олег Скрынник Автор

      Леонид, немного не так. Если говорить про релизы, то я обычно агитирую за полный отказ от них. Ежедневный ритм — всё ещё компромисс. В данном кейсе он может стать следующим сложным шагом, но не обязательно последним. Данная команда уже работает над построением CI/CD, и там тоже не всё так просто, как хотелось бы.

  2. Виктор

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

    Также и здесь, можно получить тот же эффект.

    Однако я бы не пошел по 4 пути 🙂 И дело как раз в предыдущем опыте: масштабировать идею, имея серьезные изъяны на уровне 50% брака — это не просто небольшой косяк, требующий впоследствии доработок, а прям серьезная корневая проблема методологии.

    А учитывая, что мы каждую неделю имеем очередной живой пример проблемы, то и докопаться до корня при должной мотивации не составит труда.

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
20
Бесплатный вебинар:
ITIL 4 за пределами "основ" 
ИЮН
24
ИЮЛ
1