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

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

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

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

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

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

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

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

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