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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

  • Леонид

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

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

  • Виктор

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

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

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

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

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


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

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

  • Рубрики

  •  
  • Авторы

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

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT