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

Есть в системе Lean production одна техника оптимизации, которая мне очень нравится, и с которой я сейчас хочу вас познакомить. Называется она Value stream mapping, что на русский переводится плохо. Лучший официальный перевод, что я нашел - это Карта потока создания ценности, хотя mapping - это не карта в этом контексте, а скорее “отображение”.
Но не в этом суть, в дальнейшем я буду называть этот метод для краткости VSM (от Value stream mapping).
VSM - это техника, которая изначально была придумана в системе 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 выглядел примерно так:



Как видно из новой 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 в основном используется управленцами и иногда менеджерами, но незаслуженно игнорируется техническими специалистами - этот пробел я и пытался заполнить этой статьей.



В этой статье я описал только основы VSM и привел один простой пример. На эту тему можно еще много написать, а лучше просто привести больше примеров.
Стоит ли мне писать продолжение с примерами других более технических VSM?
Если да, то какие VSM вы бы хотели увидеть?



Похожие записи:
Канбан в IT (Kanban Development)
Откуда берется эффективность программиста 2
10 заповедей для программистов
Shu-ha-ri для программистов

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

  • Круто, спасибо. Расскажу манагерам :)

    (On a sidenote, ссылка “понравилась статья — подпишись на rss” внутри rss-фида выглядит занятно.)

    • (On a sidenote, ссылка “понравилась статья — подпишись на rss” внутри rss-фида выглядит занятно.)

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

  • zihotki

    Спасибо, занятная история, в первый раз слышу

  • bialix

    Спасибо, очень интересно. Давайте еще примеров!

  • спасибо за статью - примерно тот пример “доводки” идей до реализации, который я искал. Относительно примеров - да можно еще, только я даже не знаю что бы я еще хотел увидеть :)

  • Eugeon

    А существует ли пример VSM для Maintenance проектов?

    Типа:

    RCA0->FIX0->Dev Test0
    \
    RCA1->FIX1->Dev Test1->Code Freeze->Integration-> System Test-> Release
    /
    RCA2->FIX2->Dev Test2

    Естественно, что большие части тут будут занимать Fix & System Test.
    Первая у меня идет по Kanban с начала марта примерно - уже начали показывать результаты лучше, чем раньше.

    А вот с System Test - сложнее, очень много неавтоматизированных тестов, все приходится ручками:( Денег на автоматизацию тоже пока нет:(
    Аргументация “лучше день потерять, потом за пять минут долететь” для начальства не аргумент - нужно около пары человеко-лет, чтобы все автоматизировать. За такой срок, боюсь, система может уйти из продакшна.

    Есть ли у Вас примеры решения подобных кейсов?

    • Есть ли у Вас примеры решения подобных кейсов?

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

  • Карта технологического процесса - так назывались подобные карты для будущих инженеров-механиков лет 12 назад.

  • От первого сообщения осталось только первое предложение. Во втором вообще ничего нет. Глюки?

    • У openid плагина есть баг - если предложение начинается с большой буквы и, то оно отрезается :(
      Если зарегистрироваться на сайте или не использовать openid или большую букву и - все ок.
      Разработчики плагина в курсе, но до сих пор не поправили.

  • Николай

    Коротко про карты тех. процесса - для них были ГОСТы и вроде даже пара учебников изданных еще при Союзе.

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

    • Я составлял VSM для мэйнтенанса - для команды, исправляющей баги в продукте. Это только кажется, что там нечего оптимизировать.
      А на деле оказалось, что процесс приводит к тому, что баги слишком долго копились в базе багов, было до сотни багов одновременно в базе. Средний срок программиста на исправление бага - несколько дней. При этом среднее время от попадания бага в саппорт до исправления - полгода!
      Решение очевидно - убирать накопление багов, “инвентори”. Сократили максимум багов в базе до 10. После этого время от попадания бага в базу до его исправления сократилось до нескольких недель.
      Вот и польза.

  • Андрей Н

    Статья хорошо построено, содержание +++!! Идея хороша и глобальна)

Ответить

 

 

 

Вы можете использовать эти HTML тэги

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>