Каждому teamlead’у, project’у или руководителю отдела однажды приходилось настраивать жизненный цикл для задач, фич, багов и прочих вещей и как-то визуализировать это дело. Однако по итогу получалось так, что никто этой визуализацией не пользовался и вдобавок сопротивлялся созданному вами workflow. Да и вообще у подопечных появилось больше вопросов, чем у вас ответов.

Меня зовут Алексей Пименов, я аккредитованный Kanban-тренер и Kanban-консультант. Каждый использует какую-то визуализацию процессов. Наверняка у многих на работе есть в электронном, либо в бумажном виде какие-то досочки со стикерами. Очевидная история, но есть несколько тонкостей. А именно, что существует большой разрыв между «подозреваю, что что-то не так» и реальным «что-то не так». Разберём типичные ошибки, которые люди делают при построении жизненных циклов и визуализации, а главное — как их исправить.

Зачем нужна визуализация

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

Например, официанту в кафе не нужна никакая доска со стикерами. У него есть посетители, бутербродики и кофе-машина. В принципе, топология его перемещений и работа вполне понятны.

Но в офисе невозможно сказать, чем занимается сотрудник. Если дети придут в кабинет посмотреть, чем занимается мама/папа, то они не смогут сказать ничего хорошего: «Мама/папа сидит, тыкает в кнопки в компьютере, разговаривает по телефону, переклеивает какие-то бумажки».

Таким образом, в мире нематериального производства нужен физический эквивалент умственной работы. И тут появляется её величество доска, которую, уверен, каждый из вас на каком-либо из мест работы строил, делал, либо как-то использовал.

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

Как сделать правильно

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

Кроме этого, производство XXI века отличает большая социальная составляющая. Каждый человек — это личность. Плюс в нашей сфере все люди очень умные. Это значит, что если им не понравится история, которую пытаются навязать, они будут её подрывать. Наверняка были истории, связанные с тем, что вы пытались собрать людей у доски на дейли-митинг, а они сопротивлялись этому, говорили, что и так всё знают.

Поэтому мои посылы к вам следующие:

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

Разберемся с конкретикой.

Буферные состояния

Одна из самых простых вещей, которая часто упускается — это буферные состояния.

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

Отсюда появляются буферные состояния. Часто на доске есть не просто Активность 1, Активность 2, Активность 3, а эти активности ещё разбиваются на подколонки, в которых указано, что активность или ещё идёт, или уже закончена, а следующая пока не началась.

Подзадачи

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

На схеме крупная фича (жёлтый стикер) разбита на подзадачи (зелёные стикеры). Между ними установлено отношение parent/child (родитель/ребёнок). Зелёный стикер — это работа, которая чаще всего распознается специалистом: «Я — аналитик, понимаю, что это такое и знаю, что надо с этим сделать». Жёлтый стикер — это то, что должно однозначно быть распознаваемо заказчиком.

Вот как это могут визуализировать люди:

Это типичные доски To do («Сделать»), In progress («В работе») и Done («Сделано»). На них нарисованы задачи. Доска слева разделена на горизонтальные составляющие, к каждой из которых прикреплён жёлтый стикер. Он замещает собой какую-то фичу, в рамках которой делаются какие-то подзадачки. Можно сделать наоборот, то есть так, чтобы каждый зеленый стикер обозначал этап работы. Таким образом, можно визуализировать рабочие элементы, однозначно распознаваемые заказчиком.

Вопрос в том, какой вид визуализации лучше использовать. И хотя оба вида показывают одно и то же — тот, что внизу слева, более удобен для команды. На нём видно, кто чем загружен. А доска сверху более удобна для заказчика, product-менеджера или project-менеджера. Так как на ней видно, как идут запросы заказчика, и понятно, когда работа будет завершена.

Портфель работ по продукту (когда много команд)

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

Но иногда попадается идиотизм.

Представим стандартный айтишный процесс. Сначала нужно проанализировать рабочий элемент. Потом поставить задачу. После этого начать разработку и тестирование. Ещё люди декомпозируют рабочий элемент на подзадачи (разработка, анализ и тестирование) и пытаются уместить и подзадачи, и этапы на одной доске. Получается, что задача на анализ зачем-то должна пройти этапы анализа, разработки и тестирования. Здесь задача аналитика висит в разработке:

Зачем? Это непонимание фундаментального принципа того, что визуализируется.

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

Инструменты для анализа

На типичной доске есть этапы, по которым работа идёт (АРБАЙЕН) или не идёт (ВАРТЕН), так как что-то ожидается.

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

Cами по себе подобные собранные данные можно использовать для улучшений.

Если поделить общее время, за которое делается запрос на время чистой инженерной работы, то получается метрика под названием «эффективность потока». Если взять какую-нибудь компанию, у которой эффективность потока выходит от 1 до 15%, то это значит, что работа больше стоит, чем идёт.

Чтобы работа шла, с объёмом времени, когда работа в застое, нужно что-то сделать.

Статус «заморожено»

Собранные данные ещё недостаточно точны. Во время работы бывает множество остановок. Например, вы начали делать какую-то работу, поняли, что надо задать вопрос заказчику. Пишете ему письмо — а он занят, ответит позже. Работа оказывается брошенной, продолжить нельзя.

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

В этот статус перемещается работа из любого этапа, там лежит и потом возвращается в любой другой этап.

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

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

Как это сделать? Чаще всего при визуализации используются блокеры.

Блокеры

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

В Atlassian Jira можно поступить по одному из вариантов:

Убрать поле «assignee». Это означает, что задача никому не назначена.
Использовать флаг в Jira как метку.

По-хорошему, надо собирать статистику о том, почему работа не идёт. На красных стикерах стоило бы записывать, по какой причине остановлена работа и какой нужен человек, чтобы это исправить. Когда этот блокер (красный стикер) убирается, надо записать, что проблема снята, то есть можно продолжать работу. Данные, которые на этом стикере записаны, надо не выкидывать, а куда-то сложить, потому что потом можно провести собрание и все задержки (красные стикеры) вывесить на флипчарт и кластеризовать. Можно даже посчитать суммарное время в большом столбце, а ещё сколько спрятано под каждым из классов проблем различных причин и почему работа останавливается. Потом адресно начинать улучшать процесс.

Но Jira из коробки не умеет собирать статистику.

Но голь на выдумку хитра. Можно с помощью бесплатного плагина для Jira написать скрипты, которые позволят собирать такую статистику.

Человек — не колонка

Если у вас работа выстроена таким образом, что во время активности №3 возникает блокировка (тестировщик выявляет проблему в изначальной постановке задачи), то, чтобы её снять, нужен человек с активностью №1 (аналитик должен прийти и поправить эту проблему). Получается, что люди уже не живут в рамках колонок. Человек не является колонкой. Колонка «разработка» — это не место в визуализации, где живут разработчики. Также тестировщики не живут в колонке «тестирование». Все живут в рамках одной доски.

А раз люди живут в рамках всей доски, то однозначно есть понимание того, чем лучше заняться каждому. Надо пройти по доске справа налево и посмотреть, где требуется внимание сотрудника. Почему начинаем справа? Потому, что чем правее, тем ближе к завершению. Иначе говоря, это более значимая для завершения проекта работа.

Но достаточно часто встаёт проблема:

Бывают слишком разные рабочие элементы, то есть сущности, которые отображаются на доске. У них могут быть слишком разные жизненные циклы. Как их можно совместить на одну доску?

Для этого есть инструменты. В тикетах Jira есть кнопка «View Workflow», если нажать на неё, то можно увидеть что-то похожее:

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

Здесь ключевая проблема в том, что жизненный цикл проектируется, исходя из того, как люди работу передают. Но многие используют, например, SCRUM и работают в кросс-функциональных командах с высокой социальной сплоченностью и взаимопомощью. Как поступать, когда есть отсылка к всяким T-shaped людям, специалистам разной функциональной направленности, которые могут одновременно работать над одной и той же задачей?

Каждый этап процесса как этап накопления знаний

В реальности, если посмотреть на процесс работы как на процесс накопления знаний, то получается такая картина:

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

Идея о том, что интенсивность работы людей меняется во времени, не нова. Давным-давно в Rational Unified Process даже проводились исследования, как изменяются процессы разной функциональной направленности с течением времени на разных фазах проектов.

Накопление знаний

Этот процесс изменения можно отобразить на графике:

Здесь по вертикали — объём накопленных знаний, а по горизонтали — процент реализации запроса от 0 до 100%.

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

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

Самое прикольное, что если смотреть на процесс как на процесс накопления знаний, мы не можем знания «раззнать». Если я это знаю, то это не стереть. Например, очень часто в наших Workflow при нахождении дефекта тестировщик возвращает работу разработчику. Но это не значит, что мы начинаем заново разработку. Тестировщик выявляет некий блокирующий фактор, который не даёт дальше пропустить запрос через gate тестирования . А разработчик должен прийти и исправить это, чтобы тестировщик мог продолжить свою работу.

Получается так, что получение знаний — на самом деле линейный процесс.

Естественно, этот процесс может ветвиться, но циклов не создаёт. Исходя из этого, на доске чаще всего всё движется слева направо.

Перейдём к финальной истории.

Совмещение не совмещаемого

Представим ситуацию: в команду сыпятся запросы типа «сделать выгрузку из БД», «провести консультацию». Как это всё совместить?

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

Сложные моменты

Хотя доска чаще всего визуализирует линейный процесс, бывают сложные моменты.

Неупорядоченные активности

В частности, этапы работы могут быть неупорядоченными. Например, прилетает первая фича, для которой надо сделать фронтенд и бэкенд. Во второй фиче надо вначале — бэкенд, потом — фронтенд, а в третьей фиче — их надо сделать одновременно. Как это визуализировать?

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

Как проводить собрания с такой доской

Типичный паттерн, когда вы собираетесь командой или командами у такой доски и по очереди опрашиваете каждого, кто что сделал вчера и что будет делать сегодня, не работает при решении неупорядоченных активностей. Эта хаотичная история не позволяет сфокусировать людей на то, чтобы что-то завершить. Даже если вы работаете в SCRUM-команде, и ваша доска сложнее, чем «To do, In progress, Done», то формат SCRUM-митинга всё же должен быть другой.

Ведущий собрания должен идти по доске справа налево, брать некоторый стикер и задавать вопросы:

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

В конце можно задать ещё суммирующий вопрос:

Есть ли какая-то информация, которой стоит между собой поделиться?

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

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

Необязательные активности

Активности могут быть не просто неупорядоченными, но и необязательными. Есть фичи, на которые обязательно сделать фронтенд и бэкенд, но для одной требуется разработка на iOS, для второй только на Android, а для третьей на iOS и Android.

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

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

Резюме

— Визуализация не диктует правила работы, а лишь отражает, как идёт работа.

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

— Визуализация для каждого кейса уникальна и копипастить её не стоит.

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

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

Если бы зрелость можно грейдировать по разным уровням, то выходом на определенный уровень мог бы быть барьер, который называется copy organizational structure blueprint.

Представьте, вы пришли на референс-визит в одну компанию, видите, что там ребята сидят параллельно-перпендикулярно, а вы — циклическими кругам и, думаете: «давайте сделаем CTRL+C/CTRL+V этой системы к нам!». В таком случае вы начинаете играть в басню Крылова «Квартет»: «А вы, друзья, как не садитесь, всё в музыканты не годитесь». Поэтому растите свой собственный процесс в рамках зоны компетенций, которая вам выделена.

— Визуализируйте работу, однозначно распознаваемую заказчиком.

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

— Визуализируйте не то, как люди передают работу друг другу, а то, как идёт накопление знаний.

—Люди не живут в колонках, они живут на всей доске.

Люди перемещаются по доске и приходят туда, где их внимание требуется больше всего. Даже сама по себе метафора перемещения людей по доске предполагает кросс-функциональность.

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

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

— Ярко видимыми на доске вещами являются горизонтальные дорожки и цвета стикеров.

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

Открылась продажа билетов на конференцию https://teamleadconf.ru/ на 27 и 28 февраля в Москве. В программе тренд-темы про текучку кадров, накопление и передачу экспертизы, замену и поиск лидеров.

Workflow и визуализация процессов: как сделать правильно и не выстрелить себе в ногу