Канбан. Альтернативный путь в Agile - [63]

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

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

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

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

Цель 6. Упрощение расстановки приоритетов

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

В области разработки программ и управления проектами схемы расстановки приоритетов развиваются с начала появления программных проектов – уже примерно 50 лет. Большинство схем просты. Например, они классифицируют приоритеты как высокие, средние и низкие. Однако для бизнеса это не имеет значения. Несколько более сложные схемы стали использоваться после появления agile-методов разработки ПО – это, например, MoSCoW (Must have – «необходимо»; Should have – «стоило бы»; Could have – «может быть»; Won’t have – «не нужно»). Другие методы, например разработка на основе функционала, пользовались упрощенной и модифицированной техникой анализа Кано, популярной среди японских компаний. Кто-то продолжал защищать строгий нумерованный порядок (1, 2, 3, 4…) на основе коммерческой ценности или технического риска. Однако эта схема часто вызывает конфликт между элементами высокого риска, которые должны оказаться в первом ряду, и элементами высокой коммерческой ценности, которые тоже должны оказаться в первом ряду.

У всех этих схем есть один основной недостаток: в ответ на изменения, вызванные рынком или развитием событий, необходимо расставлять приоритеты заново. Представьте, что у вас есть бэклог с 400 требованиями по приоритетам, расставленными в порядке от 1 до 400, и вы выпускаете пошаговые релизы, используя один из agile-методов разработки с ежемесячными итерациями. Каждый месяц вам придется заново расставлять приоритеты в бэклоге едва ли не для всех 400 элементов.

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

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

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