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

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

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

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

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

Выводы

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

• Канбан отделяет каденцию поставки как от времени выполнения, так и от каденции пополнения.

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

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

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

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

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

• Эффективность и каденцию можно увеличить, сосредоточившись на сокращении операционных и координационных расходов.

• Регулярные поставки порождают доверие.

• Задавая ожидания регулярных поставок и постоянно их оправдывая, вы формируете привычку.

• Планирование регулярных поставок снижает координационные издержки.

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

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

Глава 9

Формирование каденции пополнения

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

Координационные расходы на расстановку приоритетов

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

Шесть подразделений конкурировали за общие ресурсы, необходимые для внесения небольших изменений и обновлений. При первом представлении канбан-системы был рассмотрен кейс, направленный на возможность поставки частых, «тактических» релизов командой поддержки. Эта команда обеспечивала ограниченную деловую гибкость путем выпуска небольших, инкрементальных релизов, тогда как новые IT-проекты создавались в соответствии с традиционным процессом управления отдела руководства программой (PMO). Обоснование и авторизация каждого проекта в портфеле проходили в индивидуальном порядке. Команда поддержки была одобрена исполнительным комитетом, на нее выделили 10 % бюджета, что позволило взять еще пятерых сотрудников. Отдел получил название «команда быстрого реагирования» (КБР). Но оно оказалось неудачным, потому что реакция не была быстрой, а иногда вовсе отсутствовала, да и команды как таковой не было.

Создать новый отдел технического обслуживания из этих пяти человек не удалось. IT-системы Corbis были очень разными, многие из них требовали специализированных навыков. Функции аналитиков, разрабатывающих и уточняющих системные требования, давались специалистам особенно тяжело. Пять новых сотрудников примерно на равных выполняли все задачи команды поддержки, включая управление проектами, системный анализ, разработку, тестирование, управление конфигурациями и сборками. То есть никакой команды не существовало. Буква «К» в аббревиатуре КБР ничего не значила. А ведь это считалось отдельной задачей менеджмента – показать, что дополнительные 10 % ресурсов потрачены на работу по обслуживанию и поддержке, а не просто поглощены общими крупными проектами.

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

Чтобы сохранить целостность общей среды тестирования, которая использовалась при работе над всеми проектами, Corbis ввела правило, согласно которому только билд-инженеры могли переносить код из среды разработки в среду тестирования. Позднее оно изменилось, но в сентябре 2006 года для передачи кода в тестирование был необходим билд-инженер.

До введения Канбана расходы на координацию – согласование требований для релиза техподдержки – были чрезмерными. Менеджеру проекта Дайане Коломиец, а часто и ее руководителю, менеджеру группы проектов, нужно было собрать встречу с участием всех заинтересованных сторон – бизнес-аналитиков, представителей бизнеса, системных аналитиков, руководителей разработки, руководителей групп тестирования и билд-инженера, а иногда также менеджера по управлению конфигурациями, представителей служб поддержки и сопровождения. Такие совещания порой длились несколько часов и заканчивались безрезультатно: членам разных команд поручалось провести оценки и назначалась следующая встреча. Она нередко переходила в дискуссию о приоритетах и тоже завершалась ничем. В сентябре 2006 года, чтобы договориться об объеме релиза, выпуск и поставка которого занимали две недели, приходилось затрачивать те же две недели на бесконечные совещания. Из-за двухнедельных итераций в релиз включались только очень небольшие задачи, а многие потенциально прибыльные запросы игнорировались. Эти запросы перенаправлялись в основной проект, поэтому период внедрения составлял месяцы, а порой и годы. Система, использовавшаяся до канбан-системы, не предполагала ни быстроты, ни реагирования. Буквы «БР» в аббревиатуре КБР не имели смысла.

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

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

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

Формирование каденции расстановки приоритетов

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

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

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

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

Эффективность расстановки приоритетов

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

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

Операционные расходы на расстановку приоритетов

Чтобы обеспечить эффективность утренних совещаний, Дайана Коломиец в четверг или в пятницу направляла всем участникам электронные письма с информацией о том, сколько свободных мест в очереди ожидается в понедельник. Она просила их просмотреть бэклоги и выдвинуть кандидатов на эти освободившиеся места. Такая «домашняя работа» часто помогала подготовить аргументы в защиту своих задач. Работать с документами, обосновывающими выбор, мы начинали на понедельничном совещании. Чтобы поддержать свое предложение, кто-то готовил бизнес-кейс, а кто-то – презентацию. Другие начинали вербовать сторонников, которые бы выступили за их задачи. Вполне возможно, что одни члены совета по приоритетам приглашали других на обед, где договаривались о взаимной поддержке на предстоящем совещании. Появились закулисные переговоры: один участник соглашался поддержать предложение другого на этой неделе в обмен на то, что тот пролоббирует его интересы на следующей. Новые правила игры, в которой несколько организаций соперничали за общие ресурсы ГБР, привели к совершенно новому уровню сотрудничества.

Иногда представителей бизнеса беспокоило то, что запрос требовал слишком больших капиталовложений при внедрении, особенно в сравнении со своей ценностью, так что они просили команду аналитиков произвести оценку. Впоследствии сформулировали правила о классах сервиса: они помогали определить, стоит ли затевать оценку той или иной задачи. Подробнее об этом – в главе 11.

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

Увеличение эффективности для сокращения каденции расстановки приоритетов

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

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

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

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

Именно из-за координационных расходов такие agile-методы планирования эффективны только для небольших команд, сосредоточенных на единственной системе или линейке продуктов.

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

Расстановка приоритетов по мере необходимости или по запросу

Как уже говорилось в главе 4, в 2004 году Драгош Думитриу внедрил канбан-систему в своей команде инженерного обеспечения XIT в Microsoft. Соседями сверху по цепочке были четыре менеджера продукта, представлявшие несколько подразделений. Они собирали и расставляли в приоритетном порядке запросы на изменения примерно для 80 IT-систем, поддерживаемых XIT.

Когда мы с Драгошем разрабатывали канбан-систему для внедрения в XIT, мы спроектировали входящую очередь так, чтобы в нее помещалась по крайней мере неделя работы. Хотя все четыре бизнес-представителя и Драгош работали в Редмонде, в кампусе Microsoft, встречи по расстановке приоритетов проводились по телефону. Дело в том, что кампус Microsoft огромен, и номера заданий перевалили за сотню, хотя на самом деле зданий всего около сорока. Площадь кампуса – несколько квадратных километров, и между зданиями перемещаются на микроавтобусах или на Toyota Prius. Поэтому многие предпочитают проводить координационные совещания при помощи телефонных конференций, а не лично. Это отрицательно сказывается на уровне доверия и социального капитала среди сотрудников, но положительно – на эффективности.

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

Итак, правила корпоративной игры, по методу которой осуществлялась расстановка приоритетов в XIT, были простыми. Каждую неделю менеджеры продукта заполняли освободившиеся места во входящей очереди – обычно их было три. Каждый из них получал право выбора в соответствии с алгоритмом. Время выполнения в соответствии с соглашением об уровне обслуживания составляло 25 дней. Поэтому, получая возможность выбрать запрос изменения для дальнейшей разработки, они должны были спросить себя: «Какие из элементов своего бэклога я больше всего хотел бы видеть реализованными через 25 дней?» Установился простой и четкий порядок, в котором они получали право на выбор, – он зависел от уровня финансирования ими отдела.

Поскольку правила были действительно несложными, совещания заканчивались очень быстро. Вскоре стало ясно, что даже координационный конференц-звонок был не так уж необходим. Драгош сделал так, что база данных Microsoft Product Studio (предшественник Visual Studio Team System, Team Foundation Server) автоматически посылала ему электронное письмо при освобождении места в очереди. Он пересылал это письмо менеджерам продукта. Они быстро выясняли, чья сейчас очередь, и этот человек делал свой выбор. Обычно освободившееся место заполнялось в течение двух часов. Исключительно низкие координационные издержки наряду с небольшими операционными издержками, связанными с решением не производить оценку запросов изменений, а также довольно высокая зрелость рабочей команды позволили Microsoft XIT отказаться от регулярного проведения совещаний по расстановке приоритетов.

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

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

Выводы

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

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

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

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

• Правила, связанные с расстановкой приоритетов и информацией для принятия решений, в Канбане применительно к разработке ПО представляют собой правила корпоративной игры.

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

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

• Можно увеличить эффективность расстановки приоритетов и ее каденцию, сосредоточившись на снижении операционных и координационных расходов.

• Частые совещания по расстановке приоритетов укрепляют доверие.

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

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

Глава 10

Задание WIP-лимитов

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

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

Лимиты на рабочие задания

Драгош Думитриу в команде XIT в Microsoft решил, что разработчики и тестировщики не должны работать одновременно более чем над одним заданием. Никакой многозадачности. Объявление было сделано в одностороннем порядке, но, к счастью, не привело к проблемам с другими заинтересованными лицами. Это соответствовало текущим методам работы и индивидуальному процессу разработки ПО (PSP), принятому в то время в команде. Организация обладала достаточной степенью зрелости, чтобы поддерживать дисциплину и следовать заранее установленным процедурам. Как уже упоминалось, осенью 2004 года в команде было три разработчика и три тестировщика. Таким образом, WIP-лимит на разработку и тестирование равнялся трем.

В 2006 году в Corbis, выступив с инициативой в области инженерного обеспечения, мы приняли такое же решение: аналитики, разработчики и тестировщики должны работать над одной задачей одновременно. Для новых крупных проектов мы принимали другие решения. Работа над ними предусматривала увеличение численности команды. Нередко над одной задачей трудились небольшие команды из двух-трех человек. Поскольку эти задачи могли блокироваться или откладываться, мы решили использовать переключение между задачами и дополнительную параллельность в работе, поэтому WIP-лимит был задан с таким расчетом, чтобы над единицей работали два-три человека, но допускалось некоторое перекрытие задач. Например, если у нас было десять человек и расчет «два человека на задачу», то WIP-лимит составил бы пять плюс еще немного, чтобы нивелировать возможный эффект от блокировки. В таких обстоятельствах подходящее значение лимита – 8 (5 + 3).

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

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

Лимиты на очереди

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

Например, очереди «Разработка» и «Готово к разработке» объединены, как показано на рис. 10.1. Если установлены действительно жесткие правила по WIP-лимитам, например строго один элемент на одного-двух человек или на небольшую команду, то необходимо организовать очередь, чтобы поддерживать рабочие задания и амортизировать вариативность. Когда ваша канбан-система на практике страдает от политики «остановка-запуск», которая вынуждает сотрудников к простою из-за того, что на выполнение заданий требуется разное время, стоит подумать об увеличении размеров очереди. Однако если вы сделали выбор в пользу, например, двух задач на одного-двух человек или на команду, то буфер для амортизации вариативности уже организован, так что размер очереди часто будет равен нулю. Просто объедините столбец рабочих задач с очередью.

Рис. 10.1. Стена карточек, демонстрирующая различные типы очередей и буфер

Буфер для бутылочного горлышка

Бутылочное горлышко в рабочем потоке может потребовать буфера перед ним, как показано на рис. 10.1. Это типичный механизм амортизации бутылочных горлышек, о чем будет рассказано в главе 16. Важен масштаб буфера – желательно, чтобы он был как можно меньше. Буферы и очереди вносят в систему незавершенные задачи, что увеличивает время выполнения. Однако буферы и очереди делают рабочий поток более равномерным, что улучшает предсказуемость времени выполнения. Тем самым они увеличивают пропускную способность, и канбан-система может обработать больше задач. Буферы также сохраняют более равномерную занятость людей. Необходим баланс, который и помогают поддерживать буферы. Во многих случаях приходится стремиться к деловой гибкости и более короткому времени выполнения, а также повышению качества, связанному с меньшим количеством незавершенных задач. Однако в погоне за гибкостью или качеством не стоит жертвовать предсказуемостью. Если размеры очереди и буфера слишком малы, так что ваша система страдает от политики «остановка-запуск», вызванной вариативностью, то время выполнения окажется непредсказуемым, а вариативность – огромной. Выбирая WIP-лимит для буфера, нужно иметь в виду, что он должен быть достаточно большим, чтобы обеспечить равномерный ход работы по системе и исключить простой перед бутылочными горлышками. Подробнее о масштабах буфера и о том, как создать буферы для бутылочных горлышек с ограниченной пропускной способностью и задержкой доступа элементов, мы расскажем в главе 16.

Размер входящей очереди

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

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

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

Какой должна быть входящая очередь, если вы используете расстановку приоритетов по запросу? Как уже упоминалось в главе 4, входящая очередь команды XIT состояла из пяти элементов. Она создавалась в расчете на то, что будет достаточно велика для амортизации недельной пропускной способности, исходя из того предположения, что совещания по приоритетам будут еженедельными. Однако вскоре менеджеры продукта пришли к выводу, что совещания не очень нужны, а решения можно принимать по ситуации, как только освобождается место в очереди. Когда это случилось, мне следовало посоветовать Драгошу сократить входящую очередь с пяти позиций до одной. Я этого не сделал по неопытности. Система изменилась. Основания, на которых она выстраивалась, – тоже. Правила о размерах входящей очереди были основаны именно на прежней системе, поэтому их нужно было пересмотреть. Если бы мы так и поступили, то сокращение времени выполнения оказалось бы еще более впечатляющим.

Когда в XIT переключились на расстановку приоритетов по запросу, пополнение очереди обычно занимало около двух часов на один элемент. Можно с уверенностью сказать, что на пополнение очереди никогда не уходило более четырех часов. Однако разработчики находились далеко от менеджеров продукта. Люди, принимавшие решения по приоритетам, сидели в Редмонде, а разработчики – в Хайдарабаде. Все они официально трудились по восемь часов в день, причем время работы у них чаще всего не совпадало. Поэтому нередкими были ситуации, когда сотрудники, жившие в Индии, утром приходили на работу, завершали задачи и ждали пополнения очереди, в то время как у менеджеров продукта в США продолжался сладкий ночной сон. Следовательно, нужно было учесть возможность 16-часового ожидания пополнения элемента очереди в критических обстоятельствах. Помните, что в этом рабочем процессе бутылочным горлышком были разработчики, и, чтобы максимально увеличить пропускную способность, мы совершенно не хотели их простоя. Поэтому нужно иметь запас прочности: 16 часов – это консервативное решение, учитывая, что в среднем решение по пополнению очереди занимает всего два часа. Итак, какова будет пропускная способность за эти 16 часов? На пике производительности команда реализовывала 56 элементов за квартал, то есть менее пяти в неделю. Так что маловероятно, чтобы за 16 часов они закончили бы хоть один элемент. Таким образом, очередь из одного элемента была вполне приемлемой. А вот отсутствие очереди неприемлемо. При этом сохранялась вероятность, что команда будет простаивать, когда они закончат работу за те 16 часов, пока менеджеры продукта будут недоступны для пополнения очереди.

Неограниченные разделы рабочего потока

В вытягивающей системе, связанной с теорией ограничений и известной как «барабан-буфер-канат», WIP-лимит всех рабочих станций после бутылочных горлышек не установлен. Это основано на предположении, что пропускная способность этих рабочих узлов выше, чем у бутылочных горлышек, так что они обладают резервной мощностью, что приводит к простою. Поэтому устанавливать WIP-лимит нет необходимости. Это отражено на рис. 10.2а, который основывается на метафоре, использованной в книге Элияху Голдратта и Джеффа Кокса «Цель: процесс непрерывного улучшения»[7] и показывает скаутский патруль, идущий змейкой. Между ведущим и самым медленным скаутом (четвертый в змейке) натянут канат. Самый медленный в змейке – это и есть бутылочное горлышко в пропускной способности (то есть в темпе хода скаутов). Необходим только один канат, поскольку скауты, идущие вслед за самым медленным из них, никогда от него не отстают, так как могут идти быстрее, чем четвертый в змейке, который снижает темп перемещения всего патруля.

Рис. 10.2. Человечки, иллюстрирующие четыре различных варианта WIP-лимитов в разных вытягивающих системах

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

В некоторых случаях в канбан-системе приемлемо отсутствие лимита на следующие этапы процесса. В примере Microsoft XIT было высказано предположение, что пользовательская база, доступная для проведения приемочного тестирования, практически бесконечна и доступна сразу же, поэтому для приемочного тестирования не нужны WIP-лимиты. В Corbis ограничения не касались очереди на подготовку к релизу. Это основывалось на предположении, что очередь на подготовку к релизу никогда не превысит пропускную способность при установленной двухнедельной каденции релиза. А если все же скапливался излишний материал для подготовки релиза, это повышало его сложность, так что координационные и операционные издержки на релиз слишком возрастали и пришлось бы установить WIP-лимиты и на этом этапе. Однако в Corbis такого не случалось, поэтому ограничения для данной фазы не устанавливались.

Не подвергайте организацию стрессу

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

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

Не устанавливать WIP-лимит – это ошибка

Хотя я советую быть сдержаннее при установлении изначальных WIP-лимитов, вовсе не устанавливать их – это ошибка.

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

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

Распределение мощности

Установив WIP-лимиты для всего рабочего потока в системе, можно задуматься о распределении мощности по типам единиц работы или классам обслуживания.

На рис. 10.3 изображена стена карточек из главы 6 с WIP-лимитами по столбцам – всего 20 карточек. Мощность распределена по типам работы: 60 % идет на запросы изменений, 10 % – на элементы поддержки и 30 % – на производственные текстовые изменения.

Рис. 10.3. Стена карточек с «плавательными дорожками» для каждого типа единиц работы с указанными для каждой дорожки WIP-лимитами

Это соответствует таким значениям WIP-лимитов для каждой «плавательной дорожки»: 12 для запросов изменений, 2 для элементов поддержки и 6 для производственных текстовых изменений.

Распределение мощности позволяет гарантировать обслуживание для каждого типа работы, введенного в канбан-систему, и должно производиться в соответствии с примерным спросом для каждого типа работы. Таким образом, чтобы разумно распределить WIP-лимиты для каждого типа работы по «плавательным дорожкам», важно провести некоторый анализ предъявляемых требований.

Выводы

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

• Возможно и одностороннее установление WIP-лимитов, однако позднее, когда система окажется под стрессом, эту позицию будет трудно защищать.

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

• Обычно лимит задается из расчета 1–3 единицы на 1–2 человек или на команду.

• Лимиты для очереди должны быть достаточно небольшими – обычно такими, чтобы амортизировать естественную (случайную) вариативность в размере элементов и длительности задач.

• Бутылочные горлышки нужно снабдить буфером.

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

• Все WIP-лимиты можно изменять эмпирически.

• Канбан – это эмпирический процесс.

• Не нужно тратить слишком много времени, пытаясь определить идеальный WIP-лимит; просто возьмите приблизительное значение и работайте. При необходимости внесете изменения позже.

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

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

• После установления WIP-лимитов распределяйте мощность по типам единиц работы.

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

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

Глава 11

Формирование соглашений об уровне обслуживания

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

Эта идея известна в сфере программного обеспечения и 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-сигма) в качестве целевого времени выполнения. Так вы получите оптимальное время, в которое наверняка сможете уложиться в обычных условиях, а задержки связаны только с реальными проблемами, возникающими из-за систематических погрешностей (подробнее об этом – в главе 19).

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

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

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

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

Назначение класса обслуживания

Страницы: «« 12345678 »»

Читать бесплатно другие книги:

Охватывает абсолютно все тонкости и нюансы российского налогообложения, не обходя стороной историю и...
Еще совсем недавно я был нищим малолетним беспризорником. Жил в подвале разрушенного дома, питался к...
Свою вторую книгу (после абсолютного бестселлера «Книга о теле») Кэмерон Диас посвятила поискам отве...
Международный синдикат зла нацелен помешать Китаю и России вдохнуть жизнь в экономику Евразии и Вост...
Если вы хотите окунуться во времена года, пройтись по лесу, промокнуть под тёплым июльским дождём, п...
В основу этого трехтомного издания положен текст гигантского компендиума «Чжоу И Чжэ Чжун» («Анализ ...