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

Руководство по оптимизация потока создания ценности в контексте DevOps

Оптимизация потока создания ценности (Value stream optimization, VSO) — это сложный процесс повышения эффективности потока создания ценности. VSO позволяет предприятиям и брендам оптимизировать свои потоки за счет повышения операционной эффективности.

Недавно Gartner поделилась своим мнением о потоках создания ценности, определяющих успех DevOps, — прогноз, который подтверждает важность постоянной оптимизации потоков создания ценности:

«К 2023 году 70% организаций будут использовать управление потоком создания ценности для улучшения работы конвейера DevOps, что приведет к более быстрой доставке ценности для заказчиков».

Проблемы оптимизации потока создания ценности

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

Обеспечение прозрачности в рамках организации

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

Неспособность понять «большую картину»

Часто ИТ-организации стремятся применять гибкие подходы, востребованность которых существенно выросла за последнее десятилетие. Гибкий подход (agile) основан на хорошо известной концепции бережливого производства. Манифест Agile, разработанный в 1992 году, в настоящее время является наиболее известной попыткой привнести эту концепцию в разработку программного обеспечения, в ИТ в целом, да и в другие части бизнеса.

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

VSM включает в себя документирование и анализ потока информации и данных через цепочку из множества внутренних и внешних заинтересованных сторон, включая поставщика, отправителя, службы закупок и обеспечения качества, разработку, продажи, доставку и многих других. Противоречивые цели и задачи различных отделов затрудняют оптимизацию.

Проблемы безопасности и уязвимости

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

Вот почему оптимизация потока создания ценности требует, чтобы каждая команда решала как можно больше проблем безопасности.

Неисправное или неэффективное программное обеспечение

Оптимизация может быть успешной и приносить желаемые результаты только тогда, когда функциональность программного обеспечения и функции позволяют бренду это делать. Любой тип программного обеспечения, который не может быть последовательно протестирован и для которого не обеспечивается соответствие требованиям, также не принесет пользы, даже если вы нанесли его разработку на карту потока.

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

«Колодцы» (silos) неизбежны

Когда мы говорим об организационных структурах, одним из ключевых принципов DevOps является устранение разрозненности между подразделениями для обеспечения свободного и прозрачного потока информации, что, в свою очередь, позволяет легко и высокоэффективно картировать потоки создания ценности. Все команды, включая разработчиков, тестировщиков и тех, кто сопровождает, всегда демонстрируют некоторую степень независимости.

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

Как оптимизировать поток создания ценности

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

Построение «большой картины»

Несмотря на все препятствия, вам необходимо определить оптимальный процент потерь (waste) для каждого этапа. Бережливое управление предполагает, что при поставке программного обеспечения может быть 8 различных типов потерь:

  • Транспорт – выявление ненужной передачи данных
  • Инвентаризация – хранение завершенных функций без выпуска
  • Движение – обеспечение мобильности информации с помощью физических и цифровых средств
  • Ожидание – терпеливое ожидание получения определенной роли, разрешения, сборки, результатов тестирования или развертывания
  • Перепроизводство – создание функций или потоков на основе предположений
  • Чрезмерная обработка – выполнение большего количества тестов, чем необходимо для проверки программного обеспечения
  • Дефекты – ошибки и баги, которые могли быть выявлены ранее
  • Навыки – чрезмерное или недостаточное использование определенной роли (ролей)

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

Пересмотрите свою карту потока создания ценности

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

После этого оцените свои показатели и критерии. Начните с общего времени, необходимого для доставки. В технических терминах это называется временем цикла (Cycle Time, CT). Соответствует ли оно вашим ожиданиям? Или оно превышает ваш желаемый лимит? Часто есть вероятность, что вы будете удивлены временем цикла (CT) вашего продукта, поэтому оно действует как мотивирующий фактор для оптимизации.

В целом показатели потока включают следующие:

  • Cycle Time (CT) – время, необходимое для завершения определенной фазы
  • Valued Added CT – время, необходимое для добавления фактической ценности
  • Non-Value Added CT – время, которое можно отнести к потерям
  • First Time Right (FTR) – доля случаев, когда конкретная фаза успешна на первом этапе

Используйте показатели для оптимизации потока создания ценности

Наличие доступа к метрикам позволит вам проанализировать, соответствуют ли ваши значения CT, FTR и другие вашим ожиданиям. Например, если тестирование определенной функции программного обеспечения не должно занимать более 1 часа, но в среднем оно занимает 1 час 45 минут, вы сможете определить, что вам нужно либо исправить процесс, либо команду, либо, возможно, и то, и другое.

Составьте сравнительную таблицу, чтобы вы могли лучше видеть разницу между ожидаемыми/идеальными и фактическими показателями. Помните, что наличие различий не обязательно означает, что есть возможности для улучшения. Это также может указывать на то, что ваши показатели потока являются чрезмерно амбициозными или откровенно неточными. Процесс оптимизации будет включать в себя приведение каждой метрики как можно ближе к идеальному значению, с одновременной корректировкой ваших собственных ожиданий относительно определенных значений.

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

Поток и использование ресурсов

Для дальнейшего улучшения потока вам также потребуется сопоставить поток с использованием ресурсов. Это покажет, стоит ли результат, который вы получаете, всех ресурсов, которые вы используете для получения этого результата. Вы можете создать диаграмму или матрицу, чтобы сопоставить сделанные вами улучшения и усовершенствования с затраченными усилиями и ресурсами.

Следует начинать с оптимизации, которая требует наименьшего количества ресурсов и при этом существенно улучшает поток. Затем вы можете постепенно переходить к оптимизации, которая обеспечивает более высокую скорость потока, но также требует больших усилий.

Заключение

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

Оригинал статьи доступен по ссылке.

Учебные курсы и сертификация
специалистов по ИТ-менеджменту

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

  • Сергей

    Манифест Agile вроде был разработан в 2001 году

    • Мне тоже так помнится. Но в оригинале заметки именно такой год указан, что странно.


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

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

  • Рубрики

  •  
  • Авторы

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

    • ITIL 4 Specialist: Create, Deliver and Support: Что внутри?
      Несмотря на то, что мы рассказывали о новой сертификационной линейке ITIL 4, очередности прохождения курсов, практиках, рассматриваемых на курсах, все равно, периодически,
    • Куда растворился Access management в ITIL4?
      Коллеги, доброго дня. Неожиданный вопрос: куда растворился Access management в ITIL4? В практике Request Mgmt есть упоминание о том, что запросы на доступ управляются в практике Security Mgmt, но в описании этой практики нет об этом ничего, кроме управления инцидентами безопасности и аудита и ревью. Есть легкий намек, что эта практика используется в access control.
    • Конференция «Качество данных 2022. Стратегии, инструменты, практики, перспективы»
      Приглашаем принять участие в третьей ежегодной конференции «Качество данных 2022. Стратегии, инструменты, практики, перспективы». «Качество данных» – единственная в России конференция, полностью посвященная стратегии и практике обеспечения качества данных, гарантирующего высокий уровень бизнес-решений, сервисов и процессов. «Качество данных 2022» – это совершенно новые практические кейсы и проекты в развитии, привлекшие наибольший интерес участников предыдущих конференций.
    • Лучшие материалы Digital Enterprise за 2021 год
      Редакция Digital Enterprise поздравляет Вас с наступающим Новым годом! В этом посте мы собрали ТОП 5 авторских публикаций от экспертов Cleverics и 10 самых популярных статей портала в этом году.
    • Cleverics. Сколько курсов пройти, чтобы точно хватило?Сколько курсов пройти, чтобы точно хватило?
      В IT невозможно дойти до предела совершенства — всегда есть куда расти. Основная сложность в работе специалиста IT в том, что IT очень изменчивая область. Вам необходимо постоянно учиться, чтобы выжить во всем этом — и не остаться в колесе Сансары, когда оно будет делать новый оборот.
    • Почему запуск продукта проваливается (и как этого избежать)
      Сколько запусков новых продуктов происходит каждый год? По данным Nielsen около 30 000 среди товаров повседневного спроса. Для программного обеспечения гораздо труднее найти
    • Российскому стандарту ITAM быть!
      Управление ИТ-активами (ITAM), как дисциплина, существует уже не первое десятилетие. Однако в силу ряда причин именно сейчас ИТ-организации начинают проявлять к нему все больший практический интерес. Почему ИТ-менеджеры сейчас обращают на ITAM пристальное внимание?
    • Здравствуй, (VUCA) Новый год!
      Каждый раз, провожая уходящий год, хочется оглянуться назад, посмотреть на то, что было и попробовать помечтать и спрогнозировать то, что будет (или может быть) в новом году.
    • Возврат в системе канбан
      Что делать на доске канбан с задачей, по которой требуется переделка?
    • Записи вебинаров 21 сезона CleverTALK
      16 декабря завершился двадцать первый сезон вебинаров CleverTALK. Благодарим вас за интерес к нашим вебинарам и за то, что делитесь информацией о них!
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT