Смоделируйте производственный процесс

В этой главе показаны три подхода к моделированию производственного процесса, которые поможет развивать наша канбан-система:

1. Выстраивание общей схемы.
2. Разбивка сверху вниз.
3. Организация снизу вверх.

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

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

Выстраивание общей схемы

Мы не станем рекомендовать вам какую-то определенную систему записи. Сами решайте, что использовать — классический «бизнес-процесс», картирование потока стоимости, принятые у вас в организации значки или же нечто совершенно неформальное. Выберите тот способ, который не породит ненужное сопротивление у ваших коллег и не заставит уделить этой стадии больше времени, чем нужно.

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

На рис. 20.1 показана (система записи нарочито неформальная) первая стадия истории XIT (см. «синюю книгу», главу 4 «От худшего к лучшему за пять кварталов»).

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

Может быть, вас интересует, что происходит после того, как пользователь примет продукт? Хороший вопрос!

Разбивка сверху вниз

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

1. Выявите свои точки вовлечения (обычно их одна-две): например, те моменты, когда вы соглашаетесь приступить к созданию или обслуживанию продукта, а затем договариваетесь о его поставке или об иной форме завершения работы.
2. Разбейте на категории те состояния или виды деятельности, которые существуют до этих точек, между этими точками, после этих точек. В примере с XIT это могут быть «Портфель заказов», «Разработка» и «Внедрение».
3. Используя столько уровней, сколько необходимо, разбейте эти категории так, чтобы они отражали повседневную реальность вашей работы. Например:
   • Работы, которые необходимо выполнить:
     • получено;
     • оценка;
     • приоритизировано.
   • Разработка:
     • создание продукта;
     • тестирование.
   • Внедрение:
     • принятие пользователем;
     • выпуск на рынок.
   • Сделано.
4. Есть стадии, когда задачи ждут дальнейшей работы над ними в промежутках между активными стадиями и совершенствованием. Такое часто встречается при передаче работы от одного сотрудника к другому.

   В нашем примере категории «Полученные» и «Приоритизированные» описывают состояния ожидания. Весьма вероятно, что ожидание возникнет также между созданием и тестированием продукта, если эти операции проводят разные люди. Отдельно сформулированные состояния «Создание продукта завершено» или «Продукт готов к тестированию» покажут, что задача обычно ожидает дальнейшей работы до или после такой передачи другому сотруднику.

В высшей степени неформальный вариант такого подхода: начните с самой примитивной схемы «Что надо сделать», «Что делается», «Что сделано» (возможно, какая-то подобная схема уже у вас в ходу). Затем спросите:

• Есть ли разница в том, «что надо сделать»? Как организовывать процесс — по виду деятельности или по приоритетности?
• Что происходит на стадии «делается»?
• Есть ли разница в «сделанном»? Как мы определяем, что работа «действительно сделана»?

Организация снизу вверх

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

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

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

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

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

А заодно эта методика может помочь выявить некоторые любопытные проблемы:

Вопрос: что нужно сделать для выполнения этой задачи?

Ответ: нужно исправить баг, прежде чем можно будет продолжать тестирование.

Или: нужно, чтобы ее вернула нам команда Х.

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

Промежуточные итоги

Прежде чем мы двинемся дальше, назову несколько хороших способов проверить и улучшить то, что у вас уже есть:

• Быстро объедините разные подходы, чтобы подтвердить действенность своей модели. Например:
  • Выстройте схему на основе своей модели типа «сверху вниз» или «снизу вверх».
  • Убедитесь, что на вашей схеме или в модели «сверху вниз» представлены реальные рабочие задачи. Затем используйте вопросы типа «Что нужно для выполнения этой задачи?».
  • Подумайте, полезно ли будет сгруппировать или разбить какие-то категории.
• Проверьте, чтобы стадии ожидания были представлены адекватно. Удостоверьтесь, что вы знаете расположение своих точек вовлечения.
• Подумайте, где могут возникать факторы неудовлетворенности и разочарованности, обсуждавшиеся в главе 18.
• Определите типы приобретаемых знаний, связанных с каждым активным состоянием.
• Старайтесь не обращать особого внимания на функциональную организацию.
• Представьте вашу модель другим.

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

Отправить