Понимание вашего процесса как процесса Коллективного накопления знаний – Часть 2 (наблюдения)

Я продолжаю серию постов, посвященных визуализации процессов умственного труда. Ранее я писал, о:

  1. понимании таких процессов как последовательности доминантных коллективных активностей, приводящих к накоплению знаний и получению информации – на примере поставки программного обеспечения;
  2. примерах таких процессов из других областей (один пример, другой);
  3. создании отображения существующего процесса с группой работающих в нем.

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

Рис. 1 – Наивная визуализация процесса как передача туда и обратно между функциональными колодцами

что может привести к неэффективному использованию источников информации(рис. 2),

Рис. 2 – Псевдо-Канбан доска в результате наивной визуализации

мы пытаемся понять этот процесс как совместное накопление знаний (рис. 3)

Рис. 3 – Процесс понимается как накопление знаний и информации через последовательность доминантных активностей

и включить выявленные доминантные активности в дизайн нашей Канбан системы (рис. 4).

Рис. 4 – Проектирование системы Канбан в результате понимания процесса как совместного исследования знаний и определения доминирующих видов деятельности

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

Составляйте карту процесса вместе с максимально возможной группой

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

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

Долговечность вместо «болтания досок»

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

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

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

Короткие заголовки и сотрудничество

Поскольку группы выбирают заголовки для столбцов Канбан доски, представляющих доминантные активности процессов, самостоятельно, они часто предпочитали короткие имена. «Dev» и QA можно встретить часто.

Удивительно, но даже если группа понимает фазу построения кода как совместную, кросс-функциональную активность, они предпочитают называть ее просто «Dev». Точно так же совместная, кросс-функциональная активность исследовательского тестирования будет значится как «QA». Таким образом, на доске Канбан рядом друг с другом будут «Dev» и QA, как если бы там был функциональный колодец разработчиков, перебрасывающих пачку кода через стену к тестировщикам.

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

Управляйте работой, а не работниками

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

«Линеаризованный» воркфлоу; проще ли ограничить WIP?

Канбан системы, созданные путем отображения процесса накопления знаний, кажутся более линейными. Более верное слово – «последовательный». Поскольку мы визуализируем накопление информации, оно и должно быть последовательным, поскольку информация накапливается по ходу процесса. Важно помнить, что поступление информации на протяжении всего процесса по-прежнему осуществляется посредством сложных, нелинейных активностей.

Последовательный порядок доминантных активностей имеет свойство устранять одну проблему, о которой часто спрашивают на тренингах. Если мы обнаружили проблему в рабочем элементе на более поздней стадии процесса и нужно отправить его обратно, перемещаем ли мы тикет назад? Например, если тестировщик обнаружил ошибку и должен отправить функционал на доработку к разработчику, мы перемещаем тикет из «QA» на «Dev»? (Ответ: поскольку тикет был в «QA», это означает, что мы уже вышли из доминантной активности кодирования, и что наша текущая доминантная активность включает исправление всех возникающих ошибок перед выпуском, поэтому колонка «QA» – это правильное место тикета, однако может быть удобно разместить на нем стикер, указывающий на блокировку).

Уменьшение движения карточек назад может помочь группам ограничить незавершенную работу. Возвраты карточек в колонки Канбан доски, которые и так заполненные до отказа, как правило, усложняют попытки ограничить WIP.

Минимально жизнеспособный процесс?

Одна из участниц моего воркшопа обозначила потребность, которую назвала “минимальный жизнеспособный процесс (Minimum Viable Process, MVP).” Процесс должен быть представлен таким образом, чтобы не требовалось сложной структурной схемы в Visio, обширной документации в SharePoint или давления со стороны офиса по улучшению процессов для его применения, а также логики процесса, заложенной в используемую систему управления жизненным циклом приложения (ALM). Она хотела, чтобы процесс был лёгким для восприятия, возможно, с помощью нескольких наглядных пособий, а не перегружал мозг информацией, и позволил бы ей и ее коллегам сосредоточиться на реальной работе, а не только на процессе.

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

Интеграция со STATIK

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

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

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

Простой, но не упрощенный

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

Оригинальная статья опубликована Алексеем Жегловым 13 августа 2014
Перевод: Артур Нек
Редактура: Евгений Степченко

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *