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

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

При использовании первого метода к некоторым единицам работы прикрепляются дополнительные, более мелкие оранжевые карточки. На них пишется имя специалиста – например, «Сэнди, архитектор корпоративных данных». Даже при самом низком уровне вмешательства такой простой визуализации работы специалиста, не выделенного специально для этого проекта, достаточно, чтобы скоординировать его деятельность. Если одно и то же имя появляется на нескольких карточках, может возникнуть вопрос, как этот человек собирается одновременно справляться с множеством заданий. Возникает дискуссия, после которой возможна смена тактики (нужно ли, чтобы вся работа проходила через одного человека?) или переход на следующий уровень.

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

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

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