Дэвид Андерсон - Канбан. Альтернативный путь в Agile
Класс обслуживания «фиксированная дата поставки»
В середине февраля 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 собиралась прекратить поддержку предыдущего продукта, и если не произвести обновление, то бизнес останется со старыми машинами и не поддерживаемыми больше операционными системами и соответствующей инфраструктурой. Если это слишком большой риск, то код необходимо обновить. Проблема замены платформы встречается довольно часто: команды разработки ПО сталкиваются с ней постоянно. Всегда есть желание сразу начать работу и вовремя ее завершить, но необходимость произвести обновления обычно отступает перед более срочными или важными задачами. Иными словами, замена платформы, которая обладает сравнительно низкими непосредственными издержками из-за отсрочки, отходит на второй план из-за заданий, отсрочка по которым ведет к более крупным и непосредственным издержкам.
Можно предложить класс обслуживания, который позволит быстро начинать такую работу, или ресурсы, чтобы убедиться, что задание завершено. Но гарантий по времени может и не быть. К тому же это как раз такая работа, которую легко отложить в сторону, если появляются более срочные задачи. Чтобы иметь резервы для обработки ускоренного запроса, должна быть работа с низкой стоимостью отсрочки, которая откладывается в сторону при поступлении ускоренного запроса. И этот резерв как раз обеспечивается элементами нематериального класса.
Правила для классов обслуживания
Визуализация, которую мы делаем на канбан-доске, должна давать возможность сразу определить класс обслуживания для задачи. Как уже говорилось, чаще всего используются либо карточки разных цветов, либо разные «плавательные дорожки» на стене карточек. Некоторые команды добавляют такие «украшения», как звездочки, прикрепленные к карточке. «Плавательная дорожка» для ускоренных запросов тоже встречается часто. Выбор визуализации классов обслуживания остается за вами. Цель – убедиться, что любой сотрудник в любой день может применить простые принципы расстановки приоритетов, связанных с классами обслуживания, чтобы принять качественное решение без надзора или вмешательства руководства.
Ниже приведены примеры правил расстановки приоритетов для четырех определенных ранее классов обслуживания. Разумеется, каждая реализация определения классов обслуживания уникальна и правила их использования будут отличаться от данных примеров. Представленные правила основаны на эмпирических свидетельствах и довольно точно отражают ситуации в реальных командах.
