В самом управлении потоком создания ценности (value stream management, VSM) нет ничего плохого, но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие обозреватели, которые часто смешивают его с DevOps и Agile. Это не одно и то же, пишет на портале TechBeacon Эндрю Фукуа, старший вице-президент по продуктам компании ConnectALL.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я часто слышу, что необходимо согласовывать усилия по разработке ПО с бизнес-результатами. Это благородно, но это не имеет большого отношения к VSM. Считайте, что «усилия» — это эпосы и истории. Управление продуктом вводит эпосы и истории в поток создания ценности.

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

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

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

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

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

4. Улучшение правильных вещей

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

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

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

5. Приравнивание VSM к Agile

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

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

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

О чем нужно говорить

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

Многие авторы и докладчики в своих статьях и вебинарах по VSM любят говорить о lean, Agile и DevOps. Но я не слышу, чтобы люди говорили или писали достаточно часто о следующем:

  • совершенствование управления продуктами в рамках VSM;
  • хорошие методы ITSM как часть VSM;
  • обеспечение качества (QA) или передовые методы обеспечения качества проектирования, которые оттачивались годами;
  • повышение мастерства программирования или парного программирования как часть VSM;
  • признание того, что эффективное управление потоком ценности может включать в себя концепции, выходящие за рамки lean и Agile, такие как бирюзовые организации (teal organizations), Менеджмент 3.0, свод знаний PMI по управлению продуктом, автономия/мастерство/цель, инновации и расширение возможностей.

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

Воспринимайте VSM таким, каким оно является

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

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