Одна из последних задач, которую я решал в области совершенствования процессов проектирования — анализ карт идеального состояния потоков создания ценности нескольких филиалов одного предприятия. Очень интересная задача в том смысле, что она дала много пищи для размышлений. Одну часть выводов из этой истории я расскажу ниже.
Diverse education shoot
Рисовать карту потока создания ценности в нотации VSM, которую придумали Ротер и Шук, — не самое лучшее решение. Неудобна форма VSM для потоков разработки.
Поэтому я обычно рекомендую использовать для изображения потока разработки кросс-функциональные диаграммы, или плавательные дорожки.
И если вы используете плавательные дорожки, то часть анализа можно выполнять «визуально», фиксируя «типичные ошибки» по внешнему виду, чтобы потом разобраться — а почему поток выстроен именно так, и что сделать, чтобы он стал лучше.
Многие, кто использует «плавательные дорожки», стараются уплотнить схему. Из-за этого, во-первых, становится неочевидной временная шкала вдоль дорожек, а еще, во-вторых, часть процессов отображают параллельно.
Уточню: параллельно делается не несколько одинаковых действий (как если бы три человека параллельно чертили три чертежа разных деталей, не связанных друг с другом), а разные действия (параллельно оформляется договор с клиентом, разрабатывается конструкция по его запросу и закупаются материалы для производства под этот запрос)
И это типичная ошибка, с которой надо разбираться.
Причины параллельного выполнения работ
Мы всегда делали это параллельно
Это, в общем-то, не причина, а повод. Раз всегда так делали, то почему бы и дальше не делать параллельно.
Мы думаем, что так можно сэкономить время
Это, скорее всего, говорит о том, что сейчас процесс выполняется последовательно, но для его ускорения участники предлагают делать ряд действий параллельно. Если посмотреть по процессу, то эти действия идут друг за другом, но участникам кажется, что можно не ждать друг друга, а ускорить процессы за счет одновременного выполнения разных действий.
Мы экономим таким образом время уже сейчас
Параллельное выполнение работ — устоявшаяся практика.
Опасности параллельного выполнения разных работ
Есть несколько рисков, которые возникают при параллельном выполнении разных действий.
Параллельно выполняемые действия на самом деле влияют друг на друга
В параллельно выполняемых действиях участвуют одни и те же исполнители
Действия влияют друг на друга
Иногда влияние является неочевидным. Или кажется незначительным. Ну, подумаешь, не учли результаты параллельного процесса. А если там «брак»?
Пример из жизни: три параллельных процесса, упомянутые выше, заключение договора, разработка дизайна и закупка сырья выполняются одновременно под один и тот же заказ. Потому что если последовательно, то слишком долго.
Что может пойти «не так»? Сырьё купили, а договор не заключили. Дизайн сделали, а договор не заключили. Сырьё купили, а дизайн пересогласовали на другой и сырьё не потребовалось. Во всех трех случаях попытка «сделать быстрее за счет параллельного выполнения» провалилась, плюс понесли дополнительные, часто невосполнимы расходы. Сырьё, например, придётся выкидывать или утилизировать, либо хранить сто лет до следующего потенциального заказа.
В информационных процессах это означает, что процессы, которые, по хорошему, должны выполняться позднее, не получат на входе необходимые данные. И это может привести к ошибкам.
В любом случае, надо расставлять процессы по порядку их исполнения, а не параллельно.
Причем порядок может быть разным. Например, вполне можно представить, что сначала проектируется дизайн, а потом закупается сырьё под дизайн. А в некоторых, особо стеснённых обстоятельствах, когда доступ к сырью сильно ограничен, можно увидеть обратную картину — закупается сырьё, а потом уже на основании имеющегося сырья проектируется дизайн. Словами известной песни «я его слепила из того, что было».
Но в любом случае процессы не должны выполняться параллельно, т.к. пока мы не получили результат первого из них, второй начинать нельзя. Поспешишь — людей насмешишь.
Действия выполняют те же исполнители
Скорее всего, это происходит не в явном виде, а закамуфлированно. Например, первый процесс выполняет Иванов, а участвуют Петров и Сидоров. Второй процесс выполняет Петров, а участвуют Иванов и Сидоров. В третьем процессе ведущую роль играет Сидоров, а участвуют Иванов и Петров.
Что будет, если эти процессы делать параллельно? Люди будут делить своё время на параллельное выполнение действий, переключаться с одной работы на другую, бегать с одного рабочего места на другое и так далее. Может получиться даже дольше из-за накладных расходов времени на то, чтобы несколько раз «переключаться с действия на действие»,
Гипотетически, параллельное выполнение действий в этом случае может сработать, но только в том случае, когда «помощники» помогают основному исполнителю в те периоды времени, когда сами они не заняты другой работой. Чтобы понять, есть ли такие периоды времени, нужно хронометрировать работу всех исполнителей и строить схемы занятости. Получится выполнять работу, не бросая её незаконченной, чтобы помочь товарищу, значит, параллельное выполнение действий удалось. Но для этого нужна очень слаженная игра.
Примерно как в командных видах спорта.
Один игрок ведёт мяч, второй вырывается вперёд, пробегая мимо игрока с мячом блокирует игроку соперника проход к партнёру с мячом. Потом свободный игрок уходит вперёд, ведущий мяч игрок отвлекает на себя защитника, даёт пас партнёру и тот забивает гол.
Без слаживания действий сыграть такую комбинацию не получится.
И в производстве — то же самое. Нужно «слаживать действия», а в условиях производства это делается не «на тренировках», а в рабочем процессе через планирование процессов после тщательного анализа.
Когда в процессах разработки можно выполнять действия параллельно
Это можно делать тогда, когда исходные данные можно разделить на независимые наборы и работать с каждым таким набором отдельно. Например, когда цветовые предпочтения заказчика не зависят от массогабаритных размеров изделия. Тогда выбирать краску можно заранее, красить готовые детали можно не дожидаясь окончания сборки.
Но для этого надо разделить набор исходной информации на части и проверить — а действительно ли они не зависят друг от друга? Действительно ли нам не потребуются одни и те же исполнители в обоих ветках процесса? Если ответы утвердительные, то процессы можно распараллелить.
Но в общем случае, лучше делать все действия последовательно, а если есть проблем с «длинным сроком выполнения работ», то надо искать способы сокращения потерь, а не распараллеливания потерь.
Дополнение для «продвинутых пользователей»
В книге «Система разработки продукции в Toyota» Джеффри Лайкера и Джеймса Моргана, авторы пишут о том, что в Toyоta процесс проектирования сжат по времени как раз за счет параллельного выполнения процессов из разных этапов проектирования. Это так. Но такая работа требует прочного базиса, чтобы не увеличить количество переделок на стадии проектирования.
Все участники должны быть в тесном информационном контакте друг с другом. Нельзя работать по принципу «я свою работу сделал, а что будет дальше — меня не волнует», а это наиболее популярный принцип в традиционном производстве с разделением труда рабочими местами, участками, цехами и т.п.
Должен работать принцип «постепенного сужения спектра альтернатив», (в книге — Принцип 2 «Обеспечить правильный старт процесса разработки, чтобы на ранней стадии проектирования досконально изучить альтернативные варианты»). Подход, который стоит за этим принципом называется «Параллельное проектирование на основе множеств», и этот подход практически не известен в России.
Должна действовать очень жесткая система стандартизации процесса проектирования. В книге Лайкера и Моргана это Принцип 4 «Применять жесткую стандартизацию, чтобы снизить вариацию, повысить гибкость и обеспечить предсказуемость результатов».
Это, наверное, минимум того, что нужно иметь в качестве базиса. Если этого нет, то попытки запараллелить работы, которые в традиционном «водопадном» подходе выполняются последовательно, приведут к огромному количеству переделок и дополнительных потерь времени. Особенно в тех случаях, когда речь идёт о сложных продуктах.
Поэтому для тех производственных компаний, которые еще не занимались отладкой процессов проектирования, этап жесткого «последовательного» выполнения работ является обязательным, а попытки сразу вскочить в поезд Agile по аналогии с ИТ может привести к краху, который можно описать старым бородатым анекдотом про программистов:
«Если бы строители строили дома так же, как программисты пишут программы, то первый же залётный дятел разрушил бы всю цивилизацию»
[…] […]