Дэвид Андерсон - Канбан. Альтернативный путь в Agile

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

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

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

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

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

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

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

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

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

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

Организация должна создать и согласовать механизм эскалации проблем. Без него поддержание и восстановление потока после блокировки усложняется.

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

Как уже говорилось, проблемы нужно фиксировать как задачи и выделять в собственный тип. Для визуализации проблем обычно используют розовые и красные карточки или стикеры (рис. 20.2). Дата начала, дата окончания, ответственный сотрудник, описание проблемы и ссылки на заблокированные задачи и пользовательские запросы – вот минимальный набор требований к визуализации проблем (рис. 20.3).

Рис. 20.2. Доска, на которой показано несколько блокирующих проблем, влияющих на различные функции

Рис. 20.3. Кумулятивная диаграмма потока с наложенным графиком проблем

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

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