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

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

Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.

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

 

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

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

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

Вы можете услышать, что «VSM дает командам возможность сокращать потери». Да? Как? Конечно, мы хотели бы, чтобы наши усилия по внедрению VSM расширяли возможности команды, но я бы не сказал, что это так. Правильнее будет сказать, что ваши усилия VSM должны расширять возможности вашей команды. Или, по крайней мере, они не должны лишать команду полномочий. Но утверждение, что VSM делает то или иное, искажает представление о VSM и сеет путаницу.

«VSM автоматизирует поток информации». Каким образом? Автоматизация доступности информации — это хорошо, но, повторюсь, VSM — это концепция. Как концепция, она ничего не предоставляет и не делает.

 

  1. Излишняя конкретика и ограниченные возможности для улучшений.

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

Иногда эти афоризмы могут быть верны. Но что делать, когда это не так?

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

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

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

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

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

Слишком много людей, которые пытаются вести дискуссию о VSM, имеют ограниченное (бережливое, DevOps- или IT-ориентированное) представление о том, как должен работать поток создания ценности. У них узкий взгляд на факторы, которые способствуют тому, как должен быть спроектирован и оптимизирован поток создания ценности в организации.

 

  1. Путать работу в бизнесе с работой над бизнесом

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

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

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

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

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

 

  1. Улучшать правильные вещи

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

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

Однако это не бизнес-результаты. Это организационные улучшения. Выбор историй (работа по управлению продуктом) подразумевает работу в потоке создания ценности. Улучшение процесса выбора этих историй — это работа над потоком создания ценности, т.е. VSM.

 

  1. Приравнивание VSM к agile

Некоторые люди в отрасли продолжают ругать водопад и восхвалять agile, как будто это и есть VSM или способ выполнения VSM. Но agile — это не главное.

Что делать компаниям с существующими потоками водопада? VSM к ним не относится? Их не пускают в клуб? Боже упаси. Эти сценарии также являются потоками ценности, и ими тоже нужно управлять. Водопад — подходящий процесс в определенных ситуациях. Иногда не стоит прерывать попытку гибкой трансформации.

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

 

О чем вы должны говорить

Я не знаю, в каком направлении будет развиваться VSM и как со временем изменится ее определение. На данный момент, похоже, что выдвигаемые определения не ограничиваются бережливым производством, и это хорошо. Но многие авторы и докладчики любят говорить о lean, agile и DevOps в своих статьях и вебинарах по VSM.

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

  • Совершенствование управления продуктами в рамках VSM.
  • Хорошие методы ITSM как часть VSM
  • Обеспечение качества или передовые методы проектирования качества, которые оттачивались годами
  • Привитие мастерства программирования или парного программирования как часть управления потоками создания стоимости
  • Признание того, что эффективное управление потоками ценности может включать концепции, выходящие за рамки lean и agile, такие как Teal organizations, менеджмент 3.0, описанный в этой замечательной книге, свод знаний по управлению продуктом, автономия/мастерство/цель, инновации и расширение прав и возможностей.

Не менее важно и то, что не многие игроки в индустрии программного обеспечения говорят о человеческом элементе и его важности в VSM. Они не понимают, что эффективная VSM достигается не только применением lean, agile, SAFe, DevOps или каких-то конкретных инструментов. Она предполагает вовлечение человека и разнообразные виды его деятельности.

 

Видеть VCM такой, какая она есть

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

Если вы хотите проповедовать agile, DevOps или текущий тренд месяца по совершенствованию программного обеспечения, делайте это. Только не смешивайте и не путайте эти подходы с VSM. Вместо этого давайте примем истинную природу VSM, включая «необходимую беспорядочность», которую привносят в уравнение люди, и будем использовать ее для создания лучших организаций и потоков ценности.

 

Оригинал статьи

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

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

Ваш адрес email не будет опубликован.

  • Рубрики

  •  
  • Авторы

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

    • Внедрение ИИ для вашей службы поддержкиВнедрение ИИ для вашей службы поддержки
      Но что на самом деле означает внедрение ИИ для возможностей ITSM вашей организации, особенно для службы технической поддержки?
    • Бесплатная конференция IT-Entrance для тех, кто хочет стать айтишниками
        28 мая в Минске пройдет бесплатная 11-я международная конференция IT-Entrance. Это мероприятие для тех, кто хочет попасть в IT, для начинающих IT-специалистов уровня junior с
    • ITIL 4 Specialist: High-velocity IT. Что внутри?
      В дополнение к уже опубликованным обзорам курсов по направлению Managing Professional (MP) сертификационной линейки ITIL4, сегодня мы рассмотрим еще один модуль – ITIL 4 Specialist: High-velocity IT (HVIT).
    • Весення уборка в бэклоге продукта: порядок за четыре шага!
      Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы. 
    • Warranty и Utility в ITIL4
      У услуг, которыми мы управляем в рамках Service есть две основные характеристики: гарантия — Warranty и Utility — полезность. Эти характеристики нужны нам, чтобы определить, будет ли услуга способствовать достижению результатов, которые нужны пользователю, а как следствие — создавать для них ценность.
    • Шесть практик для лучшего взаимодействия бизнеса и ИТ
      Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
    • Используйте технологии для повышения эффективности рабочего процесса вашей ИТ-команды
      Эффективное рабочее место создает, так сказать, хорошо смазанную машину, повышая итоговую прибыль и, как следствие, успех вашего бизнеса. Дополнительное время на работе не всегда означает большее достижение. Важно то, что вы делаете с тем временем, которое у вас есть, а это все об эффективности рабочего процесса.
    • Хранение данных и «внутренний хомяк»
      Хранение информации, которая больше не пригодится, сопряжено со огромным количеством рисков. Иллюстрация этому — череда сливов персональных данных пользователей крупных сервисов, которую мы могли наблюдать с января по март. Кажется, что предприятиям нужны правила, когда и как избавляться от данных.
    • Action BiasAction Bias — известная ловушка, в которую мы всё равно постоянно попадаем
      Action Bias: склонность к реагированию и действию, даже если это не приведёт к положительным результатам. «Делать хоть что-то» создаёт иллюзию загрузки ресурсов полезной работой.
    • бэклог27 антипаттернов бэклога продукта
      Эта статья показывает 27 распространённых антипаттернов продуктового бэклога, включая процесс уточнения бэклога продукта, ограничивающих успех вашей Скрам-команды.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT