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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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