Оптимизация потока создания ценности (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%, но при повторной оценке может оказаться, что эффективность доступных инструментов и сложность процесса делают этот показатель нерациональным.

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

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

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

Заключение

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

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

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

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

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