Дэвид Андерсон - Канбан. Альтернативный путь в Agile
Важно указать причину блокировки и считать разблокирование приоритетной задачей, даже если это создает ложную нагрузку. К задаче имеет смысл привязывать отдельную сущность – «проблему». «Проблемы» визуализируются, например, при помощи розовых карточек (рис. 20.1). Им должен быть присвоен номер и определен ответственный исполнитель – обычно это менеджер проекта.
Рис. 20.1. Розовая карточка, описывающая блокирующую проблему (или препятствие) и прикрепленная к пользовательскому запросу на изменение, которое эта проблема затрагивает
Когда сотрудник, занимающийся пользовательским запросом, не может продолжить работу, он должен отметить задачу как заблокированную, прикрепить к ней розовую карточку с перечнем причин блокировки и создать «проблему» в электронной системе управления задачами. «Проблема» должна быть связана с исходной задачей (рис. 20.1). Вот некоторые примеры: двусмысленность требований (причем эксперт, который мог бы немедленно устранить двусмысленность, недоступен); требуется создание среды, а инженер, который может этим заняться, недоступен; для работы с задачей нужен узкий специалист, но он болен, находится в отпуске или отсутствует в офисе по иным причинам.
Как уже говорилось в главе 7, тема поддержания равномерного потока должна быть основной на ежедневных встречах команды. Команде следует сосредоточиться на обсуждении блокировок и прогресса в решении проблем. Особое внимание нужно уделять розовым карточкам. Задавайте вопросы о том, кто работает над устранением проблемы и каковы их успехи, нужно ли эскалировать проблему и если да, то кому.
Простаивающих членов команды следует мотивировать на то, чтобы они добровольно взялись устранять проблемы, коллективно обсуждали их и помогали решать, тем самым восстанавливая равномерность потока. Команда с мощной самоорганизацией именно так и будет действовать, люди сами захотят помочь. Но если такой самоорганизации пока нет, то менеджеру проекта придется назначить членов команды для решения проблем.
Проблемы нужно фиксировать, как и все остальные задачи. В информацию для их отслеживания необходимо включить даты начала и окончания работы и ссылку на все затронутые пользовательские запросы. При этом одна проблема может блокировать несколько других задач. Это еще одна причина, чтобы учитывать проблемы как независимые задачи и создать отдельный тип задач – «проблема».
Выбирая электронный инструмент для визуализации канбан-системы, убедитесь, что он позволяет оформлять проблемы как задачи или настроен так, чтобы можно было создать новый тип задачи – «проблему», и задать его отражение в виде розовых или красных карточек.
Эскалация проблем
Если команда не может самостоятельно справиться с ситуацией или для этого требуется другая сторона, которая в данный момент недоступна, то проблему нужно передать выше по инстанции – старшему руководителю или в другой отдел.
Организация должна создать и согласовать механизм эскалации проблем. Без него поддержание и восстановление потока после блокировки усложняется.
Налаженный механизм эскалации – это задокументированные правила и процедуры передачи проблем. В главе 15 говорилось о том, как эффективна совместная разработка организационных правил. Правила эскалации тоже следует выработать совместно, и необходим консенсус между всеми подразделениями, участвующими в цепочке создания ценности. Кроме того, правила эскалации должны быть известны всем работникам, а документ (или сайт), где они описываются, – доступен всем членам команды. Никакой двусмысленности в отношении эскалации проблемы не допускается. Потратив время на определение способов эскалации и создание соответствующих правил, команда обретает понимание того, куда адресовать проблемы. Это уменьшает время принятия решения, кому именно эскалировать проблему, и создает у этих вышестоящих сотрудников понимание, что они непосредственно участвуют в процессе разрешения проблем. Руководители должны взять ответственность за решения на себя. Это поможет поддерживать поток и минимизировать расходы из-за простоя (или компенсировать расходы быстрой поставкой).
Учет проблем и отчетность по ним
Как уже говорилось, проблемы нужно фиксировать как задачи и выделять в собственный тип. Для визуализации проблем обычно используют розовые и красные карточки или стикеры (рис. 20.2). Дата начала, дата окончания, ответственный сотрудник, описание проблемы и ссылки на заблокированные задачи и пользовательские запросы – вот минимальный набор требований к визуализации проблем (рис. 20.3).
Рис. 20.2. Доска, на которой показано несколько блокирующих проблем, влияющих на различные функции
Рис. 20.3. Кумулятивная диаграмма потока с наложенным графиком проблем
Полезными для учета могут оказаться также трудозатраты по решению проблемы, история назначения сотрудников, информация о пути эскалации проблемы, предполагаемое время разрешения, оценка негативного влияния и предлагаемые варианты устранения первопричин, препятствующие повторному возникновению проблемы.
Хотя розовые карточки на доске наглядно демонстрируют, сколько задач заблокировано на данный момент, полезно также фиксировать проблемы и сообщать о них иными способами. Кумулятивная диаграмма потока с указанием количества заблокированных задач – хороший визуальный индикатор возможностей организации по оперативному решению проблем.
Тренд по количеству заблокированных задач показывает, насколько компания развила способность к анализу и устранению первопричин – умению ликвидировать вариации с особыми причинами. Табличная форма отчета о текущих проблемах, назначенных сотрудниках, статусе, предполагаемой дате решения проблем, затронутых задачах и потенциальном негативном влиянии на бизнес тоже может оказаться полезной в крупных проектах.
Такие отчеты следует готовить к операционному обзору, на котором выделяют время для обсуждения возникновения и становления возможностей организации в области управления проблемами и их решения, а также анализа и устранения первопричин. Организация должна понимать вред избыточной нагрузки, возникающей из-за блокирующих проблем. Это позволит принимать объективные решения о возможностях совершенствования и осознать вероятные преимущества инвестирования в устранение первопричин для предотвращения вариаций с особыми причинами.
Выводы
• Канбан-системы должны иметь особый тип задач – «проблема», который используется для учета проблем, блокирующих другие задачи, создающие ценность для потребителей.
• В обиход вошло использование розовых или красных стикеров на стене карточек для визуализации проблем.
• Розовые карточки прикрепляются к заблокированным задачам.
• Способность организовать эффективный процесс идентификации и устранения проблем необходима для поддержания равномерности потока.
• Заблокированные задачи и проблемы – это не бутылочные горлышки. Их нужно считать вариациями с особыми причинами, а не ресурсами ограниченной мощности или ресурсами с ожиданием доступа.
• Управление проблемами должно стать главной темой ежедневных встреч команд.
• Своевременная эскалация проблем – неотъемлемая часть умения управлять ими.
• Правила эскалации должны быть четко определены и задокументированы, а члены команд – иметь к ним доступ.
• Правила эскалации гораздо эффективнее, если совместно разработаны всеми подразделениями, участвующими в цепочке создания ценности.
• Проблемы должны фиксироваться электронно.
• Отчеты на основе электронных данных облегчат повседневное управление проблемами и их решение в крупных проектах.
• Использование кумулятивной диаграммы потока с наложенным графиком проблем позволяет визуализировать развитие способностей к управлению проблемами и их решению и к анализу и устранению первопричин.
Благодарности
Каждая изданная книга – это результат серьезных усилий по координации и управлению проектом, в которое вовлечена целая команда, и роль автора здесь ограниченна. И эта книга не вышла бы в свет без упорного труда Дженис Линден-Рид и Вики Роулэнд. Я хочу сказать им спасибо за безграничное терпение и настойчивость, благодаря которым рукопись попала в печать несмотря на жесткий дедлайн (и высокие расходы из-за отсрочки).
Хотелось бы также упомянуть Дональда Рейнертсена, который предложил попробовать Канбан и предоставил площадку для публичного выступления по этому поводу. Спасибо ему за теплые слова в предисловии и за создание жизнеспособного сообщества в Lean Software & Systems Consortium.
