Несколько советов из книги Drew A. Locher «Value Sream Mapping for Lean Development. A How-To Guide for Streaming Time to Market».
Раздел 2. Что отличает процесс разработки?
Организации изо всех сил пытаются отобразить существующие процессы разработки, а затем изо всех сил пытаются их перепроектировать. Но истинная сила картирования потока создания ценности заключается не в визуальном изображении текущего состояния процесса. а скорее в предпринимаемых действиях и достигнутых при этом результатах. Другими словами, сила этого процесса заключается в достижении «будущих состояний», которые обеспечивают организации прорывные результаты. Однако, если у людей возникают трудности с отображением «текущего состояния», им наверняка будет трудно применить к нему «бережливое производство». Итак, в чем же источник этой трудности? Чем процесс разработки отличается от других процессов внутри организации?
Во-первых, процессы разработки часто очень изменчивы, и создатели карт потоков создания ценности часто испытывают трудности с отображением таких процессов. Существует несколько возможных коренных причин этой изменчивости. Понимание этих коренных причин позволит пользователю лучше применить инструмент картирования потока создания ценности и начать думать о том, как устранить и минимизировать корневые причины в будущем состоянии. Ниже представлен неполный список потенциальных причин, а также различные «советы по картированию», которые следует учитывать при изображении этих причин на карте текущего состояния.
Одни и те же ресурсы разработки выполняют несколько задач в течение примерно одного и того же периода времени. Эти задачи могут включать в себя как сильно вариативную деятельность по созданию по созданию знаний, так и менее вариативную деятельность по повторному использованию знаний, а также различные виды работ по поддержке разработки, которые по своей природе являются скорее административными или транзакционными. Во-первых, перед картированием необходимо четко определить «семейство» продуктов или услуг. Как только онр будет согласовано, все собранные данные будут относиться к контексту этого конкретного семейства продуктов или услуг, как обсуждалось в главе 1. Это позволит сосредоточить внимание команды картирования и поможет провести мероприятие по картированию более гладко.
Совет по картированию:
Мы можем отметить на карте, что определенные ресурсы «распределены» между другими семействами, и записать нашу оценку доли времени, которое ресурсы тратят на определенные работы. Наконец, данные для карты могут отображать диапазоны значений, с комментариями с подробным описанием того, почему данные попадают в этот диапазон. Ниже приведен пример того, как эту информацию можно отметить на карте потока создания ценности.
Работа партиями может привести к вариативности. В процессе разработки под работой партиями чаще всего подразумевают объем работы (в часах), передаваемый на следующий этап обработки. При наиболее классической форме работы партиями анализ проекта проводится раз в месяц, релизы проекта завершаются по пятницам и т. д. В таких случаях информация будет ожидать в очереди до тех пор, пока она не будет периодически обрабатываться (т. е. в «партии»).
Проблемы с качеством информации могут создавать «циклы» доработок и, следовательно, вносить большую вариативность в процесс. Люди часто не могут решить, как отобразить это на текущей карте штата. Есть несколько способов изобразить такие петли. Гораздо важнее понять, где они возникают и каково их влияние на поток создания ценности, чем пытаться описать многочисленные пути, по которым информация может передаваться для устранения проблемы.
Руководство может использовать ресурсы разработки для одновременной работы над слишком большим количеством проектов разработок. Это может значительно повысить вариативность процесса, особенно когда возникают проблемы с одним из проектов, что может затем повлиять на выполняемые одновременно с ним другие проекты.
Проектировщики не соблюдают стандартные методы работы. Слишком часто проектировщики предоставлены сами себе в поисках лучшего способа выполнения различных действий по разработке. Однако это приводит к росту вариативности процесса. Помните: средства, с помощью которых достигается результат, так же важны, как и сам результат.
Планированию уделяется недостаточно внимания, особенно, планированию использования «общих ресурсов» (например, испытательных лабораторий, производственных площадок). Чтобы противостоять этой корневой причине, команда должна понимать, каким образом расставлять приоритеты разным работам в потоке создания ценности.
Совет по картированию:
Важным показателем качества информации является доля ситуаций, в которых получена вся необходимая информация, при этом еще и точная информация. Это называется «Полнота и точность». Если информация не является полной и точной, группа может записать это в блок данных, указав, где дальше в потоке была обнаружена проблема (см. пример ниже). Если для окончательного исправления проблемы нужно сделать несколько итераций, это можно отметить с помощью значка итераций. Также можно записать влияние на поток создания ценности (например, на время выполнения заказа) отсутствующей или неточной информации, как и практики работы партиями. Пример ниже показывает, как эта информация может выглядеть на карте потока создания ценности.
Совет по картированию:
Значок «Входящие» можно использовать для обозначения количества выполняемых в настоящее время проектов разработки, а также способа приоритезации этой работы. Представление данных в диапазонах, снабжённых примечаниями, объясняющими, что означают эти диапазоны, может подчеркнуть отсутствие стандартных методов работы. Один из способов отображения этой информации на карте показан ниже.
Вы сможете обнаружить, что большая часть вариативности в процессе разработки создается самими организациями. Текущая практика управления и то, как в настоящее время в компании организована работа, связанная с разработкой, могут способствовать вариативности этого процесса.
Сложность существующего процесса — это еще одна проблема, с которой должен справиться специалист по бережливому производству, приступая к процессу разработки. Лишь немногие компании имеют адекватную документацию на текущий процесс разработки. У других описание есть, но не в такой детализации, которая требуется для картирования потока создания ценности, например, при определении всех необходимых данных, необходимых для того, чтобы «увидеть поток» и «увидеть потери». Поэтому создание первой карты текущего состояния может быть весьма разочаровывающим. Сложность процесса разработки может принимать несколько форм. Чаще всего, текущий процесс разработки склонен к множественной передачи ответственности (от исполнителя к исполнителю — ВК) в течение длительного периода времени. Эти характеристики взывают к применению бережливого производства и его вниманию к сокращению времени выполнения заказов. Однако те, кто используют картирование, могут испытывать сложности, пытаясь определить правильный способ отображения этой информации.
Всегда задавайте этот вопрос: получим ли мы какие-либо новые знания, добавляя детали? Например, люди пытались представить карту потока создания ценности в виде «функциональных плавательных дорожек». В одном примере на карте было одиннадцать «полос» — действительно, очень глубокий бассейн. На вопрос, почему они изобразили информацию таким образом, команда ответила «для того, чтобы действительно подчеркнуть сложность текущего процесса». Процессы разработки уже очень сложны. Действительно ли нам нужно усложнять карту потока создания ценности, чтобы доказать это? Разве простые суммарные показатели числа участвующих отделов (в данном случае одиннадцати) и количества переходов ответственности (сто семьдесят девять) не приведут к тому же результату?
Нужно ли нам добавлять «глубину» карте? Шаги процесса, которые на самом деле происходят параллельно, нужно изображать параллельно. Это добавляет карте «глубины», при этом точно отображая, когда что-то происходит на самом деле. В ходе оптимизации процесса разработки знание о том, когда что происходит, будет более важным, чем знание того, кто выполняет задачу. Если группа считает важным определить функцию или функции, выполняющие конкретный процесс, то желаемую информацию может передать простая заметка в каждом блоке процесса.
Совет по картированию:
Всегда отображайте информацию самым простым способом. Например, функциональную ответственность можно отобразить на карте простым комментарием. Это оставляет место для ясного отображения протекающих сейчас процессов. Ниже показан один из способов, как это сделать.
Еще одним фактором, который может изменить процесс разработки, являются ограничения клиентов и/или отрасли. Существуют нормативные требования, которые должны соблюдаться в конкретных отраслях. Хотя это обычно не усложняет отображение текущего состояния, эти требования необходимо учитывать при проектировании будущего состояния. Главное здесь – не предполагать. Например, организации в регулируемых отраслях часто предполагают, что регулирующие органы не примут изменения, которые они рассматривают. Такие предположения должны быть оспорены и либо подтверждены, либо опровергнуты. Иногда организации испытывают удивление от положительного ответа, который они получают от аудиторов или регулирующих органов в целом. Потери в процессе разработки может быть трудно заметить. Однако если мы правильно используем инструмент картирования потока создания ценности, эти потери станут совершенно очевидными. Как выявить потери при разработке, будет рассмотрено в главе 3.
