Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Комментариев: 4

  • Леонид

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

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

  • Виктор

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • FinOps с помощью Governance-as-Code
      Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В
    • Применима ли концепция «сдвиг влево» (shift left) для инженеров по надёжности систем (SRE)?
      Концепция «сдвига влево» помогает упростить некоторые аспекты разработки программного обеспечения. Но предназначена эта концепция не только для разработчиков. Она
    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT