Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
Когда вы читаете об управлении потоком создания ценности, вы должны уметь распознавать ложную информацию, когда видите ее. Вот пять вещей, скрывающих правду о VSM, и то, на чем вам следует сосредоточиться.
- Неправильная атрибуция, персонификация и принятие желаемого за действительное.
Первая проблема связана с многочисленными необоснованными заявлениями о преимуществах VSM. Остерегайтесь заявлений, начинающихся с таких фраз, как “VSM обеспечивает видимость … ” или “VSM обеспечивает контроль над … “.
VSM не обеспечивает видимость или контроль. Конечно, вы хотите этого, но VSM – это не конкретный процесс, метод, структура, инструмент или платформа. Это всего лишь концепция, и вы сами решаете, как ее использовать.
Вы можете услышать, что “VSM дает командам возможность сокращать потери”. Да? Как? Конечно, мы хотели бы, чтобы наши усилия по внедрению VSM расширяли возможности команды, но я бы не сказал, что это так. Правильнее будет сказать, что ваши усилия VSM должны расширять возможности вашей команды. Или, по крайней мере, они не должны лишать команду полномочий. Но утверждение, что VSM делает то или иное, искажает представление о VSM и сеет путаницу.
“VSM автоматизирует поток информации”. Каким образом? Автоматизация доступности информации – это хорошо, но, повторюсь, VSM – это концепция. Как концепция, она ничего не предоставляет и не делает.
- Излишняя конкретика и ограниченные возможности для улучшений.
Некоторые авторы слишком конкретизируют, каким должно быть рекомендуемое улучшение, в каком направлении оно должно идти или какую технику следует использовать. В результате у них остается ограниченное представление о возможностях улучшения. Опасайтесь таких фраз, как “Основное внимание следует уделить таким критическим показателям, как скорость и качество” или “Скорость и качество важны для прибыльности”.
Иногда эти афоризмы могут быть верны. Но что делать, когда это не так?
Большинство команд разработчиков программного обеспечения рассматривают время выполнения/потока, загрузку потока, сокращение потерь и качество как ключевые показатели успеха. Но что, если деятельность, необходимая для прибыльности данного бизнеса, не оценивается по скорости и качеству?
Иногда основными показателями являются предсказуемость, инновации или снижение затрат. Если высшему руководству нужна предсказуемость или инновации, оно должно быть готово принять некоторые виды потерь.
Например, для достижения предсказуемости важен определенный уровень качества, но скорость не является основным показателем. При инновациях скорость обычно идет рука об руку, но потребности в качестве могут отличаться. Слепое внимание к традиционным показателям бережливого потока может сбить команду с пути.
Если скорость – время опережения или время выхода на рынок – является критическим фактором для вашего бизнеса, вы должны принять избыточные мощности и/или ограничения на то, что допускается в систему. Почему? Пропускная способность резко падает, а время выполнения заказа увеличивается, когда загрузка системы становится слишком высокой. Когда фирмы накладывают ограничения на то, что допускается в систему, отталкивая или отказывая запросам, которые превышают заранее определенный уровень, они могут обеспечить оптимальную загрузку.
В других случаях, когда люди говорят, что им нужна скорость, на самом деле они имеют в виду, что им нужна высокая пропускная способность – ускоренное завершение большой партии работы. Если драйвером является высокая пропускная способность, то вы должны рассмотреть другие бизнес-цели и разработать программу улучшения и подход VSM с учетом этих потребностей.
Слишком много людей, которые пытаются вести дискуссию о VSM, имеют ограниченное (бережливое, DevOps- или IT-ориентированное) представление о том, как должен работать поток создания ценности. У них узкий взгляд на факторы, которые способствуют тому, как должен быть спроектирован и оптимизирован поток создания ценности в организации.
- Путать работу в бизнесе с работой над бизнесом
Часто я слышу, что необходимо согласовывать усилия по разработке программного обеспечения с результатами бизнеса. Это благородно, но это не имеет большого отношения к VSM.
Бизнес-результаты похожи на усовершенствования и исправления продукта – такие вещи, как сокращение количества брошенных корзин, повышение удержания, или облегчение найма – которые решаются работой, проходящей через поток создания ценности. Бизнес-результаты – это то, что выходит из потока создания ценности.
Вы надеетесь, что ваши истории соответствуют бизнес-результатам. Так и должно быть. Вы также надеетесь, что они приведут к желаемым бизнес-результатам. Но это проблема управления продуктом, а не проблема VSM. Это станет проблемой VSM только в том случае, если возникнут проблемы с процессом управления продуктом.
Реальные бизнес-результаты (предмет управления продуктом) могут быть связаны с характеристиками продукта или удержанием клиентов. В отличие от этого, VSM занимается проблемами людей или процессов, которые мешают достижению этих результатов в рамках желаемых параметров.
Параметры относятся к таким элементам, как время выхода на рынок, предсказуемость, качество, инновации и пропускная способность. Эти параметры улучшаются путем работы над потоком создания ценности.
- Улучшать правильные вещи
Это означает, что ваша организация должна определить проблему потока создания ценности и цель улучшения. Например, у вас могут быть проблемы с выполнением обязательств перед маркетингом, клиентами, обучением или другими командами. Все они жаждут предсказуемости.
Если это характерно для вашей организации, вам могут понадобиться улучшения, связанные с разрывом зависимостей или выявлением и управлением зависимостями. Возможно, вам нужно улучшить стабильность пропускной способности – не обязательно увеличить пропускную способность, и особенно не обязательно увеличить вариабельность пропускной способности.
Однако это не бизнес-результаты. Это организационные улучшения. Выбор историй (работа по управлению продуктом) подразумевает работу в потоке создания ценности. Улучшение процесса выбора этих историй – это работа над потоком создания ценности, т.е. VSM.
- Приравнивание 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, включая “необходимую беспорядочность”, которую привносят в уравнение люди, и будем использовать ее для создания лучших организаций и потоков ценности.
