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

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

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

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

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

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

Цель 7. Обеспечение прозрачности дизайна и работы системы

Когда я впервые начал использовать канбан-систему, я верил в необходимость прозрачности незавершенных процессов, пропускной способности и качества, поскольку понимал, что это создает доверие клиентов и руководства. Я обеспечивал прозрачность, демонстрируя, где именно в системе находится запрос, когда он может быть выполнен и каково его качество. Прозрачности добивались и в отношении производительности команды. Мне хотелось внушить клиентам уверенность в том, что мы работаем над их запросом, и объяснить, когда он может быть выполнен. К тому же я хотел разъяснить руководству наши методы работы и вызвать доверие к себе как к менеджеру и к моей команде как к крепкой профессиональной группе разработчиков.

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

Цель 8. Создание процесса, способствующего возникновению организации высокой степени зрелости

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

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