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

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

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

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

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

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

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

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

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

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

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

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