Портал №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 не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

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

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

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT