Движение стикеров назад

В соцсетях вы наверняка сталкивались и с вопросами, и с ответами на вопрос: “Можно ли в Канбане двигать стикеры назад?” И часто ответом является слово “нет”, но это неверный ответ и в данной статье мы разложим по полочкам все, что касается движения стикеров назад.

Для кратко разберем, что такое "движение стикера назад" - это прецедент при котором:

1. На каком-то этапе работы, выясняется, что продолжать работу на этом этапе нельзя;
2. Надо привлечь к решению проблемы специалиста, который работал на каком-то из предыдущих этапов;

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

Самый простой пример: тестировщик обнаруживает дефект, при котором нельзя продолжать тестирование пока дефект не будет исправлен. Стикер перемещается из этапа “Тестирование” в этап “Разработка”, где нужный специалист должен будет исправить дефект.

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

Первое, что можно сказать о производственной системе, в которой есть передвижение стикеров назад - это то, что там процесс выстроен не по принципу накопления знаний, а по принципу того, как люди передают работу друг другу. Условно это можно описать так: у вас есть этап работы “Анализ” и на нем работают аналитики, этап работы “Разработка” и на нем работают разработчики и этап “Тестирование” на котором работают тестировщики. Если тестировщик, выполняя свою работу по запросу находит проблему он передает работу в руки разработчику на этап “Разработка” или аналитику на этап “Анализ”. В любом случае работа покидает свой этап при передаче ее в другие руки, а эти руки связаны с этапами. Как результат мы получаем систему, в которой люди привязаны к колонкам на доске и если какая-то задача находится у разработчика, это значит, что она находится на этапе “Разработка”. Возникает вопрос - а проблема ли это? Это может быть проблемой и препятствием для использования практик.

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

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

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

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

• А эти недостатки - это разовое явление или систематическое?
• А прецеденты по решению этих недостатков влияют на время производства драматически или это мелочи, которыми можно пренебречь?

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

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

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

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

Самое сладкое оставим на конец статьи. Если вы использует практику WIP-лимитов или собираетесь ее внедрить, то у вас будут проблемы с возвратом назад. Дело в том, что в колонке, в которую вы пытаетесь переместить стикер может просто не быть емкости и вы по сути нарушаете договоренность, которую сами же и заключали. Можно встретить лайфхак/оправдание в виде правила: “WIP-лимит защищает этап работы от проникновения слева а не справа”, это позволит вам держать свою же договоренность в силе, да и перемещение стикера не увеличит общее количество работы в производственной системе, поэтому какого-то грандиозного ухудшения по метрикам мы не увидим, но визуально у нас будет на доске беспорядок. Движение стикеров назад визуально нарушает ту визуальную гармонию, которой мы хотим добиться, но это можно одновременно засчитать и в плюс, т.к. подсветка нарушения WIP-лимита при прилете работы справа будет сигнализировать о том, чтобы специалисты сфокусировались на вернувшейся работе, т.е. это позволит решить проблему фокуса описанную в предыдущей главе. В общем - движение стикера назад можно считать не препятствующим использованию WIP-лимитов и даже решающим проблему фокуса, но визуально это будет смотреться неприглядно.

Итак, никто вам не запрещает двигать стикеры назад, но только помните о том, что у вас:

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