Топ за месяц!🔥
Книжки » Книги » Домашняя » Канбан. Альтернативный путь в Agile - Дэвид Андерсон 📕 - Книга онлайн бесплатно

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

281
0
На нашем литературном портале можно бесплатно читать книгу Канбан. Альтернативный путь в Agile - Дэвид Андерсон полная версия. Жанр: Книги / Домашняя. Онлайн библиотека дает возможность прочитать весь текст произведения на мобильном телефоне или десктопе даже без регистрации и СМС подтверждения на нашем сайте онлайн книг knizki.com.

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 70 71
Перейти на страницу:
Конец ознакомительного отрывкаКупить и скачать книгу

Ознакомительная версия. Доступно 15 страниц из 71


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


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

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

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

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

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

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

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

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

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

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

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


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


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


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

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

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

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

Выводы

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

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

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

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

Ознакомительная версия. Доступно 15 страниц из 71

1 ... 70 71
Перейти на страницу:

Внимание!

Сайт сохраняет куки вашего браузера. Вы сможете в любой момент сделать закладку и продолжить прочтение книги «Канбан. Альтернативный путь в Agile - Дэвид Андерсон», после закрытия браузера.

Комментарии и отзывы (0) к книге "Канбан. Альтернативный путь в Agile - Дэвид Андерсон"