Канбан. Альтернативный путь в Agile - [89]

• Предстоит еще много работать над передовыми стратегиями и тактиками управления рисками в Канбане – это станет темой следующей книги.

Глава 20 Управление проблемами и правила эскалации

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

Я заметил, что некоторые новички в использовании Канбана считают заблокированные задачи бутылочными горлышками. Это неверно. Заблокированная задача действительно образует затор, ограничивающий поток. Но он не относится к бутылочным горлышкам, описанным в главе 17, так как это не ресурс ограниченной мощности и не ресурс с ожиданием доступа. Точно так же пробка – это вовсе не бутылочное горлышко. Чтобы возобновить поток жидкости из бутылки, надо попросту вынуть пробку.

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

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

Управление проблемами

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

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

Рис. 20.1. Розовая карточка, описывающая блокирующую проблему (или препятствие) и прикрепленная к пользовательскому запросу на изменение, которое эта проблема затрагивает

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

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

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

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

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

Эскалация проблем

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