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

Эта идея известна в сфере программного обеспечения и IT-систем, в частности, при исправлении ошибок, особенно возникших в продуктивной среде. Мы разделяем ошибки по степени серьезности (воздействия) и приоритету (срочности). Очень серьезные и высокоприоритетные ошибки устраняются немедленно. Они получают другой, более высокий класс обслуживания по сравнению с остальными задачами. Чтобы устранить серьезную ошибку в продукте, мы откладываем в сторону другую работу, привлекаем максимальное количество людей и часто составляем отдельные планы для срочной отладки, патча или релиза, разрешающих проблему.

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

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

Классы обслуживания обычно определяются на основе ожидаемого экономического эффекта. Стикеры разного цвета, каталожные карточки или талоны назначаются для каждого класса и четко идентифицируют класс обслуживания для любого запроса, как показано на рис. 11.1. Отдельные «плавательные дорожки» на стене карточек определяют соотнесенность с классом обслуживания.

Рис. 11.1. Стена карточек с цветными карточками, соответствующими классам обслуживания

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

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

Ускоренный класс обслуживания (другое название – «серебряная пуля») хорошо известен в области производства. Типичен такой сценарий: продажники пытаются выполнить квартальный план, а у клиента есть бюджет, который требуется потратить к концу финансового года. Клиент долго откладывает решение о приобретении, но наконец делает выбор как раз к концу текущего финансового года. Заказ размещается, но возможен только в случае поставки до дедлайна. Производитель соглашается с ценой и количеством и принимает заказ, который должен быть выполнен, доставлен и представлен к оплате ранее последнего дня квартала. Такой заказ обычно поступает в работу через офис вице-президента по региональным продажам и снабжается запросом на ускорение работы в связи с жесткими временными рамками и своей ценностью.

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

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

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

В середине февраля 2007 года в мой офис пришел разработчик и спросил, знаю ли я о проблеме с сервисной платформой, которую мы использовали для работы с кредитными карточками. Я ответил «нет», и он объяснил ситуацию. Судя по всему, поставщик обнаружил, что поддерживать кодовую базу слишком сложно, поскольку разработчики добавляли все новые функции к платформе – это обычное дело. Чтобы удовлетворить спрос на новые функции в 2006 году, они полностью заменили платформу новой системой, имевшей совершенно другой интерфейс прикладного программирования (API).

Об этом проинформировали всех клиентов и за 15 месяцев предупредили, что прежняя система будет выключена после 31 марта 2007 года. Иными словами, если не обновить системы для использования новой платформы, то 1 апреля 2007 года мы будем отрезаны от интернет-торговли. Это влекло за собой существенные неудобства для бизнеса, который большую часть выручки получал от продаж в интернете, не говоря уже об ощущениях владельца фирмы. У нас оставалось всего шесть недель, чтобы внести необходимые изменения и выпустить новый код. Карточка на эту работу поступила в нашу канбан-систему. Дополнительная информация на карточке должна была привлечь внимание к затратам и ущербу от опоздания, а также позволить команде самостоятельно ускорить обработку элемента и обеспечить своевременное выполнение задания.

С таким запросом мы сталкивались не впервые. До этого поступил запрос на интеграцию IT-систем от приобретенной нами компании. Назначенная «фиксированная дата» была выработана исходя из обоснования приобретения, где указывалась существенная экономия с 1 февраля того же года.

Судя по всему, возникает своего рода тезис, или шаблон: некоторые запросы связаны с крупными контрактными обязательствами, другие – с нормативными требованиями (обычно исходящими от федерального правительства), а еще часть – со стратегическими инициативами, например с приобретением другого бизнеса.

Подобные запросы были связаны с серьезными затратами на отсрочку, прямыми или косвенными, которые обычно укладывались в одну из двух категорий: 1) наступал день, когда компания подвергалась штрафу (или иному финансовому наказанию) – прямая, конкретная потеря денег из собственного кармана, связанная с нормативными обязательствами или сроками, прописанными в контракте; 2) требовалось прекратить какую-то деятельность, например продажу определенного вида товара или работу в какой-либо сфере юрисдикции, вплоть до выполнения требований. Второй тип расходов относится к косвенным – это расходы по упущенной возможности, потенциально утраченной выручке за период отсрочки. Оба типа отражены на рис. 11.2.

Рис. 11.2. Два вида расходов из-за отсрочки для класса обслуживания «фиксированная дата поставки»

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

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

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

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

В 2005 году Microsoft запустила SQL Server 2005 – последнюю версию своего сервера баз данных RDBMS. Версия 2005 года сменила версию 2000 года, которая отслужила свое. От Microsoft как от ведущего игрока индустрии требовалось поддерживать продукты на протяжении десяти лет после их ввода в эксплуатацию. Таким образом, поддержка SQL Server 2000 должна была продолжиться до 2010 года. Это давало клиентам пятилетнюю отсрочку на замену кода, несовместимого с новыми версиями платформы, – до 2005-го или даже 2010 года. Следовательно, в 2005-м или 2006 году замена кода базы данных – хранимые процедуры, код хранения объектов – не первоочередная задача. Издержек из-за отсрочки в эти годы не произойдет. Но со временем, пока код не изменяется, возможные издержки нарастают. Становится все сложнее работать с другими продуктами, поскольку их обновленные версии требуют обязательной совместимости с SQL Server 2005. Все больше факторов побуждают перейти на новую платформу. К 2009 году вопрос стал неотложным, поскольку вскоре Microsoft собиралась прекратить поддержку предыдущего продукта, и если не произвести обновление, то бизнес останется со старыми машинами и не поддерживаемыми больше операционными системами и соответствующей инфраструктурой. Если это слишком большой риск, то код необходимо обновить. Проблема замены платформы встречается довольно часто: команды разработки ПО сталкиваются с ней постоянно. Всегда есть желание сразу начать работу и вовремя ее завершить, но необходимость произвести обновления обычно отступает перед более срочными или важными задачами. Иными словами, замена платформы, которая обладает сравнительно низкими непосредственными издержками из-за отсрочки, отходит на второй план из-за заданий, отсрочка по которым ведет к более крупным и непосредственным издержкам.

Можно предложить класс обслуживания, который позволит быстро начинать такую работу, или ресурсы, чтобы убедиться, что задание завершено. Но гарантий по времени может и не быть. К тому же это как раз такая работа, которую легко отложить в сторону, если появляются более срочные задачи. Чтобы иметь резервы для обработки ускоренного запроса, должна быть работа с низкой стоимостью отсрочки, которая откладывается в сторону при поступлении ускоренного запроса. И этот резерв как раз обеспечивается элементами нематериального класса.

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

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

• Для ускоренных запросов используются белые карточки.

• Разрешается обработка только одного ускоренного запроса за раз. То есть ускоренный класс обслуживания имеет WIP-лимит 1.

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

• На любой стадии рабочего процесса разрешается превышение WIP-лимита с целью приема ускоренного запроса. Для ускоренного запроса мощность не оставляется в резерве.

• При необходимости планируется специальный (внеочередной) релиз, чтобы как можно быстрее реализовать ускоренный запрос.

• Для элементов с фиксированной датой поставки используются фиолетовые карточки.

• Требуемый дедлайн записывается в правом нижнем углу карточки.

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

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

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

• Элементы с фиксированной датой поставки должны соотноситься с WIP-лимитом.

• Элементы с фиксированной датой поставки поступают в очередь на релиз, когда они закончены и подготовлены к релизу. Они выпускаются в соответствии с календарем релизов непосредственно перед дедлайном.

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

• Для элементов стандартного класса обслуживания используются желтые карточки.

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

• Для элементов стандартного класса, вытянутых в систему, используется алгоритм FIFO (в порядке поступления). Обычно когда есть выбор, член команды вытягивает самый старый элемент стандартного класса, если отсутствуют элементы ускоренного класса или с фиксированной датой поставки.

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

• Оценка для определения количества усилий или времени выполнения не проводится.

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

• Элементы стандартного класса обычно реализуются в течение x дней после выбора, выполнение в срок составляет m процентов.

Типичное соглашение об уровне обслуживания для стандартного класса может включать 30-дневное время выполнения с 80 %-ным выполнением в срок. Иными словами, за 30 дней должны быть выполнены четыре запроса из пяти.

• Для элементов нематериального класса обслуживания используются зеленые карточки.

• Расстановка приоритетов среди элементов стандартного класса обслуживания производится по заранее оговоренному механизму – например, голосованием. Они обычно поступают в очередь на основании оценки долгосрочного негативного воздействия или издержек из-за отсрочки.

• Элементы нематериального класса вытягиваются в систему по ситуации. Члены команды могут выбрать любой элемент нематериального класса независимо от даты его поступления, если элементы более высоких классов отсутствуют.

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

• Оценка для определения количества усилий или времени выполнения не проводится.

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

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

• В случае с элементами нематериального класса предоставление соглашения об уровне обслуживания может оказаться необязательным. Если оно все же необходимо, то должно иметь менее жесткие ограничения, чем предлагаемые для элементов стандартного класса: например, 60 дней с 50 %-ным выполнением в срок.

В приведенном примере целевое время выполнения для стандартного класса обслуживания установлено и составляет, например, 28 дней (4 недели). Идея задавать целевое время выполнения вместе с показателем выполнения в срок – это альтернатива индивидуальному подходу ко всем элементам, который предполагает оценку и обязательство успеть к определенному моменту для каждого из них. Соглашение об уровне обслуживания позволяет избежать дорогостоящих (например, оценки) и не пользующихся доверием (например, принятие на себя обязательств) мероприятий и распределить риск, собрав большое количество запросов и дав обещания только об общей производительности в форме доли работ в процентах, завершенных в срок. Не пообещав то, что вряд ли сможем выполнить, мы не рискуем потерять доверие потребителей. Таким образом, важно донести до клиентов, что целевое время выполнения для стандартного класса обслуживания – это именно цель!

Чтобы определить целевое время выполнения, следует опираться на предыдущие данные. Если их нет, то постарайтесь сделать предположение, близкое к истине. После этого внесите сроки выполнения (от изначального выбора до релиза) в статистический пакет управления процессами или инструмент отслеживания в канбане, который поддерживает статистическое управление процессами (например, Silver Catalyst), и установите верхнюю контрольную отметку (граница плюс 3-сигма) в качестве целевого времени выполнения. Так вы получите оптимальное время, в которое наверняка сможете уложиться в обычных условиях, а задержки связаны только с реальными проблемами, возникающими из-за систематических погрешностей (подробнее об этом – в ).

Если предыдущий абзац показался вам трудным для понимания, то можно сформулировать иначе: необходимо, чтобы время выполнения было достижимым, но при этом планка должна быть задана достаточно агрессивно для сохранения командой концентрации. Скорее всего, ваши рабочие единицы будут отличаться по размерам, сложности, риску и уровню требуемой компетенции. Разным будет и время выполнения. Это совершенно нормально. Если, проведя анализ предыдущих данных, вы видите, что около 70 % заданий выполняется в течение 28 дней, а оставшиеся 30 % растягиваются еще на 100 дней, то вполне разумно сделать целевым временем именно 28 дней.

По опыту знаю, что использование классов обслуживания – это очень мощная техника. В 2007 году примерно 30 % всех запросов моей команды выполнялось позже целевого времени выполнения. Мы учитывали это в показателе «доля выполнения в срок». Он никогда не превышал 70. И несмотря на такое низкое соответствие дедлайнам, жалоб поступало очень мало. Причины очевидны: все важные элементы, сопряженные с высоким риском или большой ценностью, всегда выполнялись вовремя. Поэтому заказчики были уверены, что опаздывающие элементы будут готовы через 2–4 недели, поскольку релизы выходили регулярно.

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

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

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

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

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

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

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

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

На рис. 11.3 представлена канбан-система, общий WIP-лимит для которой равен 20. Классы обслуживания обозначены карточками четырех цветов. Белые карточки ускоренного класса не учитываются в общем WIP-лимите, но ограничены одним элементом за раз. Таким образом, они (если есть в наличии) вносят 5 %-ный вклад в общую мощность, доводя реальное количество незавершенных заданий до 21. В этом примере фиолетовые карточки для элементов с фиксированной датой поставки составляют 20 % от общего количества. Это значит, что на доске может быть только четыре фиолетовые карточки в один и тот же момент, однако присутствовать они могут в любом столбце. Желтые элементы стандартного класса составляют 50 % всей мощности, а остальные 30 % отведены зеленым элементам нематериального класса.

Рис. 11.3. Стена карточек, демонстрирующая распределение мощности по классам обслуживания

Сейчас, когда мы распределили мощность по разным классам обслуживания, деятельность по пополнению входящей очереди осложняется, поскольку надо учитывать доступную мощность для каждого класса. На рисунке видно, что есть место для одного элемента с фиксированной датой поставки и трех – нематериального класса. Это порождает множество вопросов. Что если у нас нет сейчас спроса на элемент с фиксированной датой поставки? Как быть? Возможно, заполнить свободное место элементом стандартного класса? Но нужно ли в таком случае переводить этот элемент в класс с фиксированной датой поставки? Или продолжать обрабатывать его как элемент стандартного класса? А не является ли все это нарушением правил распределения мощности?

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

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

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

Распределение мощности – это еще одна стратегия в канбан-системе. Если вы считаете, что распределение не соответствует спросу, то внесите в него изменения: поменяйте правила и соответствующие WIP-лимиты.

• Классы обслуживания – это удобный метод оптимизации удовлетворенности клиентов.

• Единицам работы должен быть приписан класс в соответствии с их важностью для бизнеса.

• Классы обслуживания должны получить четкое визуальное отображение: для этого можно использовать как карточки разных цветов, так и разные «плавательные дорожки» на стене карточек.

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

• Членам команд следует объяснить классы обслуживания и связанные с ними правила.

• Некоторые классы обслуживания должны иметь целевое время выполнения.

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

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

• Классы обслуживания меняют психологию клиентов.

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

• На каждый класс обслуживания должна выделяться мощность канбан-системы.

• Доля мощности, выделенной на каждый класс обслуживания, должна согласовываться со спросом.