При использовании первого метода к некоторым единицам работы прикрепляются дополнительные, более мелкие оранжевые карточки. На них пишется имя специалиста – например, «Сэнди, архитектор корпоративных данных». Даже при самом низком уровне вмешательства такой простой визуализации работы специалиста, не выделенного специально для этого проекта, достаточно, чтобы скоординировать его деятельность. Если одно и то же имя появляется на нескольких карточках, может возникнуть вопрос, как этот человек собирается одновременно справляться с множеством заданий. Возникает дискуссия, после которой возможна смена тактики (нужно ли, чтобы вся работа проходила через одного человека?) или переход на следующий уровень.
Следующий уровень предполагает понимание того, что общие ресурсы не будут доступны по первому требованию. Визуализируется это так: элементы, требующие внимания специалиста (оранжевые карточки), помечаются как блокированные, пока он не начнет активно над ними работать. Это ведет к началу работы над проблемой, которая приводит к высвобождению специалиста, участвующего сразу в нескольких проектах. Кроме того, это сигнал руководству, что доступность данного ресурса может оказаться проблематичной и стать потенциальным бутылочным горлышком.
Высший уровень управления общими ресурсами – это создание собственной канбан-системы для данного ресурса. Например, собственную канбан-систему может получить архитектура корпоративных данных, тестирование взаимодействия с пользователем, безопасность программ и т. д. Каждая команда или специалист независимо друг от друга анализирует спрос на свою работу и устанавливает типы рабочих единиц на основе источника запроса, а также классы обслуживания на основе приоритетности и требуемого ответа. После анализа спроса устанавливаются правила распределения мощности.
На этом уровне возникает архитектура для обслуживания запросов на разработку самих программ. Каждая группа внутри организации предлагает собственный набор сервисов, которые реализуются в виде соглашений об уровне обслуживания для различных классов обслуживания и типов единиц работы. После этого клиенты общих ресурсов подают рабочие запросы, фиксируя их в бэклоге. Эти запросы поступают в очередь и оттуда вытягиваются для обработки, как и описано в этой книге. Если запросы от конкретного клиента обрабатываются недостаточно быстро, то может начаться обсуждение, удачно ли спроектирована система и не изменить ли правила распределения мощности и назначения класса обслуживания. Это может даже послужить основанием для перегруппировки или дополнения рабочего состава.
Выводы
• Крупные проекты должны выполняться в соответствии с ключевыми принципами Канбана.
• WIP-лимиты, каденция приоритетов, каденция релизов и классы обслуживания остаются полезными и в крупных проектах.
• Крупные проекты обычно имеют иерархические требования, эти уровни иерархии следует моделировать при помощи типов единиц работы.
• Обычно команды отслеживают два верхних уровня иерархии требований на стене карточек и задают WIP-лимиты на одном или обоих уровнях.
• Верхний уровень требований, как правило, моделирует клиентские и рыночные требования, составляющие неделимые элементы, которые потенциально могут быть выпущены отдельным релизом.
• Второй уровень требований обычно имеет клиентоцентрический характер и анализируется так, чтобы требования были детализированными и имели примерно одинаковый размер.
• Этот второй уровень детализированных требований облегчает рабочий поток, так как снижает вариативность в вытягивающей канбан-системе.
• Чтобы визуализировать оба отслеживаемых уровня требований, потребуется двухуровневая стена карточек.
• Популярный метод демонстрации иерархии и облегчения задания WIP-лимитов – так называемые плавательные дорожки.
• Крупные WIP ограничиваются количеством «плавательных дорожек».
• Детализированные WIP при желании можно ограничить на каждой «плавательной дорожке».
• Как правило, на каждую «плавательную дорожку» назначаются небольшие межфункциональные команды.
• Спрос на общие ресурсы можно визуализировать при помощи небольших стикеров, прикрепляемых к обычным рабочим элементам.
• Необходимость ожидания общих ресурсов можно подчеркнуть при помощи стикеров блокирования (в нашем случае розовых), прикрепленных к исходным карточкам рабочего элемента.
• Общие ресурсы должны разработать собственные канбан-системы.
• Сеть канбан-систем для общих ресурсов в портфеле проектов можно считать архитектурой для обслуживания запросов на разработку ПО.
Глава 14
Операционный обзор
До совещания
Половина восьмого утра, вторая пятница марта 2007 года. Я пришел на работу так рано, потому что сегодня у нас в отделе четвертый ежемесячный анализ производственного процесса. Со мной Рик Гарбер, менеджер нашей группы процессов разработки ПО. Рик будет координатором совещания – он отвечает за повестку. Сейчас он распечатывает раздаточный материал для сегодняшнего анализа, который состоит примерно из 70 слайдов презентации в PowerPoint. Когда он заканчивает, мы направляемся в Harbor Club в деловой части Сиэтла с коробкой раздаточного материала на сто человек. Совещание назначено на 8:30 утра, но завтрак подается с восьми. Приглашены все сотрудники моей организации и компании моего коллеги Эрика Арнольда. Однако поскольку некоторые из них работают в Индии, другие – в других штатах США, а кое-кто не может посетить совещание по личным причинам, присутствует обычно человек восемьдесят.
Приглашены также мой босс, директор Corbis по информационным технологиям, и другие представители старшего руководства – наши партнеры по цепочке создания ценности. Среди членов внешних команд больше всего представителей отдела эксплуатации сетей и систем, которым руководит мой коллега Питер Тутак. Это и неудивительно, ведь им предстоит восстанавливать системы и устранять ошибки, поэтому наши промахи скажутся прежде всего на них. Они также подвергаются наибольшему влиянию, когда мы выпускаем новые релизы. Поэтому они активно участвуют в совещаниях.
Группа начинает собираться, все стараются успеть к завтраку. Зал находится на верхнем этаже сиэтлского небоскреба, откуда открывается прекрасный вид на город, гавань, пирсы и Эллиотт-Бэй
[8]. В зале стоят круглые столы, за каждым – от шести до восьми человек. В одном конце зала – прожектор и кафедра. Рик действует в строгом соответствии с расписанием. Каждому выступающему дается примерно восемь минут, чтобы показать свои четыре-пять слайдов. Предусмотрены несколько отрезков времени на случай непредвиденных задержек, вызванных вопросами и обсуждениями. Я начинаю совещание с коротких вступительных замечаний: прошу всех мысленно вернуться к концу января и вспомнить, чем мы тогда занимались. Я напоминаю всем, что мы должны сейчас проанализировать работу организации за февраль. Рик подобрал отличную картинку из архивов компании, которая символизирует основную тему месяца и помогает вспомнить о том, чем мы тогда занимались.
