Управление потоком — часть 2: взгляд за пределы команды

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

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

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

Модели поведения, которые позволяют группе «несвязанных лиц» становиться командами в контексте управления потоком, могут быть сгруппированы в две категории:

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

Это может показаться удивительным: категории классификации и соглашения о собственности — это не то, что мы могли бы интуитивно ассоциировать с управлением движения частей работы. Однако, прежде чем вы сможете сосредоточиться на этом движении, должно быть достигнуто некоторое соглашение о цели этого управления и о том, кто за это отвечает.

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

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

Второй вопрос, который следует задать: «Какими видами деятельности вы занимаетесь?». Командам легче ответить на него. Часто ответы будут включать такие вещи, как «пользовательские истории», «баги», «тесты», «задачи» и т. д. Независимо от ответа, вот два дополнительных вопроса, которые вы можете задать. Спросите: «Можете ли вы содержательно поговорить об этих видах деятельности со своим клиентом?» и «Достаточно ли они значимы для клиента, чтобы использовать их в качестве предмета торга в процессе пополнения?» (то есть: «Это то, что их волнует?»).

Относительно простой способ изменить ситуацию — убедиться, что мы формулируем работу с точки зрения людей, которые получат от неё пользу, используя типы работ с узнаваемыми ими названиями. Если мы можем вести содержательный разговор с Клиентом о конкретной части работы так, чтобы это имело для него значение и могло использоваться в качестве предмета торга в процессе пополнения, то тогда мы называем это «Распознаваемый клиентом тип рабочего элемента»". Типичными примерами распознаваемых клиентами типов работ могут быть: «эпики», «фичи», «возможности», «проекты», «сценарии использования» и т. д.

Вы можете быть удивлены, не найдя «пользовательские истории» в приведённом выше списке примеров. Фактически, пользовательские истории могут быть сформулированы так, чтобы соответствовать критериям распознаваемости клиентами (и можно даже утверждать, что это именно то, «как истории должны использоваться»). Однако в реальном мире такое встречается редко: чаще всего пользовательские истории пишутся, чтобы удовлетворить потребность в разделении части работы на управляемые кусочки. В процессе они либо становятся нераспознаваемы для Клиента (как в случае с «техническими историями»), или недостаточно осмысленными, чтобы принимать компромиссные решения (например, история, которая просто добавляет кнопку на экран), или и то, и другое.

Также вы можете прийти к выводу, что рабочие элементы, распознаваемые клиентом, всегда являются «крупными частями работы». Возможно, в целом они будут больше, чем задачи на уровне отдельных команд. Однако, ничто не мешает вам работать с вашим Клиентом так, чтобы в процессе взаимного обучения и согласования, работа могла быть разделена на всё более и более мелкие части, которые сохраняют распознаваемость и ценность. Уменьшение размера пакета всегда считалось способом увеличения потока, поэтому постепенное уменьшение размера «эпиков» и «фич» (возможно, до такого размера, чтобы мы назвали это просто «историей») может быть желанной целью.

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

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

Что происходит с работой перед тем, как она попадает к вашей команде? Что происходит с ней после того, как команда говорит, что работа выполнена? Как правило, вы обнаружите, что вокруг процесса, который команда считает своим собственным, также существует некая форма процесса «доработки». Она необходима для подготовки работы. А также есть ещё один процесс-«Релиз», необходимый для её выпуска.

Часть процесса доработки на самом деле происходит внутри команды (часто под такими названиями, как «груминг» или «оптимизация бэклога»), но это редко визуализируется. В конечном итоге нечто подобное происходит с действиями по релизу: часто обнаруживается, что после того, как работа была названа «выполненной», для её выпуска всё ещё требуется несколько действий (настройка feature toggle, запуск скриптов развёртывания, написание примечаний к релизу и т. д.)., но часто эта работа представлена в виде дополнительных «технических историй» или вообще не визуализирована. В обоих случаях результатом является то, что эти действия остаются неявными и не признаются частью рабочего процесса.

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

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

Вы можете, конечно, продолжить и расширить поле зрения ещё вверх и вниз по течению потока, насколько позволяет ваша сфера влияния.

Наконец, более широкий взгляд на рабочий процесс может помочь лучше понять обязательства: в какой момент мы даём обещания клиентам и какова природа этих обязательств? Как долго нам нужно работать, чтобы выполнить это обязательство? С этим пониманием мы получаем возможность выполнять некоторые элементарные измерения Системного времени выполнения (System Lead Time), делая первые шаги к количественному анализу потока.

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

Старение WIP — это относительно простой индикатор, который также можно отслеживать, чтобы определить работу, которая перестала двигаться. И это может быть просто добавление «точек» на тикеты с каждым прошедшим днем. Затем можно объединить с определением «триггерных точек», чтобы предпринять какие-либо действия, если конкретная часть работы слишком долго оставалась на доске.

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

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

Для этого нам нужно уметь обнаруживать общие закономерности, которые имеют тенденцию повторяться. Полезным методом для этого является кластеризация блокеров. Это метод, впервые предложенный Клаусом Леопольдом. Он заключается в маркировке рабочих элементов «тикетами блокеров», которые впоследствии собираются и анализируются. Это делают, чтобы выяснить, как блокеры объединяются в течение времени, а далее используют эту информацию для определения воздействия, вероятности и вариантов коррекции.