«Почему так долго?» Откуда появляются заторы в задачах и как их устранить

Даже если вы знаете, что отвечать на вопрос менеджера: «Когда будет готова задача?». Он еще обязательно спросит: «А почему так долго?». В статье обсудим, почему появляются заторы в задачах, как их обнаружить и эффективно устранить, и чем здесь будет полезна Канбан-доска.

В одном из прошлых материалов мы говорили о том, как прогнозировать сроки выполнения задач с вероятностью 80-90%. Но это только полдела. Скорее всего, в ответ на вашу уверенную фразу «с вероятностью 80% эта задача будет готова через 3 дня» вы услышите второй из топ-10 любимых вопросов заказчиков: «А почему так долго?».

Ну, или одну из его вариаций:

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

Давайте разбираться.

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

Давайте рассмотрим набор характеристик, которые определяют любой тип работы и влияют на распределение времени:

1. Любая работа состоит из какого-то набора действий или этапов работы (workflow), необходимых для ее завершения.

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

3. Задержки между этапами. К сожалению, не бывает так, что только передали следующему специалисту задачу, и он тут же начал ее делать. Всегда есть какие-то задержки.

Совокупность всех этих факторов характеризует то или иное распределение по времени.

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

С точки зрения теории ограничений систем Элияху Голдратта (кстати, очень рекомендую к прочтению его книги «Цель» и «Цель-2»), узкое место – это некий ресурс, производительность которого меньше или равно спросу. Другими словами, мы пытаемся протолкнуть в него больше задач, чем он способен «переварить». А понять, где именно находится это ограничение, очень просто по следующим признакам:

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

2. Работа в этом месте постоянно накапливается, часто откладывается и редко доводится до конца.

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

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

Как Элияху Голдратт предлагал работать с этим ограничением? Он сформулировал 3 правила:

Предлагаю посмотреть, как всё это выглядит, на конкретном примере.

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

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

Очевидно, что такая стратегия малоэффективна: добавляя ресурсы на проблемном участке, мы просто перемещаем существующее ограничение куда-то в другое место.

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

Скорее всего, в этот момент вы думаете: а можно ли как-то оптимизировать все эти процессы, не добавляя новых ресурсов? Можно. И именно об этом говорит теория ограничений Элияху Голдратта.

И для начала давайте посмотрим, как устроен этап, на котором возникает затор, образуется узкое место. Действительно ли он работает на 100% своей эффективности, или есть что-то внутри этого этапа, что нуждается в оптимизации?

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

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

В нашем случае получился следующий набор этапов:

Обратите внимание на этапы утверждения и рутинных проверок по чек-листу. Чем в этот момент занята команда?

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

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

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

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

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

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

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

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

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

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

Автор: Василий Савунов, Agile-коуч и эксперт ScrumTrek