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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Учет проблем и отчетность по ним

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

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

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

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

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

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

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

Выводы

• Канбан-системы должны иметь особый тип задач – «проблема», который используется для учета проблем, блокирующих другие задачи, создающие ценность для потребителей.

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

• Розовые карточки прикрепляются к заблокированным задачам.

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

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

• Управление проблемами должно стать главной темой ежедневных встреч команд.

• Своевременная эскалация проблем – неотъемлемая часть умения управлять ими.

• Правила эскалации должны быть четко определены и задокументированы, а члены команд – иметь к ним доступ.

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

• Проблемы должны фиксироваться электронно.

• Отчеты на основе электронных данных облегчат повседневное управление проблемами и их решение в крупных проектах.

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