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

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

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

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

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

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

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

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

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