Value stream mapping (Карта потока создания ценности)

Есть в системе Lean production одна техника оптимизации, которая мне очень нравится, и с которой я сейчас хочу вас познакомить. Называется она Value stream mapping, что на русский переводится плохо. Лучший официальный перевод, что я нашел — это Карта потока создания ценности, хотя mapping — это не карта в этом контексте, а скорее “отображение”.

Но не в этом суть, в дальнейшем я буду называть этот метод для краткости VSM (от Value stream mapping).

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

Как и практически всё остальное из тойотовского Lean manufacturing, VSM прижился и в других отраслях, включая отрасль разработки ПО. Фактически, VSM можно использовать для оптимизации любого процесса и использовать где угодно — от программирования до организации вывоза мусора.

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

Каждый этап занимает сколько-то времени, но и на передачу данных или материалов между этапами также уходит время, так что нужно отмечать временные затраты и на этапах и на переходах. После того, как такая схема нарисована — это и есть готовый Value stream mapping. На ней сразу будет видно где вы теряете время в процессе создания продукта и сколько времени вы тратите на работу, а сколько на ожидание. Главная цель создания VSM — это максимальное уменьшение времени ожидания в процессе разработки. Делается это достаточно просто с помощью анализа полученной схемы VSM.

Словами это описать сложно, а на примере понять легко, так что напишу пример из жизни.

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

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

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

На это ушло много времени, усилий и сотни тысяч долларов, но что получилось в итоге?

В итоге он смог ускорить разработку игр этой компанией на треть и в среднем игра проводила в разработке теперь не 3 месяца, а 2. Просто потрясающее достижение, правда?

А нет. Компания все равно отставала от конкурентов, потому что от момента придумывания концепта игры до ее релиза проходило больше года!

Только тут до консультанта дошло, что он оптимизировал совсем не то.

Он взял лист бумаги и нарисовал VSM для начальной ситуации. Получилось, что когда кто-то генерил идею новой игры в этой компании, то она попадала в хранилище идей (wiki или сетевая папка, неважно). На запись и разработку идеи человек тратил в среднем 1 день.

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

Отобранные идеи затем помечались, как годные и передавались в отдел бизнес планирования. Очередь идей в тот отдел была большой, отклоняли заявки они с неохотой и занимались еще и другими делами параллельно. Давление по срокам у них было маленьким, поэтому идеи ждали оценки еще в среднем 3 месяца. Когда идея попадала в бизнес отдел, то отдел разбирался с ней в среднем за 4 дня и мог отклонить идею либо признать её выгодной и целесообразной.

Одобренные бизнес отделом идеи дальше попадали в отдел препродакшена игры, который готовил дизайн графики и разрабатывал полный сценарий игры. Этот отдел тоже делал несколько препродакшенов одновременно и в очереди у него тоже было несколько одобренных идей. Так что на проработку дизайна уходил примерно месяц, а на ожидание — около 2-х месяцев.

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

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

Какие проблемы мы можем увидеть по этому VSM?

Мы видим, что от момента зарождения идеи до доставки готового продукта (игры) до клиента, уходило около 14 месяцев. При этом реальная работа выполнялась за 4 месяца и 6 дней, а все остальное время — это ожидание.

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

А консультант осознал, что он потратил кучу времени и денег и уменьшил этот срок всего на месяц!

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

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

Что было прооптимизировано в новом процессе?

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

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

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

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

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

Как видно из новой VSM, они приняли решение вообще не копить ничего нигде (ведь inventory is waste в Lean production). Они собирались каждую неделю на обсуждение новых идей и не имели больше 4-5 игр в одновременной разработке. А также они объединили отдел дизайна и разработки и разделили людей на 3 команды. В каждой команде были дизайнеры, художники, тестеры и программисты — все нужные люди для проработки и создания игры (это так называемый метод разработки с feature teams).

Это позволило сократить затраты времени на дизайн и разработку игры с 4 месяцев до 2.5! А вся цепочка от подачи идеи до выпуска новой игры теперь занимала около 3.5 месяцев!

При этом тут нет никакой магии — число игр, выпускаемых компанией за год вырасло незначительно. Если раньше отдел разработки делал по 4-5 игр одновременно, то теперь он создавал только 3 игры одновременно, зато в 2 раза быстрее. И главное, что получила фирма от изменения — это не количество выпущенных игр в год, а возможность выпускать новые игры гораздо быстрее, возможность быстрее реагировать на изменения рынка.

И в этом вся идея Lean — пропускная способность системы может оставаться той же самой, но скорость реакции на изменения должна постоянно расти — только так можно работать на быстро изменяющемся рынке.

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

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

Например, программист может оптимизировать время от изменения в коде до получения готового инсталлятора с продуктом, содержащим это изменение. Или же даже до получения инсталлятора, который прошёл все тесты в test automation, если он у вас есть.

Либо же программист может постоянно думать и оптимизировать время от получения User Story (задания) до получения версии готового продукта с этой фичей.

Художник-фрилансер может оптимизировать время от получения задания от заказчика до получения денег за выполненную работу.

И так далее — любой специалист может с помощью VSM оптимизировать время выполнения разных задач.

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

Оставить комментарий