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

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

В двух словах, диаграмма накопления знаний / информации, представленная вот так,

мы можем представить вот такой Канбан доской:

Метод отображения процессов имеет три важных аспекта:

1. Что делать, фактически, и как – конкретный рецепт.

2. Наблюдения, сделанные путем фактической работы с группами людей: плюсы, минусы, сюрпризы и подводные камни – мы узнаем только на практике.

3. Обоснование того, чтобы делать или не делать что-то определенным образом – это то, что нам нужно уяснить, чтобы больше походить на шеф-поваров, а не на поварят.

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

Простые вещи: что делать и как

Чтобы начать отражение нашего процесса, нам нужна информация:

• определите организационное подразделение и его границы: обычно это отдел, команда, департамент или несколько связанных команд;
• определите интерфейсы и те сервисы, которые предоставляет эта группа (внешним и внутренним клиентам), а также типы рабочих элементов сервисов;
• найдите несколько примеров недавно поставленных рабочих элементов каждого типа.

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

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

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

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

Со временем группа начнет замечать сходство между ними (конечно же в рамках одного и того же типа рабочего элемента). Ведущий должен уточнять у участников порядок выстраивания стикеров с аналогичными активностями. Иногда порядок становится очевидным достаточно быстро, поэтому нет необходимости записывать каждый отдельный шаг для каждого рабочего элемента на стикере. Основные, доминантные виды активности затем могут быть определены путем расположении на временной шкале и группирования стикеров соответствующим образом. Как напоминание (это было подробно описано в предыдущем посте), один из основных видов активности доминирует в накоплении знаний какое-то время, но в конечном итоге затухает и заменяется новым доминантным видом активности.

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

Явная политика

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

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

•  критерии готовности (Definition of Ready);
•  критерии завершенности (Definition of Done);
• правила очередности или выбора элементов для выполнения (некоторые называют это приоритезацией);
• каденции пополнения и поставки;
• и так далее.

Всё это может быть обнаружено и зафиксировано на новой доске.

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

Оригинальная статья Алексея Жеглова доступна тут . За помощь с переводом огромное спасибо Евгению Степченко.